New ID System (Verifiable Credentials)

National digital identity and verifiable credentials under S.I.G.N., including SSI principles, trust registry, offline verification, and revocation/status.

Purpose

The New ID System provides a reusable national identity + credentialing layer built on:

• Self-Sovereign Identity (SSI) principles

• W3C Verifiable Credentials (VC)

• W3C Decentralized Identifiers (DID)

• selective disclosure + privacy-preserving proofs

• trust registry + revocation/status infrastructure

This system enables:

• one citizen, one verifiable identity layer (across agencies and regulated operators),

• interoperability across service providers,

• privacy-preserving verification without central “query my identity” APIs,

• standardized, inspection-ready audit evidence.

---

SSI principles (operationalized)

A national SSI design should support:

• User control and consent: holders decide when/where to present credentials

• Portability: credentials usable across agencies and regulated operators

• Privacy by design: disclose only what is required; avoid linkability

• Cryptographic verification: verifiers validate without issuer live queries

• Standards-based interoperability: reduces fragmentation and vendor lock-in

---

Credential lifecycle (VC)

1) Issuance

• Authorized issuer signs a VC bound to a schema

• Credential is delivered to a holder wallet (non-custodial)

2) Storage

• Holder stores VCs locally (device secured)

• Keys and credential material must be protected by device security and policy-approved recovery

3) Presentation

• Holder constructs a presentation (VP)

• Only required attributes are disclosed (or proved via ZK / selective disclosure)

4) Verification

Verifier checks:

• issuer signature validity

• issuer legitimacy via trust registry (accreditation)

• schema compliance (expected fields/types)

• revocation/status validity at verification time

5) Revocation / status

Issuer updates status registry; verifiers check during verification.

---

Components

A) Issuer services

• credential issuance service (OIDC4VCI recommended)

• issuer DID/key custody

• issuer governance and audit logging

B) Holder wallets

Key capabilities:

• non-custodial storage

• biometric/device-protected access

• offline presentation (QR/NFC)

• multi-credential management

• secure key backup/recovery (as approved by policy)

C) Verifier services

• verification SDK/service for VCs and VPs

• status check logic (bitstring status lists)

• verification event logging (evidence)

D) Trust registry (anchored)

Tracks:

• issuer DIDs + public keys

• issuer accreditation status

• approved schemas and schema versions

• revocation/status endpoints/references

• governance policy for issuer onboarding/offboarding

---

Reference technical specifications (identity stack)

• Credential model: W3C Verifiable Credentials 2.0

• Identifier: W3C DIDs

• Formats: VC-JWT, SD-JWT VC, JSON-LD with BBS+

• Signature algorithms: ECDSA (secp256k1, P-256), EdDSA (Ed25519), RSA

• ZK proof systems: Groth16, Plonk, BBS+ (unlinkable credentials)

• Wallet security: device secure enclave + biometric authentication

• Issuance protocol: OpenID for VC Issuance (OIDC4VCI)

• Presentation protocol: OpenID for VC Presentations (OIDC4VP)

• Revocation: W3C Bitstring Status List

• Offline support: QR and NFC-based credential presentation

• mDL compatibility: ISO/IEC 18013-5/7

---

Privacy-preserving verification

Selective disclosure patterns

Examples:

• “age ≥ 18” without revealing full DOB

• “resident of region X” without revealing full address

• “licensed professional” without revealing full license number

Unlinkability patterns

When using unlinkable credentials (e.g., BBS+ or ZK-backed), design verifiers to:

• avoid storing correlatable identifiers

• store minimal evidence required for audit

• rotate verifier session identifiers to reduce metadata linking

---

Revocation and status (recommended model)

A verifier should:

1. verify issuer signature

2. verify issuer trust registry accreditation

3. check status list at verification time

4. log the status check time + reference (evidence)

Example verification evidence (illustrative):

{
  "verification_event_id": "VERIF_2026_04_01_01002",
  "verifier_id": "bank:psp-001",
  "subject_ref": "did:example:citizen:8f1c...",
  "credential_type": "ResidentCredential",
  "schema_id": "schema:resident:v1",
  "issuer_did": "did:example:issuer:gov-id",
  "status_check_ref": "statuslist:bitstring:v1:0xaaa...",
  "status_at_time": "valid",
  "verified_at": "2026-04-01T12:05:00Z"
}

---

How Sign Protocol fits (evidence layer)

Sign Protocol can anchor:

• issuer accreditation events

• schema publication and versions

• verification evidence (when appropriate)

• eligibility proofs for programs

• audit manifests and reconciliation anchors

It also supports privacy modes (including ZK attestations) to avoid exposing sensitive details on public rails.

---

Interoperability with money + capital

Identity → Money

• Identity proofs enable account creation (CBDC or regulated stablecoin)

• compliance checks can reuse credential evidence (per policy)

Identity → Capital / distribution

• eligibility attributes gate access to benefits and subsidies

• duplicate prevention uses identity-linked targeting and evidence checks

---

Where to go next

• Payments rail: New Money System

• Distribution + RWA: New Capital System

• Deep attestations + schemas: For Builders

• Full vocabulary: Glossary