Digital Identity Wallet — Verify Once, Prove Anywhere

The citizen journey

1. The Government Identity Authority verifies the citizen and issues a signed identity credential to the wallet. Its issuance checks establish the original evidence; the wallet does not create that authority.
2. The Driving Licence Authority and University Credential Service issue their own driving and education credentials. Each issuer remains responsible for its claims, signing keys, validity periods and status.
3. The wallet checks incoming credentials and keeps accepted credentials in encrypted device storage. The holder manages which credentials are available and can review disclosure requests.
4. For bank onboarding, the bank requests specific identity attributes and supplies a fresh transaction challenge. The rental company requests current driving entitlement; the age service requests an issuer-backed eligibility claim.
5. The Consent / Presentation Manager shows the requester, purpose and required claims. The citizen approves, declines or chooses an alternative; approval applies to this presentation, not unrestricted future access.
6. The Proof Generator produces a supported proof for the approved claims, bound to the intended verifier and challenge. An age-only proof needs an issuer-provided threshold claim or a cryptographic scheme capable of proving the predicate.
7. Each relying party verifies the cryptographic proof, its holder binding and freshness, the issuer’s authority to make those claims, and the credential’s current status. The bank’s internal design shows this split in detail.
8. The verifier returns a result to its business flow. Bank onboarding, age access or rental proceeds only if local policy accepts the evidence. Education credentials can support a later qualification check using the same roles; no fourth verifier is added just to enlarge this example.

Why architects should care

This is a trust-distribution problem that extends beyond login. Authentication establishes access to a session; a credential carries an issuer’s claim that another organization must interpret, trust and accept for a specific purpose.

• Where does trust originate? Identify who can authorize an issuer for identity, driving or education, and how that decision can be challenged or withdrawn.
• Who sees which attributes? Trace disclosure through wallet code, verifier services, status endpoints and logs, including identifiers that could link otherwise separate transactions.
• What survives a lost wallet? Decide whether recovery restores keys, restores encrypted credentials, or requires reissuance, and who can authorize each path.
• How do industries interoperate? Agree on claim meanings, assurance levels, accepted formats and issuer scope. A mathematically valid signature does not make a foreign qualification or licence acceptable.
• What is consent evidence? Make the approved claim set, requester and purpose understandable to the holder; define retention without creating a universal record of citizen activity.

Architecture at a glance

• Issuer — verifies evidence in its own domain, creates and signs credentials, and remains responsible for corrections, expiry and status.
• Holder — receives credentials in a personal wallet, controls presentation and authorizes the disclosure. The holder and credential subject coincide in this scenario; delegation would need a separate design.
• Verifier / relying party — requests transaction-specific claims, checks evidence and applies its own acceptance policy. Bank, rental and age-service verification are independently operated.

The Trust Registry / Issuer Directory provides governed discovery of issuer authority and verification keys. The Credential Status / Revocation Service represents issuer-controlled status endpoints, not a single shared citizen database. A production implementation can federate directories and distribute signed status lists; neither capability needs to process the full presentation.

Context shows the independent organizations and their trust relationships. Container focuses on wallet custody and the bank interaction. Component expands receipt, consent and proof generation alongside the bank’s presentation verifier, trust resolver and status checker. Other issuers and verifiers remain in the model and Context view; the deeper views intentionally focus on one transaction.

Key architectural decisions

• Keep credentials with the holder. Issuers retain their authoritative domain records; verifiers receive transaction evidence. There is no universal citizen profile store or central presentation broker.
• Request claims, not unrestricted identity records. Bind a request to purpose, audience and challenge; the wallet must reject unnecessary disclosure or offer an alternative.
• Make selective disclosure an explicit capability choice. Revealing fewer signed claims and proving an age predicate are different operations. Select credential formats and issuer claims that support the required evidence.
• Separate signature validity from issuer authority. The trust resolver checks whether a recognized issuer is permitted to attest the requested claim under the relying party’s policy.
• Verify status independently of the wallet. Relying parties obtain signed issuer status evidence with bounded freshness; the wallet’s assertion that a credential is valid is insufficient.
• Keep acceptance and audit local to each relying party. Shared trust infrastructure supports independent issuers; it should not become the operator of every citizen transaction.

Trust, security and the privacy boundary

Credential authenticity depends on protected issuer keys and verification of the secured credential or derived proof. The verifier must also check audience, fresh challenge, holder binding where required, expiry and requested claim semantics. It validates evidence before the business workflow decides whether the evidence is sufficient.

The device is a security boundary. Local encryption, protected key facilities and user presence can reduce misuse, but a compromised wallet can still expose credentials or misrepresent a request. Issuer compromise requires coordinated trust withdrawal, investigation and reissuance; routine credential revocation alone may not address forged issuance.

Consent makes a disclosure visible and specific; it does not by itself make an excessive request appropriate. Selective disclosure can reduce attributes shared, while stable identifiers, repeated signatures, device metadata and status lookups can still correlate activity. Prefer issuer-supported minimal claims, privacy-conscious status distribution and limited local evidence retention. Do not claim anonymity merely because a birth date was omitted.

Recovery must re-establish control with appropriate assurance. A recoverable backup can improve availability while creating another target; reissuance can limit key reuse while imposing verification costs. Fraud detection and audit should retain justified decision evidence at the organization that made the decision, with access and retention rules. Avoid a central log containing every presentation or the full personal profile.

Failure and abuse scenarios

• Compromised issuer — distrust affected keys or authority, determine the exposure window and require fresh evidence or reissuance. A valid-looking signature from a compromised key cannot be accepted on cryptography alone.
• Stolen device — protected keys and user presence limit use; revoke or reissue affected holder-bound credentials according to policy. Do not recover access using only possession of the lost device’s identifiers.
• Revoked credential — reject the requested entitlement even when the original signature remains valid. Distinguish revoked or suspended status from a network error.
• Malicious verifier — show its identity and requested attributes, reject excessive requests, and allow the holder to decline. Bank identity disclosure is not the default template for an age-only service.
• Unavailable status service — return indeterminate, retry or use sufficiently fresh signed cached evidence only where policy allows. Never silently treat an unavailable check as valid; offline high-risk bank onboarding may need to wait.
• Expired credential — reject or request renewal unless an explicit policy accepts a historical fact. A degree awarded in the past and a current driving entitlement have different freshness requirements.
• Replayed presentation — reject a consumed challenge, wrong audience or expired transaction proof. Signing a presentation is insufficient if it can be reused in another transaction.

Questions for the architect

• Would you allow offline verification, for which transactions, and with what maximum age of trust and status evidence?
• How would you recover a lost wallet without turning a help desk or backup provider into a weaker identity authority?
• Who should operate the trust registry, authorize issuers for each claim type, and resolve disputed trust decisions?
• Should relying parties retain verification evidence? What minimum record supports audit without enabling unnecessary correlation?
• How would this architecture work across national borders when trust governance, claim definitions and assurance levels differ?
• Which attributes should support selective disclosure, and which eligibility questions need issuer-backed threshold claims or predicate proofs?
• Where would you draw the privacy boundary between holder, verifier, issuer, status distribution and operational logging?

Explore and adapt the architecture

Inspect the embedded diagram and switch between Context, Container and Component to follow the relationships. After publication, Open presentation provides a larger canvas and Remix this architecture opens a new local copy in the existing Designer. Change one trust assumption, issuer governance model or recovery policy, then trace which relationships and acceptance decisions must change. The original curated architecture remains separate from your remix.