Re: Selective Redaction - docs and examples?

I will use Christopher's note about terminology to repeat a comment I've
made several times, which is that we ought not to use "selective
disclosure" for anything we do. Before the identity and credentials
community started using "selective disclosure" as a term for a technique of
sharing only part of a credential's attributes, this term already had a
long, well-defined, and ugly history in financial services. It refers to
the nefarious practice, by business executives, of sharing only part of the
relevant details about company finances with an auditor, a regulator, or a
potential acquirer, in order to distort perceptions and manipulate stock
prices. (A simple web searching on this term, without using "credentials"
or "identity" as a qualifier, will confirm the gravitas and age of that
meaning relative to our own...) In other words, in the minds of many smart
people, "selective disclosure" is a fraud technique. Applying such a term
to an advocated feature in verifiable credentials doesn't seem like savvy
politicking to me, especially if we want VCs in finance.

--Daniel

On Fri, Feb 21, 2025 at 9:47 PM Christopher Allen <
ChristopherA@lifewithalacrity.com> wrote:

> On Fri, Feb 21, 2025 at 7:23 AM Andrea D'Intino <andrea@dyne.org> wrote:
>
>> writing live from CCG data-integrity meeting: does anyone has some and
>> examples about "selective redaction" (maybe Calvin Cheng?)
>>
> The term **"selective redaction"** lacks a well-defined formal meaning,
> though it has gained traction—particularly within the Singapore DID/VC
> community—to describe specific hash-based redaction techniques in
> credential verification. However, at Blockchain Commons, we have generally
> preferred the term **"elision"**, as the underlying technique is useful for
> more than just redaction.
>
> The earliest reference to this topic within the W3C community that I’m
> aware of is from 2016:
>
>    Redaction Signature Suite 2016:
> https://w3c-ccg.github.io/lds-redaction2016/
>
> This JSON-LD Signature Suite used a hash list approach, but I don't know
> if it was ever formally implemented. I believe the Singapore DID/VC
> community uses something similar to it. ISO mID/mDOC also uses a hash list
> approach, but they don't call it selective redaction.
>
> Elision, as we define it at Blockchain Commons, enables **structured
> omission** of data while preserving cryptographic integrity. This allows
> verifiable claims to be **selectively revealed or concealed** without
> invalidating proofs. Unlike redaction, which focuses on removing data,
> **elision can support progressive disclosure, controlled compression, and
> layered encryption**, making it applicable to a wider range of use cases.
>
> We avoided the term **"selective redaction"** due to potential confusion
> with **"selective disclosure."** Historically, selective disclosure
> referred to **minimal disclosure**—revealing only the necessary subset of
> data. However, more recently, it has also come to describe cryptographic
> techniques like **BBS proofs**, which focus on unlinkability and
> anti-correlation of signatures. Given these evolving meanings, precision in
> terminology is crucial.
>
> For those interested, I’ve written extensively on **selective disclosure
> and data minimization** in the context of verifiable data exchange:
>
>     Musings of a Trust Architect -- Data Minimization & Selective
> Disclosure:
> https://www.blockchaincommons.com/musings/musings-data-minimization/)
>
> We have useful section of a our video on Gordian Envelope specifically
> about "Elision and Redaction" starting at the 6m25s mark:
>
>     Understanding Gordian Envelope (#Elision and Redaction 6m25s):
> https://youtu.be/-vcLCFKQvik?feature=shared&t=385
>
> On Fri, Feb 21, 2025 at 3:39 PM Steve Capell <steve.capell@gmail.com>
> wrote:
>
>> The “selective redaction” that is needed for supply chain use cases has a
>> similar sounding name but very different use case
>>
>> It’s not the subject / holder of the credential that wants to redact in
>> supply chain - it’s the verifier that needs to redact it before passing it
>> on to the next actor
>> - personal use case : I want to redact MY personal details in MY
>> credential before I show it to a verifier that wants it
>> - supply chain use case : I received a credential from my supplier
>> containing claims about my supplier (eg my farm is deforestation free).  I
>> need to redact the supplier name before I pass it on to my customer as
>> evidence that my product is made from deforestation free inputs
>>
>> Sounds similar - but big difference in how it could be implemented.  This
>> supply chain use case is the rationale behind the trade trust (Singapore)
>> selective redaction proof method
>>
>
> For those interested in other practical use cases of elision (or
> "selective redaction"), we written about how it can be applied across
> industries such as education, where it enables secure, selective sharing of
> student records; wellness, where it protects sensitive health data while
> supporting controlled disclosures; and data distribution, where it ensures
> recipients only access necessary information. More details can be found
> here:
>
>     Envelope Use Cases Overview:
> https://developer.blockchaincommons.com/envelope/use-cases/
>
> For more details on our specific **elision and our specific implementation
> within Gordian Envelope**, which uses structure hash trees, see:
>
>     Envelope Developer Overview:
> https://developer.blockchaincommons.com/envelope/
>     IETF draft-mcnally-envelope-08 -- The Gordian Envelope Structured Data
> Format: https://datatracker.ietf.org/doc/draft-mcnally-envelope/
>
> I’d be happy to provide additional pointers or discuss further if anyone
> is interested.
>
> -- Christopher Allen
>
>