Two APIs Walk Into a Browser: FedCM vs. the DC API
“The web is in the middle of a significant redesign, one that touches on architecture, governance, politics, and more.”
For years, browsers were passive conduits, rendering pages, storing cookies, and quietly stitching together the signals that made identity flows work. That passivity is gone.
Privacy reforms have pushed browsers into new roles. Safari and Firefox got there early with cross-site tracking restrictions; Chrome’s initial stance on the third-party cookie phase-out forced everyone else to pay attention. But while “cookiepocalypse” is what first brought the Federated Credential Management API (FedCM) into the spotlight, the story is more complicated. Google stepped back from full cookie removal after UK regulators raised concerns that deprecating third-party cookies would give Google an unfair advantage in online advertising. Even with that pause, the Chrome team still had a clear problem to solve: federated sign-in was vulnerable, insufficiently privacy-preserving, and overly dependent on tracking-era mechanics.
So instead of treating FedCM as a bandage for a disappearing feature, the team reframed it as an opportunity to create a better user experience—one that would not require hidden redirects, ambient signals, or cross-site cookies to function safely. Privacy and usability, rather than cookie deprecation alone, became the primary justification for the API.
In parallel, entirely new ecosystems around verifiable digital credentials are emerging, and the Digital Credentials API (DC API) is meant to be the web-layer bridge for them. That puts us in an unusual moment: two identity APIs, developed for two very different purposes, landing at roughly the same time, each reshaping the browser’s role in digital identity.
And so the question becomes: how do these APIs relate to each other, and what happens if they collide?
You can Subscribe and Listen to the Podcast on Apple Podcasts, or wherever you listen to Podcasts.
And be sure to leave me a Rating and Review!
FedCM: a user-experience upgrade disguised as a structural repair
FedCM started life because the underlying assumptions of the web were changing. Third-party cookies—one of the invisible building blocks used by various federated identity flows—were going away. But as people dug into the problem, they realized that federated sign-in wasn’t just at risk; it was uncomfortable for users, leaky for privacy, and built on mechanisms never intended for this purpose.
FedCM’s goal, especially after some time examining the cookie problems, moved beyond “keep federated login working.” The idea now is to give users an experience that is safer, clearer, and less ad-tech-shaped.
To do that, FedCM inserts the browser as an active intermediary between:
- the Relying Party, or RP (the site requesting the sign-in),
- the Identity Provider, or IdP (the service supplying the identity), and
- the user (the person deciding whether to allow that relationship).
The browser becomes responsible for:
- showing a consistent, browser-owned account selection interface,
- protecting users from silent tracking,
- enforcing permission steps, and
- ensuring both parties only learn about each other with explicit user consent.
This makes FedCM a smart API, not in the “AI” sense, but in the architectural one:
Smart = the browser makes decisions
A smart API:
- enforces rules,
- manages UX,
- maintains state,
- shapes flows, and
- carries explicit opinions about what good privacy and usability look like.
Right now, Chrome is the only browser implementing FedCM, which is promising and precarious in equal measure. The ecosystem needs more than one implementer if this is going to become foundational. But at least we’re getting real-world experience on how this could work. And that said, I don’t want to ignore the fact that quite a few people do NOT want browsers to be active mediators in the web experience, especially when it comes to digital identity-related actions, but I think that ship has probably sailed.
The Digital Credentials API: a deliberately minimal transport layer
Where FedCM is opinionated, the DC API is intentionally unopinionated. I wrote about that a few weeks ago: “Digital Identity Wallet Standards, the DC API, and Politics“.
It enables a website to:
- request the presentation of a digital credential, and
- request the issuance of a digital credential.
And then it steps aside.
The DC API does not tell anyone:
- which credential format to use,
- which presentation or issuance protocol should be followed,
- what a wallet should look like,
- how selective disclosure should work, or
- what verification actually means.
Instead, the DC API offers a security boundary and a transport mechanism. Basically, it is a very small window through which appropriately structured requests and responses can pass.
This is why people call it a “dumb pipe.”
Dumb pipe = the browser transmits with consent, but does not judge
A dumb pipe:
- does not choose the wallet,
- does not choose the credential,
- does not evaluate trustworthiness,
- does not interpret the content, and
- has no opinion about the structure or semantics of the data.
Its design goals—transparent requests, encrypted responses, user activation, wallet selection UX delegated to the platform—reflect this philosophy.
It is meant to be a flexible, protocol-agnostic infrastructure for a world where credentials live in wallets, and wallets live on devices that may or may not be integrated into the browser.
Two APIs, two philosophies
Put side-by-side, the differences sharpen:
| Area | FedCM | DC API |
|---|---|---|
| Primary domain | Federated sign-in | Verifiable digital credentials & wallets |
| Browser role | Active mediator | Minimal transport boundary |
| UX responsibility | Browser-owned account chooser | Platform-owned wallet/credential chooser |
| Architectural posture | Opinionated (“smart”) | Unopinionated (“dumb pipe”) |
| Implementation reality | Chrome only, today | Under development; multi-vendor interest |
These are not competing APIs. They solve different problems for different ecosystems.
The overlap we’re not talking about enough
Even though FedCM and the DC API were created to solve different problems, it’s hard not to notice how easily their scopes could start touching. If a website can already ask the browser to help pick an identity provider for a federated sign-in flow, it’s not a huge stretch to imagine that same browser helping the user pick a wallet or select a credential in a verifiable credential flow. The underlying mechanics are different, but the user’s mental model isn’t: choose an account, choose a wallet, choose a credential. They’re all variations of the same action.
That overlap leads to a more delicate question: if the browser is already trusted to mediate identity selection in one domain, should it also mediate credential selection in another? Some people see this as a natural evolution—a unified identity experience across the web. Others see it as a risk, especially when FedCM itself is still stabilizing and the verifiable credential ecosystem is trying to balance innovation with regulatory caution. Treating FedCM as a convenient foundation for wallet behavior could introduce more tight coupling than the ecosystem can handle.
The result is a quiet tension, at least for me: the possibility of convergence is there, and it may even be appealing, but the consequences of moving too quickly—or of not noticing that convergence is happening implicitly—could shape the identity layer of the web in ways we don’t fully understand yet.
The political sensitivity
Identity on the web has never been just a technical matter, but the stakes are now higher than they’ve been in years. Regulators have entered the room with strong expectations about predictability, interoperability, and user protection. If they don’t get it from the technical standards, they’ll introduce regulation to require it. Platforms, meanwhile, are trying to ensure that new identity layers don’t diminish their control or introduce obligations they can’t realistically meet. Wallet vendors worry about being sidelined if browsers centralize too much of the user experience. Standards bodies, all with their own histories and governance norms, disagree about how much power should sit in the browser stack at all.
The DC API was deliberately designed to stay neutral and avoid becoming a governance surface. FedCM, however, is explicitly opinionated and user-agent driven. If those two worlds start blending—whether by design or by accident—the browser suddenly becomes the arbiter of identity behavior across both federated authentication and verifiable credentials. That shift wouldn’t just raise architectural questions; it would raise political ones. Who gets to define the rules? Who enforces them? And what happens if regulators expect consistency that the underlying specifications were never meant to guarantee?
This is why the conversation is sensitive. Changes to the identity layer ripple outward: to wallet ecosystems, to platform policies, to regulatory compliance pathways, and even to what users believe is “normal” on the web.
So where does this leave us?
We are at an interesting point where two identity systems—federated sign-in and verifiable digital credentials—are evolving in parallel, and both now rely on the browser in ways they never did before. FedCM gives the browser real authority over account selection and permissioning. The DC API gives the browser a clean, minimal boundary for credential issuance and presentation. These aren’t incompatible visions, but they do reflect different philosophies about what the browser is supposed to do.
The challenge is that the identity ecosystem is trying to absorb both shifts simultaneously. Meanwhile, only one browser has implemented FedCM. Wallet standards are still being debated across multiple forums. Regulators are writing requirements faster than implementers can test them. And users—who ultimately need to understand and trust all of this—are not clamoring for complexity. They just want to get to their newspaper subscription or social media feed. It’s a precarious landscape, and the choices made now will influence the next decade of identity design on the web.
Convergence between FedCM and the DC API might eventually happen, especially if the ecosystem wants a unified identity experience. But convergence too early, or without a clear understanding of the tradeoffs, could entangle two very different problem spaces and make it harder to deploy either one successfully.
What we should be watching
Over the next couple of years, several developments will tell us which direction things are heading. The most immediate signal will come from browser support: if additional browsers adopt FedCM, it becomes far easier to treat the API as a stable foundation rather than a Chrome-specific solution. At the same time, the level of enthusiasm—or reluctance—from wallet vendors will shape how quickly the DC API moves from “promising concept” to “reliable infrastructure.”
Regulators will also exert force here, especially those drafting rules that assume uniform behavior across wallets, platforms, and device ecosystems. If regulatory expectations outpace technical reality, we may see pressure to treat one of these APIs as the harmonizing layer by default. And finally, the standards community itself will need to decide how much responsibility the browser should carry. There’s a meaningful difference between an API that coordinates identity transactions and one that governs them, and the line between those two roles is thinner than it appears.
This is a moment when paying attention matters. The work happening now—stabilizing FedCM, maturing the DC API, clarifying responsibilities across layers—will determine whether identity on the web becomes more coherent or more fragmented. The cement is still wet, but not for long. I’m watching this from the front row as co-chair of the Federated Identity Working Group, where both APIs are going through the standardization process. I don’t want to say “wish us luck”. Instead, I want to say, “please follow along and chime in!”
📩 If you’d rather track the blog than the podcast, I have an option for you! Subscribe to get a notification when new blog posts go live. No spam, just announcements of new posts. [Subscribe here]
Transcript
Today’s episode begins with a very bad joke — but it opens the door to a much more serious conversation about how two emerging browser APIs are reshaping identity online.
Two APIs Walk Into a Browser
[00:00:29] Two APIs walk into a bar.
The bartender asks, “You two together?”
FedCM replies, “Absolutely not. I need explicit user consent first.”
The DC API shrugs: “I’m just here to pass messages.”
Bad jokes aside, these two APIs — FedCM and the Digital Credentials API (DCAPI) — were created for very different reasons. Yet today, they’re quietly occupying neighboring territory. And whenever standards live close together, people inevitably ask:
- Are they supposed to converge?
- Should one replace the other?
- How will they interact?
To answer that, we need to start at the beginning.
The End of Browser Passivity
[00:01:48] For most of the web’s history, browsers played a surprisingly passive role. They simply rendered pages, stored cookies, and moved signals between sites so identity systems could function. Browsers weren’t designed to be intermediaries — they were just convenient containers for developer hacks like third-party cookies.
But that era is ending.
Privacy reforms fundamentally changed the game:
- Safari and Firefox blocked cross-site tracking early.
- Chrome’s (now paused) plan to remove third-party cookies forced the entire ecosystem to reconsider its identity assumptions.
- Regulators pushed browsers to take responsibility for what happens on their platforms.
As a result, old federated login flows — with their fragile redirects and opaque cookies — became too risky and too leaky to survive unchanged.
Enter FedCM: A Smart, Opinionated API
[00:03:01] FedCM began as a stopgap solution for the disappearance of third-party cookies. But when Google revised its approach, the API evolved into something more ambitious: a way to redesign federated login with stronger user protection.
FedCM places the browser directly in the middle of the flow:
- The browser shows the account chooser.
- The browser prevents silent tracking.
- The browser enforces permissions.
- The browser ensures the identity provider and relying party only learn about each other when the user agrees.
[00:04:11] In short, FedCM is a smart API. Not AI-smart — architecturally smart. It makes decisions. It carries strong opinions about usability and privacy. And with Chrome as the only browser currently implementing it, FedCM is powerful but still precarious.
Some dislike the idea of browsers becoming active mediators, but that ship has sailed. Browser involvement is now part of the reality of the identity stack.
Enter the Digital Credentials API: A Minimalist, “Dumb Pipe” Approach
[00:05:00] The Digital Credentials API takes a very different approach. Where FedCM is opinionated, the DCAPI is intentionally neutral.
It allows a site to request:
- Presentation of a credential, or
- Issuance of a credential
…and then it steps back.
Unlike FedCM, the DCAPI does not decide:
- Which credential format is used
- Which protocol applies
- How a wallet should behave
- What trust model is appropriate
[00:06:23] Instead, it creates a narrow transport boundary — a simple, structured pipe between a website and a credential wallet. Many call it a “dumb pipe,” and in this context that’s a compliment. It stays out of the way and focuses on preventing silent or unexpected credential exchanges.
This neutrality makes it attractive for a wide range of use cases:
- Government IDs
- Travel documents
- Employment or education credentials
- Enterprise or sector-specific proofs
In other words, the DCAPI solves a different problem than FedCM.
Where the Lines Start to Blur
Even though these APIs have different roles, they sit close enough together that interesting questions emerge.
For example, the browser already helps users choose an identity provider through FedCM. It’s easy to imagine the browser helping them choose a wallet, or even selecting a credential. From a user perspective, these actions can feel similar:
- Choose an account
- Choose a wallet
- Choose a credential
This similarity raises the question: Should these two APIs converge?
Some in the ecosystem think yes.
Others — including me — see risks.
The Governance Question
FedCM, by design, is a governance interface. It enforces policies and offers a consistent user experience.
The DCAPI, by contrast, deliberately avoids that role.
If the industry tries to use FedCM as a governance layer for the DCAPI, we could see:
- A unified identity decision point inside the browser
- A single interface covering federated login and verifiable credentials
- A user experience that feels cohesive — but also more tightly controlled
And yet that tight coupling could create more complexity, not less.
Political Pressure and Regulatory Realities
[00:09:14] Identity on the web has never been just technical. Today, political pressure is especially high.
Key players have competing priorities:
- Regulators want predictability and interoperability.
- Platforms want to avoid compliance burdens.
- Wallet vendors fear being boxed out if browsers centralize identity choices.
- Standards bodies disagree on how much control browsers should have.
If these two APIs merge accidentally — or prematurely — we may end up with browsers arbitrating identity across both federated and verifiable credential workflows. That brings questions about authority, enforcement, and unintended regulatory assumptions.
Where Things Stand Now
[00:10:23] Two identity systems — federated login and verifiable credentials — are evolving in parallel. Both depend on the browser more than ever before.
- FedCM gives the browser active authority.
- The DCAPI gives the browser a minimal but powerful boundary.
These are not incompatible visions, but they reflect different philosophies about what browsers should be.
Meanwhile:
- Only Chrome currently supports FedCM.
- Standards across W3C, IETF, and other bodies are still in motion.
- Regulators are drafting rules faster than developers can test them.
- Users just want access to their newspaper or social media — not more complexity.
Will the Two APIs Converge?
[00:10:45] It is entirely possible that FedCM becomes the governance layer people want for managing credential flows. That could drive convergence.
But if convergence happens too soon, we risk entangling two problem spaces that need room to mature independently. Some experimentation and stabilization still need to happen.
So what should we watch?
- Browser adoption — If more browsers implement FedCM, it becomes foundational.
- Wallet-vendor responses — Their enthusiasm (or hesitation) will shape adoption.
- Regulatory pressure — Especially where governments demand uniform behavior.
- Standards decisions — Particularly around how much authority resides in the browser stack.
The line between an API that coordinates identity and one that governs it is very thin — thinner than many admit.
Final Thoughts
[00:12:14] The identity layer of the web is in a formative moment. Decisions about FedCM, the DCAPI, and browser roles are happening right now. The cement is still wet — but not for much longer.
[00:12:38] That’s it for today’s episode. As always, stay curious about where the web is heading… because it’s definitely going somewhere.
[00:12:53] If this episode helped clarify things, share it with a colleague and connect with me on LinkedIn at @hlflanagan. And for the full written post, visit sphericalcowconsulting.com.
Stay curious. Stay engaged.
