Security & Privacy
Security and privacy model for S.I.G.N. including data placement, selective disclosure, audit access controls, and operational security practices.
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:
Integrity
evidence and records cannot be forged without detection
state transitions are verifiable over time
Confidentiality
sensitive citizen data is not exposed broadly
privacy-sensitive payments remain confidential to the public
Availability
systems continue operating under national concurrency and adversarial conditions
Non-repudiation
actions (issuance, approvals, distributions) are cryptographically attributable
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 and New Capital System pages.)
Last updated
Was this helpful?