Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add key attestations #389
base: main
Are you sure you want to change the base?
add key attestations #389
Changes from 38 commits
6da765e
876c29c
feced43
56e26fc
7c0baa3
a96b09b
f5db4bf
6e3a118
64878e0
1932f71
3c15c3c
ef84be4
bfa2a26
8a8dcfd
42de92f
1b98041
23c8762
7735e1c
05aa467
246e083
33612a3
4e6dc79
1f9e94b
1131416
f71e748
4b3c00d
c148e8c
4d803c0
f9cfdba
b004300
638cc52
3c6bb15
02aaaa9
0641305
5677f13
19b7815
e7c882e
00224dc
28f282b
0fc69ef
30f32fc
e71e851
996139e
799b9d3
d840dda
77fe221
e578c84
c20d7f9
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Given that the description of metadata here: https://github.com/openid/OpenID4VCI/pull/389/files#diff-1f424614b35a9899813079f1b1f6218631a2aedd993368ccb89bb81a9eda0289R1308 says
Is this sentence here valid
It reads to me that a Credential Issuer can decide to require attestations but not put it in the metadata, but maybe that is the goal.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you mean SHOULD -> MAY ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Justto clarify key attestations are completly optional, but if an Issuer wants them, the typical way in OAuth is to include the needs in the metadata, therefore we added such entries to the Credential Issuer metadata
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not qualified to have this conversations. :) I will try to explain In layman's terms the way I read this
The issuer medatada section says:
So my expectation here would be that if I read the metadata, don't find this object, i don't send an attestation as it is not required/expected -- but I think my expectation would be wrong because there is this sentence:
This one reads, for me at least, like "Issuer may choose to require the attestation but the exact way this requirement is communicated is not enforced" i.e. if I go to metadata and see that there is no
key_attestations_required
it could just mean that this expectation/requirement is defined elsewhere (other metadata, or using the mentioned out-of-band mechanisms like policy or interop profile).I would potentially just remove the sentence I mentioned above from the issuer metadata section and add a link to the attestation section where one can read that this object can be used to advertise attestation requirement but that the usage of this filed is not mandated for such a purpose and that one needs to consult the issuer's/ecosystem's documentation on whether the wallet must include it or not. Or maybe even not add a link.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
in JWT proof type, we only defined iat, and did not define exp, because we said it is up to the issuer's policy to decide how long to accept the proofs. why do we need exp here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the assurances about a key storage component and its keys usually have an expiration, see recommendations from BSI and NIST
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I would agree this is a bit different: The key attestation might not come from the wallet directly, but a third party (the wallet provider). The wallet provider should be able to signal (via expiration) how long such an expiration should be deemed valid.
I am wondering if there are there cases where we think it should be optional instead of required?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok to resolve?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i think it makes sense for pre-generated key attestations in jwt proof type - it can also be a signal when a wallet needs to ask wallet backend to re-generate the key attestation. but i think it makes less sense in key attestations in attestation proof type, that are generated fresh, with issuer-provided nonce.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thinking with security-by-design I would like to let everything expire
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe make it OPTIONAL?
There is a
status
claim defined below so I guess the attestation generated by the Wallet Provider could be revocable if it is meant to be long lived or it could use theexp
otherwise to limit the lifetime of the attestation.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Following the discussion, would this be acceptable for everyone?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wondering it this could be an JWKS (https://www.rfc-editor.org/rfc/rfc7517.html#section-5) instead of directly an array if JWK. Having an object here is an extra indirection however it is a standard representation and provides "extra space" to add more common properties to this set of keys.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Using JWKS would also allow a single top-level claims, with the extra properties being defined inside the JWKS (which allows for extensibility):
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thinking a bit more, a better design could be
attested_keys
attestation
.key_type
,user_authentication
and other future properties.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't this model also allows for key derivation scenarios (e.g. Hierarchical
Deterministic Keys), where instead of explicitly listing all the keys, the attestation contains some seed parameters for the key generation?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the proposal. JWKS make sense
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you prefer nesting and attested_keys is a JWKS, I'd prefer:
JWKS Parameters is an existing IANA Registry.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My reasoning is that this spec would contribute with a single parameter to the JWKS Parameters IANA register (e.g.
attestation
), which would be an object. The schema of this object and its extensibility would be own by this spec.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Brian expresses concerns about registering these parameters to IANA
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMO, if
attested_keys
is defined to be a JWKS object as defined in RFC 7517, then it is probably necessary to register included parameters with IANA. Currently, there is only one parameter registered in the IANA JWKS registry which iskeys
. To avoid name clashes, these additional ones have to be registered there as well.On the other hand, if we would just not define
attested_keys
as a JWKS but instead fully define it which would also require definingkeys
, then no IANA registration is needed.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One additional thing that Android native key attestation contains is the timeout that a user authentication remains valid. If the timeout is 0, user is required to authenticate for every key usage. Values greater than zero mean that a single user authentication allows key usage for the given number of seconds.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That sounds like an important detail to include in an attestation, but I wonder if there is a good way to abstract this into something that can also be used to express other things around user authentication. Basically something to convey the policies used for user_authentication?
We are not mentioning it right now, but there is also a big difference between allowing any fingerprint enrolled on a device (which would allow sharing) or a specific fingerprint (bound to a specific user).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since
user_authentication
is an array, we need to define how the elements compose. E.g. if the array containsmethod-1
andmethod-2
, does this mean that user authentication can be performed:method-1
ormethod-2
.method-1
andmethod-2
(e.g. biometric followed by PIN).I presume the intent is to have it be a disjunction but that isn't clear from the text.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We thought about it as an OR right now and adding new values for combinations like fingerprint AND pin. I think it would make sense to keep this rather simple for the first iteration and try to avoid more complex things like boolean operators.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
where is this claim name coming from..? and what are the potential values of the URNs..?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ISO/IEC 18045 is the most common way, we could have the initial values from the spec
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
that is not a freely available standard, and i would expect a push back relying on it? but if that is a starting point, pointing to it as a place where to find URNs would be kind.
but what does this claim name even stand for..?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
attack potential resistance - from my understanding it's basically a more refined way to define what level of security a system can achieve and what attack vectors it cannot prevent
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've asked experts to provide initial values for this, hope to add some initial values or to improve the text within the next days.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this object also used for proof type "attestation"? If so, this statement should be conditional.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you are correct. @c2bo did you add this text?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is from from your initial commit, but it seems I forgot to change it when introducing the second proof type. We should move this into the jwt proof type text imho.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Stupid comment, but this
kid
is a bit confusing for me here in this form, is this referring to a particular key from the attestation or is it just a random value for the sake of the example?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This jwt would be signed by the Wallet Backend or the key storage directly - it cannot be referring to a key from the attestation. But it might make sense to change it to x5c for the example to avoid confusion?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would just point out this thing if it makes sense.
https://openid.github.io/OpenID4VCI/openid-4-verifiable-credential-issuance-wg-draft.html#section-8.2-2.3.1 says:
Not sure if this will be in conflict because now credentials are not then bound to the key doing the proof or possession
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch! We probably need to adapt those lines describing proofs and proof a bit. We still get a proof that the wallet is in possession of the key(s), it just doesn't have to be a proof of possession.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Without any further information or references, I believe it is almost impossible for a reader to know what
Trusted Execution Environment
orSecure Element
mean. If they are supposed to refer to Android and iOS concepts, should we include explicit references or description.If the OpenID4VCI spec defines these identifiers then it also need to define its meaning in a usable way.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
agree, references are needed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The best reference I was able to find was section 3.3 of ISO 27071 (https://www.iso.org/obp/ui/en/#iso:std:iso-iec:27071:ed-1:v1:en) for the general descriptions and then reference ios (secure enclace) and android (strong box) directly?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As an additional question, what is meant with
secure_element
? Is that an abstraction to unify the Android and iOS concepts (secure_enclave
andstrong_box
)?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would say both secure enclave and strong box are subtypes of a secure element.
In general I would say, a secure element is a security chip/component that provides a secure platform that is capable of securely running applications and storing its confidential data (keys etc).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Trusted Execution Environments are isolated secured processing areas on a common purpose main processor running its own operating system.
Secure Elements usually refers to Common Criteria certified chips that use ISO7816 or ISO14443 from the smartcard industry.
I agree that we would use some references and further explanations for the key types
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i think there were specs for TEE in their own standards body, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know this is a rabbit hole but to be even more specific, Secure Elements themselves can also comply to different Common Criteria protection profiles which means they can have different characteristics, i.e., not all of them are equally secure, and some of them don't even comply to any since they didn't perform certification.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@awoie that's correct. That's why the
apr
claim is actually the most interesting one, but for some this is hard to measure and some people will not have the security background to know what it actually means, that's why I put key_storage_type and user_authentication as a more approachable/easy way to describe the key storage component