[OID4VCI] CWT proof requirements

[Takahiko Kawasaki]

Regarding the proof in a credential request defined in OID4VCI. The "Proof Types" section in the current snapshot of the specification lists JWT proof requirements and CWT proof requirements as follows.

JWT proof requirements:

• typ
• alg
• kid
• jwk
• x5c
• iss
• aud
• iat
• nonce

CWT proof requirements:

• Label 1 (alg)
• Label 3 (content type)
• Label COSE_Key
• Label 33 (x5chain)
• Claim Key 3 (aud)
• Claim Key 6 (iat)
• Claim Key 10 (Nonce)

The CWT proof does not have requirements that correspond to kid and iss requirements for the JWT proof. Is this difference intentional?

[Torsten Lodderstedt]

Thanks for raising this issue. I’m not an CWT expert but here are my thoughts:

• iss (Claim Key 1) should be added
• kid (Label 4) could also be added. However, I’m not sure the kid makes a lot of sense for a proof of possession. I would assume it makes sense of the proof is signed with a key associated with a DID. In all other cases, I would assume the key is kept by the sender and cannot be discovered using a key distribution mechanism, like jwks_uri. That holds true for JWT based proofs as well.

‌

[Takahiko Kawasaki]

If the value of kid is not a DID URL, the implementation of the credential issuer may try to search the JWK Set of the client for the key identified by the kid. This is possible when the access token presented at the credential endpoint is associated with a client. The JWK Set of the client can be (1) the value of the jwks client metadata, (2) the resource pointed to by the jwks_uri client metadata, or (3) the resource pointed to by the signed_jwks_uri client metadata (OIDC Federation).

[Torsten Lodderstedt]

The proof type is about prof of possession for key material controlled by the user(holder. I’m not sure we want to use client keys for this kind of proof of possession as this would mean a client could do proof of possession (and credential presentations) with the same key for different users. My feeling is the key will always be send with the request (with the only exception of DIDs),

[Takahiko Kawasaki]

@Torsten Lodderstedt Thank you. I confused the key of the holder with the key of the client application. But, maybe I’m not alone. User, Holder, Wallet, OAuth/OIDC Client, DID subject, DID controller are easily confused. Holder sometimes means User, sometimes means Wallet, … I should use the terms carefully. I’ll need to read specifications again carefully.

[Kristina Yasuda]

05182023 looks like we need to add these 2 claims

[Kristina Yasuda]

PR #523 for iss. (did not do for kid because did not look like there was an agreement)

[Kristina Yasuda]

PR merged. is there agreement not to add kid to a CWT proof type and close the issue? or do we want to keep this issue open and potentially add kid? (closing if no response in a week)

[Mark Haine]

Migrated to GitHub

https://github.com/openid/OpenID4VCI