Re: JSON-LD vs JWT for VC

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

Received on Sunday, 28 October 2018 06:28:01 UTC