CAC Privacy: Selective Disclosure and ZK Anchoring

Balancing Transparency, Confidentiality, and Cryptographic Proof in Risk-Aware Governance

4.8.1 Why Privacy Is Foundational to Verifiable Governance

In domains such as:

• Public health

• Supply chain traceability

• Disaster response logistics

• Financial aid disbursement

• Security and migration management

Clause execution often involves sensitive data:

• Personal identifiers

• Geolocation traces

• Forecasts with market-moving implications

• Institutional credential metadata

• Enforcement logic under sovereign control

NSF must balance:

Goal	Tension
Transparency	Verifiable, auditable clause execution
Confidentiality	Redacting sensitive data from public logs
Compliance	Supporting GDPR, HIPAA, and treaty-bound data handling
Zero Trust	Ensuring trust without revealing secrets

The answer: CAC Privacy Framework powered by Selective Disclosure and ZK Anchoring.

---

4.8.2 Core Privacy Constructs in CACs

CACs support multi-layered privacy controls:

Layer	Mechanism
Input-level redaction	Only hashes of inputs stored publicly
Output filtering	Action-only CACs expose decisions, not reasoning
Selective disclosure	Disclose only required fields based on VC or policy scope
ZK Anchoring	Zero-knowledge proofs of correct execution without revealing logic, inputs, or outputs
Encrypted CAC payloads	For DAO or jurisdiction-specific consumption
Sealed audit trails	Accessible only with proper governance credentials

---

4.8.3 Selective Disclosure Model

CAC fields are tagged:

"fields": {
  "trigger": {
    "type": "sensor",
    "value": "[REDACTED]",
    "disclosure_policy": "RevealTo:WHO-VC#AdminOnly"
  },
  "outputs": {
    "action": "Revoke:ExportVC",
    "disclosure_policy": "Public"
  }
}

Rules are:

• Defined per clause or DAO governance

• Enforced at execution time

• Attached to the CAC and signed as metadata

• Recorded in Registry Layer and optional Access Ledger

Agents only see what they are authorized to see, based on:

• Role

• Jurisdiction

• Credential

• Clause trust class

---

4.8.4 ZK Anchoring of Clause Execution

For fully private clauses:

• Logic is compiled into a ZK circuit (e.g., SNARK, STARK)

• Inputs are committed via hash

• Prover generates:

  • Proof of execution

  • Proof of compliance with simulation or trigger

• Outputs are embedded or referenced separately

• Public can verify:

  • The clause ran as declared

  • Under attested input hashes

  • In governance-approved scope

  • Without seeing any raw data

Example circuit:

circuit: "[email protected]"
proof_type: "Groth16"
verifier_contract: "eth://0x7fa8..."
commitments: {
  "input_hash": "0xabc123...",
  "clause_hash": "0xdef456..."
}

---

4.8.5 Encrypted CAC Payloads and Decryption Policies

CACs can contain:

• Encrypted fields (e.g., sensor_data, personal_credentials)

• With recipient-specified access policies (e.g., DAO public key, sovereign court key)

• Supporting:

  • Multi-party access

  • Timelocks

  • Jurisdictional filters

  • Emergency override logic

Encryption schemes include:

• AES-GCM (symmetric)

• ECIES (recipient-keyed)

• Proxy re-encryption (for credential-scoped redistribution)

---

4.8.6 Privacy-Tiered CAC Classification

Tier	Description
Public CAC	All fields visible (e.g., emissions triggers, open governance)
Scoped CAC	Inputs/outputs redacted unless in jurisdiction DAO
Confidential CAC	Requires VC to decrypt output/action
ZK-Proven CAC	No content revealed; proof only
Ephemeral CAC	Action recorded; full trace sealed unless dispute raised

Each clause declares its privacy_profile:

"privacy_profile": "ZK-Proven + Credential-Gated Output"

---

4.8.7 Credential-Linked Decryption

Only agents with matching verifiable credentials can decrypt sealed CAC components.

Example:

access_control: {
  required_credential: "DisasterOpsCommanderVC",
  jurisdiction: "FRA",
  action: "Decrypt CAC payload"
}

This enables:

• Redacted but actionable CAC streams

• Verified internal coordination

• Minimization of data exposure

• Trustable agent autonomy

---

4.8.8 Public Ledger Anchoring Without Disclosure

CACs can be:

• Hash-anchored to L1/L2 blockchains

• Time-stamped and notarized

• Stored as Merkle roots only

• Without revealing:

  • Clause logic

  • Inputs

  • Agent identity

  • Simulation model

The ledger proves:

“Something verifiable happened, and you can check inclusion if authorized.”

---

4.8.9 Redaction Trails and Forensic Recovery

Every redaction is:

• Logged

• Signed by DAO governance

• Accompanied by:

  • RedactionReasonVC

  • AuditRetentionHash

• Subject to override only by:

  • Dispute court

  • Emergency governance

  • Treaty-mandated disclosure review

This ensures privacy does not override accountability.

---

4.8.10 Privacy in NSF as a Pillar of Trust, Not a Barrier

In NSF:

• Transparency and privacy are not opposites—they are co-designed

• Trust is derived from verifiable process, not open exposure

• Auditability, not visibility, is the guarantee

• Credentials, ZKPs, and sealed CACs allow governance to scale without data leaks

Privacy is not a privilege—it is a constitutional layer of the NSF trust protocol.