Requirements for JWK in key attestation `attested_keys`

[jogu]

The exact fields present in a JWK is a frequent cause of interoperability problems.

We don't currently appear to have an language (in VCI or HAIP) that says whether kid, use, alg are required to be sent, so issuers & wallets are likely to make different assumption.

I'm not fully thought it through but in the general case people seem to like it when kid is present so we might want to at least mandate that in HAIP.

If we're not going to mandate it then it would probably be good to be clear that implementations need to tolerate kid being absent.

Whatever we do decide to say should probably apply to the jwk in the openid4vci-proof+jwt header.

[Sakurann]

WG discussion:

• problem statement understood. need to clarify. kid is probably the best option.
  • In VCI, elsewhere we are saying something like Each JWK in the set MUST have a kid (Key ID) parameter that uniquely identifies the key?

[c2bo]

I think we are fine not mandating anything for key attestation JWKs. We don't need x5c because we are not talking about trust here and we use kid in other places to do proper matching of keys used (e.g., encryption), but in this case we have the following cases:

• attestation proof type: no matching required
• JWT proof type with 1 key attestation per jwt proof: no matching required
• JWT proof type with 1 key attestation containing all keys: we can match with key contained in jwk (or x5c,kid if those are used to identify the key)

The wallet always matches with the public key contained in the credential anyway

-> There are cases where it might make sense to have a kid in the JWK inside key attestations, but that would basically be if you identify the public key in the jwt proof via kid as well (I think that is the case for dids?) --> imho let's not make it mandatory?

[paulbastian]

As I see it, JWK defines mandatory members and no implementation should expect any of the non-mandatory members, this is what we could reemphasize. If we mandate kid we should have good reasons.

[c2bo]

It might make sense to explicitly state that only implementations must be able to deal with kid not being present (I do believe I've seen implementations treating it as a mandatory field), but apart from that I would not change anything.

[jogu]

Consensus on today's WG call: Implementation must not break if optional fields are absent. Adding a note might be good but it would sit better in VCI. No immediate need to do anything before HAIP 1.0.