- From: Anders Rundgren <anders.rundgren.net@gmail.com>
- Date: Mon, 31 Dec 2018 06:39:37 +0100
- To: Kevin Poulsen <dean@authenticity.ac>, pelle.braendgaard@consensys.net
- Cc: public-credentials@w3.org, Manu Sporny <msporny@digitalbazaar.com>
FWIW, a JSON Canonicalization work-item has finally gotten some traction in the IETF and will (as it appears...) be discussed in a potentially WG-forming (https://www.ietf.org/mail-archive/web/jose/current/msg05795.html) BoF session at the next IETF in Prague. Input specification: https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-02 Combining it with detached JWS: https://mobilepki.org/jws-jcs/home Other standardization efforts are also at a cross-road including: https://www.w3.org/securepay/charter.html Open Banking APIs using HTTP bindings + detached JWS which severely limits the scope. Using JWT "as is" seems to be a [very] hard sell... Anders On 2018-12-31 00:52, Kevin Poulsen wrote: > Pelle, > > In late October, I responded to this email thread with a proposed revision to the signed JSON-LD/VCWG signature standards. The proposal was prompted because verifying the signature is made difficult by these standards: they require the signed content to be modified after it's signed; then, the modified signed data needs to be reconstructed in order to verify the signature. This same technique has been used in XML signatures, causing much hair-pulling. We should abandon it. > > I appreciate the open and frank replies to my earlier proposal. From the conversation, I gathered that the VCWG was considering following one of two paths: > > 1. Develop tools to make the existing standards easier to implement. In my opinion, this isn’t an option because they require modification of the signed content. > > 2. Use the JWT/JWS signature format instead. After some additional research on this option, I’m presenting an updated proposal (attached .PDF below). > > I’ll watch the evolution of these standards. I hope that our formats are eventually compatible with each other. In the mean time, we can’t wait for the standards process to play out. We need to move forward using the format proposed below. > > Thanks for your time, > Kevin Poulsen > > > > > p.s. Spoiler alert: Here's a side-by-side comparison of the current VCWG verifiable claim format and my proposed verifiable claim format based on the JSON serialization in the JWS standard: > > > > > p.p.s. Here's a .PDF of my proposal: > > > > > > p.p.s. Manu, I’ve created a W3.org <http://W3.org> account. However, I’m not allowed to join the VCWG. Owell….. > > > > > > >> On Oct 25, 2018, at 6:14 AM, Terry Alves-Hunter <terry@reliableid.com <mailto:terry@reliableid.com>> wrote: >> >> >> >> >> >> ============ 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 Monday, 31 December 2018 05:40:07 UTC