-
Notifications
You must be signed in to change notification settings - Fork 19
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
Conversation
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 it as a first draft and added some general comments.
General question: The plan would be to describe the overall mechanism in an Appendix and reference in Credential Endpoint (additional parameter for a Credential Request) and in Credential Issuer Metadata (to signal this is required for specific credential configurations)?
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 one @paulbastian , I support and follow this work, thank you
Co-authored-by: Giuseppe De Marco <[email protected]>
Is it possible to add description to the PR what this PR does and which issues it touches upon? thank you |
@@ -2166,6 +2166,88 @@ The following is a non-normative example of a Credential Response containing a C | |||
|
|||
<{{examples/credential_response_sd_jwt_vc.txt}} | |||
|
|||
# Key Attestations {#keyattestation} | |||
|
|||
A key attestation is an interoperable, verifiable statement that provides evidence of the authenticity and security properties of a key and its storage component. Keys can be stored in various key storage components, which differ in their ability to protect the private key against extraction and duplication, as well as in the methods used for End-User authentication to unlock key operations. These key storage components may be software-based or hardware-based, and can be located on the same device as the Wallet, on external security tokens, or on remote services that enable cryptographic key operations. |
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 already have a definition of a key attestation here. could we simply point there? https://openid.github.io/OpenID4VCI/openid-4-verifiable-credential-issuance-wg-draft.html#section-12.1-4
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 big question to this PR is where in the request do I put this key attestation needs to be defined, no?
I had the same question as @Sakurann as to where to put the key attestation. Moreover, if one attestation contains a list of keys, how can we provide one PoP for each key, and how to figure out which PoP corresponds to which key in the keys array. |
Co-authored-by: Christian Bormann <[email protected]>
Co-authored-by: Christian Bormann <[email protected]>
Co-authored-by: Christian Bormann <[email protected]>
@c2bo and I feel somewhat confident with the current state of the PR and are looking for more feedback!
|
Some eyes especially on the possible values for |
Closes #355
Closes #368