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

I've said it before. I hope that adventures in applied category theory help
in seeing mappings between different expressions. Slowly I've been
ingesting this and recording thoughts:
https://github.com/bshambaugh/Explorations-of-Category-Theory-for-Self-Sovereign-Identity/blob/main/todo.txt
. Best of luck until I find time to ingest more and understand the nuances
of various implementations.

-Brent Shambaugh

GitHub: https://github.com/bshambaugh
Website: http://bshambaugh.org/
LinkedIN: https://www.linkedin.com/in/brent-shambaugh-9b91259
Skype: brent.shambaugh
Twitter: https://twitter.com/Brent_Shambaugh
WebID: http://bshambaugh.org/foaf.rdf#me


On Mon, Oct 17, 2022 at 3:14 PM Christopher Allen <
ChristopherA@lifewithalacrity.com> 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
>