Requirement around key_attestations_required with attestation proof type is not clear
Nobody has claimed this yet.
- Dominant language
- No language data
- Stars
- 125
- Forks
- 41
- PR merge metrics
- No merged PRs in 30d
Description
Current text says:
key_attestations_required: OPTIONAL. Object that describes the requirement for key attestations as described in Appendix D, which the Credential Issuer expects the Wallet to send within the proof(s) of the Credential Request. If the Credential Issuer does not require a key attestation, this parameter MUST NOT be present in the metadata.
Probably "within the proof(s)" should be "within or as the proof(s)" as I think it is intended to be able to use key_storage etc to set requirements for the attestation proof type, not just for attestations within the jwt proof type.
But also these two are semantically equivalent:
"proof_types_supported": {
"attestation": {
"proof_signing_alg_values_supported": [
"ES256"
],
"key_attestations_required": {
}
}
},
"proof_types_supported": {
"attestation": {
"proof_signing_alg_values_supported": [
"ES256"
],
}
},
(in that in both cases the wallet is required to send a key attestation)
and probably both are valid by my reading of the spec. It'd be useful to get other people's interpretations as otherwise we probably need to test both forms in the conformance tests.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the key_attestations_required text, Appendix D, and the proof_types_supported examples in the issue; then inspect the conformance tests mentioned. Resolve whether the requirement applies within or as proof(s), document whether an empty object and omission are equivalent, and give the specification or tests an explicit outcome.
Written by the indexing model from the issue text.
Assessment
- Domain
- documentation, testing-qa
- Issue type
- Documentation
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100