Ambiguity what should happen when no kid parameter is present in header when DID is used as iss value

[TimoGlastra]

The spec mentions that a kid is optional when the iss value is a DID. The same seems to be true when using JWT Issuer Metadata (although there it mentions it is RECOMMENDED at least). It doesn't describe however what should happen if no KID is present.

This has caused some interop issues with implementations not including a kid field when a DID is used when e.g. did:key or did:jwk is used as you can infer which key is meant. However this means you have to make exceptions for specific did methods instead of following a general pattern.

Is there a specific reason to make the kid optional if the iss value is a DID (and also similarly when JWT Issuer Metadata is used)? If a DID is used, it MUST be signed with a key in the did document right? And it also mentions that "If a recipient cannot validate that the public verification key corresponds to the iss value of the Issuer-signed JWT, the SD-JWT VC MUST be rejected."

So I don't see a very good reason here to make the usage of kid optional, as it results in ambiguity. If there is a good reason to make it optional, would it be possible to also add the RECOMMENDED to using a kid when iss is a DID, that way we can at least promote other implementation to always include a kid when using a DID.

[peacekeeper]

I agree that there should not be any DID method specific exceptions. Even though we know that did:key and did:jwk basically encode a single public key, there should not be any logic in this specification which assumes this for all DIDs. DIDs resolve to DID documents that can potentially contain several public keys, therefore it is necessary to identify the specific public key using a DID URL, not just a DID.

[bc-pi]

The resolution described in #250 would address this.

[decentralgabe]

In implementations of DIDs I have worked on, with JWTs, we have required that kid is always a fully-qualified key identifier such as did:example:abcd#key-1, where the iss would be did:example:abcd.

Handling all the variations of using fragments (#key-1, key-1, etc.) make things complex, so clearly requiring fully qualified key identifiers from DID Document Verification Methods is a simple choice.

[babisRoutis]

I also believe that kid should be:

• mandatory and perhaps most importantly
• a fully-qualified DID URL (as per @decentralgabe comment)

In addition, a check should be required to ensure that kid is a DID URL (sub-resource) of the DID in the iss claim.