> For the complete documentation index, see [llms.txt](https://docs.therisk.global/organization/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.therisk.global/organization/standardization/nexus-sovereignty/v.-verifiable-credentials/selective-disclosure-and-privacy-preserving-proofs.md). # Selective Disclosure and Privacy-Preserving Proofs ## Selective Disclosure and Zero-Knowledge Credential Presentation in the Nexus Sovereignty Framework: Privacy-Preserving Verification, Claim-Level Disclosure Control, ZK Non-Revocation, Audit-Safe Credential Use, and Procedural Transparency Without Overexposure ### Why Selective Disclosure Is Critical in NSF Selective disclosure is critical because the Nexus Sovereignty Framework operates in domains where the proof required to establish trust may itself contain sensitive information. A disaster response credential may include location, training history, deployment authority, emergency team membership, or access to logistics routes. A public health credential may include institutional role, jurisdictional authority, epidemiological access rights, health-system affiliation, or protected data privileges. A mobility or migration credential may include identity, vulnerability status, protection category, route history, or legal status. A supply-chain credential may reveal facility relationships, inspection records, trade routes, or commercially sensitive compliance evidence. A finance-readiness or insurance-readiness evidence credential may reveal project data, asset exposure, transaction context, risk model outputs, or diligence-sensitive information. A simulation credential may reveal which model, dataset, agency, reviewer, or scenario was involved. An AI agent credential may reveal model operator, tool permissions, memory policy, restricted data access, or incident status. In such environments, requiring full credential disclosure is unsafe. It can violate privacy, expose vulnerable people, reveal operational security details, compromise market-sensitive information, disclose community-protected knowledge, enable surveillance, weaken institutional trust, or create legal and jurisdictional conflicts. A zero-trust system must verify more, but it must not expose more than necessary. Verification and minimization must be designed together. Selective disclosure allows a credential holder, human, organization, machine, AI agent, or controlled evidence environment, to prove only the claims required for a specific action. The verifier may learn that the holder has an active credential, that the role matches the clause requirement, that the jurisdiction is correct, that the credential is not revoked, and that the credential is within its validity period, without learning unrelated fields. In more sensitive cases, the verifier may learn only that a predicate is true, such as “the holder is authorized for this role in this jurisdiction,” without seeing the holder’s full DID, organizational affiliation, training records, internal agency structure, or underlying evidence. The NSF principle is simple: **Trust should be proven by the minimum information necessary for the authorized purpose, with cryptographic assurance, audit traceability, and no unnecessary exposure of identity, data, role, operational context, or institutional structure.** Selective disclosure is therefore not a privacy feature added to credentials. It is the privacy-preserving presentation layer of verifiable governance. ### Selective Disclosure Is Not Secrecy Without Accountability Selective disclosure does not mean that a credential holder can hide everything and still demand trust. It means that the credential holder can reveal only what the relying clause or verifier needs, while preserving cryptographic linkage to a valid credential, issuer, schema, revocation status, time window, and audit record. A verifier should not need to see a full disaster operator credential if the clause only requires role and jurisdiction. A public-safe output system should not need to see health details if it only needs proof that a public health reviewer is authorized. A finance-readiness workflow should not need to expose all project evidence if the verifier only needs proof that an evidence-room review occurred under a registered clause. A cross-border system should not need to reveal a person’s full identity if a ZK proof can show non-revoked role eligibility. Selective disclosure replaces full visibility with proof-scoped visibility. The verifier receives enough to trust the action. The Audit Layer receives enough to preserve institutional observability. The credential holder retains unnecessary private information. The system remains dispute-capable because commitments, proof hashes, issuer references, clause IDs, credential status roots, and disclosure receipts remain available. The result is not secrecy. It is accountable minimization. ### Concepts and Principles of Selective Disclosure Selective disclosure refers to the ability to present only selected claims from a credential while proving that those claims are part of a valid, signed, non-revoked, non-expired credential. The disclosed claims may be literal values, such as role equals `SimulationAuditor`, jurisdiction equals `EGY`, or credential type equals `PublicSafeReviewerVC`. They may also be predicates, such as age above threshold, risk class within range, credential recognized in jurisdiction, model status active, or training completed. They may also be commitments, such as proof that a CAC exists without revealing its payload. A mature selective disclosure model should satisfy several principles. First, disclosure must be purpose-bound. A field is disclosed because a clause, verifier, or governance workflow requires it for a defined purpose. The same credential may disclose different fields for different actions. Second, disclosure must be minimal. If a predicate is enough, the raw value should not be revealed. If proof of role is enough, training records should not be exposed. If jurisdiction match is enough, exact location should not be disclosed. Third, disclosure must preserve revocation and expiry checks. Privacy must not allow a revoked or expired credential to pass. Fourth, disclosure must preserve issuer and schema integrity. The verifier must know that the credential was issued under an accepted schema by a recognized issuer, even if the full credential remains hidden. Fifth, disclosure must preserve auditability. The system should record proof hashes, disclosed field categories, verifier, clause, time, and outcome without storing unnecessary raw content. Sixth, disclosure must support dispute paths. If a credential use is challenged, authorized review channels must be able to inspect appropriate evidence under policy. Seventh, disclosure must prevent correlation where possible. Reusing the same DID, proof, or presentation identifier across unrelated contexts can expose behavior patterns. Pairwise identifiers, unlinkable proofs, ZK presentation, and disclosure receipts should be used where needed. Selective disclosure is thus both cryptographic and institutional. It defines what machines can verify and what institutions are allowed to know. ### Technical Mechanisms for Selective Disclosure NSF selective disclosure can be implemented through several complementary mechanisms. BBS+ style signatures and related cryptographic signature schemes can support selective disclosure of signed credential attributes. A holder can reveal some claims while proving the signature covers the full credential. This is useful for W3C VC-style credentials where claim-level presentation is needed. Merkleized credential structures can hash credential fields into a tree. The holder reveals selected fields and Merkle proofs showing inclusion under the credential root. Hidden fields remain committed but undisclosed. Zero-knowledge proofs can prove predicates about hidden fields, such as role membership, jurisdiction match, active status, non-revocation, threshold satisfaction, or schema compliance, without revealing the underlying values. Selective disclosure JSON Web Tokens or linked-data proof formats can support practical wallet and verifier interoperability, depending on implementation profile. Pairwise DIDs and holder-binding can prevent one credential presentation from being correlated across contexts. Encrypted presentations can provide field-level disclosure to specific recipients while hiding the same fields from others. ZK non-revocation proofs can prove that a credential is active under a revocation root without exposing the credential ID. No single mechanism covers all NSF needs. Public-safe operational workflows may use selective disclosure signatures. Highly sensitive health or migration workflows may use ZK proofs. Enterprise evidence rooms may use encrypted field-level disclosure. Community-protected knowledge may use controlled-room disclosure and commitments. Edge devices may use compact Merkle proofs. The framework should define interoperable profiles rather than a single universal privacy mechanism. ### Credential Schema Design for Disclosure Control Selective disclosure begins at schema design. Credential authors must declare which fields may be disclosed, which fields are hidden by default, which fields are never disclosed, which fields require credential-gated access, which fields may be proven only as predicates, and which fields require controlled-room review. A credential schema should classify fields by disclosure class. Common classes include public, verifier-required, holder-consented, credential-gated, jurisdiction-restricted, audit-only, encrypted, ZK-only, public-safe summary, community-controlled, sovereign-controlled, enterprise-controlled, and never-disclose. A simplified credential fragment may look like: ```json { "credentialSubject": { "id": "did:nsf:human:0x9ab2", "jurisdiction": "KEN", "role": "FieldLogisticsOfficer", "training_status": "completed", "sim_output_hash": "0x...", "internal_assignment": "restricted" }, "disclosure_metadata": { "id": { "disclosure": "pairwise-or-zk-only" }, "jurisdiction": { "disclosure": "required-for-jurisdictional-clauses" }, "role": { "disclosure": "required-for-role-authorization" }, "training_status": { "disclosure": "predicate-only" }, "sim_output_hash": { "disclosure": "credential-gated" }, "internal_assignment": { "disclosure": "never-public" } } } ``` The credential metadata should also declare supported proof types. A credential may support BBS+ selective disclosure, Merkle inclusion proofs, ZK predicate proofs, encrypted presentations, or controlled-room verification. A privacy-aware VC metadata block may include: ```json { "@context": [ "https://www.w3.org/2018/credentials/v1", "https://nsf.example/context/vc-privacy/v1" ], "privacy_profile": "SelectiveDisclosure+BBS+NonRevocation", "proof": { "type": "BbsBlsSignature2020", "proofPurpose": "assertionMethod" }, "revocation_proof_profile": "SMT-ZK-NonRevocation@1.0" } ``` The seed references `nsf.gcri.global`; final canonical deployment domains should use only active, authorized domains when publishing. In conceptual examples, neutral `nsf.example` avoids implying a live endpoint unless the user provides one. Credential schema authors may include GCRI, GRF, GRA, national registries, regional consortia, community stewards, enterprise evidence rooms, or authorized issuers depending on role. But schema design must preserve role separation and claims discipline. ### Disclosure Policies and Clause Requirements Smart Clauses should define minimum credential claims required for execution. A clause should not request full credential visibility unless necessary. It should declare which fields or predicates are required, which proof profiles are accepted, whether non-revocation proof is required, what freshness window applies, and whether audit logging is mandatory. A clause condition may look like: ```scl require VC.discloses("role") require VC.discloses("jurisdiction") require VC.proves("not_revoked") require VC.proves("valid_at", now) require VC.has_valid_proof() ``` A more privacy-preserving clause may require predicates only: ```scl require VC.proves("role_in", ["SimulationAuditor"]) require VC.proves("jurisdiction_matches", clause.jurisdiction) require VC.proves("credential_status", "ACTIVE") require VC.proves("valid_time_window", now) deny if presentation.discloses("personal_details") ``` If a VC is presented without required claims or proof, execution fails deterministically. If redactions are unverifiable, execution fails or routes to review. If the credential discloses prohibited fields, the system may reject the presentation and trigger a privacy violation alert. This allows runtime enforcement of minimum disclosure policies without requiring full credential visibility. The clause sees what it needs, verifies proof, and refuses over-disclosure where policy demands minimization. Disclosure requirements should be part of clause metadata and Registry Layer records. They should be testable. AI agents and wallets should read them before generating presentations. ### Privacy-Preserving Zero-Knowledge Proofs In highly sensitive domains, selective disclosure may still reveal too much. The fact that a holder is a specific person, belongs to a particular agency, audited a particular model, or holds a sensitive role may itself be private. Zero-knowledge proofs allow credential holders to prove claims without revealing the underlying credential fields. A holder may prove that they possess a credential issued by a recognized disaster-risk evidence issuer, hold the role SimulationAuditor, are authorized in Egypt, are not revoked under the latest status root, and are within the validity window, without revealing their full DID, full credential, exact employer, internal assignment, training record, or model audited. A ZK presentation may prove: The credential signature is valid. The issuer is in an approved issuer set. The credential type matches the clause requirement. The role field equals or belongs to an allowed set. The jurisdiction field matches the clause jurisdiction. The credential is active under an SMT root. The expiration time is after current time. The presentation has not been replayed. The holder is bound to the proof. A proof object may look like: ```json { "presentation_type": "ZKCredentialPresentation", "proof_profile": "NSF-ZK-Role-Jurisdiction-NonRevocation@1.0", "public_claims": { "role_membership": "SimulationAuditor", "jurisdiction_match": "EGY", "issuer_set": "RecognizedSimulationCredentialIssuers@2025-Q2", "status": "ACTIVE" }, "hidden_claims": [ "holder_did", "full_credential", "training_records", "internal_agency_structure", "model_assignment" ], "proof": "zkproof-0x..." } ``` The seed refers to a credential issued by `did:nsf:org:UNDRR-DAO`. Unless an authorized issuer exists, this should be written as a recognized disaster-risk evidence issuer or `UNDRRRef` mapping. Production ZK circuits should be standardized, open to review, conformance-tested, audit-compatible, and governance-approved for their declared scope. “DAO-approved” should be broadened to governance-approved, since NSF governance may be national, regional, community, enterprise, or registry-based. ZK proofs protect privacy, but proof scope must remain explicit. A ZK proof that a person is a SimulationAuditor does not prove that the simulation output is correct. A proof of non-revocation does not prove legal compliance. A proof of issuer recognition does not prove public authority. The circuit proves only the statements encoded. ### Integration With Revocation and Expiry Systems Selective disclosure must preserve revocation and expiry guarantees. Privacy cannot become a way to use revoked credentials. A privacy-preserving presentation should prove that the credential is active under a known status root, that the credential has not expired, that the issuer remains recognized where required, that the credential type is compatible with the clause, and that any required parent credential remains valid. This can be done through SMT proofs, status lists, accumulators, ZK non-revocation proofs, or signed status receipts. If the credential is Merkleized, disclosed fields can be proven as part of the credential tree. If the credential status is SMT-based, the presentation can include a Merkle branch or ZK proof of non-revocation. If the credential is expired, the proof should fail. If the credential is suspended, the proof should fail or disclose restricted status depending on policy. Credential usage should still produce an audit event. The audit event may store proof hash, credential type, issuer set, disclosed field categories, clause ID, verifier DID, timestamp, jurisdiction, status root, and outcome. It should not store hidden credential content. This allows the system to retain observability without breaching privacy. ### Field-Level Metadata for Disclosure Control Field-level metadata allows credential schemas to encode disclosure rules directly. Each field can declare how it may be used. A field may be required for specific clauses. It may be optional. It may be public. It may be holder-consented. It may be proof-only. It may be encrypted. It may be never disclosed. It may require jurisdictional match. It may require community steward approval. It may require controlled-room access. It may require public-safe review before display. A schema fragment may look like: ```json { "role": { "value": "SimulationAuditor", "disclosure": "required_for_clause('RiskAudit@3.2')" }, "jurisdiction": { "value": "EGY", "disclosure": "required_for_jurisdictional_match" }, "personal_details": { "value": "encrypted-or-hidden", "disclosure": "never-public" }, "training_records": { "value": "commitment-only", "disclosure": "predicate-only" } } ``` Credential oracles can validate whether a presentation satisfies policy. They can detect when a holder fails to disclose required fields, when a verifier requests forbidden fields, when a wallet over-discloses, or when an agent attempts to extract hidden data. Privacy violation alerts can route to governance review. Field-level metadata makes privacy executable and testable. ### Credential Holder Tools for Privacy Presentation Selective disclosure requires usable tools. Credential holders, human, organizational, machine, or agentic, need wallets and presentation systems that can interpret clause requirements, generate correct disclosures, produce ZK proofs, check revocation roots, and create disclosure receipts. An NSF-compatible credential wallet should be able to read a clause’s disclosure requirements, identify which credentials satisfy them, generate a presentation containing only required claims, prove non-revocation and expiry, use pairwise DIDs where appropriate, generate ZK predicates, encrypt fields for authorized recipients, warn the holder about over-disclosure, and produce an audit receipt. For advanced users, a CLI wallet may support policy simulation, proof generation, controlled-room export, and offline presentation. For institutional users, a GUI wallet may support role-based workflows, credential bundles, public-safe review, and disclosure approvals. For machine and AI agents, wallet functionality may be embedded into runtime policy gates. Wallets should operate within published credential frameworks, execution-layer compatibility matrices, local privacy policies, jurisdictional constraints, and user or institutional preferences. They should not silently reveal hidden fields because a verifier asks. They should not allow AI agents to summarize hidden claims unless disclosure policy permits. Privacy must be operationally easy, or it will fail in practice. ### Audit Layer Logging Without Breaching Privacy When credentials are used in privacy-preserving mode, the Audit Layer should log enough to support institutional observability without storing raw credential content. It should record proof hash, presentation profile, clause ID, verifier DID, issuer set, credential type, disclosed field categories, status root, timestamp, jurisdiction, outcome, and audit policy. It should not persist full credentials, hidden fields, sensitive personal details, training records, internal assignments, protected community knowledge, market-sensitive data, or restricted evidence payloads unless a controlled audit policy explicitly permits it. An audit event may state: a credential presentation proved active SimulationAuditor role in Egypt for RiskAudit\@3.2 under status root X at time Y. It need not reveal the holder’s full DID or all credential fields. For dispute review, the Audit Layer can preserve proof commitments and disclosure receipts. Authorized reviewers may request additional evidence through governed channels if policy permits. If a credential presentation is challenged, the holder or issuer may provide controlled disclosure, ZK witness review, or registry proof under dispute rules. Auditability is preserved through commitments and proofs, not raw exposure. ### Selective Disclosure for CAC-Linked Credentials Many NSF credentials are CAC-linked. Selective disclosure must allow a holder to prove that a credential is supported by a CAC without revealing the full CAC. For example, a FinanceReadinessEvidenceVC may prove that a controlled evidence CAC exists and is valid without revealing confidential project evidence. An InsuranceReadinessEvidenceVC may prove that hazard model review occurred without exposing asset-level exposure data. A PublicSafeReviewerVC may prove training and role eligibility without disclosing personal records. A DisasterOperatorVC may prove training and jurisdiction without revealing full deployment history. A CAC-linked selective presentation may disclose: Credential type. Issuer set. Role or predicate. Jurisdiction. Non-revocation proof. Clause binding hash. CAC hash or rollup inclusion proof. Authority class. Non-meaning boundary. It may hide: Full CAC payload. Personal identifiers. Training records. Operational location. Simulation details. Project evidence. Community-protected knowledge. This allows CAC-linked credentials to remain useful without exposing the evidence they protect. ### Selective Disclosure for AI Agents and Copilots AI agents must be privacy-aware credential presenters and verifiers. An agent presenting its own credentials should reveal only the tool-use claims required for a task. An agent verifying a human or institutional credential should request only the claims required by the clause. An agent summarizing credential status should not expose hidden fields or infer sensitive attributes. Agent policies should prevent over-disclosure. If a verifier asks for full credential content where a predicate is sufficient, the agent should reject or request justification. If a user asks an agent to reveal hidden credential data, the agent should follow access policy. If the agent has access to restricted credential fields, its output should be public-safe checked before disclosure. AI agents can amplify privacy failures. NSF must make selective disclosure a mandatory agent behavior, not an optional wallet setting. ### Selective Disclosure for Project SPVs, Finance-Readiness, and Insurance-Readiness Project SPV and capital-relevant workflows need selective disclosure because underlying evidence is often confidential. A Project SPV may need to prove that an asset operator credential is active, that climate scenario review occurred, that safeguard evidence exists, that data provider authority is valid, that monitoring evidence is current, or that finance-readiness evidence has been assembled, without disclosing contracts, financial models, asset exposure, pricing assumptions, or confidential engineering records. Selective disclosure allows authorized reviewers to receive proof of evidence status, CAC inclusion, schema completeness, and reviewer credentials. More detailed evidence can remain in controlled rooms. Public summaries can expose only boundary-safe status, such as evidence package active, under review, expired, or superseded. Finance-readiness selective disclosure must not imply finance approval, investment advice, credit rating, or guarantee. Insurance-readiness selective disclosure must not imply underwriting, coverage, pricing, claim determination, or insurability. The disclosed credential should carry non-meaning fields so verifiers and AI agents do not overinterpret the proof. Selective disclosure makes capital-relevant evidence verifiable without making it public. ### Selective Disclosure for Community and Indigenous Data Governance Community and Indigenous data governance requires especially careful selective disclosure. A credential may prove that a community steward approved a public-safe output, that protected knowledge review occurred, or that a data access request was authorized, without exposing protected knowledge, sacred sites, community identities, local vulnerability data, or internal governance records. Community-controlled credentials may require collective governance rules, community-defined disclosure classes, local-language consent records, protected knowledge commitments, and controlled review paths. Public verifiers may see only proof that community review occurred under an active steward credential. Authorized community bodies may access more. Selective disclosure protects collective rights as well as individual privacy. ### Disclosure Receipts and Accountability Each credential presentation should produce a disclosure receipt. The receipt records what was disclosed, what was hidden, what proof profile was used, which clause required the disclosure, who requested it, when it occurred, what status root applied, and what outcome resulted. It may be stored by the holder, verifier, and Audit Layer in privacy-appropriate form. A disclosure receipt protects both sides. It proves that a holder did not overshare beyond policy. It proves that a verifier requested only required fields. It supports disputes if a verifier later claims a field was disclosed when it was not. It supports privacy audits if a wallet or agent reveals prohibited fields. Disclosure receipts make privacy operationally auditable. ### Selective Disclosure Boundary Statement Selective disclosure and ZK credential presentation support privacy-preserving role verification, claim minimization, non-revocation proof, expiry verification, CAC-linked evidence proof, credential bundle validation, AI agent access control, Project SPV evidence confidentiality, finance-readiness evidence, insurance-readiness evidence, public-safe disclosure, community data stewardship, and audit-safe credential use. They do not by themselves create legal compliance, regulatory approval, certification, public authority status, procurement approval, finance approval, investment advice, insurance underwriting, claims determination, official public warning status, treaty compliance, legal privilege, or immunity from lawful disclosure. Selective disclosure proves selected claims or predicates under a proof profile. The authority and legal meaning of those claims depend on issuer authority, credential schema, jurisdiction, recognition rules, applicable law, contracts, community rules, institutional adoption, and public-safe policy. A selective disclosure proof is not full transparency. A ZK proof proves only the encoded statement. A hidden field is not erased. A disclosure receipt is not legal privilege. A finance-readiness proof is not finance approval. An insurance-readiness proof is not underwriting. A public-safe credential presentation is not official public authority unless competent authority provides that status. This boundary must appear in credential schemas, wallets, verifier tools, agent policies, audit dashboards, disclosure receipts, and public documentation. ### Privacy as a First-Class Right in Machine-Verifiable Governance Selective disclosure in NSF is foundational because zero-trust governance should not mean zero privacy. A system can be verifiable without being invasive. A credential can be trusted without being fully exposed. A clause can authorize action without seeing unrelated personal data. An audit trail can preserve institutional memory without storing raw sensitive content. An AI agent can verify permission without learning more than its task requires. A public-safe output can show proof without revealing protected evidence. The NSF privacy principle is: **Trust is earned by proof, not oversharing.** Governance should happen with consent, minimization, role-bound access, public-safe disclosure, and correction paths. Transparency should be procedural before it is personal. Auditability should be based on commitments, proofs, status roots, and disclosure receipts, not uncontrolled exposure of human, community, institutional, sovereign, or enterprise data. Selective disclosure makes this possible. It allows credentials to operate in high-stakes environments where full disclosure would be unsafe, unlawful, or institutionally unacceptable. It lets NSF support disaster relief, public health, mobility, migration, supply chains, simulations, AI agents, Project SPVs, finance-readiness evidence, insurance-readiness evidence, and public-safe governance without turning credential verification into surveillance. That is the role of selective disclosure in the Nexus Sovereignty Framework: to make trust machine-verifiable while keeping privacy, dignity, sovereignty, and institutional confidentiality intact. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## 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, and the optional `goal` query parameter: ``` GET https://docs.therisk.global/organization/standardization/nexus-sovereignty/v.-verifiable-credentials/selective-disclosure-and-privacy-preserving-proofs.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.