Re: JSON-LD vs JWT for VC

On 10/24/2018 08:10 PM, Pelle Braendgaard wrote:
> We had a session at IIW trying to figure out what the primary 
> problems/benefits are with JSON-LD and JWT. While this was a general 
> conversation it was seen in the context of W3C Verifiable 
> Credentials.

Was there anyone from the W3C JSON-LD Working Group, or implementers
that have committed to using JSON-LD in the room when you had this
conversation? The reason I ask is because the meeting seems to have
happened without experts in the room from the JSON-LD community, which
is not optimal.

All that said, I'm going to try to focus on how we can collaborate to
build a healthy ecosystem as all of our companies build solutions for
this ecosystem. While some of us are taking different technological
paths to get there, in the end, we all want the same outcome. So, let's
try to figure out how to help one another to get there.

> JSON-LD Pros: - Semantics - Graph - Human Readable

+1 - yes. There are also other guidance/benefits here:

https://docs.google.com/document/d/1tDX6LXJn6KITKIvNbbexHfcdWZ9z9TCElC5cZygaacw/edit

and here:

https://www.w3.org/TR/json-ld/#design-goals-and-rationale

As for the cons, I'm interested in hearing what came out of IIW (as we
have heard these cons before, but everyone has a slightly different
reason... sometimes misguided, but sometimes very pertinent... and
sometimes you learn something new from a concern being phrased in a
slightly different way).

> Cons: - Difficult to integrity/canonicalization of graph for signing
>  purposes

What reasons were given for it's difficulty? The reason I ask is that
this stuff is probably going to go W3C standards track in 2019, so we
need to understand the difficulties people are having with it.

> - Canonicalization requirement

Why is the requirement a problem? You could just shove the entire VC in
a JWT, but then you lose all the benefits of canonicalization (such as
syntax-agnostic signatures, ability to protect the entire message,
ability to add non-signature-destroying whitespace, compatibility with
schema.org, etc.).

> - Difficult to understand what is signed

Why is it difficult to understand this? The answer is: Everything.

Everything is always signed with Linked Data Signatures to avoid the
footgun that is JWT protected/unprotected fields.

> - Cognitive overload when understanding data

What specifically is the cognitive overload?

> - Lack of diversity in tooling

This is a real problem, yes... but keep in mind that we're still trying
to ensure that the technology is solid for DIDs and VCs, so people tend
to not put a tremendous amount of effort into tooling until a W3C
specification hits Candidate Recommendation. Those of us that are
shipping to customers today with JSON-LD, DIDs, and VCs are investing in
tooling (and making it open source so the rest of you can use it).

We realize this is a pain point, but the only thing that fixes it is
other people rolling up their sleeves, jumping in, and helping us build
the tools.

> - You have to really know what you do to verify a signed json-ld 
> document

Yes, also a problem, which tooling is intended to solve.

> Asks of JSON-LD community to make it useful for Verifiable 
> Credentials: - Better Tooling (automatically resolve DIDs and verify
>  signatures)

Yes, agreed. This came up at W3C TPAC as well and there is a renewed
commitment to build better tooling. Over the years we've dumped hundreds
of thousands of dollars into building open source tooling for the
community (and releasing it free for use to everyone).

We've asked the larger organizations that are financially benefiting
from this work to to put similar amounts in... it rarely ever happens.
Governments have been stepping in to help more recently because they
understand the positive effect on the global economy in supporting
standards.

That said, many of the open source developers are once again put in a
position where they're expected to build the tools for free. It'll
eventually happen, but money helps move these things along (non-profit
donation to Spec Ops). Let me know if your organization needs one of
these open source libraries and we can make it happen faster.

If there is no cash flow into improving tooling, then it'll happen in
time, but on the backs of open source developers that are doing this out
of the goodness of their hearts.

Digital Bazaar specifically is in the process of building tooling for
browser-based Javascript and Node.js to make signing and verification
easier.

> - Better documentation for specific use cases

Yes, agreed. What sort of documentation did folks in the room think the
community should be focusing on?

> - Middleware for various server implementations to automatically 
> verify signatures etc of json-ld requests

Hmm, JSON-LD signatures are typically at the application layer, although
I guess we could add some express-style middleware. Were there thoughts
on exactly what this middleware would do and how it should work?

> - Remove embedded schema

What does this mean? Not use @context at all? Or restrict it to URLs?

We have been kicking around the idea of being able to use VCs/DIDs w/o
passing it through a JSON-LD processor at all. So, there is interest.
We've also been trying to figure out if there is a way to eliminate the
canonicalization process.

In short, we're very interested in making JSON-LD disappear where it is
not needed. There are many use cases that we're dealing with and so
while a subset of them are possible with JWTs... not all of them are.
The challenge is figuring out how to aggressively chop away at the
solution we currently have for all use cases w/o leaving a subset of the
community behind.

> Asks of JWT community: - Help work on defining Verifiable Credentials
> using JWT

Yes, please. We've been asking for this help for a very long time now
with no takers. Keep in mind that we started out w/ JWTs many years ago
until the ecosystem requirements made it such that JWTs couldn't address
what the community needed. These requirements are roughly outlined here:

https://docs.google.com/document/d/1tDX6LXJn6KITKIvNbbexHfcdWZ9z9TCElC5cZygaacw/edit

I should also note that there was rough consensus to move towards COSE
for key expression formats and signature expression formats to close the
gap w/ the IETF and W3C communities.

> To be able to support JSON-LD signed VCs we need better tooling. The
>  JSON-LD community should invest time in this, to make it as easy as
>  being able to easily verify the data and understand what was
> signed.

Yes, agreed. I know that Digital Bazaar (and a few others) are investing
in open source tooling in the space. It was clear from W3C TPAC 2018
that this is a pain point currently, and with Verifiable Credentials
going into Candidate Recommendation, we'll start to see better tooling
in the space as the call for implementations goes out.

For example, active development on open source DID resolution library
for browser and node.js:

https://github.com/digitalbazaar/did-io/commits/development

Active development on open source Verifiable Credentials library for
browser and node.js is also happening since we're getting ready to go
into the implementation phase for the Verifiable Credentials
specification in the Working Group. We already have one implementation
that automatically looks up DIDs and verifies signatures that is passing
90%+ of the official test suite.

Next steps that we identified at W3C TPAC:

* Improve DID tooling around JSON-LD / canonicalization.
* Improve VC tooling around JSON-LD / canonicalization / DID resolution.
* Migrate all key and signature formats to COSE.

If large organizations would like to help accelerate this work by
funding it, there is a route for doing so. Get in contact with me if you
are interested, and I'll put you in touch with the appropriate people at
Spec Ops to make it happen.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Veres One Decentralized Identifier Blockchain Launches
https://tinyurl.com/veres-one-launches

Received on Monday, 29 October 2018 14:34:49 UTC