Re: Seeking Support for an Elision-Focused Encoding Format for VCs, VPs & DIDs

I wonder if Gordian Envelopes could be packed into JWP "Issued Form" (https://json-web-proofs.github.io/json-web-proofs/draft-jmiller-jose-json-web-proof.html#section-4.1) then selectively disclosed via "Presented Form". Do you see any parallels there? Please forgive if I misunderstood some aspect of your architecture upon first glance, haven't had a chance to work through the materials in detail yet. Just looking to make sense of the emerging set of identity-related specifications and their relationships from an implementer's perspective, as we'll be on the hook making it work E2E for customers in a way that makes sense and is familiar as possible to them.

Best,
- Wayne

On Mon, Oct 17, 2022, at 1:10 PM, Christopher Allen wrote:
> *TL;DR* Is there interest in the W3C for a CBOR alternative to the JSON JWT/JSON-LD formats for VCs/VPs & DIDs to focus on support for elision/redaction?
> 
> 
> We have had many discussions in the W3C-CCG community, and in the VC & DID working groups, on the problem of how to selectively disclose data. Techniques have been proposed such as CL-Sigs & BBS+ signatures, such that only some of our data can be correlated. I am now seeking support and interest in a different architecture that avoids correlation through redaction in hash trees, that we call Gordian Envelope.
> 
> This format would be an alternate to JWT and JSON-LD formats for VCs, VPs, and DIDs. I’m aware that there have been many work-years of effort put into JWT and JSON-LD and their implementation in VCs/VPs and DIDs, and that this creates the possibility of an XKCD 15th standard: https://xkcd.com/927/.
> 
> However, as both a long-term member of this group and its former co-chair, I’d never been happy with the use of those encoding formats in our standards. Though I saw advantages in each, such as the fact that many of JWT’s early security issues were understood and thus more mature, and that JSON-LD was built on powerful semantic triples, but I hoped that better privacy-focused encoding architecture for encoding would emerge.
> 
> There were strong reasons for my reluctance to support JWT/JSON-LD. Like many of my cryptographer colleagues, I could not fully back JWTs for security architecture reasons. Like many, I also could not fully back JSON-LD because of its requirements for fully described semantic contexts and their barrier of canonicalization complexity. (There still isn’t a reviewed C or C++ library after 5 years!)
> 
> As I could not fully support either of these formats, but also did not have a good alternative to offer, I stayed on the sidelines in the debate as co-chair here and invited expert to the WGs. The VC and DID specs ultimately incorporated compromises between the two in their final versions, but years later they do not appear to yet satisfy many advocates from either group.
> 
> For me, the biggest problem remains is a lack of support for redaction by any party, whether they be issuer, subject, or subject. More broadly, this is what I call elision, which is the removal of some content for a variety of reasons. Elision is a requirement for strong privacy, and it’s missing! Yes, there are proposals for cl-sigs and bbs+ signatures. Though powerful, they are also very constrained and cryptographically complex.
> 
> The result is that all of today’s POCs and pilots are sharing far too much correlatable data.
> 
> Since retiring as co-chair of this community group, I’ve been working with the community of wallet developers that support Blockchain Commons to puzzle out a better architecture to both overcome some of the problems of JWT and JSON-LD and most importantly to support elision.
> 
> The solution that we’ve come up with is called Gordian Envelope. It’s already fully functional and can be demonstrated as an MVA (Minimum Viable Architecyure) via a CLI program <https://github.com/BlockchainCommons/envelope-cli-swift> that creates and updates Gordian Envelopes.
> 
> Here are the fundamentals of how Envelopes work:
> 
>  * Each Envelope is a triple, with a subject, predicate, and a set of assertions.
>  * Every subject, predicate, and assertion itself can be an Envelope. It’s Envelopes all the way down.
>  * Every Envelope, subject, predicate & assertion has a hash associated with it, which is part of a larger hash tree.
>  * Elsion is fundamentally supported:
>    * All four parts of the Envelope can be elided: the Envelope as a whole, its subject, its predicate, and every assertion.
>    * Elements can be elided for redaction (for example, for selective disclosure), for encryption, or for external reference (for example, with IPFS-style lookup).
>    * Instead of presenting redactive structures, you can optionally offer proofs of inclusion in a top-level hash.
>    * There are limits of non-correlation with an elided hash (even with salts) that require care, but it is fundamental and always available.
>    * The Envelope format still allows for cl-sigs, bbs+, and other privacy-preserving techniques such as zk-proofs (I like integer bulletproofs), differential privacy, etc.
>  * Even after elision, the original hashes can still be verified!
> Here are some more specifics:
> 
>  * Envelopes structure are expressed in a binary CBOR structure.
>  * No text transcoding format is specified, you can use our QR-focused UR specs, base64, or even hex.
>  * Canonicalization is achieved not by using a context or other semantic quad techniques, but instead by sorting the hash of the envelopes in CBOR.
>  * If you need semantic context or quads, they can be added to subject, predicates or assertions, but they are optional.
>  * The format is not locked into any single-proof technique. You could use COSE, multisig schnorr, 25519 or ristretto, BLS signatures, timestamps, etc.
> I believe this format offers a lot of advantages to our community, in particular because elision is included as a fundamental feature that allows both issuers & holders to choose what to elide.
> 
> Ultimately, the Gordian Envelope offers an alternative to not just VCs, but also to VPs and DIDs, and additionally it expands upon their possibilities. For example, you could use a “proof of inclusion” construction where multiple parties can share a single DID or VC for “herd privacy”. Thus, all students who graduate could be in a single diploma VC, and instead of offering their own diploma, they prove they were part of the graduating class. Another example is that all people in a cohort could share a single DID, contributing to a single hash tree, and only revealing selective portions under their control.
> 
> Given these advantages, I’m asking the community whether Gordian Envelopes are worth bringing forward into the W3C, either in the CCG or with the VC 2.0 working group. There are multiple privacy-focused blockchian companies that would be willing to join the W3C to do so, but they are reluctant unless there is interest here by the broader W3C community. So: should we do so, or would it be too much of a distraction to ongoing efforts to begin to also discuss Gordian Envelopes here?
> 
> For now, we definitely plan to submit the underlying CBOR envelope triple structure to the IETF. But beyond that we’d love to work with the W3C communities if that’s desired, or wait until post-VC 2.0 and do so then, or alternatively to work with the JWT and JSON-LD Communities to revive redaction signature requirements from 2016 proposals … all depending on the interest and suggestions from those communities.
> 
> Let me know your thoughts!
> 
> Here are some links if you’d like to learn more about Gordian Envelopes:
> 
>  * The best high-level non-technical intro is “Introduction to Envelopes” video (10m): https://www.youtube.com/watch?v=tQ9SPek0mnI
>  * The best high-level technical intro is our command-line MVA demo video “Envelope CLI  - Commands Overview” (24m): https://www.youtube.com/watch?v=K2gFTyjbiYk
>    * …or skim the text and examples in the transcript: https://github.com/BlockchainCommons/envelope-cli-swift/blob/master/Transcripts/1-OVERVIEW-TRANSCRIPT.md
>  * If you’d like to understand more about elision, see our RWOT topic paper: “Elision, Redaction, and Noncorrelation in Smart Documents”: https://github.com/WebOfTrustInfo/rwot11-the-hague/blob/master/advance-readings/elision-redaction-correlation-smart-documents.md
>    * …and a draft RWOT white paper on “Selective Correlation” with an interesting multi-party educational credential use case for redaction that could be implemented by Gordian Envelopes: https://github.com/WebOfTrustInfo/rwot11-the-hague/blob/master/draft-documents/selective-correlation.md
>    * …and our video deep-dive into elision via the cli: https://www.youtube.com/watch?v=3G70mUYQB18
>  * If you like videos, the rest of them are in this playlist: https://www.youtube.com/playlist?list=PLCkrqxOY1FbooYwJ7ZhpJ_QQk8Az1aCnG
>  * For a deep dive into the Gordian Envelope specs: https://github.com/BlockchainCommons/BCSwiftSecureComponents/tree/master/Docs
> If you have any questions, or are interested in joining the Blockchain Commons developer community implementing Envelopes, feel free to contact me at ChristopherA@LifeWithAlacrity.com
> 
> – Christopher Allen - Blockchain Commons
> Principal Architect, Executive Director
>