- From: Niels Klomp <nklomp@sphereon.com>
- Date: Wed, 5 Oct 2022 12:15:30 +0000
- To: Snorre Lothar von Gohren Edwin <snorre@diwala.io>, David Chadwick <david.chadwick@crosswordcybersecurity.com>
- CC: "public-credentials@w3.org" <public-credentials@w3.org>
- Message-ID: <AM9PR08MB71183706F248637875D0B106B65D9@AM9PR08MB7118.eurprd08.prod.outlook.com>
Let's not forget https://github.com/decentralized-identity/did-jwt-vc I think there are relatively few open-source libs, because all in all it is just using JWTs with a bit of encoding/decoding rules from the W3C VC Datamodel spec Kind regards, Met vriendelijke groet, Niels Klomp CTO [cid:0af814db-9ddc-4507-bca4-81ede014c887] Bisonspoor 8007 (Tower Berlin) 3605 LW Maarssen +31 (0)852 736513 Op woensdagmiddag niet aanwezig ________________________________ Van: Snorre Lothar von Gohren Edwin <snorre@diwala.io> Verzonden: woensdag 5 oktober 2022 14:11 Aan: David Chadwick <david.chadwick@crosswordcybersecurity.com> CC: public-credentials@w3.org <public-credentials@w3.org> Onderwerp: Re: A new VC-JWT Implementation 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? [https://mailfoogae.appspot.com/t?sender=ac25vcnJlQGRpd2FsYS5pbw%3D%3D&type=zerocontent&guid=84bb4574-1c1f-4507-a884-e8116882ba72]ᐧ On Wed, Oct 5, 2022 at 1:32 PM David Chadwick <david.chadwick@crosswordcybersecurity.com<mailto: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 ? [https://mailfoogae.appspot.com/t?sender=ac25vcnJlQGRpd2FsYS5pbw%3D%3D&type=zerocontent&guid=42a91edd-9681-42a3-9cc2-223ed8b12c45]ᐧ On Wed, Oct 5, 2022 at 12:12 PM David Chadwick <d.w.chadwick@truetrust.co.uk<mailto: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 [https://mailfoogae.appspot.com/t?sender=ac25vcnJlQGRpd2FsYS5pbw%3D%3D&type=zerocontent&guid=6234d549-d5f4-47a9-91a3-f59bb66e9702]ᐧ 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://drive.google.com/a/transmute.industries/uc?id=1hbftCJoB5KdeV_kzj4eeyS28V3zS9d9c&export=download]<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>
Attachments
- image/png attachment: Outlook-jchcol33.png
Received on Wednesday, 5 October 2022 12:15:48 UTC