search

oauth-wg / oauth-sd-jwt-vc

draft-terbu-sd-jwt-vc
Creative Commons Zero v1.0 Universal
20 stars 12 forks source link

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

Closed TimoGlastra closed 1 week ago

TimoGlastra commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

The resolution described in #250 would address this.

decentralgabe commented 3 months ago

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 commented 3 months ago

I also believe that kid should be:

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

bc-pi commented 1 week ago

The resolution described in #250 would address this.

This issue then has been overcome by events.

I encourage interested parties and proponents of DID usage in this context -- which, despite any potential misunderstanding, remains permissible -- to work on specifying it in a manner and forum befitting its importance.

In #250 @kimdhamilton pointed to a recent initiative that might be relevant for those interested in contributing to DID method standardization: https://identity.foundation/publications/LOI-DIDMethodStandardization.pdf