Re: JSON-LD vs JWT for VC

Thank you Dan and Oliver for doing this. I’m very encouraged by this
iteration of JSON-LD/JWT email threads, and eagerly awaiting your results.

I imagine the scope could be a bit beyond what you can take on for VCWG, so
let us know if you’d like CCG airtime/involvement. We’ve already discussed
taking on some tooling improvements (mentioned above), but that’s just part
of the solution.

On Tue, Oct 30, 2018 at 2:28 AM Daniel Burnett <daniel.burnett@consensys.net>
wrote:

> It turns out that Oliver and I are both in Prague this week, so we will
> meet first in person to brainstorm practical options for how this work
> might occur in relation to the VCWG's current specifications and timelines.
>
> -- dan
>
> On Tue, Oct 30, 2018 at 4:54 AM Oliver Terbu <oliver.terbu@consensys.net>
> wrote:
>
>> Hi Dan,
>>
>> I have been following this thread for a while now. After last RWOT and
>> especially after last IIW, I can clearly see that we should make progress
>> in both directions: JWT and JSON-LD. As Pelle mentioned, it doesn’t make
>> sense to refer to articles listing the pros and cons of one option over the
>> other. We already are aware of those. It is time to make progress.
>>
>> @Dan: I am very interested and I am willing to contribute on a proposal
>> for a JWT-based VC specification as suggested by Dan Burnett. Does it make
>> sense to organise separate calls which are only JWT-specific until we have
>> a first draft and then bring it to the W3C CC (VC) group? In this case, I
>> am happy to arrange these calls for all people that are interested.
>>
>> If you believe separate calls do not make sense, please let me know what
>> would be an appropriate approach.
>>
>> Thanks,
>> Oliver
>>
>> On 29. Oct 2018, at 21:20, Daniel Burnett <daniel.burnett@consensys.net>
>> wrote:
>>
>>
>>
>> On Sun, Oct 28, 2018 at 5:32 PM Pelle Braendgaard <
>> 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> 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
>>>> (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
>>>>
>>>> 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
>>>> >
>>>> >
>>>> > ------
>>>> > 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>>
>>>> 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
>>> 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>
>>>
>>
>> --
Kim Hamilton Duffy
CTO & Principal Architect Learning Machine
Co-chair W3C Credentials Community Group

kim@learningmachine.com