cryptographic_binding_methods_supported feels under described

[jogu]

cryptographic_binding_methods_supported feels like it's probably a bit under defined.

https://openid.github.io/OpenID4VCI/openid-4-verifiable-credential-issuance-wg-draft.html#section-11.2.3 says:

cryptographic_binding_methods_supported: OPTIONAL. Array of case sensitive strings that identify the representation of the cryptographic key material that the issued Credential is bound to, as defined in Section 7.1. Support for keys in JWK format [RFC7517] is indicated by the value jwk. Support for keys expressed as a COSE Key object [RFC8152] (for example, used in [ISO.18013-5]) is indicated by the value cose_key. When the Cryptographic Binding Method is a DID, valid values are a did: prefix followed by a method-name using a syntax as defined in Section 3.1 of [DID-Core], but without a :and method-specific-id. For example, support for the DID method with a method-name "example" would be represented by did:example.

which refers to section 7.1, but that sections doesn't mention cryptographic_binding_methods_supported.

I think an extra sentence like this might help, assuming this is correct:

The wallet uses a key type listed in cryptographic_binding_methods_supported in the proof.

[babisRoutis]

I find the definition of cryptographic_binding_methods_supported difficult to grasp.

Initially, I had the impression that it expresses the way/format the pub key can be represented in the proof.
But then, x5c was missing from the list of expected cryptographic binding methods (jwk, cose_key, did, did:xyz) and this was a problem since it is clearly described in the jwt proof as an option.

My current understanding is that it expresses the format that the pub key will be embedded inside the issued credential. At least this was interpretation of

Array of case sensitive strings that identify the representation of the cryptographic key material that the issued Credential is bound to

[TakahikoKawasaki]

The existence of completely different interpretations is evidence that the definition of cryptographics_binding_methods_supported is unclear. To be honest, I've been aware of this issue for a long time, but I remained silent until you raised this issue in java-oauth-server Issue 59.

Anyone with actual experience implementing a credential issuer knows for sure that the key format embedded in the key proof and the key format embedded in the verifiable credential do not necessarily have to be the same.