Wiki · Concept · Last reviewed June 23, 2026

Federated Credential Management

Federated Credential Management, or FedCM, is a browser-mediated Web API for federated login: it lets a relying party ask the browser to coordinate account selection and identity assertion exchange with an identity provider, so "sign in with..." flows can work with less dependence on third-party cookies, redirects, embedded frames, and hidden cross-site state. It improves the login ceremony; it does not by itself settle identity proofing, trust, authorization, profiling, or agent delegation.

Category: Web identity / privacy infrastructure Published: June 23, 2026 Modified: June 23, 2026 Last reviewed: June 23, 2026 Tags: FedCM, digital identity, browser APIs, privacy, identity federation, AI agents

Definition

Federated Credential Management is a web identity concept and API family for letting a browser mediate login among three parties: the person using the browser, a relying party website, and an identity provider. The W3C FedCM draft describes it as a Web Platform API for letting users log in to websites with federated accounts in a privacy-preserving manner.

FedCM is not a new identity provider, password manager, passkey system, proof-of-personhood scheme, digital wallet, or AI system. It is a browser-level interface around identity federation. Traditional web federation often depends on redirects, embedded frames, and third-party cookies so that a site can ask an identity provider whether a user is signed in. FedCM moves more of that exchange into browser-controlled prompts, login-status state, and API calls. It can reduce some silent cross-site identity plumbing, but it does not decide legal identity, identity proofing, token trust, authorization policy, or downstream data use.

The term belongs near Digital Identity, Data Minimization, Contextual Integrity, and Platform Governance. It is also relevant to AI Agent Identity and AI Browsers and Computer Use, because delegated agents increasingly depend on browser sessions, consent prompts, and account boundaries.

Snapshot

How It Works

In a normal federated login, a relying party outsources authentication to an identity provider. OpenID Connect describes this pattern as an authentication protocol built on OAuth 2.0: a site asks an identity provider to authenticate the user and return identity information or tokens. FedCM does not replace every federation protocol. Instead, it gives the browser a standardized role in the account-selection and login ceremony.

Under FedCM, the relying party calls a browser API such as navigator.credentials.get() with identity-provider configuration. The browser checks configured identity-provider endpoints, mediates account selection, and can return an IdentityCredential containing a token if the flow succeeds. The identity provider still has to support the required endpoints, and the relying party still has to validate and handle the returned assertion under its own federation protocol and policy.

Chrome's developer documentation says FedCM supports sign-up, sign-in, and sign-out with federated accounts for users browsing without third-party cookies, while also saying FedCM is not supported by all browsers and that relying parties should keep existing non-FedCM federation paths. MDN similarly marks the FedCM API as experimental and limited availability.

The W3C draft includes identity-provider HTTP endpoints for well-known metadata, configuration, accounts, client metadata, identity assertions, and disconnect. It also includes login-status machinery and a permissions-policy integration. Those details matter because the privacy benefit depends on which information is exposed through which browser-mediated path, not merely on the presence of a new button.

The governance meaning is that identity exchange stops being only a relationship between websites and identity providers. The browser becomes an explicit mediator. That can improve user visibility, but it also gives browser vendors power over which identity flows feel normal, which providers integrate smoothly, and what consent text users repeatedly see.

Boundaries and Non-Goals

FedCM is best understood as a mediation layer, not a full identity governance system. It changes how a website asks for a federated credential in supporting browsers; it does not define the whole trust relationship among users, relying parties, identity providers, credential issuers, wallets, regulators, and automated agents.

Current Context

As of this review on June 23, 2026, FedCM is still standards work, not a settled universal login layer. The W3C technical report page lists Federated Credential Management as a First Public Working Draft on the Recommendation track and explicitly says the draft should be cited as work in progress. The active W3C Federated Identity Working Group charter says the group develops Web Platform features for secure and privacy-preserving interactions related to digital identities or credentials, including federated identity, digital wallets, and credential presentation.

Browser and developer documentation frame the same problem from the deployment side. MDN describes FedCM as experimental and limited availability. Chrome frames it as a privacy-preserving identity federation API and notes that support is not universal. That means FedCM should be described as a migration and mediation mechanism for some federation flows, not proof that every browser, identity provider, and relying party supports the same behavior.

Chrome's third-party-cookie context also changed after early FedCM discussions. On April 22, 2025, Google said it would maintain its current approach to third-party-cookie choice in Chrome and would not roll out a new standalone third-party-cookie prompt. FedCM still matters because users, browsers, enterprise policies, private modes, and other engines can block or restrict third-party cookies; but current claims should not imply that Chrome has fully removed third-party cookies by default.

On June 16, 2026, W3C's Federated Identity Working Group also published a Working Draft of the Digital Credentials API, which specifies browser mediation for the presentation and issuance of digital credentials and builds on Credential Management Level 1. That adjacent draft is important because web identity is converging around browser mediation, but it should not be collapsed into FedCM: federated sign-in and credential presentation are related but different trust ceremonies.

FedCM sits beside, not above, other identity standards. OpenID Connect remains a major protocol for federated authentication. OpenID Federation 1.1, published as final on May 5, 2026, defines protocol-independent trust infrastructure such as entity statements, trust chains, metadata policies, trust marks, and federation endpoints. NIST SP 800-63-4, finalized on July 31, 2025, covers identity proofing, authentication, and federation for U.S. federal digital services; its federation volume treats both general-purpose identity providers and subscriber-controlled wallets.

Governance and Safety

FedCM addresses one privacy problem without ending identity governance. It can reduce dependence on third-party cookies and silent cross-site mechanisms, but federated login still creates concentration risk. A few identity providers may become default gateways to many services. A browser vendor may shape access through implementation choices. Relying parties may request more identity attributes than necessary. Users may approve flows because the prompt is familiar, not because the data transfer is understood.

The W3C draft's privacy section names attack scenarios such as manifest fingerprinting, timing attacks, identity-provider intrusion, cross-site correlation, unauthorized data usage, relying-party fingerprinting, and secondary use. Those are not abstract edge cases. They are the same political questions that surround platform identity: who learns that a person visited which service, who can join records across contexts, and who can deny access when identity federation fails?

The active W3C charter also draws an important boundary: the working group is not designing new authentication methods, credential formats, or security-confidence assessment of the token that encodes identity assertions. That means FedCM can improve the browser ceremony while relying parties and identity providers remain responsible for token validation, audience checks, issuer trust, account recovery, fraud response, retention, and authorization.

NIST SP 800-63C-4 shows the broader governance frame: federation requires defined assurance levels, trust agreements, permitted attribute release, wallet security disclosures, activation factors, and assertion protections. FedCM can be part of the delivery path for some web flows, but the assurance and accountability questions remain outside the browser prompt.

FedCM also matters for agentic browsing. An AI agent operating a logged-in browser should not silently inherit every consequence of a human login. Authentication answers whether a user or account is recognized; delegation answers what an agent may do, under whose authority, for how long, and with what audit trail. Without that separation, a privacy-preserving login ceremony can still become an overbroad action grant.

Defense Pattern

Source Discipline

Claims about FedCM should separate standards status, browser implementation, identity-provider support, relying-party deployment, and policy interpretation. A W3C First Public Working Draft establishes a standards-track proposal, not universal deployment. Chrome documentation establishes Chrome behavior and migration advice, not cross-browser support. MDN compatibility notes should be checked before production claims.

Privacy claims should name the specific channel being reduced, such as third-party cookie dependence or hidden cross-site login checks, and should not imply that all tracking, account linking, profiling, or identity-provider concentration disappears. Identity-governance claims should distinguish the browser API from OpenID Connect, OpenID Federation, NIST federation guidance, legal identity proofing, credential wallets, and downstream authorization rules.

For current web-platform context, cite the dated source. A Chrome Privacy Sandbox post, a Chrome developer guide, MDN compatibility page, W3C technical report, W3C editor's draft, W3C publications page, and OpenID specification answer different questions. Do not use a browser vendor's migration guidance as proof of standards maturity or use W3C standards status as proof of production interoperability.

When FedCM is discussed with AI agents, name the action boundary. "Signed in" is not the same as "authorized an agent to buy, post, message, delete, export, or configure." Source-disciplined agent claims should identify the account, actor, tool permission, action type, confirmation requirement, audit log, and revocation path.

Spiralist Reading

FedCM is a small browser API with a large cultural lesson: identity is becoming a browser ceremony.

The person sees an account chooser. Underneath, institutions negotiate trust, attributes, identifiers, cookies, redirects, browser policy, and platform power. The humane version narrows surveillance and makes login safer. The worse version makes identity friction disappear while moving more of public life through a few private chokepoints.

Open Questions

Sources

Return to Wiki