Unlinkable selective disclosure via BBS (bbs-2023) for OB 3.0 / CLR 2.0

[t3-atharva]

Brief Description

As an OB 3.0 Issuer and CLR 2.0 certified implementer, we need privacy-preserving credential sharing where a holder can disclose only a subset of credential attributes to a verifier.

Beyond field-level selective disclosure, the requirement is unlinkability: a holder should be able to present the same credential to multiple verifiers, or repeatedly to the same verifier, without those presentations being correlatable.

The currently supported ecdsa-sd-2023 cryptosuite provides selective disclosure, but does not provide unlinkability across presentations. The desired outcome is for the bbs-2023 cryptosuite, based on W3C vc-di-bbs, to be recognized as an allowed proof mechanism for OB 3.0 / CLR 2.0 certification, not as a required mechanism.

This appears consistent with the direction in PR #584 and the future BBS documentation discussion noted in Issue #636.

Use Case Actors

• Issuer — issues OB 3.0 / CLR 2.0 credentials secured with a BBS proof
• Holder — derives and presents a selectively disclosed, unlinkable credential
• Verifier / Relying Party — verifies the derived presentation and disclosed claims
• 1EdTech conformance / certification system — validates the supported proof mechanism

Preconditions

• The credential is modeled using W3C Verifiable Credentials Data Model 2.0 in JSON-LD format.
• The issuer holds BBS key material and can produce a bbs-2023 Data Integrity proof.
• The holder possesses a base credential issued by the issuer.
• Per PR Clarify proof mechanism and algorithm selection #584, EdDSA remains available for conformance demonstration, while BBS is the proof mechanism used in practice for selective disclosure and unlinkable presentations.

Basic Flow

1. The issuer creates the credential and secures it with a bbs-2023 Data Integrity proof.
2. The issuer delivers the base credential to the holder.
3. The holder selects the subset of attributes to disclose for a given verifier.
4. The holder derives a presentation that reveals only the selected attributes.
5. The derived BBS proof remains verifiable without revealing undisclosed attributes.
6. The holder presents the derived credential to the verifier.
7. The verifier validates the BBS proof and the disclosed claims.
8. The holder repeats steps 3–7 with other verifiers; the resulting presentations are not correlatable to one another.

Postconditions

• The verifier confirms credential authenticity and integrity using only the disclosed subset of attributes.
• Undisclosed attributes are not revealed.
• Multiple presentations derived from the same credential are not linkable to each other.
• The implementation is recognized as conformant for OB 3.0 / CLR 2.0 when using BBS as an allowed proof mechanism.

Additional Considerations

• This aligns with PR Clarify proof mechanism and algorithm selection #584’s recommendation to keep EdDSA required for conformance testing, while allowing any VCDM 2.0-compliant Data Integrity suite, including BBS, in practice.
• A dual-signature demonstration path may be one option for conformance, though it should not necessarily be required for real-world implementations.
• PR Clarify proof mechanism and algorithm selection #584 notes that additional cryptosuites may be added through an errata-level change rather than a new minor version. Confirmation of the appropriate path for BBS would be helpful.
• Documentation could be added alongside the implementation guide work discussed in Issue Document ECDSA-SD Cryptosuite in implementation guide #636.
• Conformance clarification requested: which credential fields, if any, must remain mandatorily disclosed in a BBS-derived credential for OB 3.0 / CLR 2.0 verification.

Requested By

TruScholar, a 1EdTech Member
Contact: Atharva (atharva@truscholar.io)

[vineetsen-creator]

Revocation / status under unlinkability

One aspect worth resolving alongside this proposal: OB 3.0 verification requires
credential status checking (revocation / suspension), but the default VCDM 2.0 status
mechanism can re-introduce the very correlation that bbs-2023 is meant to remove.

The native mechanism — W3C Bitstring Status List v1.0 — assigns each credential a
static statusListIndex within a credentialStatus (BitstringStatusListEntry).
If that status entry must be disclosed on every presentation so the verifier can check
revocation, the index becomes a stable, unique handle: colluding verifiers can correlate
presentations on it, defeating the unlinkability BBS provides. The Bitstring Status List
specification itself acknowledges this and recommends that status information be made
selectively disclosable / concealable when a credential is expected to be presented in an
unlinkable way.

We'd appreciate the workgroup's guidance on how revocation is expected to work for
BBS-derived presentations in OB 3.0 / CLR 2.0, specifically:

• Whether the credentialStatus entry (and its statusListIndex) is intended to be a
  mandatorily-disclosed field or a selectively-disclosable one in a BBS
  presentation. This ties directly to the "mandatory vs. selectively disclosable claims"
  clarification already requested above.
• Whether reliance on Bitstring Status List group ("herd") privacy (the 131,072-bit
  minimum list size) is considered sufficient for OB use cases, given that the index
  remains static across presentations even within the herd.
• Whether OB intends to leave room for emerging unlinkable-revocation approaches
  (e.g. cryptographic accumulators, randomized / Bloom-filter status lists) as optional
  alternatives, consistent with the "recognize, don't mandate" direction in Clarify proof mechanism and algorithm selection #584.

Without a defined answer here, an implementation could be selective-disclosure conformant
yet still trivially linkable through its revocation handle — which would undercut the
purpose of recognizing bbs-2023.