# Selective Disclosure and Privacy-Preserving Proofs

#### **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:

```json
"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:

```json
"@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:

```scl
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:

```json
"role": {
  "value": "SimulationAuditor",
  "disclosure": "required_for_clause('RiskAudit@3.2')"
},
"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.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.therisk.global/organization/standardization/nexus-sovereignty/v.-verifiable-credentials/selective-disclosure-and-privacy-preserving-proofs.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.