Re: [w3ctag/design-reviews] Verifiable Credentials Data Model 1.0 (#343)

> Has any thought been given to a serialisation formation that is less error-prone than JWT? For instance, CBOR?

Great question!

Yes, we considered CBOR and yes, we're aware of JWTs shortcomings :) ...

https://w3c.github.io/vc-imp-guide/#benefits-of-json-ld-and-ld-proofs

Note, though, that JWT is not the serialization format. JSON and JSON-LD is the data model serialization format. JWTs and LD Proofs are the proof format (e.g., digital signatures).

We would have preferred to use COSE for the digital signature expression format but the work and library development wasn't at the point where the group could rely on it. Even to this day there isn't a decent CBOR implementation in isomorphic Javascript (use of node.js Buffers everywhere for no reason) and no Javascript COSE implementation exists for a variety of different languages (and attempts to compile to wasm have been deemed too bleeding edge for the companies deploying Verifiable Credentials today). 

In the future, it should not be difficult to express the data model in CBOR (we have internal experiments that already do this), and then digitally sign the data using LD Proofs (with a COSE signature... which is where some of us want to go), or CWTs... but for that future to unfold, a good chunk of the developer community is going to have to get the underlying CBOR/COSE library support there.

> On that front, perhaps signing could re-use an existing container format, e.g. SXG: https://developers.google.com/web/updates/2018/11/signed-exchanges

We are aware of the Signed HTTP Exchanges work (I'm the editor for https://tools.ietf.org/html/draft-cavage-http-signatures-11).

Since the data model is designed to be separate from the proof format, someone could "sign" a Verifiable Credential using SXG (in theory).  No one in the group felt like SXG was ready to be used in a W3C REC-track spec. I just took a quick look again to try and see if the SXG format was published anywhere, and was having a hard time finding a spec for it. I also took a look in a hex editor at some of the example files in the chromium source repo example and couldn't make heads or tails of the format.

Do  you have a link to the SXG file format? It would help us determine how easy or difficult it would be to express a Verifiable Credential using an SXG as the proof format.

> Has thought been given to providing a JSON-LD+JWT (or other format) decoding/validation Web API? It seems as though we'll take on quite a lot of polyfill debt (and potential security problems) without ways of pulling the crypto bits out of userland.

Yes, thought has been put into that but browser vendors seemed hostile to the idea of anything JSON-LD related going into the browser (this was 4+ years ago). Things may have changed now that Google is including jsonld.js in the browser as a part of their Lighthouse tooling. If the browser vendors want to explore putting JSON-LD + LD Proofs (or JWTs) into the browser, we'd be happy to discuss.... but

Almost all of the digital signature and verification for Verifiable Credentials happens on the server or in app and not in the browser. We do have isomorphic Javascript libraries that can use the WebCrypto APIs if they're available, but there has been little desire to work on that as most (maybe all?) of the production implementations sign stuff server side. The WebCrypto APIs also don't expose the digital signature schemes that are most heavily used for Verifiable Credentials either (ed25519 and secp256k1).

Does that answer all of your questions, @slightlyoff?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/343#issuecomment-521397337