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


---

# 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/national-systems/new-id-system.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.