Misallignment between did-core and this document

[kdenhartog]

In section 5.3 of the did-core specification it states:

It is RECOMMENDED that JWK kid values are set to the public key fingerprint [RFC7638]. It is RECOMMENDED that verification methods that use JWKs to represent their public keys utilize the value of kid as their fragment identifier.

However in this document option 1 seems to be in conflict with that statement.

If I remember correctly consensus was to go with option 1 so should we recommend to the DID WG that the kid statement is removed?

The intent here is for us to decide what makes sense and make sure did-core is in alignment with what we're recommending so that the two documents aren't in conflict with each other.

@OR13 do you remember if option 1 was what we decided on?

[OR13]

yes, on the wg call, we had consensus to recommend option 1.... we really need to rephrase it though... it should say:

1. kid MUST NOT be present in publicKeyJwk of a verificationMethod in a DID Document.
2. kid MUST be present in the header of a JWS.
3. It is RECOMMENDED that the value of kid in a JWS header match the id of a verificationMethod in a DID Document. (supports the statement made in did core / but on the JWS side).
4. kid MAY be present in the header of a JWE.
5. If kid is present in the header of a JWE It is RECOMMENDED that the value of kid match the id of a verificationMethod in a DID Document. (supports the statement made in did core / but on the JWE side... supports EDV data model today).

@kdenhartog can you take a stab at moving the markdown to spec text, in respec / IETF standards format?

We should make these recommendations clearer / more formal.... we have had enough review / consensus.

See this comment regarding the MAY for JWE... https://github.com/decentralized-identity/did-jose-extensions/issues/5#issuecomment-682597343

[oed]

Thanks for finding this @kdenhartog. What would be needed in order to have it change in did-core?

If kid is present in the header of a JWE It is RECOMMENDED that the value of kid match the id of a verificationMethod in a DID Document. (supports the statement made in did core / but on the JWE side... supports EDV data model today).

@OR13 This doesn't make sense to me. Wouldn't you want to have the kid match the id of a keyAgreement key? That seems like the only way to know which key to decrypt with. Am I missing something?

[OR13]

@oed thats true, but it also leaks the social graph associated with the cipher text.... we should not REQUIRE the social graph associated with a cipher-text to be revealed.... although in practice it might be common.

It remains possible to decrypt by possessing decryption keys... you don't need to be identified.

[oed]

@OR13 Not sure I follow. Why would setting kid to a key from keyAgreement leak more information than a key from verificationMethod?

Totally agree that kid on JWEs should be optional.

[OR13]

I meant for JWEs only.... keyAgreement is a verificationMethod.

[oed]

Ah, I see!

[letmaik]

Is this still being worked on? I checked the spec and it still recommends to use kid in the JWK.

[oed]

I don't know about JWK, but in this example a DID URL is used in the kid of a JWT: https://w3c.github.io/did-core/#example-37-verifiable-credential-as-decoded-jwt

[kdenhartog]

Is this still being worked on? I checked the spec and it still recommends to use kid in the JWK.

Ahh shucks I'm not sure any of us got around to updating that in the did spec. @OR13 do you remember the reason we wanted to not put it in the DID Document JWKs?

[OR13]

i think the reason was to avoid potential ambiguity regarding these to string identifiers:

1. controller#kid -> verificationMethod
2. kid -> verificationMethod.publicKeyJwk

then when making a JWS, per the RFC, kid can be anything.... so depending on what you choose, dereferencers would have to handle both cases...