# 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](https://docs.sign.global/national-systems/new-money-system) and [New Capital System](https://docs.sign.global/national-systems/new-capital-system) pages.)