✅ Distributed Trust Registry

Authoritative source of truth for who can issue, verify, and revoke credentials

What It Is

A Trust Registry is a verifiable directory of authorized issuers, verifiers, and credential schemas within an identity ecosystem. It answers critical questions: Who is allowed to issue university degrees? Which organizations can verify health credentials? Is this credential schema valid?

Core Problem: Verifiable Credentials are cryptographically secure, but cryptography alone doesn't establish trust. Anyone can create a DID and issue a credential claiming "Harvard University Diploma." The Trust Registry provides the authoritative answer: "Is did:web:harvard.edu actually Harvard?"

Unlike X.509 Certificate Authorities (centralized), Trust Registries can be distributed— federated across jurisdictions, governed by different authorities (government, industry consortia), yet interoperable. Think DNS for trust: hierarchical, cached, globally resolvable.

Technical Architecture

Core Components

Component Technology Purpose
DID Registry did:web, did:ebsi, DLT-based (e.g., Hyperledger Indy) Map DIDs to real-world entities (verified identities)
Issuer Registry PostgreSQL, EBSI Trusted Issuers API List of authorized credential issuers (with permissions)
Schema Registry JSON Schema, SHACL, W3C VC Context Valid credential types and data models
Revocation Registry Status List 2021, CRL, OCSP Track revoked credentials (expired licenses, fired employees)
Accreditation Store Government database, blockchain ledger Store proof of issuer authorization (audited, time-stamped)
API Gateway REST, GraphQL Verifiers query registry ("Is this issuer authorized?")
Cache Layer Redis, CDN Fast lookups (millions of verifications/day)

Trust Registry Architecture

┌──────────────────────────────────────────────────────────────────┐ │ National Trust Registry (trust.suomi.fi) │ └──────────────────────────────────────────────────────────────────┘ ┌─────────────────────────────────────────────────────────────────┐ │ REGISTRATION (Issuers Apply) │ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ │ │ University │ │ Government │ │ Chamber of │ │ │ │ (Degree) │ │ Agency (ID) │ │ Commerce(CoO)│ │ │ └──────┬───────┘ └──────┬───────┘ └──────┬───────┘ │ │ │ Apply │ Apply │ Apply │ │ │ Authorization │ Authorization │ Authorization │ └─────────┼───────────────────┼───────────────────┼────────────────┘ │ │ │ └───────────────────┼───────────────────┘ │ ┌─────────▼─────────┐ │ Trust Authority │ │ (Governance Org) │ │ - Validates │ │ - Issues DID │ │ - Records Auth │ └─────────┬─────────┘ │ ┌─────────▼─────────┐ │ Trust Registry │ │ (Database) │ │ ┌────────────┐ │ │ │ Issuer: │ │ │ │ did:web: │ │ │ │ university │ │ │ │ fi │ │ │ │ Authorized:│ │ │ │ - Degrees │ │ │ │ - Diplomas │ │ │ │ Valid: │ │ │ │ 2026-2030 │ │ │ └────────────┘ │ └─────────┬─────────┘ │ ┌─────────────────────────────┼─────────────────────────────────────┐ │ VERIFICATION (Verifiers Query) │ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ │ │ Employer │ │ Bank │ │ Gov Portal │ │ │ │ (HR Check) │ │ (KYC) │ │ (E-Service) │ │ │ └──────┬───────┘ └──────┬───────┘ └──────┬───────┘ │ │ │ Query │ Query │ Query │ │ │ "Is did:web: │ "Is did:web: │ "Is revoked?" │ │ │ university.fi │ bank.fi │ │ │ │ authorized?" │ authorized?" │ │ └─────────┼──────────────────┼──────────────────┼───────────────────┘ │ │ │ │ │ │ └──────────────────┴──────────────────┘ │ [API Response: YES/NO] Security: HTTPS + DNSSEC, cached for performance, audit trail for all queries

Registry Types & Hierarchies

National Trust Registry (Finland)

Registry Type Scope Governance
Government Issuer Registry Agencies authorized to issue official credentials (ID, tax, health) Ministry of Finance (centralized approval)
Education Registry Accredited universities, vocational schools Ministry of Education (delegation to accreditation bodies)
Healthcare Registry Licensed hospitals, clinics, pharmacies National Supervisory Authority for Welfare and Health (Valvira)
Business Registry Companies authorized to issue business credentials (B2B) Patent and Registration Office (PRH) + sector regulators
Schema Registry Valid credential types (linked to tietomallit.suomi.fi) Interoperability Platform governance board

EU-Level Federation (EBSI)

The European Blockchain Services Infrastructure (EBSI) provides a distributed trust registry for cross-border recognition. Finnish issuers register in the national registry; that registry federates into EBSI, making Finnish credentials verifiable across EU.

# Trust hierarchy example Level 1: EU Trust Root (EBSI) └─ Level 2: Finland National Registry (trust.suomi.fi) └─ Level 3: Education Sector Registry └─ Issuer: University of Helsinki (did:web:helsinki.fi) └─ Authorized credentials: - Master's Degree in Computer Science - Bachelor's Degree in Engineering Verification flow: 1. Verifier in Germany receives Finnish degree credential 2. Verifier queries EBSI: "Is did:web:helsinki.fi authorized?" 3. EBSI resolves → Finland registry → Education registry 4. Response: "YES, authorized for degree credentials" 5. Verifier trusts credential (cross-border recognition)

Registry Operations

1. Issuer Registration

Process: Organization applies to become authorized issuer.
  1. Application: Submit proof of authority (e.g., university accreditation certificate)
  2. Verification: Trust Authority validates documents, audits security posture
  3. DID Assignment: Organization creates DID (did:web:university.fi), publishes public key
  4. Registry Entry: Trust Authority adds issuer to registry:
    { "issuerDID": "did:web:university.fi", "legalName": "University of Helsinki", "country": "FI", "accreditation": { "body": "Finnish Education Evaluation Centre", "validUntil": "2030-12-31" }, "authorizedCredentials": [ "UniversityDegreeCredential", "DiplomaCredential" ], "status": "active", "registeredAt": "2026-01-15T00:00:00Z" }
  5. Publication: Entry propagates to federated registries (EBSI)

2. Credential Verification

Scenario: Employer verifies job applicant's degree credential.
  1. Receive Credential: Applicant presents VC (signed by did:web:university.fi)
  2. Query Trust Registry:
    GET https://trust.suomi.fi/api/v1/issuers/did:web:university.fi Response: { "authorized": true, "credentialTypes": ["UniversityDegreeCredential"], "status": "active", "accreditationValid": true }
  3. Verify Signature: Fetch issuer's public key from DID document → verify VC signature
  4. Check Revocation: Query Status List 2021 → confirm credential not revoked
  5. Decision: All checks pass → credential trusted

3. Revocation Management

Revocation Method Use Case Performance
Status List 2021 Batch revocation (e.g., expired diplomas) Fast (bitstring lookup), privacy-preserving
OCSP (Online Certificate Status Protocol) Real-time revocation (e.g., stolen credentials) Slower (HTTP request), issuer knows when credential checked
Accumulator-based Privacy-preserving (ZK-SNARKs), no issuer query Complex, emerging (not production-ready)

4. Issuer Suspension/Revocation

Critical Scenario: Issuer's accreditation is revoked (e.g., university loses license).

Action:
  1. Trust Authority updates registry: status: "revoked"
  2. All existing credentials issued by that DID become untrusted
  3. Verifiers querying registry receive: "authorized": false
  4. Credential holders notified: "Your credential issuer is no longer authorized"
Challenge: Balancing revocation speed (security) vs. issuer due process (legal fairness).

Security & Resilience

Threat Model

Attack Mitigation
Fake Issuer Registration Manual verification of legal documents, background checks, security audits
Registry Tampering Blockchain-backed audit log (immutable), append-only database
DNS/HTTPS Hijacking DNSSEC, CAA records, certificate pinning
DDoS on Registry CDN caching (Cloudflare), rate limiting, geo-distribution
Issuer Key Compromise Hardware Security Modules (HSMs), key rotation policies
Insider Threats Multi-party approval for registry changes, audit logs, separation of duties

High Availability Design

# Trust Registry HA Architecture Primary Site (Helsinki): - PostgreSQL primary (active) - Redis cache (hot) - API servers (3x load balanced) Secondary Site (Oulu): - PostgreSQL replica (streaming replication) - Redis cache (replicated) - API servers (standby, auto-failover) CDN Layer (Cloudflare): - Cache TTL: 5 minutes (balance freshness vs. load) - DDoS protection - Global edge distribution Backup: - Daily snapshots to S3 (encrypted) - Point-in-time recovery (1-hour RPO) SLA Target: 99.9% uptime (43 minutes downtime/month)

Privacy Considerations

Challenge: Registry queries leak metadata (who verifies what, when).

Privacy-Preserving Techniques:
  • Batch Queries: Verifier requests multiple DIDs at once (obfuscate specific interest)
  • Anonymous Resolution: Query via Tor, mixnets (hide verifier IP)
  • ZK Proofs: Prove "issuer is in registry" without revealing which issuer (future)
  • Cached Lookups: Verifiers cache registry data locally (reduce query frequency)

Standards & Interoperability

Standard Organization Purpose
Trust over IP (ToIP) Trust Registry Protocol ToIP Foundation API specification for querying trust registries
EBSI Trusted Issuers Registry European Commission EU-level trust registry (DLT-based)
W3C DID Specification W3C Decentralized identifier format (did:web, did:ebsi)
Status List 2021 W3C Community Group Revocation status representation
TRAIN (Trust Registries & Accreditation) GLEIF, ToIP Global Legal Entity Identifier integration

Deployment Roadmap

Phase Timeframe Deliverables
Foundation 2025 National trust registry operational, first 10 issuers registered
Sector Expansion 2026 Education, healthcare, business registries live, 100+ issuers
EU Integration 2027 Finland registry federates with EBSI, cross-border recognition
Private Sector 2027-2028 Banks, employers integrate registry checks into verification workflows
Global Interop 2028+ Recognition of non-EU credentials (US, ASEAN) via mutual agreements

Technical References

Back to Overview