Decentralised Identity vs Federated Identity: Trust Anchors, Privacy and When to Use Each

Federated identity puts an identity provider in the middle of every login, while decentralised identity hands the user a signed credential and takes the issuer out of the transaction, and the two models fail in very different ways. Federation (SAML 2.0, OpenID Connect) has run enterprise and consumer single sign-on for two decades. Decentralised identity, built on the issuer, holder and verifier model of verifiable credentials and on wallets, now has final OpenID protocols and a legal push from the EU Digital Identity Wallet. This guide compares the two on trust anchors, threat models, privacy and correlation, operational burden and agent use cases, and gives decision criteria and a worked scenario. It is for identity architects, CIAM owners and relying party teams deciding whether to accept wallet credentials, keep federating, or run both.

Key takeaways

• The trust anchor moves. In federation the relying party trusts an identity provider at login time; in decentralised identity the verifier trusts an issuer's signing key and the holder's proof of possession, and the issuer need not be online.
• The worst failure differs. A compromised identity provider signing key lets an attacker impersonate any user everywhere at once; a compromised issuer key forges credentials, but a stolen wallet key affects one holder.
• Privacy is a design choice in both. Federation exposes which services a user visits to the identity provider; credentials remove that, but reused identifiers and signatures can still let verifiers correlate users.
• They are converging, not competing. OpenID4VP and OpenID4VCI reuse OAuth 2.0 patterns, NIST SP 800-63C-4 treats a subscriber-controlled wallet as a kind of identity provider, and many deployments use a wallet once to prove attributes and federation afterwards.
• Regulation sets the calendar in the EU. Regulation (EU) 2024/1183 requires Member States to offer wallets and certain private relying parties to accept them, on deadlines counted from the implementing acts.

Short answer

Use federation when the same organisation, or a stable set of partners, controls the accounts and you need session login, central revocation and simple operations: workforce SSO, partner access, consumer social login. Use decentralised identity when a verifier needs high-assurance attributes from an authority it has no account relationship with (age, nationality, a licence, a qualification, an employment status), when the issuer should not learn where the credential is used, or when regulation requires wallet acceptance. In practice most relying parties will do both: accept a wallet presentation for onboarding or step-up, then issue their own account and federate from there. The vocabulary is in the Verifiable Credentials Guide and the federation basics in Federation vs SSO.

Side-by-side comparison

Trust anchors and architecture in words

Federated identity

The user authenticates to the IdP, which issues a signed assertion naming the RP as audience. The RP trusts the assertion because it holds the IdP's metadata and signing certificate, exchanged once when the federation was set up. NIST SP 800-63C-4 requires federation transactions to be governed by trust agreements that set the subscriber population, permitted assurance levels, redress and data retention, and defines federation assurance levels: FAL2 requires injection protection, single-RP audience restriction and a pre-established trust agreement; FAL3 adds holder-of-key assertions or a bound authenticator at the RP. Multi-party federations scale this with signed metadata aggregates or trust chains; see the OpenID Federation and Trust Chains Guide.

Decentralised identity

An issuer signs a credential containing claims about a subject and binds it to a key held by the holder's wallet. OpenID4VCI 1.0, final since 16 September 2025, defines issuance as an OAuth-protected API with authorisation code and pre-authorised code flows, and requires key proofs to include the issuer identifier as audience. Later, a verifier sends a request, and the wallet returns a presentation; OpenID4VP 1.0, final since 9 July 2025, defines the vp_token response, the DCQL query language, direct_post response modes for cross-device flows, and requires a fresh nonce in every request. The verifier checks the issuer's signature against a trust anchor it already holds, the holder's proof of possession, the nonce and the credential status. The W3C Verifiable Credentials Data Model 2.0 became a W3C Recommendation on 15 May 2025. Credential formats are compared in mdoc vs SD-JWT.

NIST SP 800-63C-4 bridges the two: it describes a general-purpose IdP, where the account is made available by the credential service provider without the subscriber's involvement, and a subscriber-controlled wallet, where the account is made available through issued attribute bundles and the wallet acts as the IdP. See the NIST SP 800-63C-4 Federation Assurance Levels Guide.

Federated identity: threat model, failure modes and controls

• Threat model: the IdP is a single point of trust for every connected service. An attacker who takes over the IdP, its admin plane or its signing key can mint assertions for any user (MITRE ATT&CK T1606.002 SAML Tokens), and a compromised partner IdP becomes a trusted relationship into your services (T1199 Trusted Relationship).
• Failure modes: forged assertions after signing key theft, as in the SolarWinds compromise, where a stolen SAML token-signing certificate let attackers sign in as any user to federated services without MFA; XML signature wrapping in SAML parsers; missing audience or issuer checks; account linking by email address, which lets anyone who controls a matching address at another IdP take over an account; stale trust in a partner that has been breached.
• Controls: keep signing keys in HSMs and treat them as tier-zero; enforce audience, issuer, expiry and replay checks; prefer OIDC with PKCE or holder-of-key assertions for high-value RPs; link accounts on stable subject identifiers, never on email alone; monitor for tokens without a matching IdP sign-in event; review partner trust on a schedule. Deeper coverage: Identity Federation Failure Modes and the Golden SAML and Federation Trust Abuse Defence Guide.

Decentralised identity: threat model, failure modes and controls

• Threat model: trust is spread across many issuers, many wallets and many verifiers. The attacker targets the weakest of them: an issuer's onboarding, an issuer signing key, a wallet on a compromised phone, a verifier that skips checks, or the trust list that tells verifiers which issuers to believe.
• Failure modes: verifiers accepting credentials without checking status, so revoked credentials keep working; replay where a verifier disables holder binding (OpenID4VP allows this, but then requires a high-entropy state value and accepts that replay is possible); pre-authorised code interception during issuance, which the specification mitigates with a transaction code sent over a separate channel; trust list sprawl, where a verifier accepts any issuer that publishes a DID; wallet cloning where keys are software-only; phishing of the wallet user by a fake verifier asking for more attributes than needed.
• Controls: keep cryptographic holder binding on (the OpenID4VP default); require a fresh nonce and check it; check status on every presentation and cache with a short lifetime; allowlist issuers through a governed trust list rather than any resolvable DID; require wallet and key attestations for high-assurance credentials (see the Wallet Unit Attestation and Device-Bound Keys Guide); authenticate the verifier to the wallet using a signed request with a client identifier prefix such as x509_san_dns or verifier_attestation; request the minimum claims. Verifier build steps are in Relying Party Integration with Digital Identity Wallets.

Where each attack lands

Privacy and correlation

The privacy argument for decentralised identity is that the issuer is not in the presentation path. NIST SP 800-63C-4 notes that a federation IdP could build a profile of subscriber transactions from knowing which RPs a subscriber uses, and recommends pairwise pseudonymous identifiers (PPIs) so that RPs cannot join records. Credentials remove the IdP's view but create a different risk: the W3C data model warns that "identifiers of any kind increase correlatability", and a credential presented unchanged to several verifiers lets them link the user by its signature or identifier.

• Federation mitigations: pairwise subject identifiers per RP, minimal claim release, and contractual limits on IdP use of login data.
• Decentralised mitigations: selective disclosure (SD-JWT, standardised as RFC 9901, and mdoc), issuing batches of single-use credentials so that each verifier sees a different signature, omitting subject identifiers where not needed, and predicate claims such as "over 18" instead of a birth date. See the SD-JWT and SD-JWT VC Guide.
• Legal backstop in the EU: Regulation (EU) 2024/1183 states that the wallet provider shall not collect information about wallet use beyond what the service needs, requires wallets to support privacy-preserving techniques that ensure unlinkability where identification is not needed, and requires wallets to generate pseudonyms stored encrypted and locally.

Neither model is private by default. A federation with pairwise identifiers can leak less than a wallet that presents the same full credential everywhere.

EUDI wallet timelines and what they mean for relying parties

Regulation (EU) 2024/1183, which amends eIDAS to establish the European Digital Identity Framework, entered into force on 20 May 2024. Its deadlines run from the implementing acts rather than from the regulation itself:

The first wallet implementing acts, including Commission Implementing Regulation (EU) 2024/2982 on protocols and interfaces, entered into force on 24 December 2024. Counting from that date points to wallets being due around the end of 2026 and private relying party acceptance around the end of 2027, though later implementing acts and national arrangements can affect exact dates: confirm with the official text and your regulator. Recital 56 names sectors such as transport, energy, banking and health. For architecture, see the EUDI Wallet Architecture and Reference Framework Guide. This is a summary, not legal advice.

Agent credential use cases

AI agents and other non-human identities already use federation heavily: workload identity federation, OAuth client credentials and token exchange let an agent obtain short-lived tokens from a central authority. Decentralised patterns are being proposed for questions federation answers poorly: which organisation operates this agent, which person delegated authority to it, and what it is permitted to do, proven to a counterparty with no shared IdP.

Agent credential profiles are still emerging, so treat any long-lived agent credential as a high-value NHI secret: bind it to a hardware or workload key, keep validity short and log every presentation. Track the work in the Agent Identity Standards Tracker and see Know Your Agent (KYA) and the Agent-to-Agent Authentication Guide.

Decision criteria

Small organisations should usually consume wallets through their CIAM or identity verification provider rather than run verifier infrastructure. Large relying parties and issuers need their own trust list governance, status checking at scale and a key management plan for issuer keys. See the Customer IAM (CIAM) Guide.

Worked scenario: a bank adds wallet onboarding

An EU bank runs customer login through its CIAM platform with OpenID Connect, and federates to a few fintech partners. It must accept EUDI wallets at customer request.

1. Keep federation for sessions: customers keep signing in through the bank's IdP; partners keep their OIDC trust. Nothing in the regulation requires replacing this.
2. Add a verifier for onboarding and step-up: the bank registers as a relying party, builds an OpenID4VP verifier with signed requests, and asks only for the claims needed for customer due diligence through DCQL.
3. Govern trust: it accepts person identification data only from issuers on the official trust lists, requires holder binding, checks the nonce and status on every presentation, and logs the issuer, credential type and result without storing the full credential.
4. Bind to the account: after a successful presentation, the bank links the wallet-proven identity to the customer account on a verified identifier, not on email, and then issues its own session via federation.
5. Test and roll back: it pilots with staff wallets in a test environment, then a percentage of new customers, keeping the existing document check as fallback so that a wallet or trust list problem can be switched off without stopping onboarding.
6. The point: decentralised identity proves who the customer is once, from an authority; federation keeps them signed in afterwards. Each model does the part it is good at.

Detection and measurement

• Federation signals: assertions or tokens accepted without a matching IdP sign-in event, changes to IdP signing certificates or federation trust, and new account links between IdPs.
• Verifier signals: presentations failing signature, nonce or status checks, presentations from issuers not on the trust list, and repeated requests for more claims than the policy allows.
• Status check coverage: share of accepted presentations with a successful status check, target 100%.
• Holder binding rate: share of presentations with cryptographic holder binding, target 100% for anything above low assurance.
• Pairwise identifier coverage: share of federated RPs receiving pairwise rather than global subject identifiers.
• Key rotation readiness: time to rotate an IdP or issuer signing key and propagate trust, tested at least yearly.

Common failure patterns

• Treating wallets as a login replacement: building session management on repeated presentations, then discovering there is no central way to end a session.
• Verifiers that skip status: accepting a valid signature as proof the credential is current.
• Any-DID trust: accepting any issuer whose DID resolves, which turns a decentralised system into one with no trust anchor at all. See Decentralised identifiers (DIDs).
• Global identifiers in federation: sending the same subject identifier to every RP, then claiming privacy because no passwords are shared.
• Signing keys outside an HSM: for IdPs and issuers alike, a software key on a reachable server is the path to forging every token.
• Over-asking: verifiers requesting full identity data when a predicate would do, which raises breach impact and erodes user consent.

Framework mapping

Practitioner checklist

• Decide per use case whether you need session login (federation), authoritative attributes (credentials), or both.
• Keep IdP and issuer signing keys in HSMs, with a tested rotation and trust update procedure.
• Use pairwise subject identifiers for federated RPs unless a shared identifier is justified.
• For verifiers, require holder binding, a fresh nonce and a status check on every presentation.
• Maintain a governed issuer trust list; never accept any resolvable DID as trusted.
• Authenticate your verifier to wallets with signed requests and request the minimum claims.
• Link accounts on verified, stable identifiers, never on email address alone.
• Map your EUDI wallet acceptance obligations, register as a relying party where required, and track implementing act dates.
• Treat agent credentials of either kind as short-lived, key-bound NHI secrets with logged use.

Standards and references

• EUR-Lex: Regulation (EU) 2024/1183 establishing the European Digital Identity Framework
• EUR-Lex: Commission Implementing Regulation (EU) 2024/2982
• NIST: SP 800-63C-4 Digital Identity Guidelines: Federation and Assertions
• OpenID Foundation: OpenID for Verifiable Presentations 1.0
• OpenID Foundation: OpenID for Verifiable Credential Issuance 1.0
• W3C: Verifiable Credentials Data Model v2.0
• IETF: SD-JWT-based Verifiable Credentials (SD-JWT VC)

Related NHI Mgmt Group resources: Verifiable Credentials Guide · Digital Identity Wallets Guide · Federation vs SSO · EUDI Wallet Architecture and Reference Framework Guide · OpenID for Verifiable Presentations (OpenID4VP) Guide. This guide summarises Regulation (EU) 2024/1183 and is not legal advice.