Re: JSON-LD vs JWT for VC

I'd like to take a stab at summarizing this thread in an attempt to move
the community toward a solution.

It sounds to me like the crux of the disagreement of this thread is whether
we pursue a JSON signing method that requires canonicalization of the JSON
content prior to signing or not. On one side, we have LinkedDataSignatures
and JSONCleartextSignatures which both require an updated JSON library that
is capable of canonicalizing the JSON.  On the other side, we have
traditional JOSE (JWT/JWS/JWE) that signs the Base64-encoding of the JSON.

Personally, I am in favor of the approach Pelle is suggesting which is one
that does not require JSON to be canonicalized. I think we will see faster
adoption if don't require JSON parsing libraries that can perform this
canonicalization.  I won't elaborate on this position on this thread since
my primary motivation was simply to clarify what I think the primary
disagreement is and to state which side I am on.

   -chrisb

On Sat, Oct 27, 2018 at 11:29 PM Anders Rundgren <
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
>
> On 2018-10-26 00:24, Dean Kevin Poulsen wrote:
> > Pelle,
> >
> > A friend who is on the mailing list forwarded the following message to
> me.  It’s of particular interest to me because I’ve recently submitted
> proposed changes to the format for signed JSON-LD.  I submitted the
> suggestion to the email posted at this page:
> https://w3c-dvcg.github.io/ld-signatures/ However, I haven’t heard a
> response and there no longer seems to be any activity on this standard.
> >
> > I was referred to the VCWG credential format by Kaliya Identity Woman.
> I really appreciate the work that the group has done.  It’s proving to be
> quite useful for a project in which I’m actively involved.  However, it
> appears to be based on the same flawed format for signed JSON-LD.
> >
> > The email below says that JSON-LD cons include:
> >
> >> - Difficult to integrity/canonicalization of graph for signing purposes
> >> - Canonicalization requirement
> >> - Difficult to understand what is signed
> >> ...
> >> - You have to really know what you do to verify a signed json-ld
> document
> >
> >
> > After identifying the problems and discussing them with colleagues, it
> seems that this format evolved from XML, which does have canonicalization.
> However, JSON, does not.  So, I certainly understand why you're
> experiencing these issues.
> >
> > Since I haven’t received a response from those who created the signed
> JSON-LD format, I’m attaching my proposed revision.  This eliminates the
> canonicalization requirement and minimizes changes to signed content (which
> really shouldn’t change after it’s signed - big no no).  The changes that
> are still required consist of assigning a value.  So, the chances of not
> being able to verify the signature are minimized.
> >
> > I’ve also looked at JWT and JWS.  At first, I thought they may be
> useful, mistaking them for signed JSON formats.  They aren’t.  As such,
> their usefulness is limited.
> >
> > I’ve been interested in attending the Monday meetings of the VCWG, but
> haven’t yet.  I hope you find this useful, and I’d like to participate when
> I can.
> >
> > FYI,
> > Kevin Poulsen
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > ============ Forwarded message ============
> >  From : Pelle Braendgaard<pelle.braendgaard@consensys.net <mailto:
> pelle.braendgaard@consensys.net>>
> > To : "Credentials Community Group"<public-credentials@w3.org <mailto:
> public-credentials@w3.org>>
> > Date : Wed, 24 Oct 2018 19:10:02 -0500
> > Subject : JSON-LD vs JWT for VC
> > ============ Forwarded message ============
> >
> >     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)
> >     - 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.
> >
> >     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
> >
> >
> >
> >
>
>
>