Re: JWT credentials

Thanks again to all for their answers. It's been quite helpful.

Regards,
Carlos

On Mon, Oct 8, 2018 at 7:43 AM Manu Sporny <msporny@digitalbazaar.com>
wrote:

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