Re: JWT credentials

On 10/07/2018 01:19 AM, Pelle Braendgaard wrote:
> - library has no built in support for DIDs yet afaik . I’m sure it 
> can be manually wired up to support it

Hmm, different layer, JSON-LD isn't supposed to know about DIDs at
all... DIDs are at a higher layer in the stack.

That said, there are plans to extend JSON-LD to dereference DID-based
URLs. You do this via the JSON-LD document loader feature in most
implementations. The only thing that the JSON-LD library would need
support for would be dereferencing DID documents, which we have working
in a number of customer systems for Veres One. Some DID ledgers, such as
those that expose convenience endpoints via HTTP API URLs, are easier to
dereference than others.

I'll also note that JWT libraries don't have "built in" support for DIDs
either, because, again... that happens at a different layer. I'd expect
the same libraries to be useful both in JSON-LD and JWT ecosystems.

> - single JavaScript implementation

There are 10 implementations of JSON-LD:

https://json-ld.org/

... 8 (Java, Python, Ruby, PHP, C#, Go, Javascript, Erlang, etc.) of
them are nearly 100% conformant across 387 tests in the official test suite:

https://json-ld.org/test-suite/reports/#test-manifests

There is also a base C++ implementation in the works, which will enable
a much broader series of languages to gain support for JSON-LD.

> - very verbose which unfortunately leaks over into the json version 
> of Vc as well

Very verbose in what way?

> - reliance on external linked data without any cryptographic 
> integrity guarantees

Don't JWT's have the same issue? You link to something, you don't have
cryptographic integrity guarantees.

In any case, that's what Resource Integrity Proofs are for:

https://github.com/WebOfTrustInfo/rwot7/blob/master/draft-documents/resource-integrity-proofs.md

... or you can use IPFS links or any other sort of content addressable
storage.

> - very complex for new developers to understand, which could cause 
> security problems down the line

It's complex for implementers that want to know about all the details...
in the same way that implementing RSA-based digital signatures is
complex for implementers.

In time, I imagine libraries will make all of this easier. I don't mean
to downplay it... it is more complex than just plain 'ol JSON, and we've
tried very hard to hide some of the complexity... but there is a reason
for all that. We have a set of requirements that seem to have broad
consensus that require something more than simple JSON and JWTs:

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

> It is more composable than JWTs. I see that as jsonlds biggest 
> advantage. But composability I feel is less important outside the 
> http world.

While true regarding composability, it's not just about
composability,... it's about everything else in that document linked to
above.

> We see most usecase as best implemented as smaller self contained VCs
> and that JWTs are superior for that.

If you have a closed system, with one organization specifying the data
vocabulary, and a limited set of players, JWTs are better. That,
however, doesn't seem to be the ecosystem that most of us are deploying
into.

That said... I'm sure all of us would welcome a simpler solution that
meets most of the requirements outlined in the link above.

-- manu

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

Received on Monday, 8 October 2018 00:44:01 UTC