- From: Snorre Lothar von Gohren Edwin <snorre@diwala.io>
- Date: Wed, 5 Oct 2022 14:57:04 +0200
- To: David Chadwick <david.chadwick@crosswordcybersecurity.com>
- Cc: public-credentials@w3.org
- Message-ID: <CAE8zwO3-x6vSAOv__UefSvewpJ_=rKt7W8OPLjG4WP8K_SG59Q@mail.gmail.com>
So JWT is not the case here 😅 Been using that for a while. I was primarily asking the combo of VCs and JWT. Just asking questions to the community here ᐧ On Wed, Oct 5, 2022 at 2:25 PM David Chadwick < david.chadwick@crosswordcybersecurity.com> wrote: > There are plenty of open source JWT libraries that do all the crypto for > you. Take a look at jwt.io > > Kind regards > > David > On 05/10/2022 13:11, Snorre Lothar von Gohren Edwin wrote: > > So I assume nothing open source, since you are listing things with no > links? > Should not a spec list possible implementations to broaden the ecosystem? > ᐧ > > On Wed, Oct 5, 2022 at 1:32 PM David Chadwick < > david.chadwick@crosswordcybersecurity.com> wrote: > >> This is a partial list of implementations that I know about: Microsoft, >> Ping, Spruce, Crossword, Transmute - but I am sure there are many more than >> this >> On 05/10/2022 11:25, Snorre Lothar von Gohren Edwin wrote: >> >> Where are they :D ? >> ᐧ >> >> On Wed, Oct 5, 2022 at 12:12 PM David Chadwick < >> d.w.chadwick@truetrust.co.uk> wrote: >> >>> >>> On 05/10/2022 09:20, Snorre Lothar von Gohren Edwin wrote: >>> >>> THanks for sharing and doing this work! >>> What will the next steps be? >>> This is the first implementation of VC spec using JWT? >>> >>> No there are a number that have been around for a few years, not >>> necessarily open source, but VC-JWT nevertheless >>> >>> Kind regards >>> >>> David >>> >>> ᐧ >>> >>> On Mon, Sep 26, 2022 at 11:05 PM Orie Steele <orie@transmute.industries> >>> <orie@transmute.industries> wrote: >>> >>>> Friends, >>>> >>>> I built this over the weekend: >>>> https://github.com/transmute-industries/verifiable-credentials >>>> >>>> It's an implementation of W3C Verifiable Credentials in the VC-JWT >>>> format. >>>> We have another implementation that supports both formats here: >>>> https://github.com/transmute-industries/verifiable-data/tree/main/packages/vc.js >>>> >>>> The new implementation benefited from a clean slate approach, and not >>>> needing to target multiple proof formats. >>>> >>>> It uses JSON Schema to manage conformance to the normative requirements. >>>> >>>> It uses JOSE to create Verifiable Credentials and Verifiable >>>> Presentations. >>>> >>>> It uses the "In addition to..." path... which means that it does not >>>> delete terms from the original credential which have been mapped to their >>>> JOSE cousins. >>>> >>>> For example: iss -> issuer.id (both are present). >>>> >>>> This means it is simpler than code that does that mapping and then >>>> deletes the "redundant" claims from the payload ... >>>> >>>> "the instead of path..."... which full disclosure, I think is a huge >>>> mistake, and should be made normatively illegal in v2. >>>> >>>> This makes the benefits of tapping the open world semantic data model >>>> powered by JSON-LD (or just JSON!!!!) much easier to leverage... >>>> >>>> See: >>>> >>>> - https://github.com/w3c/vc-jwt/issues/8#issuecomment-1258623846 >>>> >>>> - https://github.com/w3c/vc-jwt/issues/4#issuecomment-1258625828 >>>> >>>> After verification, you can import claims directly into either an RDF >>>> or LGP graph database... No "backwards transformation required". >>>> >>>> We've been experimenting with graph based interop between Data >>>> Integrity Proof VCs and VC-JWT... and this implementation is based on our >>>> learnings from those experiments. >>>> >>>> For examples, see: >>>> https://github.com/w3c/vc-data-model/issues/881#issuecomment-1160837859 >>>> >>>> TLDR: >>>> >>>> - use `@vocab` until you are a JSON-LD expert. >>>> - use `in addition too...` instead of the `instead of...` path. >>>> - use `kid` like you would use `proof.verificationMethod`... so you can >>>> easily resolve and then dereference the public key bytes needed to verify >>>> the signature. >>>> >>>> We've also includes a CLI: >>>> >>>> npm i -g @transmute/verifiable-credentials >>>> >>>> ❯ web5 >>>> web5 <command> >>>> >>>> Commands: >>>> web5 generate-key <alg> generate a key pair >>>> web5 generate-template <type> generate a template >>>> web5 credential:issue <jwk> <tmp> secure a verifiable >>>> credential with a private key >>>> web5 credential:verify <jwk> <vc> verify a verifiable >>>> credential with a public key >>>> web5 presentation:issue <jwk> <tmp> secure a verifiable >>>> presentation with a private key >>>> web5 presentation:verify <jwk> <vp> verify a verifiable >>>> presentation with a public key >>>> web5 dereference <didUrl> dereference a >>>> decentralized identifier url (with the universal resolver... this is how >>>> you get a public key...) >>>> >>>> Options: >>>> --help Show help >>>> [boolean] >>>> --version Show version number [boolean] >>>> -n, --nonce nonce >>>> >>>> Using the word "template" here as a synonym for a "credential"... (the >>>> thing without a proof, that gets a proof by being issued as a Verifiable >>>> Credential). >>>> >>>> I took a swing at handling "multiple subjects" by issuing "multiple >>>> credentials"... >>>> >>>> See: https://github.com/w3c/vc-jwt/issues/24 >>>> >>>> In case VC-JWT gets passing a `credential` with multiple subjects, >>>> which is legal per the core data model. >>>> >>>> There are several ways that mapping might be done.... and we would want >>>> to do a much better job of covering this part in the v2 spec. >>>> >>>> Overall the experience of doing an implementation from scratch was >>>> great... I think the v1.1 version of the spec, even with its worst parts, >>>> is trivial to implement. >>>> >>>> The main problems with the spec are the places where too much >>>> optionality is allowed, or where normative requirements are not worded >>>> carefully enough to complete issuance and verification with sufficient >>>> interoperability. >>>> >>>> Specifically how `iss`, `sub` and `kid` are treated... We don't provide >>>> sufficient guidance on how these are used to obtain verification >>>> material... that needs to be fixed in v2. >>>> >>>> Regards, >>>> >>>> OS >>>> >>>> >>>> -- >>>> *ORIE STEELE* >>>> Chief Technical Officer >>>> www.transmute.industries >>>> >>>> <https://www.transmute.industries> >>>> >>> >>> >>> -- >>> >>> *Snorre Lothar von Gohren Edwin * >>> Co-Founder & CTO, Diwala >>> +47 411 611 94 >>> www.diwala.io >>> <http://www.diwala.io/> >>> *Stay on top of Diwala news on social media! **Facebook >>> <https://www.facebook.com/diwalaorg>** / **LinkedIn >>> <https://www.linkedin.com/company/diwala>** / **Instagram >>> <https://www.instagram.com/diwala_/>** / **Twitter >>> <https://twitter.com/Diwala>* >>> >>> >> >> -- >> >> *Snorre Lothar von Gohren Edwin * >> Co-Founder & CTO, Diwala >> +47 411 611 94 >> www.diwala.io >> <http://www.diwala.io/> >> *Stay on top of Diwala news on social media! **Facebook >> <https://www.facebook.com/diwalaorg>** / **LinkedIn >> <https://www.linkedin.com/company/diwala>** / **Instagram >> <https://www.instagram.com/diwala_/>** / **Twitter >> <https://twitter.com/Diwala>* >> >> > > -- > > *Snorre Lothar von Gohren Edwin * > Co-Founder & CTO, Diwala > +47 411 611 94 > www.diwala.io > <http://www.diwala.io/> > *Stay on top of Diwala news on social media! **Facebook > <https://www.facebook.com/diwalaorg>** / **LinkedIn > <https://www.linkedin.com/company/diwala>** / **Instagram > <https://www.instagram.com/diwala_/>** / **Twitter > <https://twitter.com/Diwala>* > > -- *Snorre Lothar von Gohren Edwin* Co-Founder & CTO, Diwala +47 411 611 94 www.diwala.io <http://www.diwala.io/> *Stay on top of Diwala news on social media! **Facebook <https://www.facebook.com/diwalaorg>** / **LinkedIn <https://www.linkedin.com/company/diwala>** / **Instagram <https://www.instagram.com/diwala_/>** / **Twitter <https://twitter.com/Diwala>*
Received on Wednesday, 5 October 2022 12:57:30 UTC