how is kid to be useful to distinguish the specific key used?

[TallTed]

Originally posted by @TallTed in #111 (comment)

line 377 says (and another line says the same) --

If <code>kid</code> is also present, it is expected to be useful to distinguish the specific key used.

-- in response to which I ask --

how is kid to be useful to distinguish the specific key used? This cries out for an example, or a fair amount of additional prose.

[OR13]

https://datatracker.ietf.org/doc/html/rfc7515#section-4.1.4

   The "kid" (key ID) Header Parameter is a hint indicating which key
   was used to secure the JWS.  This parameter allows originators to
   explicitly signal a change of key to recipients.  The structure of
   the "kid" value is unspecified.  Its value MUST be a case-sensitive
   string.  Use of this Header Parameter is OPTIONAL.

   When used with a JWK, the "kid" value is used to match a JWK "kid"
   parameter value.

@TallTed how would you like this issue to be addressed?

[TallTed]

The best way I can see would be to reference the RFC section you quoted here. It doesn't provide much guidance on how kid can be used, but at least it makes clear that the lack of guidance is not our doing.

[OR13]

In general, specs like ours are supposed to resolve this... similar to how data integrity proofs do today... and oidc does today...

[TallTed]

In general, specs like ours are supposed to resolve this... similar to how data integrity proofs do today... and oidc does today...

OK, so, who's going to provide the guidance about kid that's now missing from both our spec and the JWS RFC, which guidance is what I was asking for, and which is what I hoped to find in the RFC to which you pointed me, without saying "this RFC doesn't help" (which begs the question of why you pointed me there at all)?

[OR13]

We are going to provide the guidance regarding our profile of JWT spec, just like how OIDF provided guidance regarding their profile of the JWT spec.

The guidance could be the same, or we can add additional instructions to support DIDs, as data integrity proof did with their retrieve verification material section.

[TallTed]

Which "we" is "going to provide the guidance regarding our profile of JWT spec"?

I guess you must mean the VC WG, of which some subset of participants must have the relevant knowledge required to provide this guidance... But which of us make up that subset?

[vdods]

I'd like to strongly recommend requiring the "kid" field when in the context of DIDs. In particular, when you sign using a public key attached to your DID, you should set the "kid" field to the DID fragment URL that specifies the specific key you used to sign. The "kid" field should include query params if appropriate (e.g. the hl param for content integrity protection, etc).

There is no reason not to require this, since you know what key you used when you signed, and in the case where the "kid" field is not set, verifying the signature involves trying every key listed by the DID for the appropriate key purpose. This is sloppy, inefficient, and makes detecting bugs in implementations harder.

Digital signature verification is more costly than signing. In a legitimate case where a DID has say 5 public keys for the relevant key purpose (say they have 5 devices each of whose pub keys are listed in the DID document), if the verifier had to try each of those 5 keys every time, the verification portion of your performance is 5x worse. At worst, a bad actor could create a DID having thousands of public keys in an attempt to DoS the service, and the system would need additional measures to prevent this.

Relevant links:

• About the optionality of the "kid" field in JWT-formatted VCs/VPs vc-data-model#951
• About the optionality of the "kid" field in JWT-formatted VCs/VPs #31

, and at worst could lead to a DoS attack where a DID intentionally lists many keys. Signature verification is more computationally costly than signing.

[Sakurann]

(btw this issue is being referenced in the spec three times :D)

[iherman]

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

• no resolutions were taken

View the transcript

6.14. how is kid to be useful to distinguish the specific key used? (issue vc-jose-cose#117)

See github issue vc-jose-cose#117.

Michael Jones: has PR.
� gets closed after the PR is merged.

Paul Dietrich: this issue asks to define that it is more than a hint.
� so the PR is not enough.

Kristina Yasuda: .

Brent Zundel: when writing the PR I realized there was an additional ask, so I tried to express that a kid isn't just a hint, but a hint for a hint, checking that wasn't enough?

Paul Dietrich: yes.

[OR13]

This issue can't be closed until #153 (comment) is addressed.

[OR13]

I took a stab at this, see #163 please help us close this.

[selfissued]

Closing this, since addressed by the PR.