openid / openid/OpenID4VCI

Requirement around key_attestations_required with attestation proof type is not clear

Open
#679 3 comments 0 reactions 0 assignees View on GitHub

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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.