Selective Disclosure and Privacy-Preserving Proofs

Minimizing Data Exposure While Maintaining Cryptographic Verifiability in Credential Use

5.7.1 Why Selective Disclosure Is Critical in NSF

The NSF credential system is designed for high-stakes, cross-jurisdictional applications in:

• Disaster relief

• Public health

• Financial disbursement

• Mobility and migration

• Regulatory and treaty enforcement

In such domains, revealing all credential data can lead to:

• Privacy violations (e.g., personal identifiers, health data)

• Operational security breaches (e.g., emergency logistics)

• Institutional overreach

• Violations of legal frameworks (e.g., GDPR, HIPAA, UN treaty articles)

NSF solves this through selective disclosure and zero-knowledge (ZK) proof integration, enabling credentials to:

• Prove possession of specific claims

• Hide all other data

• Retain full auditability and integrity

---

5.7.2 Selective Disclosure: Concepts and Principles

Selective Disclosure refers to the ability of a credential holder to:

• Present only a subset of a credential’s claims

• Prove cryptographically that the disclosed data is part of a valid credential

• Retain revocation and expiry guarantees

• Avoid over-disclosure of sensitive or unrelated information

This is achieved using:

Technique	Description
BBS+ Signatures	Enable selective disclosure of JSON-LD VCs with hidden fields
ZK-SNARK/STARK Proofs	Cryptographic zero-knowledge proofs of possession and compliance
Merkle Proofs over Claims	Commit to claim trees, prove inclusion with specific keys
JWT Redaction (legacy)	Signed, redacted claims for legacy systems, with hash linkage

---

5.7.3 Credential Schema Design for Disclosure Control

Credential authors (e.g., DAOs, UN agencies) can:

• Define disclosure policies per claim

• Group fields into disclosure classes

• Mark certain fields as always hidden, optional, or context-dependent

Example credential fragment:

"credentialSubject": {
  "id": "did:nsf:human:0x9ab2...",
  "jurisdiction": "KEN",
  "role": "FieldLogisticsOfficer",
  "redacted_fields": {
    "sim_output_hash": "REDACTED",
    "training_records": "REDACTED"
  }
}

Selective disclosure support must be declared in the VC’s metadata:

"@context": ["https://www.w3.org/2018/credentials/v1", "https://nsf.gcri.global/vc/privacy/v1"],
"proof": {
  "type": "BbsBlsSignature2020"
}

---

5.7.4 Disclosure Policies and Clause Requirements

Smart Clauses may define required credential claims for execution.

Example clause condition:

require VC.discloses("role", "jurisdiction")
and VC.has_valid_proof()

If a VC is presented without the required claims—or with unverifiable redactions—execution fails deterministically.

This enables runtime enforcement of minimum disclosure policies, without requiring full credential visibility.

---

5.7.5 Privacy-Preserving Zero-Knowledge Proofs (ZKPs)

In highly sensitive domains, credential holders may present:

• A ZK-SNARK/STARK proving they:

  • Possess a VC issued by did:nsf:org:UNDRR-DAO

  • Hold role = “SimulationAuditor”

  • Belong to jurisdiction = “EGY”

  • Are not revoked (via Merkle proof of status = “active”)

…without revealing:

• Their full DID

• The entire credential

• The simulation they audited

• Their internal agency structure

ZK circuits used in NSF must be:

• Standardized

• Open-source

• Audit-compliant

• DAO-approved (for production environments)

---

5.7.6 Integration With Revocation and Expiry Systems

Selective disclosure must retain full compliance with:

• SMT-based revocation

• Credential expiration fields

• Audit trails

This is achieved by:

• Proving the disclosed fields match a leaf in the Merkle credential tree

• Anchoring revocation status inside the ZK proof

• Timestamping VC usage events in the Audit Layer, even if full credential is never exposed

---

5.7.7 Field-Level Metadata for Disclosure Control

NSF credential schemas include optional field metadata:

"role": {
  "value": "SimulationAuditor",
  "disclosure": "required_for_clause('[email protected]')"
},
"personal_details": {
  "value": "REDACTED",
  "disclosure": "never"
}

Credential oracles can then:

• Validate policy compatibility of disclosures

• Detect unauthorized disclosure of forbidden fields

• Trigger privacy violation alerts for governance review

---

5.7.8 Credential Holder Tools for Privacy Presentation

NSF credential wallets (CLI or GUI) support:

• Disclosing only required claims for a clause

• Generating ZK proofs using embedded oracles

• Simulating DAO governance challenges

• Exporting disclosure receipts (auditable logs)

Wallets operate within:

• DAO-published credential frameworks

• Execution-layer compatibility matrices

• Local or cloud-based privacy policies

---

5.7.9 Audit Layer Logging Without Breaching Privacy

When credentials are used in privacy-preserving mode:

• Only disclosure metadata is logged (e.g., field role was shown)

• No raw credential content is persisted

• Proof hashes, clause IDs, and usage timestamps are always retained

This allows NSF to:

• Guarantee institutional observability

• Respect human and machine privacy

• Support retroactive governance queries (within policy limits)

---

5.7.10 Privacy as a First-Class Right in Machine-Led Governance

Selective disclosure in NSF isn’t optional—it’s foundational.

It ensures that:

• Trust isn’t earned by oversharing

• Governance happens with consent, not exposure

• Zero-trust doesn’t mean zero privacy

• Transparency is procedural, not personal

The result: privacy-preserving governance—auditable, programmable, and compliant with international norms.