JWT-specific minutae: the dreaded `kid` question

[bumblefudge]

There is a mention of explicitly requiring a specific key to be used when using DIDs to address principals -- this reminds me of the VC-JWT discussions about the kid header prop (which has vexed JWT interop since the jump, i'm inferring), which some systems in OIDF use to disambiguate a principal with multiple keys, but not as a hard requirement, and not always in the same way... see for example VC-jwt#31

maybe this is not a footgun worth thinking about, but maybe it's worth making a MUST NOT if you feel the DID system handles the "multiple keys" issue well enough? Might be worth digging into this if #139 brings non-DIDs into the world of principals (since many non-DID addressing schemes can't use query strings to disambiguate between keys the way DIDs can)

[matheus23]

Hm. Just so I understand this correctly:

• There's no kid parameter in the JWT spec
• There's a kid parameter in the JWK spec
• The VC-JWT spec took inspiration from the JWK spec to allow for an optional kid parameter

I can't quite follow you here. Are you saying we should try to avoid specifying a kid? Or are you saying we should consider specifying this early?

We haven't discussed a kid parameter yet and AFAIK nobody has implemented support for something like that yet. Perhaps that's useful to some people? We've mostly been working with did:key so far, except for some did:ion, did:eth and did:pkh experiments. I think there's also at protocol using did:web.

Perhaps it's worth specifying a general "don't add off-spec features to your implementation that allow invalidating some UCANs that the spec otherwise wouldn't consider as invalid" requirement.

[bumblefudge]

I am not lobbying in any direction here, but rather trying to make useful my years of DID interop experience in the form of vague fretting!

I could be offbase here, but I believe the optional kid parameter in VC-JWT1.1 was added specifically as a patch to allow interop with OIDF servers/tooling, which uses kids extensively to allow an identifier that derefences to a single-key entity (like a did:key) to still allow a key-specific reference in contexts where all keys have to be referenced specifically. I.e., AFAIK, OIDF specs (or at least real-world convention) requires <keyholder>#<keyname> syntax all over the place, so when a situation necessitates a key to be presented as a JWK, a keyname has to be stuck somewhere, ergo kid. The further minutae about relative versus absolute keynames is also interesting, since the VC-JWT spec seems to be moving in an even more prescriptive direction to break absolute keyname referencing patterns for security reasons.

Presumably OIDC interop is not a design goal of this spec, but I gather that being able to interop with systems based on DIDs other than did:key is. This was not meant as an immediately actionable issue (i.e. I can't think of a thing to add or subtract to close it), rather as a tracking issue for a little-known depth charges lurking in the DID interop waters :D

Happy to discuss on a future call

[matheus23]

Happy to discuss on a future call

I'd gladly invite you to this month's community call tomorrow! :) https://lu.ma/ucan

[bumblefudge]

FWIW, here is a clearer example of how the specs retrofitting VC issuance and exchange onto OIDC tooling use kid to handle ephemeral keys and dereferencing of issuer keys ("even when the OP's discovery endpoint is unreachable" <> offline DID resolution?). May or may not be relevant to the did:mailto thought experiment/specification path as JWT-based prior art, or the broader questions of how to handle offline DIDs and non-DID URIs. NB @Gozala