Re: JSON-LD vs JWT for VC

Hi,

I guess the posting was not about using one or the other. The IIW community identified clear needs for improvements on both ends and we should respect that needs::

- We should make progress in defining JWT verifiable credentials and support JWT DID resolution.
- We should make progress in addressing the concerns that the IIW community identified with JSON-LD.

It doesn’t help to copy & paste links.

Thanks,
Oliver


> On 25. Oct 2018, at 01:58, a.a@tutanota.com wrote:
> 
> >FYI : 
> >https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-bad-standard-that-everyone-should-avoid <https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-bad-standard-that-everyone-should-avoid>>Might contain some useful pointers.
> 
> And this one
> https://openid.net/specs/draft-jones-json-web-token-07.html <https://openid.net/specs/draft-jones-json-web-token-07.html>
> Sorry if I repeat.
> 
> ---
> Regards,
> Alexey Anshakov
> CEO, webRunes https://wr.io <https://wr.io/>
> skype: alexey_anshakov
> 
> 
> 25. Окт 2018 08:09 от melvincarvalho@gmail.com <mailto:melvincarvalho@gmail.com>:
> 
> 
> 
> On Thu, 25 Oct 2018 at 02:12, Pelle Braendgaard <pelle.braendgaard@consensys.net <mailto:pelle.braendgaard@consensys.net>> 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.
> 
> JSON-LD 
> Pros:
> - Semantics
> - Graph
> - Human Readable
> 
> Cons:
> - Difficult to integrity/canonicalization of graph for signing purposes
> - Canonicalization requirement
> - Difficult to understand what is signed
> - Cognitive overload when understanding data
> - Lack of diversity in tooling
> - You have to really know what you do to verify a signed json-ld document
> 
> Asks of JSON-LD community to make it useful for Verifiable Credentials:
> - Better Tooling (automatically resolve DIDs and verify signatures)
> - Better documentation for specific use cases
> - Middleware for various server implementations to automatically verify signatures etc of json-ld requests
> - Remove embedded schema
> 
> JWTs
> Pros:
> - Simple
> - You always know what is signed (easy to verify)
> - No canonicalization needed
> - Good tooling
> 
> Cons:
> - Key definition/lookup part is not very well defined
> - No built in semantics/schemas
> - Not Human Readable
> 
> Asks of JWT community:
> - Libraries should support DID resolution (eg implementation https://github.com/uport-project/did-jwt <https://github.com/uport-project/did-jwt>)
> - Help work on defining Verifiable Credentials using JWT
> 
> Most people present felt that JWTs are the safest format at the moment, due in larger part to its simplicity. 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.
> 
> FYI : 
> 
> https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-bad-standard-that-everyone-should-avoid <https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-bad-standard-that-everyone-should-avoid>
> 
> Might contain some useful pointers.
>  
> 
> Regards
> Pelle
> -- 
> 
> Pelle Brændgaard // uPort Engineering Lead
> pelle.braendgaard@consensys.net <mailto:pelle.braendgaard@consensys.net>
> 49 Bogart St, Suite 22, Brooklyn NY 11206
> Web <https://consensys.net/> | Twitter <https://twitter.com/ConsenSys> | Facebook <https://www.facebook.com/consensussystems> | Linkedin <https://www.linkedin.com/company/consensus-systems-consensys-> | Newsletter <http://consensys.us11.list-manage.com/subscribe?u=947c9b18fc27e0b00fc2ad055&id=257df01285&utm_content=buffer1ce12&utm_medium=social&utm_source=facebook.com&utm_campaign=buffer>