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

*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