# Security & Privacy

## Purpose

This page defines the security and privacy posture expected for S.I.G.N. deployments:

* what goes on-chain vs off-chain,
* how privacy is preserved while keeping lawful auditability,
* the baseline security controls operators should implement.

This is not legal advice; each jurisdiction should adapt controls to local law and procurement rules.

***

## Security goals

S.I.G.N. deployments should satisfy:

1. **Integrity**
   * evidence and records cannot be forged without detection
   * state transitions are verifiable over time
2. **Confidentiality**
   * sensitive citizen data is not exposed broadly
   * privacy-sensitive payments remain confidential to the public
3. **Availability**
   * systems continue operating under national concurrency and adversarial conditions
4. **Non-repudiation**
   * actions (issuance, approvals, distributions) are cryptographically attributable
5. **Auditability**
   * authorized parties can reconstruct “who did what, when, and why”
   * evidence is inspection-ready and consistent across systems

***

## The privacy principle: “private to the public, auditable to lawful authorities”

This means:

* **The public** should not be able to trivially enumerate:
  * citizen identities,
  * balances,
  * private benefit distributions,
  * sensitive eligibility data.
* **Authorized oversight** can verify:
  * that rules were followed,
  * that recipients were eligible at time of distribution,
  * that budgets reconcile to outcomes,
  * that approvals exist for exceptional actions.

The mechanism is a combination of:

* **data minimization** (do not publish sensitive payloads),
* **cryptographic proofs** (prove without revealing),
* **segmented rails** (public vs private settlement),
* **access-controlled audit systems** (lawful inspection).

***

## Data classification and placement

### Recommended classification

* **Public**
  * program rulesets (high-level)
  * aggregate statistics
  * public benefit distributions (when transparency is desired)
* **Restricted**
  * issuer keys, operator runbooks, monitoring endpoints
* **Confidential**
  * PII
  * private payment details
  * eligibility payloads
  * internal case files and investigations
* **Sensitive (lawful access only)**
  * audit reconstruction maps linking pseudonyms to identities
  * regulatory investigation artifacts

### Placement rules of thumb

* **PII should be off-chain** by default.
* **On-chain artifacts should be proofs/anchors**, such as:
  * schema IDs
  * attestation IDs (or commitment hashes)
  * revocation/status registry references
  * rule version hashes
  * audit manifest hashes
  * settlement references (tx hashes / commit IDs)
* **Hybrid** is preferred when:
  * verifiers need open verification,
  * but payload confidentiality must be maintained.

***

## Cryptography and standards (reference)

### Credential + identity stack

* VC model: W3C Verifiable Credentials 2.0
* DID standard: W3C DIDs
* Formats: VC-JWT, SD-JWT VC, JSON-LD with BBS+
* Issuance protocol: OIDC4VCI
* Presentation protocol: OIDC4VP
* Revocation: W3C Bitstring Status List
* Offline presentation: QR and NFC
* mDL compatibility: ISO/IEC 18013-5/7

### Signature schemes (reference)

* ECDSA (secp256k1, P‑256)
* EdDSA (Ed25519)
* RSA

### Privacy / ZK (reference)

* Groth16, Plonk
* BBS+ (unlinkable credentials / selective disclosure)

### ePassport integration (reference)

* ICAO 9303 compatible proofs/verification

***

## Privacy mechanisms in practice

### Selective disclosure

A holder can prove a predicate (e.g., “age ≥ 18”) without revealing the underlying value (exact DOB).

### Unlinkability

When supported, presentations should prevent third parties from linking:

* the same citizen across different service contexts,
* or the same credential presentation across time.

### Minimal disclosure

A verifier should request only what is necessary:

* a “yes/no” eligibility proof instead of full identity payload,
* an attribute proof instead of a complete credential.

***

## Payment privacy (New Money System alignment)

A common pattern is dual-rail support:

* **Public rail** for transparency-first use cases\
  Example: public spending programs where the state wants public accountability.
* **Private rail (CBDC)** for confidentiality-first use cases\
  Example: sensitive assistance programs requiring strong privacy protections.

Within a private CBDC rail, privacy tiers may exist:

* **wCBDC** (wholesale): RTGS-like transparency for institutions
* **rCBDC** (retail): stronger privacy protections (potentially ZK-based)

***

## Access control and lawful audit

### Role-based access control (RBAC)

Deployments should define:

* who can issue credentials,
* who can approve distributions,
* who can operate bridges,
* who can run indexers,
* who can perform audits.

### Audit access

Audit access should be:

* logged,
* time-bounded,
* least-privilege,
* and require multi-party approval when appropriate.

### Evidence export

Audits should be able to export:

* signed approvals,
* rule versions and hashes,
* batch manifests and reconciliation outputs,
* settlement references,
* revocation/status proof checks.

***

## Operational security baseline

### Key management

* Root governance keys should be protected by **HSM** and/or **multisig**.
* Issuer keys (credential/attestation signing) should be separated by agency/domain.
* Operator keys (infrastructure) should not be issuer keys.
* Rotation and recovery must be documented and tested.

### Monitoring and incident response

Minimum recommended:

* service health dashboards (indexers, APIs, bridge)
* tamper-evident logs
* alerting for abnormal issuance/distribution rates
* rollback / pause procedures for emergency controls

### Supply chain and SDLC security

* dependency scanning + SBOM generation
* reproducible builds where possible
* staging environments mirroring production
* third-party audits for critical components
* bug bounty program / coordinated disclosure

***

## Threat model (high-level)

Threats to plan for:

* **Credential forgery / issuer compromise**
  * mitigations: trust registry, issuer governance, key custody, revocation
* **Sybil or duplicate claims**
  * mitigations: identity-linked targeting, duplicate prevention rules, attestation checks
* **Bridge abuse**
  * mitigations: atomicity, limits, approvals, monitoring, emergency pause
* **Indexer/API tampering**
  * mitigations: integrity anchors, replayable verification from raw sources, signed responses (optional)
* **Privacy leakage via metadata**
  * mitigations: minimal disclosure, unlinkability, careful logging and analytics policies

***

## Recommended evidence artifacts (standard set)

Every sovereign program should be able to produce:

* **RuleSet**
  * `ruleset_id`, `ruleset_version`, `ruleset_hash`
* **Eligibility proof reference**
  * VC presentation proof or attestation reference, plus status check time
* **Distribution manifest**
  * list of recipients (pseudonymous references), amounts, timestamps, assets
* **Settlement references**
  * public tx hash or private commit ID(s)
* **Audit export package**
  * signed approvals, logs, reconciliation outputs

(Examples appear in the [New Money System](/national-systems/new-money-system.md) and [New Capital System](/national-systems/new-capital-system.md) pages.)


---

# 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.sign.global/s.i.g.n./security-privacy.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.