- From: Juan Caballero <juan.caballero@spherity.com>
- Date: Wed, 5 Oct 2022 14:59:49 +0200
- To: public-credentials@w3.org
- Message-ID: <34052b93-e390-18f7-1465-b852ca8ef809@spherity.com>
See also: https://identity.foundation/JWS-Test-Suite/ On 10/5/2022 2:25 PM, David Chadwick 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> >>>> <mailto: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 <http://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 <http://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/> >>>> <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/> >>> <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/> >> <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>/ -- ----------------- Juan Caballero Research Advisor, Spherity <https://www.spherity.com> GmbH, Emil-Figge-Straße 80, 44227 Dortmund Co-chair, DIF Healthcare Use-cases Discussion Group <https://www.eventbrite.com/o/dif-healthcare-special-interest-group-31363301995> and DIF Interoperability Working Group <https://github.com/decentralized-identity/interoperability/blob/master/agenda.md> Berlin-based: +49 1573 5994525
Received on Wednesday, 5 October 2022 13:00:06 UTC