- From: Oliver Terbu <oliver.terbu@consensys.net>
- Date: Fri, 12 Jun 2020 13:12:41 +0200
- To: David Chadwick <D.W.Chadwick@kent.ac.uk>
- Cc: Dominic Wörner <dom.woe@gmail.com>, "public-credentials@w3.org" <public-credentials@w3.org>
- Message-ID: <CALu3yZ+Ogz=2=gVM02JbniSo6-3H8ASjCXU74LXf5R==5KQ9ZQ@mail.gmail.com>
Hi Dominic, As one of the authors of did-jwt, I can tell you that did-jwt does not use `kid` yet. That needs to be fixed. I would appreciate it if you could open an issue in the Github repo. Note, the library is also meant to be for general purpose and can be used for other things than VCs as well. In practice that has not been an issue yet as most DID Docs we used (did:ethr) didn't have more than one authoritative valid key at the same time. Certainly, the library can support other DID methods as well. I agree with what Orie said. We had a long discussion on the usage of `kid` with DID Docs and the interop with JOSE. As part of the DIF DID Auth WG I want to start to work on a spec for that to provide guidance. Please also keep in mind that the DID spec is not final yet and many libraries and DID methods (authors) have not incorporated all the recent changes. This will hopefully change soon as we have a global W3C standard for DIDs. This specifically applies to verification relationships (previously "proof purposes") such as "authentication", "assertionMethod" etc which came out of the LD Proof / LD Signatures work. Currently, there is the following convention: - VC issuance (and verification of the VC) -> refers to a key (or more general a verification method) from the "assertionMethod" section - VP / presentation (and verification of the VP) -> refers to a key (or more general a verification method) from the "authentication" section Thanks, Oliver On Wed, Jun 10, 2020 at 12:39 PM David Chadwick <D.W.Chadwick@kent.ac.uk> wrote: > Hi Dominic > > On 10/06/2020 10:15, Dominic Wörner wrote: > > Hello David, > > > > thank you for your response. I can follow your approach and I think it > > is sensible in many applications. > > > > However, this would imply that a verifier needs to be configured to > > not only trust specific issuers (in a broader sense), but with actual > > public keys. > > This is true. But Verifiers will always need to be configured with the > specific issuers they trust (and with the attributes they trust them to > issue). Using DIDs and DLTs does not solve that problem. They do however > solve the key rotation problem once you know which issuers to trust. But > they are not the only way of solving key rotation, and one might think > they are not the best way. There are already several well-known ways of > updating keys which have been in use for many years. > > Kind regards > > David > > > Rotating issuer keys would require to notify all verifiers about the > > key updates. From my understanding, this would be one of the > > advantages of using DIDs. > > > > Best, > > Dominic > > > > Am Mi., 10. Juni 2020 um 10:42 Uhr schrieb David Chadwick > > <D.W.Chadwick@kent.ac.uk <mailto:D.W.Chadwick@kent.ac.uk>>: > > > > Hi Dominic > > > > we dont believe you need DID documents in order to use JWT crypto to > > protect VCs. The JWT kid allows you to directly encode the public > > key so > > that the JWT is self contained and allows you to verify the > > signature of > > the JWT without any external lookups. Here is how we do it in a > > standards conformant way: > > > > We base64 encode the signer's public key using RFC 7517 Appendix A.1 > > > > > > The ‘kid’ is created according to RFC 7517 and comprises the > > algorithm > > id, and the public key parameters (for RSA this is the modulus,n, and > > the exponent,e, and for ECDSA this is the x and y co-ordinates of the > > base point). > > > > > > An example encoding for RS256 is: > > > > "n": "0vx7agoebGcQSuuPiLJXZptN9nndrQmbXEps2aiAFbWhM78LhWx > > > > 4cbbfAAtVT86zwu1RK7aPFFxuhDR1L6tSocBJECPebWKRXjBZCiFV4n3oknjhMs > > > > tn64tZ_2W-5JsGY4Hc5n9yBXArwl93lqt7RN5w6Cf0h4QyQ5v-65YGjQR0_FDW2 > > > > QvzqY368QQMicAtaSqzs8KJZgnYb9c7d0zgdAZHzu6qMQvRL5hajrn1n91CbOpbI > > > > SD08qNLyrdkt-bFTWhAI4vMQFh6WeZu0fM4lFd2NcRwr3XPksINHaQ-GxBniIqb > > > > w0Ls1jF44-csFCur-kEgU8awapJzKnqDKgw", > > > > "e":"AQAB", > > > > "alg":"RS256" > > > > And for EC256 is: > > > > "x":"MKBCTNIcKUSDii11ySs3526iDZ8AiTo7Tu6KPAqv7D4", > > > > "y":"4Etl6SRW2YiLUrN5vfvVHuhp7x8PxltmWWlbbM4IFyM", > > > > "alg":"ES256" > > > > This allows you to verify the signatures on both the VP and the > > VC. Note > > that it does not solve the trust issue. How you decide which > > issuers to > > trust is a separate issue and should be configured out of band. > > > > Kind regards > > > > David > > > > On 10/06/2020 08:30, Dominic Wörner wrote: > > > Thanks Orie for the detailed response. > > > > > > Could you try explain how you distinguish Vanilla JWS and > > VC-JWT? It > > > could be that my reply below is confused because I don't really > > > understand the terms you use. > > > > > > If I get the following; > > > If its a vanilla JWS (not a VC-JWT) check the JWS header for > > `kid`... > > > if its a VC-JWT, check the payload `iss` or `vc.iss`... figure out > > > which did is the issuer... resolve the issuer did... or `kid`. > > > Then you argue, one should not use the `kid` in the JWT header > > in the > > > case of VC-JWT. > > > Although the following is written in the VC-JWT Spec: > > > |kid|/MAY/ be used if there are multiple keys associated with the > > > issuer <https://www.w3.org/TR/vc-data-model/#dfn-issuers> of the > > JWT. > > > The key discovery is out of the scope of this specification. For > > > example, the |kid| can refer to a key in a DID document > > > > > < > https://www.w3.org/TR/vc-data-model/#dfn-decentralized-identifier-documents > >, > > > > > or can be the identifier of a key inside a JWKS. > > > > > > This approach is also used in the example of the domain linkage > > > credential at DIF: > > > > > > https://identity.foundation/.well-known/resources/did-configuration/#json-web-token-proof-format > > > > > > I don't get the following: > > > If its a VC-JWT, search assertionMethod for the public key to > verify > > > I thought assertionMethod is a term used by LD Signatures and don't > > > appear in VC-JWT ?! > > > > > > Thanks a lot! > > > > > > Best, > > > Dominic > > > > > > > > > Am Di., 9. Juni 2020 um 21:42 Uhr schrieb Orie Steele > > > <orie@transmute.industries>: > > > > > > There is no consensus on key resolution for JWT with VC Data > > > Model.... it's been a huge problem, and has been discussed many > > > times... We were finally able to add this language to did core, > > > which hints at a standard way of resolving a public key from > > a kid... > > > > > > It is RECOMMENDED that JWK kid values are set to the public key > > > fingerprint. It is RECOMMENDED that verification methods > > that use > > > JWKs to represent their public keys utilize the value of kid as > > > their fragment identifier. See the first key in EXAMPLE 15 > > for an > > > example of a public key with a compound key identifier. > > > > > > https://w3c.github.io/did-core/#example-15-various-public-keys > > > > > > however the value of kid in the JWS can either be > > > `did:example:123#kid` or `kid`... I strongly urge everyone > > to use > > > `did:example:123#kid` and not rely on an undocumented / non > > > standard combination of `iss` and `kid`... unlike JWT in > > OAuth... > > > there is no spec for doing what did-jwt does... consider > > also that > > > `iss` and `vc.issuer` might both be used, or only 1 might be > > > used... because VC-JWT says: > > > > > > For backward compatibility with JWT processors, the following > > > JWT-registered claim names MUST be used *instead of, or in > > > addition to*, their respective standard verifiable credential > > > counterparts > > > > > > So semi-safe verify JWS from a did logic logic based on > did-core > > > and vc-data-model today looks like this: > > > > > > If its a vanilla JWS (not a VC-JWT) check the JWS header for > > > `kid`... if its a VC-JWT, check the payload `iss` or > `vc.iss`... > > > figure out which did is the issuer... resolve the issuer > > did... or > > > `kid`. > > > > > > If its a vanilla JWS, search all the > > > https://w3c.github.io/did-core/#verification-relationships for the > > > public key to use to verify. > > > > > > If its a VC-JWT, search assertionMethod for the public key > > to verify > > > > > > If its a VP of a VC-JWT also encoded as a JWT, search > > > authentication for the key to verify... > > > > > > Someday, we will have this documented somewhere... and we > > can just > > > reference it... I think it's high time we updated the > > > vc-data-model to explain how to use VC-JWT correctly, and in > > > particular how to use JWS / JWE with DIDs... when the payload > IS > > > NOT a VC. > > > > > > OS > > > > > > On Tue, Jun 9, 2020 at 7:52 AM Dominic Wörner > > <dom.woe@gmail.com <mailto:dom.woe@gmail.com> > > > <mailto:dom.woe@gmail.com <mailto:dom.woe@gmail.com>>> wrote: > > > > > > Hi, > > > > > > We currently work with JWT VC because of the lack of proper > > > JSON-LD tooling in Java. > > > The iss property of VCs is a DID and I have a question > > on the > > > verification algorithm since it's not well defined in > > the data > > > model spec because it is out of scope. > > > > > > After reading the spec, we implemented the following > > approach: > > > > > > * Resolve issuer DID > > > * If kid in header then get pubkey with kid form did doc. > If > > > not found => abort > > > * If no kid in header then there must be only one public > key > > > > > > Now, I've looked at the code of > > > https://github.com/decentralized-identity/did-jwt > > > There the following approach is taken (if I'm correct) > > > > > > * Resolve issuer DID > > > * Get authenticators (pub keys referenced in authentication > > > array in DID doc) > > > * Try all authenticators. Fail only of none of the > > > authenticators work > > > > > > I don't think the library handles the usage of a kid in the > > > header. > > > > > > This leaves me with the question, is there consensus > > about the > > > approach taken in did jwt? ;) > > > * Public Keys to verify VCs, need to be referenced in the > > > authentication block of the DID doc > > > * It's not required to reference a specific key in the VC > if > > > there are multiple keys in the DID doc? > > > > > > I can see that the second point has some advantages. Given > I > > > have a DID doc with a single public key and I create a VC > > > without specifying the kid, I would invalidate the VC by > > > adding another key to the DID doc, if the verifier would > not > > > try all keys. > > > > > > Best, > > > Dominic > > > > > > > > > > > > -- > > > *ORIE STEELE* > > > Chief Technical Officer > > > www.transmute.industries > > > > > > <https://www.transmute.industries> > > > > > > >
Received on Friday, 12 June 2020 11:13:06 UTC