Re: JSON-LD vs JWT for VC

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>
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>
>>
> --
*Pelle Brændgaard // uPort Engineering Lead*
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>