Re: A new VC-JWT Implementation

THanks for sharing and doing this work!
What will the next steps be?
This is the first implementation of VC spec using JWT?
ᐧ

On Mon, Sep 26, 2022 at 11:05 PM Orie Steele <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>*