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 2 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.
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