Re: JSON-LD vs JWT for VC

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