A new VC-JWT Implementation

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>