Re: JSON-LD vs JWT for VC

Please see my recent PR for IPLD and CBOR:

https://github.com/w3c/vc-data-model/pull/261 <https://github.com/w3c/vc-data-model/pull/261>


I argued my points in my recent Rebooting Web of Trust paper (draft) :

https://github.com/WebOfTrustInfo/rwot7/blob/master/draft-documents/ipld_did_documents.md <https://github.com/WebOfTrustInfo/rwot7/blob/master/draft-documents/ipld_did_documents.md>

sorry I couldn’t make to IIW.


Since both IPLD and JSON-LD are 100% compatible with JSON, the large number of JSON parsers and libraries are already available.

The only requirement in the VC model and DID-spec is to reserve “/“ for CID syntax with resolution over IPLD.


I don’t think we have fully committed to JSON-LD as the only approach for VC and DID. These are early days for DID and VC.


Manu,

The specific attacks include:

https://en.wikipedia.org/wiki/DNS_spoofing <https://en.wikipedia.org/wiki/DNS_spoofing>

https://medium.com/mit-security-seminar/eclipse-attacks-on-bitcoin-s-peer-to-peer-network-e0da797302c2 <https://medium.com/mit-security-seminar/eclipse-attacks-on-bitcoin-s-peer-to-peer-network-e0da797302c2>



I am also a fan of COSE rather than JOSE or JWT, see my comment in the JSON-LD spec:

https://github.com/json-ld/json-ld.org/issues/463#issuecomment-431191285 <https://github.com/json-ld/json-ld.org/issues/463#issuecomment-431191285>

Signing a serialized IPLD CID as CBOR provides a deterministic output and would be much more secure.


Pelle,

My issue with JWT is the lack of linking and the order of the JSON document changes the entire base64.
Linking using IPLD, serializing using CBOR then back out to JSON then encoding as base64 the JWT etc would be ok
 … but you then need self-describe the payload the output you got so it can be validated and there should only be one way of doing it.



Best,

jonny


> On Oct 29, 2018, at 4:39 PM, Pelle Braendgaard <pelle.braendgaard@consensys.net> wrote:
> 
> As mentioned we are fully aware of this and will work on this.
> 
> We would like to also support json-ld claims and would like more serious work on tooling before we can support it.
> 
> Pelle
> 
> On Mon, Oct 29, 2018 at 21:21 Daniel Burnett <daniel.burnett@consensys.net <mailto:daniel.burnett@consensys.net>> wrote:
> 
> 
> On Sun, Oct 28, 2018 at 5:32 PM Pelle Braendgaard <pelle.braendgaard@consensys.net <mailto:pelle.braendgaard@consensys.net>> wrote:
> Just to clarify. I’m not a fan of canonicalization for the reasons mentioned here, but it could work with proper tooling.
> 
> My main problem is that it you have to be intimately  knowledgeable of how json-ld,  canonicalization and even how did resolution works before you can safely take a verifiable claim and verify it.
> 
> It is even more complex due to the nested aspects of many parts of the proposed VC standards.
> 
> In many cases in its extreme flexibility it has the same very dangerous aspects of xmlsig.
> 
> For VC to actually be used it needs to have tooling that can safely be used by regular bank or web devs to verify what is sent to them.
> 
> Ideally it would be simple enough that we could get a plethora of implementations as well, but it seems unlikely since it’s fans don’t seem interested in fixing these aspects in the name of flexibility and readability.
> 
> This is why I propose a workable middleground. Those who believe strongly in the power of JSONLD invest in useable tooling to make it foolproof.
> 
> At the same time those of us that are sceptical work to create better proposals for VC based on JWT.
> 
> The Verifiable Claims Working Group, the standards-track group where this work is being finalized, takes this very seriously, having discussed this topic at every face-to-face meeting since inception and always reaching a conclusion of 'we would like more detailed proposals from those who prefer a JWT-based approach'. As a member of the VCWG yourself, you are no doubt aware that we have been seeking precisely such detailed proposals since the beginning of that group in March 2017.
>   As a co-chair of the VCWG, I would like to ask you to expedite that work.  Our group is chartered to complete in March of next year, with an expectation of feature / substantive content freeze on November 6th of this year (yes, in just a couple of weeks).  If your detailed proposals come in after that time we may need to consider adding them in a version 2.0 when/if such additional work is chartered.  We look forward to receiving your (and others') proposals.
> 
> 
> Currently the state of libraries for json ld signature validation means that most of us working on real production apps will not support it.
> 
> The problem is not solved by a back and forth sending links on the pros and cons. I think we’re all aware of them and are past that.
> 
> Thanks. Hopefully we can make progress.
> 
> Pelle
> 
> On Sun, Oct 28, 2018 at 17:04 Anders Rundgren <anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>> wrote:
> On 2018-10-28 19:37, Dean Kevin Poulsen wrote:
> > Anders,
> >
> > Maybe canonicalization can be eliminated, because the need for canonicalization stems from the core issue, which is:
> >   —  The requirement that signed content be modified after being signed.
> 
> Kevin,
> It is rather the wish using standard JSON tools which (typically) do not respect property order that calls for canonicalization.
> 
> In the case of JSON-LD it is even worse since the requirement is to verify that both sides use the same graph expansion scheme.
> 
> I started with building unique JSON tools which preserved property order and textual representation of elements.  This worked flawlessly but I had to give it up anyway since nobody wanted to change their parser :-( The recent draft has a potentially very interesting quality: It can (with ease) be implemented as a option in a JSON serializer.  Sorting is a one-liner and number serializing is well defined and open sourced.  I use the canonicalization scheme for multiple purposes in my applications.  Example: https://cyberphone.github.io/doc/saturn/bank2bank-payment.html#userauthz <https://cyberphone.github.io/doc/saturn/bank2bank-payment.html#userauthz> (requestHash).
> 
> Enveloping and detached signature schemes do not require explicit modification of signed data but I stick to enveloped signatures because they preserve the structure of the data.
> 
> Related discussion in the IETF: https://www.ietf.org/mail-archive/web/jose/current/msg05752.html <https://www.ietf.org/mail-archive/web/jose/current/msg05752.html>
> 
> Regards,
> Anders
> 
> 
> Then, the receiver is required to recreate the signed content through prescribed manipulations.
> >
> > “Seasoned XML developers recalling difficulties getting signatures to
> >     validate (usually due to different interpretations of the quite
> >     intricate XML canonicalization rules as well as of the equally
> >     extensive Web Services security standards)…”
> > — From the introduction to: https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-01 <https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-01>
> >
> >
> > ------
> > My opinion:  SIGNED CONTENT SHOULD NOT BE MODIFIED AFTER IT IS SIGNED.
> >
> > To simplify the proposal, here's a signed JSON-LD in the existing standard and the same signed JSON-LD revised per my proposal:
> >
> >
> > My proposal does two things:
> >
> > 1.  It splits the “proof” array into two arrays:  “proofMetadata” and “proofValue”.
> > 2.  It puts the signed content into a “signedContent” array.  The “proofValue” immediately follows the “signedContent”
> >
> > This pulls the “proofValue” out of the signed content, eliminating the need to modify the signed content after it has been signed (except in the case of signature sets, where minimal modification is suggested for convenience).
> >
> >
> > —
> > You mentioned that one form of canonicalization doesn’t require the signature to be included.  I can’t find that option in the links that you sent.  Can you point me in the right direction?
> >
> > Thanks,
> > Kevin
> > [“Dean” is a title, not my name.  :) ]
> >
> >
> >
> >
> >> On Oct 27, 2018, at 11:27 PM, Anders Rundgren <anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com> <mailto:anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>>> wrote:
> >>
> >> Hi Dean,
> >>
> >> I don't completely follow your proposal.  Does it actually remove the need for RDF/LD canonicalization?
> >>
> >> Anyway, there are subtle differences between formats and one is if the signature parameters should be included or not.  Including them requires that the data is modified by the signature and verify process.
> >>
> >> FWIW, this is how my Java verifier code deals with this particular topic for JSON Clear text Signatures:
> >>
> >>    // 1. Make a shallow copy of the signature object
> >>    LinkedHashMap<String, JSONValue> savedProperties =
> >>        new LinkedHashMap<String, JSONValue>(innerSignatureObject.root.properties);
> >>    // 2. Hide the signature value property for the serializer...
> >>    innerSignatureObject.root.properties.remove(JSONCryptoHelper.VALUE_JSON);
> >>    // 3. Serialize ("JSON.stringify()")
> >>    normalizedData = signedData.serializeToBytes(JSONOutputFormats.CANONICALIZED);
> >>    // 4. Restore the signature object
> >>    innerSignatureObject.root.properties = savedProperties;
> >>
> >> Regards,
> >> Anders
> >
> 
> --
> 
> Pelle Brændgaard // uPort Engineering Lead
> pelle.braendgaard@consensys.net <mailto:pelle.braendgaard@consensys.net>
> 49 Bogart St, Suite 22, Brooklyn NY 11206 <https://maps.google.com/?q=49+Bogart+St,+Suite+22,+Brooklyn+NY+11206&entry=gmail&source=g>
> 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>--
> 
> 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>