Reusable Identity vs Self-Sovereign Identity Compared

"Verify once, use everywhere" can mean two very different architectures: a provider that keeps your verified identity in its own account and shares it on request, or a wallet in which you hold signed credentials yourself. Both promise to end repeated document uploads and selfie checks, and both are sold as reusable identity, but they put the credential, the keys, the fraud risk and the revocation switch in different hands. This guide compares provider-held reusable identity with holder-held, self-sovereign style credentials on custody, threat model, fraud, revocation, privacy and the trust decision a relying party has to make. It is for CIAM owners, KYC and fraud leads, and identity architects. The protocol basics are in the Verifiable Credentials Guide and the federation contrast is in Decentralized Identity vs Federated Identity; this page goes deeper on custody and reliance.

Key takeaways

The question is custody. In provider-held reusable identity the verified record and the signing keys stay with the provider; in self-sovereign identity the holder keeps a signed credential and a device-bound key, and the issuer need not be involved at presentation.
Each model concentrates a different risk. A provider-held profile store is a high-value honeypot and its account recovery is the weak point; a wallet spreads data out but moves risk to device security, key binding and the verifier's checks.
Revocation works differently. A provider can stop sharing a profile instantly; a holder-held credential stays valid until a verifier checks a status list such as W3C Bitstring Status List and refuses it.
Reliance is a decision, not a feature. Whichever model you accept, you are relying on someone else's proofing: document the assurance level, the trust framework and who carries liability before you switch off your own checks.
Most relying parties will accept both. EU Digital Identity Wallets arrive from 2026 alongside existing hosted identity accounts and bank ID style schemes, so plan one policy engine that evaluates either kind of evidence.

Short answer

Choose provider-held reusable identity when you want a fast, mature integration today, your users already have accounts with a trusted provider, and you are comfortable with that provider seeing each verification request. Choose holder-held credentials (self-sovereign identity, verifiable credentials, EUDI Wallet) when you need high-assurance attributes from an authority with which you have no contract, want to minimise data you receive, or face a legal duty to accept a wallet. If your obligations are anti-money laundering (AML) customer due diligence, the answer turns less on architecture and more on whether the scheme's assurance and governance meet your regulator's expectations; the FATF Guidance on Digital Identity asks regulated firms to judge the assurance level of a digital ID system's technology, architecture and governance and whether it is reliable and independent enough for the risk.

What each term actually means

Reusable identity (provider-held)

A user completes identity proofing once with a provider: document capture, liveness and a database or fraud check. The provider stores the verified attributes in an account it controls. When a second relying party needs the same attributes, the user signs in to the provider and consents, and the provider returns claims, usually over OpenID Connect, sometimes with OpenID Connect for Identity Assurance metadata describing how the claims were verified (see the OpenID Connect for Identity Assurance Guide). Bank ID schemes and government sign-in accounts follow the same pattern. In NIST SP 800-63C-4 terms this is a general-purpose identity provider: it verifies authenticators bound to the subscriber account and makes the account available to relying parties.

Self-sovereign identity (holder-held)

The term was popularised by Christopher Allen's 2016 essay The Path to Self-Sovereign Identity, which set out ten principles including control, portability, consent and minimalisation. In practice it is implemented with verifiable credentials: an issuer signs claims about a subject and transmits them to a holder, who keeps them in a credential repository such as a wallet and later generates presentations for verifiers (W3C Verifiable Credentials Data Model v2.0, a W3C Recommendation since 15 May 2025). NIST SP 800-63C-4 calls this a subscriber-controlled wallet: software on a subscriber-controlled device, or a hosted service, that is issued signed attribute bundles and then acts as the identity provider.

Note the hosted-wallet case: a cloud wallet that holds credentials and keys on the holder's behalf sits between the two models. Judge it by where the keys and the presentation decision live, not by the label.

Side-by-side comparison

Dimension	Provider-held reusable identity	Holder-held credentials (SSI, VC, EUDI Wallet)
Where verified data lives	Provider database, one record per user	In the holder's wallet; issuer keeps its own source records
Who signs what the relying party receives	The provider, per request (ID token or assertion)	The issuer, once, at issuance; the holder adds a fresh key-binding proof
Online at verification	Provider must be online for every reuse	Holder and verifier; issuer only for status lists, if at all
Who learns where the user goes	The provider sees every relying party request	Issuer does not see presentations; colluding verifiers may correlate shared identifiers
Typical protocols and formats	OpenID Connect, OIDC for Identity Assurance, SAML	OpenID4VCI, OpenID4VP 1.0, SD-JWT VC (RFC 9901), ISO/IEC 18013-5 mdoc, W3C VC 2.0
Revocation	Provider stops sharing or flags the account; immediate for new requests	Issuer flips a status bit; effective only when verifiers check status
Data minimisation	Depends on provider scopes and consent screen	Selective disclosure built into SD-JWT and mdoc; age over 18 without birth date
Main attack target	Provider account takeover and the central profile store	Wallet device, key extraction, issuer signing keys, verifier misconfiguration
Liability and recourse	Contract with the provider; defined in its terms and any scheme rules	Trust framework or law (eIDAS 2.0 for EUDI Wallets); often no direct contract with the issuer

Threat model: provider-held reusable identity

Architecture in words: user, provider, relying party. The relying party trusts the provider's signing key and its proofing; the user's only credential is their login to the provider.

Account takeover equals identity takeover: whoever controls the provider login can share a verified identity with any new relying party. Phishable passwords or SMS codes on the provider account undo the value of strong proofing. Require phishing-resistant authentication at the provider for any share above low assurance; see the Passwordless and Passkeys Guide.
Recovery is the soft spot: help desk or email-based recovery lets an attacker rebind the account. Recovery should re-run proofing to the original level, not a knowledge check.
Central profile store: one database holds document images, selfies and attributes for every user. Breach impact is population-wide. Ask how long raw images are kept after verification and whether they are needed at all after the attributes are extracted; see Securing the Identity Verification and KYC Platform Itself.
Stale verification: the profile records what was true at proofing time. A document can expire, a person can die, a profile can be built on a stolen identity and reused across many services. Fraud seeded once spreads everywhere the profile is accepted; see the Synthetic Identity Fraud Guide.

Controls: phishing-resistant authentication at the provider, re-binding (a fresh liveness or face match against the stored template) on high-risk reuse, freshness claims (verification date and method in the assertion), signed and audience-restricted assertions at FAL2 or above, and contractual breach notification and liability terms.

Threat model: holder-held credentials

Architecture in words: issuer, holder wallet, verifier, plus a trust list or registry of issuers and, for EUDI, a wallet attestation. The verifier trusts the issuer's key, the wallet's key-binding proof and, where required, an attestation that the wallet app and its key storage are genuine.

Stolen or cloned device keys: if the holder key is exportable, a credential can be copied and presented by someone else. NIST SP 800-63C-4 notes that FAL3 for a device wallet may require non-exportable key storage. Ask for wallet unit or key attestation; see the Wallet Unit Attestation and Device-Bound Keys Guide.
Replay of a presentation: OpenID4VP 1.0 (Final, 9 July 2025) requires a fresh nonce in every request and warns that presentations without holder binding may be replayed. RFC 9901 key-binding JWTs carry aud, nonce, iat and sd_hash; the verifier's own policy, not the presence of a key-binding JWT, must decide that binding is required, so an attacker cannot strip it.
Wallet onboarding fraud: the wallet is only as good as the proofing done when the credential was issued. A wallet onboarded on a stolen identity carries a perfectly valid signature. See the Digital Identity Wallet Fraud Risks Guide.
Unchecked status: a revoked credential still verifies cryptographically. If the verifier skips the status check or cannot reach the list and fails open, revocation does nothing.
Rogue verifiers and over-asking: phishing sites can request credentials too. Verifier authentication (OpenID4VP client identifier prefixes such as x509_san_dns or verifier_attestation) and EU relying party registration let the wallet show the user who is asking and for what.
Correlation: the W3C data model warns that identifiers of any kind increase correlatability; the same credential identifier or signature shown to two verifiers lets them link the user. Use batch-issued, single-use credentials or formats that support unlinkable presentations where privacy matters.
Issuer key compromise: forged credentials for anyone, until the key is removed from the trust list and every verifier refreshes.

Controls: trust list based issuer validation, required key binding, wallet attestation for higher assurance, nonce and audience checks, status checks that fail closed above a defined risk threshold, and minimum claim requests.

Fraud and revocation compared

Event	Provider-held response	Holder-held response	What the relying party should do
User reports stolen phone	Provider revokes sessions; account still recoverable by the user	Issuer revokes or suspends the device-bound credential (status purpose revocation or suspension); user re-issues to new device	Re-check status on next sensitive action; do not rely on a cached result
Identity found to be synthetic	Provider closes the profile; past shares are not recalled	Issuer revokes; past presentations already accepted	Subscribe to provider or issuer notifications where offered and re-review accounts onboarded with that identity
Source document expires	Provider may or may not re-verify; ask	Credential `validUntil` passes; verifier must check it	Enforce maximum evidence age per use case
Provider or issuer key compromise	All assertions suspect; provider rotates and notifies	Trust list removal; all credentials from that key suspect	Keep a kill switch per trusted issuer or provider; log which accounts relied on which key
Status endpoint unavailable	Not applicable: no answer, no share	Verifier must choose fail open or fail closed	Decide per risk tier and cache lists within their stated TTL

The W3C Bitstring Status List v1.0 Recommendation sets a minimum list size of 131,072 entries so each check hides among a crowd, asks issuers to assign indexes randomly and publish lists in a cacheable way, and recommends verifiers cache lists or use Oblivious HTTP so the issuer cannot watch who checks what. A one-to-one mapping between a credential and its list URL would defeat this.

Privacy and data protection

Minimisation: holder-held formats let the user disclose only selected claims. RFC 9901 lets the holder send none, some or all disclosures; mdoc supports the same idea. Provider-held schemes can minimise too, but only if the relying party asks for narrow scopes and the provider honours them.
Visibility: the European Commission describes an EUDI Wallet privacy dashboard that shows every relying party the user has dealt with and the data shared, and lets the user ask for deletion or draft a complaint to a data protection authority. A provider-held scheme offers whatever dashboard the provider chooses to build.
Truth versus authenticity: the W3C data model is explicit that verifiability does not establish that claims are true. Both models move the question of truth to the issuer's or provider's proofing, which is why assurance level matters more than format.

Regulation and trust frameworks

EU: Regulation (EU) 2024/1183, adopted 11 April 2024 and in force since 20 May 2024, amends eIDAS to create the European Digital Identity Framework. The Commission states that every Member State will offer at least one EU Digital Identity Wallet by 2026, free to users. Relying party obligations, timelines and registration are covered in the eIDAS 2.0 and the European Digital Identity Framework Guide and the technical profile in the EUDI Wallet Architecture and Reference Framework Guide.
UK: the UK digital verification services trust framework is the statutory framework under section 28 of the Data (Use and Access) Act 2025; version 1.0 was published on 9 June 2026. GOV.UK identity checking guidance (GPG 45) is built on evidence, validity, fraud checks, verification and activity history. See the UK Digital Verification Services Trust Framework Guide.
US: NIST SP 800-63-4 gives a common language: IAL for proofing, AAL for authentication, FAL for federation, and explicit treatment of subscriber-controlled wallets. Mobile driving licences follow ISO/IEC 18013-5:2021; see the Mobile Driving Licence (mDL) Guide.
AML: whether a regulated firm can rely on either model for customer due diligence depends on its national AML rules on reliance and digital identity. FATF's 2020 guidance is technology-neutral and frames the test as assurance plus independence. Confirm your regulator's position before reducing your own checks; see the Identity Verification Requirements Map.

Relying party trust decisions

Whichever model presents the evidence, the relying party makes the same five decisions.

Whose proofing am I accepting? Name the provider or the set of issuers (by trust list), and the assurance level each claims: IAL2 under NIST SP 800-63A-4, a GPG 45 profile, or eIDAS level of assurance high.
How fresh must it be? Set a maximum age for the original verification and for status checks. Opening a savings account and buying age-restricted goods need different answers.
How is the presenter bound to the evidence? Provider-held: phishing-resistant login at the provider plus optional re-binding. Holder-held: required key binding, and wallet attestation for high assurance.
What happens when revocation information is missing? Fail closed for high-value actions, fail open with a later re-check for low-risk ones, and log which choice was taken.
Who pays when it goes wrong? Provider-held schemes put this in a contract. Holder-held schemes put it in a trust framework or law, and often there is no contract with the issuer at all. Your legal team should read both.

Decision criteria

If this is true	Lean towards	Why
You need to launch reuse within a quarter	Provider-held	Mature OIDC integrations; wallets still rolling out
You are an EU relying party in scope of wallet acceptance duties	Holder-held (plus existing)	Acceptance is a legal duty, not a preference
The attribute comes from a public authority (licence, nationality, qualification)	Holder-held	Authority-signed credential, no intermediary database
You must not reveal to a third party which users join you	Holder-held	Issuer does not see presentations
Your users are mostly on shared or older devices	Provider-held, with step-up	Wallets depend on device secure hardware
You need ongoing monitoring (perpetual KYC)	Provider-held or hybrid	Providers can push changes; credentials are point-in-time. See Perpetual KYC.
You want the smallest stored data footprint	Holder-held with selective disclosure	Receive only the claims needed

Small versus large organisations: a small relying party should integrate one provider or wallet aggregation service and keep data minimal; a large one should build a policy layer that maps several providers and wallet credentials to assurance levels and can switch any one off.

Worked scenario: a lender adds reusable onboarding

A consumer lender in the EU currently runs its own document and selfie checks. It wants to cut drop-off and prepare for EUDI Wallets.

Phase 1, provider-held: it integrates one certified reusable identity provider over OpenID Connect, requesting only name, date of birth, address and the verification method and date. It accepts the result only where verification is under 12 months old and the provider login used a passkey; otherwise it runs a fresh liveness re-binding.
Phase 2, pilot wallet acceptance: it adds an OpenID4VP verifier for person identification data from EUDI Wallets in one Member State, registered as a relying party, with key binding required, wallet attestation checked and status lists cached with a fail-closed rule for loan amounts above its threshold.
Phase 3, single policy: both routes produce the same internal record: evidence source, assurance level, verification date, binding method, status check result. Fraud rules (velocity, device and application data) run identically on both.
Testing and rollback: each route runs in shadow mode for a month alongside the existing checks, comparing outcomes. A per-provider and per-issuer kill switch returns customers to the legacy flow without code changes.

Detection and measurement

Log per verification: evidence source (provider or issuer identifier), assurance level, verification date, binding method, nonce, status check result and latency, and the policy decision.
Alert on: spikes in reuse of one profile or credential across many new accounts, presentations failing key binding, status checks that time out, and new accounts linked to a later-revoked identity.

Metric	What it shows
Share of onboardings by route (own checks, provider, wallet)	Adoption and dependence on each trust anchor
Fraud rate per route at 90 days	Whether reused evidence is as good as fresh checks
Status checks performed per presentation (target 100%)	Whether revocation can work at all
Median age of accepted verification evidence	Freshness drift
Time to act on an issuer or provider revocation notice	Response speed when upstream evidence fails
Attributes stored per customer versus attributes required	Data minimisation in practice

Framework mapping

Framework	Reference	Relevance
NIST CSF 2.0	PR.AA-02	Identities are proofed and bound to credentials based on context: the core of both models
NIST CSF 2.0	GV.SC-05	Contract terms with identity providers and wallet aggregators
NIST SP 800-53 Rev. 5	IA-12	Identity proofing, including accepting external proofing
NIST SP 800-53 Rev. 5	IA-8	Identification and authentication of non-organisational users
NIST SP 800-53 Rev. 5	SA-9	External system services: the provider or verifier service you depend on
NIST SP 800-63-4	800-63A-4 IAL, 800-63C-4 FAL and wallets	Assurance levels and subscriber-controlled wallets

Common failure patterns

Treating a valid signature as a verified person: skipping key binding or accepting presentations without a nonce, so a copied credential works for anyone.
Silent fail-open on status: status list unreachable, verifier accepts anyway, revoked credentials keep working.
Weak login on a strong profile: a provider account proofed to a high level but protected by password and SMS, so account takeover hands over a verified identity.
No freshness rule: accepting a reusable profile verified years ago against a document that has since expired.
Over-collecting from wallets: requesting full person identification data when an age-over claim would do, recreating the honeypot the model was meant to avoid.
Undefined liability: switching off in-house checks with no contract or trust framework saying who carries the loss.

Practitioner checklist

Classify each use case by required assurance level and maximum evidence age.
List every accepted provider and issuer, with the trust framework and contract or legal basis for each.
Require phishing-resistant authentication at providers and key binding for wallet credentials.
Check wallet or key attestation for high-assurance presentations.
Check credential status on every presentation and define fail-open or fail-closed per risk tier.
Run the same fraud rules across every onboarding route and compare 90-day fraud rates.
Keep a kill switch per provider and per issuer key, and test it.
Confirm with compliance whether AML reliance on each scheme is permitted before reducing own checks.

Reusable Identity vs Self-Sovereign Identity: Who Holds the Credential and Why It Matters