Re: A new VC-JWT Implementation

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>*

Received on Wednesday, 5 October 2022 10:25:46 UTC