Closed TallTed closed 1 year ago
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?
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.
In general, specs like ours are supposed to resolve this... similar to how data integrity proofs do today... and oidc does today...
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)?
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.
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?
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:
, and at worst could lead to a DoS attack where a DID intentionally lists many keys. Signature verification is more computationally costly than signing.
(btw this issue is being referenced in the spec three times :D)
The issue was discussed in a meeting on 2023-09-14
This issue can't be closed until https://github.com/w3c/vc-jose-cose/pull/153#issuecomment-1723406924 is addressed.
I took a stab at this, see #163 please help us close this.
Closing this, since addressed by the PR.
_Originally posted by @TallTed in https://github.com/w3c/vc-jwt/pull/111#discussion_r1244392502_
line 377 says (and another line says the same) --
-- in response to which I ask --