Re: FW: Selective Redaction - docs and examples?

Dear Calvin,

thanks a lot for your input.

I did re-read your 3 points some 5 times...then I decided to open your 
attachment and at that point, in a split second, I understood exactly 
what you are after :-) This seems in fact closely related to what we 
call "Digital Product Passport" (DPP) here in the EU (see: 
https://www.deloitte.com/uk/en/services/risk-advisory/perspectives/digital-product-passports-are-just-around-the-corner.html), 
something we have been working on since 2019.

I find interesting your approach of using VCs to solve this problem, I'd 
be glad to share insights about our experience in the field - ping me 
anytime if interested (the same invitation is extended to the whole group).

Cheers,

Andrea

On 23/02/2025 14.21, Calvin Cheng wrote:
>
> 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>
> *Sent:* Sunday, February 23, 2025 12:09:59 AM (UTC+08:00) Kuala 
> Lumpur, Singapore
> *To:* Christopher Allen <ChristopherA@lifewithalacrity.com>
> *Cc:* Steve Capell <steve.capell@gmail.com>; Leonard Rosenthol 
> <lrosenth@adobe.com>; Andrea D'Intino <andrea@dyne.org>; 
> public-credentials@w3.org <public-credentials@w3.org>; Shannon 
> Appelcline <shannon.appelcline@gmail.com>; Wolf McNally 
> <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> 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
>     <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
>
-- 
| Andrea D'Intino | +45  21 62 79 18 | Project Manager
|https://Dyne.org think &do tank  | software to empower communities
| ⚷ crypto κρυπτο крипто गुप्त् 加密הצפנה المشفره