System Architecture
This page presents the end-to-end architecture for identity tokenization systems, covering component interactions, security boundaries, and data flow patterns.
Architecture Overview
An identity tokenization system consists of five core functional areas:
- Issuer/Authority - Establishes identity and issues the foundational UIN
- Tokenization Service - Manages token generation, validation, and de-tokenization
- Consent Service - Records user consent and issues User Consent Tokens
- Verifier/Relying Party - Requests and consumes identity attributes
- Audit/Logging - Records all operations for accountability
Figure 1: High-level architecture showing component relationships
Component Details
Issuer / Identity Authority
The trusted authority responsible for identity proofing and UIN issuance.
| Sub-component | Function |
|---|---|
| Enrollment Service | Collect and verify identity documents and biometrics |
| UIN Generator | Generate unique, non-meaningful identifiers |
| UIN Registry | Store UIN-to-identity mappings |
| PII Vault | Secure storage for personal attributes |
| Lifecycle Manager | Handle updates, deactivation, deceased processing |
Tokenization Service
The core service that manages token operations.
| Sub-component | Function |
|---|---|
| Token Generator | Create cryptographically random tokens |
| Sectoral Derivation | Derive sector-specific identifiers from UIN |
| Token Validator | Verify token validity and status |
| De-tokenizer | Resolve tokens to attributes with consent verification |
| Token Store | Persist token-to-reference mappings |
| HSM Interface | Cryptographic operations via hardware security module |
Consent Service
Manages user consent lifecycle and authorization.
| Sub-component | Function |
|---|---|
| Consent Manager | Record, update, revoke consent grants |
| UCT Issuer | Generate signed User Consent Tokens |
| UCT Validator | Verify consent token validity and scopes |
| User Portal | Web/mobile interface for consent management |
| Consent Registry | Store consent records with audit trail |
Audit/Logging Layer
Provides comprehensive accountability and monitoring.
| Sub-component | Function |
|---|---|
| Event Collector | Aggregate events from all components |
| Immutable Store | Append-only, tamper-evident storage |
| Query Interface | Search and retrieve audit records |
| Anomaly Detector | Identify suspicious patterns |
| Report Generator | Compliance and operational reports |
Data Flow Patterns
Enrollment Flow
- Subject presents identity documents to Issuer
- Issuer verifies documents and performs identity proofing
- UIN Generator creates unique identifier
- UIN and verified attributes stored in Registry/Vault
- Subject receives confirmation (may include credential)
- Audit log records enrollment event
Consent Grant Flow
- Relying Party requests specific attributes with stated purpose
- Request routed to User Portal or consent channel
- User reviews request details (scopes, purpose, RP identity, duration)
- User approves or denies request
- Consent Service records decision and issues UCT
- UCT returned to Relying Party
- Audit log records consent grant
Data Disclosure Flow
- Relying Party presents UCT to Tokenization Service
- Tokenization Service validates UCT with Consent Service
- Consent Service verifies: audience, scopes, expiry, revocation status
- If valid, Tokenization Service retrieves requested attributes
- Attributes formatted according to scope (may be derived/aggregated)
- Response returned to Relying Party
- Audit log records disclosure event
Figure 2: Selective disclosure ensures minimal data exposure
Separation of Duties
Security depends on proper separation between components:
Critical Separations
| Separation | Rationale |
|---|---|
| Issuer ↔ Tokenization Service | Tokenization operator should not have direct access to raw PII |
| Tokenization Service ↔ Relying Parties | RPs receive only authorized attributes, never full records |
| Consent Service ↔ Data Access | Consent recording is independent from data retrieval |
| Operations ↔ Audit | Those performing actions should not control audit records |
| Key Custodians ↔ Data Access | HSM operators should not have access to token store contents |
Trust Boundaries
The architecture defines several trust boundaries:
- Identity Authority Boundary: Highest trust, controls UIN issuance and PII
- Platform Boundary: Tokenization and Consent services, controlled access to identity data
- Relying Party Boundary: Limited trust, receives only authorized data
- User Boundary: Subject controls consent grants via authenticated channels
Data Minimization Boundaries
The architecture enforces data minimization at multiple layers:
Layer 1: Collection
- Collect only attributes necessary for identity proofing
- Define minimum dataset for each identity level
- Do not collect "nice to have" attributes
Layer 2: Storage
- Separate PII vault from operational systems
- Store tokens and references, not PII, in application databases
- Apply retention limits and automated purging
Layer 3: Disclosure
- Selective disclosure releases only requested claims
- Derived attributes where possible (e.g., "over 18" vs. birth date)
- Scopes limit what can be requested
Layer 4: Analytics
- Use tokenized identifiers for operational analytics
- Anonymize data for aggregate analysis
- k-anonymity or differential privacy for sensitive queries
Deployment Considerations
High Availability
- Tokenization service is on the critical path - design for high availability
- Multiple HSM instances with key replication
- Database replication for token and consent stores
- Geographic distribution for disaster recovery
Scalability
- Stateless tokenization service allows horizontal scaling
- Token store can be sharded by token prefix
- Caching for frequently validated tokens (with careful invalidation)
- Async processing for non-critical operations (audit, analytics)
Network Architecture
- PII Vault in isolated network segment
- HSM in dedicated secure network
- API Gateway for external access with WAF
- Service mesh for internal communication with mTLS
Standards Alignment
The architecture aligns with relevant standards:
| Standard | Relevance |
|---|---|
| OSIA (Open Standards Identity APIs)[9] | API specifications for identity services |
| W3C Verifiable Credentials | Credential format and verification |
| SD-JWT[8] | Selective disclosure in JWT format |
| OAuth 2.0 / OpenID Connect | Authorization framework |
| ISO 27001 | Information security management |
| eIDAS | Electronic identification (EU context) |
Related Resources
- Integrator Guide - Implementation details and code patterns
- Administrator Guide - Governance and procurement
- Concepts - Foundational concepts explained
Disclaimer: This website provides educational content about identity tokenization concepts and architectures. It does not constitute legal advice. Organizations should consult qualified legal and technical professionals when implementing identity systems.