Relationship between `cryptographic_binding_methods_supported` values and key proof header parameters is undefined

Summary

cryptographic_binding_methods_supported describes the representation of the key
material the issued Credential is bound to. proof_types_supported describes how
the Wallet proves possession. Since draft 16 the two are coupled at the presence
level — proof_types_supported must be present if
cryptographic_binding_methods_supported is present — but there is no normative
mapping between their values.

A Wallet has no defined way to select a binding method, and an Issuer has no
defined way to reject the wrong one distinguishably.

Concrete problems

1. cose_key is not selectable. With cwt removed as a key proof format in
1.0 Final, no remaining proof type carries a COSE_Key. An Issuer advertising
cose_key (the natural value for an ISO mdoc configuration, given
DeviceKeyInfo.DeviceKey) advertises something no Wallet can express in a proof.
In practice Issuers accept a jwk header and convert — but that behaviour is
unspecified, so a Wallet cannot know whether to attempt it.

2. Selection is implicit and conventional, not normative. Implementations read
the Wallet's choice from which of kid / jwk / x5c is populated in the proof
JWT header. The only normative text linking the layers covers the DID case
(kid as a DID URL). There is no stated rule that the header form must correspond
to an advertised binding method, nor a table mapping values to header parameters.

3. Mismatch is not diagnosable. A Wallet that sends jwk where the Issuer only
supports did:key receives invalid_proof — the same code as a stale c_nonce,
a bad signature, or a malformed JWT. The Wallet cannot recover by retrying with a
different representation because it cannot tell that representation was the problem.

Possible directions

• Add a normative mapping from binding method values to the proof header parameter
  that selects them, and state that the header form MUST correspond to an
  advertised value.
• Alternatively, state explicitly that the parameter is informational — that the
  Issuer determines the binding representation from the Credential Format — and
  that Wallets MUST NOT use it for proof construction.
• Either way: clarify cose_key's status now that no COSE-based proof exists, and
  consider a distinct error code (or an error_description convention) for
  binding-representation mismatch.

I have no preference between the first two — but the current state, where the field
looks selectable and is treated as selectable by implementers without normative
backing, seems the worst of the three.

Raised on behalf of Inji

Start with the definitions of cryptographic_binding_methods_supported and proof_types_supported, then trace the proof JWT header parameters kid, jwk, and x5c and the DID case. Resolve whether values are normative selectors or informational, then clarify cose_key and how binding-representation mismatches should be reported in the relevant normative text.