Accept or Dismiss the guidance provided by DIF on kid / iss

[OR13]

See https://github.com/decentralized-identity/did-jose-extensions/blob/master/options.md

^ this guidance is ancient, I believe we can do better.

cc @tplooker @selfissued @Sakurann @dwaite

[OR13]

See also decentralized-identity/jwt-vc-presentation-profile#44 (comment)

[David-Chadwick]

I vote for dismiss. There is no requirement for the issuer to be identified with a did, only with a URI. Issuers can be identified by https URLs where the domain name equals their name in an X.509 DV PKC. This allows an issuer to sign a JWT using a validated X.509 PKC

[OR13]

@David-Chadwick

There is no requirement for the issuer to be identified with a did

Agreed.

However, in the case the issuer IS a DID... we must provide better guidance, the current guidance is unusable... and its the number 1 question I get asked regarding JOSE and DIDs... I don't get asked this question regarding Data Integrity Proofs... because of documentLoaders and the existing conventions in JSON-LD.

[David-Chadwick]

I think that allowing DIDs (when there are over 100 of them) is the number 1 reason to make interoperability very difficult. If we want to allow DIDs then we could reduce the preferred number to just one or two such as did:jwk (which fits nicely with the JWK model) or possibly did:web (which is an alternative to https://). Whilst JWS allows an infinite number of crypto algorithms it requires only a couple to be implemented to ensure interop. So we could do a similar thing in the vc-jwt spec

[OR13]

I think that allowing DIDs (when there are over 100 of them) is the number 1 reason to make interoperability very difficult.

I don't agree, but even if I did, this isn't relevant to the point.

If someone wants to use DIDs they need clear guidance, on how the parameters in a JWS are related to the the DID and DID URL.

[selfissued]

The guidance at https://github.com/decentralized-identity/did-jose-extensions/blob/master/options.md is pretty weird - starting with "kid MUST NOT be present in JWKs and MUST be present in JWA/JWE.". The "kid" is how you identify what key it is! By comparison, that conformant OpenID Connect implementations require the use of "kid".

What do the green checkmarks and red Xs signify in the guidance? I currently am not sure how to interpret it.

Does "kid value in JWA/JWE" actually mean "kid value in JWS/JWE"? (JWA is an algorithms spec - not a data structure.)

Clearly we want to allow "iss" values other than DIDs/DID URLs.

"JCS vs Stringify" - huh?

etc.

Maybe we should discuss this on a call, because I'm pretty confused.

[OR13]

@selfissued this document was created as a stop gap for how unusable the vcdm 1.1 guidance on JWTs with DIDs was.

The intention was to eliminate some of the ambiguity, to help with JWT interop with DIDs, but its at DIF, so is has basically no official standing.

Does "kid value in JWA/JWE" actually mean "kid value in JWS/JWE"? (JWA is an algorithms spec - not a data structure.)

Yes, it means "kid value in JWS/JWE".

Clearly we want to allow "iss" values other than DIDs/DID URLs.

Clearly, but THIS guidance was specific to DIDs, see the repo name.

"JCS vs Stringify" - huh?

Cryptographic operations like hashing and signing need the data to be
expressed in an invariant format so that the operations are reliably
repeatable. One way to address this is to create a canonical
representation of the data. Canonicalization also permits data to be
exchanged in its original form on the "wire" while cryptographic
operations performed on the canonicalized counterpart of the data in
the producer and consumer endpoints generate consistent results.

https://datatracker.ietf.org/doc/html/rfc8785

Sidetree... which is what Verified ID uses for DID ION, Bitcoin based decentralized identifier method...

See https://www.microsoft.com/en-us/security/business/identity-access/microsoft-entra-verified-id

Uses JCS because it requires a commitment to a JWK, which has no canonical form.

This guidance was place here, to explain more of why Microsoft chose to use JCS in development of Sidetree.

[selfissued]

Actually, a canonical representation of JWKs is defined by https://www.rfc-editor.org/rfc/rfc7638#section-3 .

@Sakurann , any suggestions on next steps for this issue?

[OR13]

Actually, a canonical representation of JWKs is defined by https://www.rfc-editor.org/rfc/rfc7638#section-3 .

I remember begging to use it.... : )

Its not a "content addressable" canonical representation... and we were already using mulithash elsewhere...

Other DID Methods I have seen to use the thumbprint RFC, and I think its wise to try to, as much as possible for identifying specific keys.

[Sakurann]

my personal opinion would be that we need to add guidance that when iss is a DID, kid must be present.
than we need to face a question whether it is absolute or relative kid URL. we could mandate a relative DID url and explain why it must be a relative DID url security wise, but it should be acknowledged that there are quite some implementations that use absolute DID url and they do not have any guidance either, for example that DID in iss and kid must match.

[OR13]

Related: https://github.com/microsoft/VerifiableCredentials-Verification-SDK-Typescript/blob/master/tests/TokenGenerator.ts#L59

[OR13]

Another argument in favor of dismissing the advice for signatures and retaining it for encryptions:

microsoft/scitt-ccf-ledger#22 (comment)

[OR13]

I suggest we add information text to vc-jwt regarding the use of kid and iss in JWS, JWT and kid in JWE.

Something like:

When using JOSE with DIDs, its can be beneficial to leverage both absolute and relative DID URLs for example:

Encryption example

{
    "protected": "eyJlbmMiOiJYQzIwUCJ9",
    "recipients": [
      {
        "header": {
          "kid": "did:example:123#key-0",
          "alg": "ECDH-ES+A256KW",
          "epk": {
            "kty": "OKP",
            "crv": "X25519",
            "x": "17sQFStg7ORPTq20OtU_MOzdzOU9iJAbqMP4cYVmUR0"
          },
          "apu": "17sQFStg7ORPTq20OtU_MOzdzOU9iJAbqMP4cYVmUR0",
          "apv": "ZGlkOmtleT...eFFx"
        },
        "encrypted_key": "mtKsC05glLghX4s6LGva3Nr9A_l9SYVdQviB81HJRoiAfi0HfhkvnQ"
      }
    ],
    "iv": "IpYeFb6utO2J_Ii8R50d-O9ppiEOQZN2",
    "ciphertext": "ewKbg3EJ6Pm4dH1tGdXGkJO5rTiMbn-tnfDGSvyvdQHD7HeE9g",
    "tag": "QYakakAfhHJ0KRXM47_uRQ"
  }

Signature example

{
  "iss": "did:example:123",
  "kid": "#key-0",
  "alg": "ES256"
}

or

{
  "kid": "did:example:123#key-0",
  "alg": "ES256"
}

We don't recommend doing this:

{
  "iss": "did:example:123",
  "kid": "did:example:123#key-0",
  "alg": "ES256"
}

[OR13]

Related PR in data integrity:

https://github.com/w3c/vc-data-integrity/pull/75/files

Notice the language about how to get the public key... thats what we need.

[iherman]

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

• no resolutions were taken

View the transcript

4.2. Add support for DIDs (pr vc-jose-cose#144)

See github pull request vc-jose-cose#144.

Orie Steele: this PR was so that the document can refer to a did document signed by a controller.
… there was concern that duplication of text from data integrity could produce conflicts, but.
… on the other hand some did not like to refer to data integrity.
… we need to get the controller document language into the spec, otherwise the draft wont be ready for CR anytime soon.
… so please read the PR and get your comments in ASAP.

Ivan Herman: Orie does this text duplicate what is already in the DID specification?

Orie Steele: Its close but not a clean copy.
… text around rdf class,.
… and key materal.
… which is not in did core.
… you wont see our text on multikey and rdf classes in other specs.
… there is a lot of confusion about finding key material. This text is there to help resolve this.
… I am still concerned about the verifier determining relationship between subject and holder (??).

See github issue vc-jose-cose#30.

Orie Steele: verification relationships is part of did core. e.g. this key is used for signing, or key agreement etc.
… the same key might be used for multiple purposes. But if the key does not have its usage specified it can be used for anything.
… but where the usage is specified is one document away from where the key is used.
… e.g. can you verify a VC signed with an issuer's key usage only for authentication?
… the controller document will specify the key uses.

Oliver Terbu: are you now requiring these controller documents to always be needed?

Oliver Terbu: thank you.

Orie Steele: there is currently an issue on this topic. Should there be a well known endpoint for controller docs, but currently there is no specification saying how you get the key material.

Orie Steele: See this section on discovery key material without using a "controller" document: https://w3c.github.io/vc-jose-cose/#well-known-uris.

[Sakurann]

we could mandate relative kid in 2.0, though it is a breaking change.

[selfissued]

https://w3c.github.io/vc-jose-cose/#kid currently says:

If kid is present in the Protected Header, a verifier can use this parameter to obtain a JSON Web Key to use in the verification process.

It's not that kid gives you a key. It gives you an identifier used to select the right key.

I'll suggest that this be corrected in PR #153.

[Sakurann]

note to myself https://www.w3.org/TR/did-core/#did-syntax as a place that can be used as a guidance for PR

[BigBlueHat]

note to myself https://www.w3.org/TR/did-core/#did-syntax as a place that can be used as a guidance for PR

This section may be more useful: https://www.w3.org/TR/did-core/#did-url-dereferencing

[iherman]

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

• no resolutions were taken

View the transcript

6.8. Accept or Dismiss the guidance provided by DIF on kid / iss (issue vc-jose-cose#30)

See github issue vc-jose-cose#30.

Michael Jones: PR that clarifies kid is merged, this issue can be cosed.

Kristina Yasuda: this is the issue that talks about using vs absolute DID URLs. DIF was recommending something there.
� If we incorporate Joe's suggested language and close this issue after the PR is merged, then that means we've agreed consciously to do that.

Manu Sporny: need to understand better where these kid values exist.

Joe Andrieu: you could specify a base.

Dave Longley: -1 to using relative, just do absolute and avoid all the trouble.

Manu Sporny: in the controller documents? if we have relative kid value, that kid value will be interpreted might be wrong, because the base of the document lives in the domain. you will end up with an https value.
� give clear guidance when to use one over the other.

Andres Uribe: +1 to dlongley.

Benjamin Young: +1 it's unclear how the absolute URL of the document (on which the relative URL will be calculated) will actually be know and calculated against and (as manu's stated) will shift around based on retrieval...and completely lost when stored.

Manu Sporny: need to prevent interop issues.
� concerned that the way you are approaching kid and giving guidance is not looking at all places where kid can be used.
� -1 to choosing one over the other, but need clear guidance.

Brent Zundel: merging the PR does not close this issue.

Michael Jones: from cose/jose perspective kid is an opaque string.
� there might be profiles that give more guidance.
� but it is not role of this spec to give guidance.

Oliver Terbu: +1 mike.

Michael Jones: will make a comment on this.

Joe Andrieu: is there a way to say that the base is a DID.

Michael Jones: there is not standard that says what is the base.

Kristina Yasuda: two things happening. 1 PR clarifies how kid is used in general. There is a key that can be a key set where kid can pick one. 2 there can be a DID and within the DID Doc you use a kid to find a refernce in there.
� the second topic is: what is the key that is expressed when the kid is a DID. Mike's comment that kid is okay and opaque is true, but when used as a DID needs to be clarified more.

Manu Sporny: +1 to what kristina said. not talking about just a general kid properties. have very specific usage in controller documents - where it is ok and where it is not ok.
� when you are expressing information within a DID Doc. if you are expressing a key outside a DID Doc, using relative DID url is highly problematic.
�
� we need to be more specific here.
� please remove the has-PR label from this issue.

Michael Jones: we should not make a decision of the format of kid. if DID spec makes a decision, we should reference that, but let's not profile DID spec.

Manu Sporny: you said you are opposed to profiling DID spec, but you have another PR that does that.
� failing to provide this kind of guidance might result in rejection of the document.

Kristina Yasuda: question, is there a place where that guidance now sits? Where are the best practices for this?

Manu Sporny: Whent his has come up before I recall the JOSE space being opposed to defining it.
� I don't think it exists.

Manu Sporny: yes, what Joe said.

Benjamin Young: https://www.w3.org/TR/did-core/#did-syntax.

Joe Andrieu: DID Core references a spec.

Benjamin Young: https://www.w3.org/TR/did-core/#did-url-dereferencing.

[OR13]

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

[selfissued]

Closing this, since addressed by the PR.