# New ID System (Verifiable Credentials)

## 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](https://docs.sign.global/national-systems/new-money-system)
* Distribution + RWA: [New Capital System](https://docs.sign.global/national-systems/new-capital-system)
* Deep attestations + schemas: [For Builders](https://docs.sign.global/for-builders/getting-started)
* Full vocabulary: [Glossary](https://docs.sign.global/reference/index)