You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Draft 15 intoruces the concept of "key attestation" as a way for the holder to provide evidence for the authenticity and security properties of a key and its storage component to the Credential Issuer.
Specificaly for proofs of possetion of type JWT the key attestation is used to prove that the key that signs the JWT is the one contained in the key attestation.
For this the following are needed
For credentials demanding key attestations issuer should reflect this in the respective credential configuration (include key_attestations_required in proof_types_supported). This can be defined as policy per supported crednetial in issuer's config properties.
If issuer demands key attestations in jwt proofs issuer must validate that proofs provided in the request include key attestation
Validate that the JWT proof provided in request is signed by the key contained in the key_attestation as specified in JWT proof's header.
Validate that the key attestation jwt is signed by someone it trusts. Spec mentions that key attestations can be signed by 'Wallet Provider or the Wallet's key storage component itself'. At the currest state we can assume that issuer has a list of certificates of trusted wallet providers against which the signature should be validated. It is unclear yet how 'Wallet's key storage component' should be trusted.
The Credential Issuer SHOULD issue a Credential for each cryptographic public key specified in the attested_keys claim within the key_attestation parameter
It is unclear how issuer should handle cases where multiple jwt proofs are included with the key attestations with overlaping keys (same key attestation included in multiple jwt proofs). It is also questinable if in the case of jwt proofs the key attestations should be used for key binding.
So for the time being and untill this is cleared up issuer should handle key attestations in JWT proof only as an evidence to validate the key singing the JWT proof.
The text was updated successfully, but these errors were encountered:
Draft 15 intoruces the concept of "key attestation" as a way for the holder to provide evidence for the authenticity and security properties of a key and its storage component to the Credential Issuer.
Specificaly for proofs of possetion of type JWT the key attestation is used to prove that the key that signs the JWT is the one contained in the key attestation.
For this the following are needed
key_attestations_required
inproof_types_supported
). This can be defined as policy per supported crednetial in issuer's config properties.key_attestation
as specified in JWT proof's header.Imlementation Considerations
For jwt Proof Type spec mentions the following
It is unclear how issuer should handle cases where multiple jwt proofs are included with the key attestations with overlaping keys (same key attestation included in multiple jwt proofs). It is also questinable if in the case of jwt proofs the key attestations should be used for key binding.
So for the time being and untill this is cleared up issuer should handle key attestations in JWT proof only as an evidence to validate the key singing the JWT proof.
The text was updated successfully, but these errors were encountered: