RE: Selective Redaction - docs and examples?

All,

Whereas “selective redaction” is a much better term than “selective disclosure”, it too is technically incorrect.

  *   “Redaction” applies to the holder blacking-out parts of the information. Take redacted government responses for Freedom-of-Information-Act requests, for example.
  *   In case of Verifiable Credentials, it is the verifier who determines what information is needed. An overzealous verifier may decide to requests the full credential: cf hotels or Facebook requesting a full (non-redacted) copy of your passport. The holder has only two options: coerced compliance or walk away. “Selective redaction” is not an option.

Technically, a benevolent verifier would be making a “VC-fragment request”. Perhaps less sexy than “selective redaction”, but also less misleading …

Oskar


From: Calvin Cheng <Calvin_cheng@hive.tech.gov.sg>
Sent: zondag 23 februari 2025 14:21
To: Steve Capell <steve.capell@gmail.com>; Leonard Rosenthol <lrosenth@adobe.com>; Andrea D'Intino <andrea@dyne.org>; public-credentials@w3.org; Shannon Appelcline <shannon.appelcline@gmail.com>; Wolf McNally <wolf@wolfmcnally.com>; Christopher Allen <ChristopherA@lifewithalacrity.com>; Daniel Hardman <daniel.hardman@gmail.com>
Subject: FW: Selective Redaction - docs and examples?

Let me chime in on this on behalf of the Singapore IMDA TradeTrust and OpenAttestation team, but apologize if I don’t get the context fully right.

We have chosen to use the term “Selective Redaction” to not confuse it with “Selective Disclosure”. Here are the considerations in respective to the TradeTrust use case.

  1.  Selective Disclosure implies a deliberate decision to disclose a subset of the information for privacy reasons. Our use case instead calls for the same document or verifiable credentials to be passed from Holder to Holder down the chain, but with subset of it optionally redacted so it’s a subtractive process.
  2.  Unlike what is discussed for “Selective Disclosure” where it is deemed important to preserve privacy, it is desirable, if not important to be able to link the verifiable credential to the original issuer. This also turns out to be useful for operations such as revocation and transfer of ownership.
  3.  Side-effect of these allows us to devise our relatively simple mechanism that is easy to be implemented with no additional cryptographic requirements over the original issuance process.

Due to these differences, we find it useful to differentiate Selective Redaction from Selective Disclosure.

I am personally not directly involved with TradeTrust, but supports the TradeTrust team on technical interaction. I am attaching their description of the use case in this email so if you are interested, you can have more context about it. I agree that we may still have some gaps and need consensus on some terminology. For example, they have avoided using the term Holder in their description, and I am seeing questions on how Selective Redaction should be defined and used. I will be glad to take your feedback and bring it to them, so we can facilitate further conversations. It would be good if we can all be consistent with our terminology and understanding.

________________________________
From: Daniel Hardman <daniel.hardman@gmail.com<mailto:daniel.hardman@gmail.com>>
Sent: Sunday, February 23, 2025 12:09:59 AM (UTC+08:00) Kuala Lumpur, Singapore
To: Christopher Allen <ChristopherA@lifewithalacrity.com<mailto:ChristopherA@lifewithalacrity.com>>
Cc: Steve Capell <steve.capell@gmail.com<mailto:steve.capell@gmail.com>>; Leonard Rosenthol <lrosenth@adobe.com<mailto:lrosenth@adobe.com>>; Andrea D'Intino <andrea@dyne.org<mailto:andrea@dyne.org>>; public-credentials@w3.org<mailto:public-credentials@w3.org> <public-credentials@w3.org<mailto:public-credentials@w3.org>>; Shannon Appelcline <shannon.appelcline@gmail.com<mailto:shannon.appelcline@gmail.com>>; Wolf McNally <wolf@wolfmcnally.com<mailto:wolf@wolfmcnally.com>>
Subject: 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<mailto:ChristopherA@lifewithalacrity.com>> wrote:
On Fri, Feb 21, 2025 at 7:23 AM Andrea D'Intino <andrea@dyne.org<mailto: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<mailto: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

-- This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.