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 #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.

[David-Chadwick]

I think this issue should be moved to
https://github.com/w3c/vc-jwt/issues
as this is specifically about jwt encodings.

[vdods]

Moved to: w3c/vc-jose-cose#31