About the optionality of the "kid" field in JWT-formatted VCs/VPs

[vdods]

https://www.w3.org/TR/vc-data-model/#jwt-encoding shows:

kid MAY be used if there are multiple keys associated with the issuer of the JWT. The key discovery is out of the scope of this specification. For example, the kid can refer to a key in a DID document, or can be the identifier of a key inside a JWKS.

I'd like some clarification on the optionality of the "kid" field. My guess is that VCs/VPs are trying to be generic regarding issuers/holders, allowing for URIs, which precludes the possibility of giving any more details about how the "kid" field should be used. Is that right?

I'm coming from a DID-centric ecosystem, and in that scenario it seems that there's no reason not to set the "kid" field on a JWT-formatted VC/VP to the DID fragment URL of the specific key used to sign. From w3c/vc-data-model#914 I understand that it would still be necessary to tie the "kid" to the "iss" field, but that seems fine.

As far as I can tell, if the "kid" field is missing, and assuming we're working with DIDs here, the process to resolve the signing key has to be:

• Identify the VC issuer / holder -- the "iss" field of the JWT. This should be a DID. (Question: Could this validly include query params such as versionTime?)
• Resolve the DID document for that DID.
• For each key with purpose "authentication", attempt to verify the VC/VP's signature using that key.
• If one of the keys verifies the signature, accept the VP/VC's signature as valid. Otherwise reject it as invalid.

To me, this seems sloppy, involving unnecessary complexity and computation, and making detecting errors in implementations harder. It also wouldn't scale if for whatever reason a DID had very many keys (inefficient at best, possible DoS at worst). Maybe I'm missing something here. Can anyone comment on this? Thanks.

[selfissued]

For what it's worth, while the OpenID Connect spec makes inclusion of the kid in ID Tokens optional when there is only one key in the issuer's JWK Set, for certification purposes, the working group decided to always require it to improve interoperation. I'd be in favor of also making kid required in this context for the same reason.

Do you agree with this suggestion, @Sakurann ?

[OR13]

Related: https://github.com/microsoft/scitt-ccf-ledger/pull/67/files

[Sakurann]

Yes, requiring kid in the header makes sense.

My question is, should kid be always mandated or only when iss is a DID?

For DID,, I think realistically, both relative and absolute DID URLs should be allowed, accompanied by a caveat that "relative DID URL is more recommended from a security perspective and implementations using absolute DID URLs should consider migrating to relative ones".

[OR13]

@Sakurann at this point, we are forced to define all paths....

• https://identity.foundation/jwt-vc-presentation-profile/

^ AFAIK, uses absolute did url.

the SCITT work uses relative did url...

So now we are going to need to define both...

[Sakurann]

PR #153

[BigBlueHat]

For DID,, I think realistically, both relative and absolute DID URLs should be allowed, accompanied by a caveat that "relative DID URL is more recommended from a security perspective and implementations using absolute DID URLs should consider migrating to relative ones".

Could this claim about relative URLs be expanded upon? What makes a relative URL more secure? The lack of context and inability to make the kid value retrievable?

[iherman]

The issue was discussed in a meeting on 2023-09-14

• no resolutions were taken

View the transcript

6.9. About the optionality of the "kid" field in JWT-formatted VCs/VPs (issue vc-jose-cose#31)

See github issue vc-jose-cose#31.

Michael Jones: looks similar to a previous issue, but this one is actually addressed by a PR.

Manu Sporny: agree with selfissued analysis of this issue and having a PR.

[selfissued]

This was addressed by PR #153