FedCM moves federated login into the browser because redirects, iframes, and third-party cookies were never designed to carry the identity infrastructure of the web. See how browser-mediated authentication can preserve federation as tracking mechanisms disappear, reduce duplicate accounts, simplify identity-provider selection, and create login experiences that individual websites cannot build from inside their own origin.
.png)
.png)
Hey, folks. Thanks for joining us for this webinar about FedCM. We'll wait a minute or two, let people filter in, and we'll get going. While we're doing that, some nuts and bolts: this webinar will be recorded and sent to you afterwards. If you're watching from the future, hello — I hope things are good. We'd love to have you ask questions, so there's a Q&A box on the right side. Feel free to drop your questions in. We'll get started in about two minutes.
Alright. Thanks for joining us, Sam. Sam's our guest who's going to be talking about FedCM. Reminder: this talk is going to be recorded and sent to you, and you can ask questions in the Q&A box whether you're here live or joining async. I'm going to intro Sam and then we'll jump into our agenda about FedCM.
Sam Goto is a senior staff software engineer at Google where he works on Google Chrome. He's been a leader on the FedCM project, which is what we're going to talk about today. Sam, thanks for joining us.
Thank you so much for having me. Excited to chat with you all.
So the first thing I'd like to talk about is a general overview of what FedCM — Federated Credential Management — is and what problem it solves.
That's a good question. There are many ways I can answer it, but I can give you a sense of how we thought about it. The general idea was a question that has been lingering in browser development for a while: what would happen if the browser took identity as a first-class citizen — built into the web — as opposed to something done outside of it?
FedCM came out of that desire to explore that space. Would there be ways in which browsers can help users with identity flows if the browser was more involved? Traditionally, federation has been done on top of the web, outside of the browser. It reused what some would call low-level primitives — things not designed to facilitate identity flows. If you think of SAML and OpenID Connect, they're top-level redirects. They work despite the browser, not because of the browser — they work around the browser in a creative way. They used primitives that weren't intended for identity flows: navigations, cookies, third-party cookies, iframes — all intended for different purposes.
So from that angle: what would happen if we exposed a purpose-specific platform API?
Sure. The web is full of things that weren't used for their intended purpose — there's a ton of those, and to some extent the web thrived because of those low-level primitives. So the question becomes: why is identity special enough to be brought up into a first-class citizen in the browser as opposed to anything else?
It's a tension that appears not just in identity, but across the board. Payments, for example, were also done outside of the browser — composition with widgets and all of that was done outside of the browser. Some of the early design decisions for browser vendors were: we're going to compartmentalize apps by the same-origin policy. The browser thinks in terms of origins as the compartment; everything is safe within that origin, and every communication outside of it gets scrutinized.
So many things got done on top of these low-level primitives, but one of the challenges is that the same mechanism that allows them to be used for good innovations also allows them to be used for bad ones. Third-party cookies are a good example. Cookies were intended as a first-party authentication mechanism, but third-party cookies were also introduced for other purposes — and the same mechanism that lets you do identity stuff also allows tracking to happen.
The problem with low-level primitives is that they can be used not just for identity, which gives a lot of autonomy and agency to identity designers, but they also give a lot of agency to people outside of identity developing other things. Not all of those things are good. There's a saying: one of the jobs of the platform is to pave cow paths. There's a good architectural lesson here: if you want to know how to pave your paths, there was a university thinking about this very problem. The architect said, let's just put down a grass field and let people walk — then pave where people walk. That tends to work better than trying to anticipate needs ahead of time and putting pavers where you want them to walk, because people just walk through the grass anyway.
Same for identity. It's like paving an existing flow that we think has been constructive and helpful for the web, so that it has a better foundation than some of the low-level primitives that aren't as good for the web.
That's a great point. At this point, the perspective of this project is: identity is well-known enough, we know the patterns, the grass has been walked on to the point where it's time to put down the pavers. And obviously, browsers aren't going to be able to iterate as fast as people building on those low-level primitives, so it makes sense that now's the time.
We're going to talk more about the past, present, and future of FedCM. But before we do that, I'd love for you to talk about the benefits people are seeing when using this new standard. We'll talk more about where it stands — but first, if you have any questions and you joined us a...
...little bit late, questions go in...
...the Q&A section. We'd love for this to be not just me and Sam talking — we'd love to answer your questions. This is also going to be recorded and sent to you, so if you missed the first couple of minutes, don't worry about it.
Sam, can you tell us a bit more about the benefits when it's been implemented? I know there are browser vendors who get benefits, there are IDPs like FusionAuth who get benefits, and then there are website developers and users who get benefits.
I guess I'd like to focus on...
...the third group — the developers who are building web applications, and the benefits they get — because that's going to be most of our audience: people building applications on the web who are interested in learning more about these topics.
That's a good question. As you noted, the web is really large and it has to serve very different audiences. The goals that an identity provider might have can be different from the goals a website might have, which can be different from the goals a user might have, which can be different from the goals a browser engine might have. It's like a four- or five-way market where you have to find an equilibrium — and it's really hard to find one. These equilibriums change over time and swing back and forth.
I can give you a sense of how we think about this. It's a TAG principle — the W3C Technical Architecture Group, which is kind of like the UN of browsers: really smart people coming up with principles. One that I like most is called the Priority of Constituencies: users first, developers second, browser engines third, and technical purity fourth. You'd be surprised how often that has to be quoted, because you'd be surprised how often people go the other way. Some people see a technical trinket and go, "oh, this is so cute." Or they think the browser's interests should come first, or the website's. But a typical browser engineer thinks: users first, developers second, browser engine third, technical purity fourth.
When it comes to developers specifically, for FedCM you have a relying party and an identity provider — a three-sided market that has to find equilibrium. Let me go through and answer your question. You said your audience has more to do with websites, so maybe we'll start there.
Websites care about acquiring new users and reengaging existing ones. It takes a massive amount of ad spend to move users through acquisition funnels, and every user you lose in that process is an extra ad you have to pay for. User acquisition and user reengagement have been some of the main factors for websites' bottom lines.
In that process, I always tell people there are really only two ways to create an account on a website: you can use federation — social login — or you can use usernames and passwords, or email verification. That's a broad approximation, but roughly speaking, those are your two options. And both have traditionally been done outside of the browser. Email verification: you put an input box to collect an email, then send a magic link. Social login: you'd have the flag with four or five different identity providers the user can pick from. All of that is outside of the browser.
If you allow the browser to change — and that's not something to take for granted — then maybe the browser can do a better job at reconciling multiple identity providers. Maybe it can do a better job knowing which identity providers you're logged into, what your preferences are. Maybe it can use browser surfaces that aren't available to websites. I really like the omnibox — the URL bar. That's prime real estate that no website can control, but if you pull identity into the browser, it lights up different aspects of the browser. Same with reconciling and unifying passwords, passkeys, and email verification — finding a way for users to create an account on a website without having to think about all this, and providing a layer with advantages you just wouldn't have if you were doing this at the page level.
I just want to tug on some of what you said there. It sounds to me like the main benefit of implementing FedCM — for developers in particular — is that because it's built into the browser, it eases the login process in a way that's impossible to do any other way. Because I can't control the URL bar, I can't do anything to Chrome outside of my website. So this is similar to passkeys: it's about leveraging things outside of a web dev's control to ease the login process. Is that roughly the main benefit of FedCM?
Yeah, I think that's the premise. If you pull that into the browser layer, what different properties would the system have? One property is that browsers, unlike websites, can look across sites. The website has the same-origin policy creating a boundary between it and other websites. The browser is the only entity that can see across every tab you have open. Maybe you have your account preferences in different tabs, or you're logged into an identity provider in a different tab — the browser can pull that account into the tab you're on now. It's like the operating system level.
A website doesn't have access to the user's passwords or passkeys — for security reasons, the operating system is protecting the user against websites that might abuse that. The browser is the only entity that knows you have a certain password, passkey, or social login. So when the user goes back to a website, they can be reminded of what they used before.
A concrete example: when you go to a website and you see social login and email, the first question you ask yourself is, "what did I use before?" Yelp is my concrete example. I literally have two Yelp accounts because Yelp is something I use once every couple of years — and every time I go back, I think, "which one did I use?" That's partly because the website doesn't have the information that the browser has.
Digging into that Yelp example a bit: there are negatives for Yelp too, right? They now think you're two separate people, there are downsides for you because you can't see reviews across both accounts — and FedCM would solve that. How does FedCM resolve that issue?
Well, so I have to look...
...at whether Yelp has actually implemented FedCM. Right? Let's just assume that.
They may have already. So I have actually created a Yelp account with my email address and with social login. The second time I went to Yelp, I used the other mechanism and it created a duplicate account. But if Yelp were using FedCM and passkeys, it could be calling an API that says: "I want the user's credentials for this website, whether it's the passkey or the social login — I don't care which, just don't give me a new one if the user already has one."
The browser has that memory, that storage, that allows the user not to have to remember in their heads what they used. Because in the page's content area you don't have access to those things, you don't know where to tell the user to click. But because the browser can remember these things in browser storage, it can say: "You've used social login here before — would you prefer that? If you create a new password, you might be duplicating the account." That's the premise: if you pull that into the browser as opposed to the page, you can reconcile and unify those two things.
Cool. I've definitely seen sites that have home-rolled solutions that do that — "sessionize" is one where they say, "hey, you logged in last time with this." But what FedCM offers is that it ships to everybody. Nobody has to reimplement this with low-level primitives. It just becomes another benefit of using a browser.
Before we let too much time slip, I'd like to ask you — if possible — to give a brief couple of minutes covering the past context, current state, and future directions of FedCM. Can you do that?
In a couple of minutes? Yeah, I'll try. I have to pay tribute to where tribute is due: if you look at the history of browsers, we have had a history of attempting to pull identity up. That idea isn't one I had — it's a history of projects that I think just demonstrates that FedCM maybe has gone a little further than average.
Basic Auth was probably one of the first ways in which browsers were responsible for building that UI. And that history will tell you the trade-offs and challenges, the equilibrium issues, that go into making a product succeed. Basic Auth largely failed because it didn't have the right UX, didn't allow customization, didn't fit into the flow, and didn't have much password management integration. But it was probably one of the first attempts to have username and password baked into the browser.
Fast-forwarding, there were many different attempts, but perhaps the most notable one was Mozilla Persona, which I'm very fond of. I wasn't at Mozilla at the time — I was at Google Search, I think. But it carried a lot of this intuition: what would happen if the browser could intermediate identity? Privacy and similar concerns were big angles. Mozilla Persona went very far and was a major influence on FedCM. I like to think it was ahead of its time, or the world wasn't ready. The technology and architecture were directionally correct. And some of what Persona did — the three-party model in particular — comes up a lot today. So Basic Auth was probably the first attempt; Mozilla Persona was probably the most notable one before FedCM.
FedCM came out of that history of people having the intuition: what would happen if the browser took on that responsibility? And obviously it comes at a trade-off. As you said, it's much faster to develop on top of the web rather than into the browser, because there are far fewer browser engineers than there are web developers. You want innovation to happen at the user level, not the browser level. Persona was maybe a bit too early in that the cows didn't want the grass paved — they liked the grass and wanted the innovation that came with it.
It's possible FedCM will fail too — it might have been too early, and that's a very plausible possibility. But a lot of the opportunity came through the deprecation of third-party cookies. It was like: well, it might be too early, but we need to find a way to block third-party cookies without killing federation.
It became more like a floor-is-lava kind of game where you wanted to place enough stepping stones for people to move around on.
A lot of the vision and inclination — we call it the separation between preservation and extension — came from that urgency. There's a moment in time where it might be useful to pull responsibility to the browser because tracking on the web is really problematic and third-party cookies need to go. How do we create alternatives? If we pull responsibility for the web for identity and payments and other things we think are good, maybe that helps. But we always thought of this as a stepping stone, not just a fix to get back to where we were. An investment of that size had to open up new possibilities.
That's why we call it preservation and extension. We should find a way to make sure that federation doesn't die when third-party cookies go away, when link decoration goes away. But it's not enough to just preserve it — it has to propel things to places they couldn't go before. Solving the NASCAR flag problem, reconciling passwords and passkeys, a lot of the agentic web work — I can walk you through what the extension ideas were.
I'd love to do that, but maybe we should first land on where we are right now. I know it's in the W3C, there's been an editor's draft published, there are ongoing meetings. This is also a good moment to mention how someone interested could get involved. So give us an estimate of where things stand now, and then we'll talk about the future and the extension ideas.
Yeah. I operate on the principle that standards follow, they don't lead. First there's a user, then there's a product that helps that user, and then there's a standard that helps that user more by enabling interoperability across browsers. So through the development of FedCM, you've probably seen us being very focused on: is the user being helped? Is the website being helped? Is the identity provider being helped? Can the browser interoperate? In that order.
When people ask where things are at, I go through: here's how users are experiencing it, here's how we want to make it better, here are the benefits developers are getting, here's how we're planning to improve those, here's how identity providers are taking advantage of it, here's how we plan to make it better for them. And then, as a fourth consideration, here's how other browser vendors can participate and create feedback loops for the ecosystem.
In terms of user experience, FedCM materializes in different UI formulations — we call them active mode and passive mode. They have different trade-offs and properties. It performs well with users overall; they accept it. I think it's more intrusive than it needs to be, and we need to rebalance between intrusiveness and conversion rates. But we also need to incentivize developers. I forget the exact number, but I believe it's around one to two percent of all Google Chrome page loads involve FedCM. If you go to the head of the web — the top sites — almost every website you visit has a FedCM integration.
FedCM has a problem of being too noisy and annoying, more so than a problem of lack of adoption. It's like the Notifications API: websites have found that FedCM doesn't have an adoption problem per se — it has the reverse problem. Too many sites are using it and they're being a bit too aggressive with users. If you look at the head of the web, FedCM is present on a good chunk of it for consumers.
As far as identity providers go, there are far fewer than there are websites — at least an order of magnitude smaller, with the exception of enterprises and research and education. For consumers, the count is growing. Google is obviously one of the biggest IDPs driving a lot of the adoption. But Shopify — I'm very proud to say — is actually larger than Google as an IDP in certain respects. And I'm super excited to see them expose themselves. Seznam was a big search engine. It's also a big identity provider. GMX and Web.de, email providers in Germany, Times of India — there are just a lot of these identity providers starting to show up.
Just to be super clear: those names you used — Shopify, Times of India, and the others — those are all identity providers that have implemented FedCM. Okay. Great.
They expose themselves as FedCM-compliant identity providers, and that serves all their websites. Google has done this, but Shopify too, and GMX, Web.de, Seznam, Times of India, and so on. These are identity providers. For every identity provider, you have maybe three orders of magnitude more relying parties. So Shopify has a massive number of merchants, and they've enabled this for all of them. You experience FedCM through the websites, not directly through the identity providers.
Sure. And this is a good moment to note that FusionAuth itself does not currently support FedCM. It's on our radar — we're clearly interested in this, which is why we're happy to host this webinar. I'll drop a link in the follow-up email. We have a couple of GitHub issues where people can chime in. If you're listening to this now or in the future and you're thinking, "FusionAuth, get on board" — we'd love to hear about your use case, what you've heard from your users, and what conversion stories you think FedCM can help with. This is not an ad for FusionAuth. We'll go back to our regularly scheduled programming.
So that's useful context about implementation across users, websites, and IDPs. Can you briefly talk about browser support? Then I'd love to hear more about the future. And we definitely want to get to a demo. So: browser support, then current state from your perspective, then future — including IDP Registration and the other things you mentioned — and then a demo, and then questions.
For sure. As far as browser vendors go, Google Chrome has supported FedCM from the start, and that propagates to almost all Chromium-based browsers. Brave and Edge — Edge is probably the most notable — also support it, and the whole Chromium lineage follows. The second major browser actively working on it is Firefox, which has been engaged from early on. I think that's partly because Firefox has a lot of Persona DNA in its personality, and I have a massive amount of admiration for the Persona engineers — much of my thinking was influenced by them. The design choices converged as a result.
Firefox has a lot of bigger fish to fry right now. They've been implementing FedCM for a couple of years but recently paused their implementation to deal with other problems. I think that's entirely understandable. As long as there's philosophical convergence, implementation follows given the right priorities. I expect Firefox will come along. They've been very supportive and have co-designed a lot of the spec with Chrome in ways that fit their needs.
Safari has been a bit less involved. When we asked for their formal position — which is required as part of launching things in Chrome — they expressed support for the direction. They've innovated a lot on the tracking side, so they understand the desire not to disrupt federation while preventing tracking. They've been generally supportive but quieter. They've also emphasized how FedCM relates to passkeys and passwords.
The way I think about browser support is that it follows from market demand — it doesn't lead. By having developers and IDPs like FusionAuth support FedCM and having more websites use it, it creates demand. Users in Chrome will have a better experience than in Firefox or Safari, someone will ask why, and the answer will be FedCM. It has to serve the goals of developers, users, and the browser — and hopefully that will, over time, converge into other browser vendors supporting it too.
Awesome. That's a helpful overview of the major browser positions.
I did write an article about this, so I know there are other mobile vendors out there — Samsung Internet browser supports it, and some others as well.
Could you...
...talk briefly about the future? You mentioned not wanting to waste this opportunity just to get back to where we were before — the idea of taking it to the next level. What are a couple of things that excite you about the future of FedCM?
We're already somewhat in the future, in that it's been a couple of years since we felt like: okay, the world's not going to die when third-party cookies go away in Chrome. When we asked around about how third-party cookies affect federation on the web, a lot of people said not that much. Front-channel logout came up as something that often isn't handled well, but also as relatively low priority. So we spent maybe a couple of years worried about preservation — how do we not kill federation as we block third-party cookies? But fairly soon after that, we got into: now that we have this baseline of the browser being able to mediate an account chooser, where do we go from here?
The most notable extension, and the one I'm most proud of, is the multiple IdP API. It's an API that lets a website say: "Put together an account chooser not only from this identity provider but also from this other one" — so you can start tackling the NASCAR flag problem. You don't have to list a button for every IDP you support; you just ask the browser to construct an account chooser and it filters to the IDPs you're actually logged into.
That's something that just couldn't be done without the browser. We actually tried once — it was called OpenYOLO. It relied on a neutral origin that every identity provider had to trust, but that didn't go well because of trust issues. The browser, though, is a trustworthy entity for every identity provider. So now we can do this in the browser. The multiple IdP API is in use today — Axel Springer and a number of German publishers have been using it for their relying parties.
This seems like a really cool feature. Let me make sure I understand. I'm an RP — a web application — and I want to support a thousand different identity providers, but as a user I don't want to see a thousand buttons on my login page. So if I've previously logged in to three identity providers — say Google and a couple of others — when I go to this website's login page, the browser will show me just those three. My three could be different from Sam's three, which could be different from everyone else's three, as long as they're all within those thousand supported providers. Is that basically it?
That's exactly it. The way this is getting into production right now with Axel Springer and the German publishers — I'm not German so I don't always know their exact names — is that they call the FedCM API on the website with a list of five or six IDPs the user can log in with, and those IDPs are often mutually exclusive. Some are email providers, so it's not like you have five accounts across five different email providers — you just have one. Instead of showing five buttons, they just show the FedCM UI, which filters to whichever IDP you're already logged into. That alleviates the user's anxiety, because it's going to be a quick thing — they already know they're logged in to that provider. So that's the multiple IdP API.
Somewhat along the same lines, one thing I'm personally very excited about is this notion that the NASCAR flag is bad not just because it has many buttons, but because it has a limited number of buttons — there's a finite amount of screen real estate. It doesn't work the same way email does. With email, you can bring your own provider and just sign up with your email address. With social login, it's been dominated by just four or five providers that take up the whole space.
With IDP Registration, just because the browser is involved, you can bring your own identity provider the same way you can bring your own email provider. I'm proud of my domain name. I'm Sam Goto, and I want to live in a world where I could use it as my identifier to log in to websites. That's another thing that can only be done because the browser is involved.
Gotcha. So it's a different flavor of the NASCAR flag problem. I really like how you framed it: it's not just that there are too many, it's that there's too little space. By leveraging the browser, we can let more identity providers be viable because they're not fighting for whatever ten or twenty pixels they get on the login page. Yeah.
It's a similar dynamic to Amazon and the infinite shelf. With a finite shelf, you only get the mainstream. It happened with MP3s, it happened with books, it happened with music, it happened with Netflix — as opposed to having just a mainstream set of choices, if you make the shelf infinite, you can allow niche providers to appear too.
I did not have on my bingo card comparing FedCM to Netflix — but I love that analogy in terms of exploding the realm of possibility. Do we have time for a demo? I think you've shown this before and I'd love for everyone on the call to see the FedCM experience.
Let's give this a try. Live demos — I'm not sure if it'll work. I'll try a couple because these are my...
...fingers are crossed for you.
I'm sorry?
My fingers are crossed. Yeah.
Let's see. I like this because it's a Shopify site. Let's say I'm buying something — I like this product, I like this website. At some point, it gives me the opportunity to log in. When I click on log in — there you go. This is what the FedCM UI looks like, because it reuses an account you have on the Shop app. You're logged into Shopify to log in to a Shopify merchant's website. If you click Continue — let's see if it works — there you go. That lets me log in to this website in a novel way, in a way that wasn't available before.
Let me show you another one. I always use Booking.com as a test because it tends to work. There you go — Booking.com also calls into FedCM. Because it knows I'm logged in to my Google Account, it can offer to log me in as Sam. Let's see if this works. This is my corp account, so I use it for testing. Yeah, it's working. There you go.
The other one I like to show is active mode, because it's a different FedCM construction and compelling in its own way. As opposed to being a widget on the side, this looks like a modal dialog front and center. It has different properties — it can fall back if you're logged out, and so on. But this is also a FedCM construction.
And I assume you use the term "active" because the user did click on a continue with Google button — it's like an active user gesture. And because of that, the browser is able to do more than it would if the browser were acting on its own. Is that roughly the difference between active and passive?
Yeah, that's exactly how we think about it. In terms of volume on a spectrum, active is very loud — it's front and center, and it's modal in that I can't interact with the page underneath it. It forces the user to take this action. And it's loud because it's proportional to the user's intent to sign in to the website.
Whereas if you go to a website like Booking.com — I'm logged in now so it won't show up, let me try logging out — when you go to a different website like Booking.com, the passive mode is there because I'm not specifically looking to log in. I want to book a flight, but it gives me a passive ambient UI — an affordance I can use to sign in and get more personalized content. It's quieter than the active mode, but I still feel like this is louder than it needs to be.
Yep. You kind of mentioned it earlier — that tension between serving website developers versus serving users. And you alluded to the fact that this could be an even better user experience and that you're taking steps to improve it. Great. Thank you for that demo.
I'd like to get to some questions. One I have: how does auto-reauthentication work and when is it triggered? I've seen that in the standard, and it feels like it would be great for conversion — I visit this website, I've already created an account there, so presumably I want to be logged in...
...so how does that work? The problem it solves is that cookies expire — and there are actually two problems. First, cookies expire. Second, cookies don't sync across devices. Auto-reauthentication tries to address both, though it fights against a tension. We're also working on an API called DBSC — Device Bound Session Credentials — that makes it so cookies don't have to expire as much, because they're bound to the hardware's TPM. Because of that, they don't have to expire for security purposes, since cookie tax becomes much harder. So I'd expect that in the same-device case, DBSC is going to make auto-reauthentication less necessary.
But auto-reauthentication also helps with cross-device flows: you've already logged in to Pinterest on one device, but when you open a different device, that device doesn't remember you were already logged in. That's also a tension — not every user wants to connect sessions across devices, especially on shared computers like family devices or library computers. But auto-reauthentication helps: if you've already used FedCM on one device, it propagates to other devices so you can be reauthenticated when you move over, or when your existing cookies expire.
Sorry, this is a new thought for me. So basically, I'm on my computer and I log in to Booking.com. Then, if things are set up correctly, when I go to my phone and visit Booking.com, I can automatically be logged in using this part of the protocol?
Yeah, that's correct. Almost as if the cookie were synced — but instead, Chrome remembers that you've already agreed to sign in to Booking.com. And if Booking.com asks to sign you in again, Chrome knows: we already asked the user that question, they already approved on this device, maybe we can transpose that approval to this device. That's how auto-reauthentication works.
But it's again a tension between users and developers. Not every user wants sessions synced across devices, but for developers it's been really helpful — it just brings the user back to a signed-in state across devices. All the personalization and reengagement happens much more effectively.
So that begs the question: how does the greater FedCM effort — not just you, Sam — deal with that tension? Is there a way for me to say, "I want this between my phone and personal computer, but not my work computer"? How does a user do that?
Controls are part of the answer — making sure users have all the control they need. But the devil is in the defaults, and it's really hard to pick defaults. We've been experimenting with machine learning a lot recently. AI has gotten quite good and has been able to capture nuances that rules couldn't before. Some of our early machine learning experiments are running in production right now. Conceptually, you want a magic box that predicts whether a user wants a particular thing. We tried writing heuristics but never managed to write ones that covered enough cases. We're hoping machine learning can do some of the things we couldn't do before. We don't know — but it's an active experiment.
Right — you're experimenting. The goal is clear: be smart and give users what they want when they want it. And I'm sure there are many ways to attack that problem.
And that's another benefit of doing this in the browser: you have economies of scale where the browser has to solve this once, as opposed to every website solving it independently. That's another one of those things you can only do in the browser. We're trying to contribute in places only we can contribute, and leave space for others to contribute where they can.
Makes sense. Let's do one more question and...
...then we'll wrap up. What's the minimum code needed to add FedCM sign-in to my website? I'm a developer, I'm excited about FedCM — what do I need to do?
As a relying party, it's actually pretty easy. I'll speak purely as an individual here, but I partially hope that no website developer ever has to know what FedCM is. It should be like an iframe — a developer shouldn't need to think, "I need to implement social login, how do I call the iframe?" I'm hoping we'll live in a future where all of this is abstracted away, and developers do it by using React, jQuery, the Google JavaScript SDKs or the FusionAuth JavaScript SDKs, and a lot of this complexity gets abstracted away from them.
Your short answer is: in the future, hopefully you won't have to think about it. I will say I've seen the Google Chrome sandbox documentation — it'll be sent out along with the recording — and it does walk you through what to do if you don't want to wait for the SDKs or the great future Sam just outlined. It's not a lot of JavaScript. It reminded me a lot of passkeys — it's a navigator.credentials call and never call, so it's not super imposing. Though I agree, this is plumbing that most devs hopefully won't have to spend a lot of time thinking about.
Any final thoughts? First, I'd say I really appreciate you taking the time to walk us through this, Sam. I think FedCM is an important step forward. As you outlined in the history section, it's not the first attempt browser vendors have made at this, but just like payments and some other things, it's an important move to take that next level of abstraction up — something trusted at a different layer so we can do the things you outlined that we couldn't do before. And I'd also say: for the foreseeable future, it feels like an augmentation of the login experience. As you alluded to during the demo, a dev is always going to want some kind of fallback — both because not all browsers support it and because it's still under active development. It can increase conversions, but you don't want someone who isn't using Chrome to be unable to log in to your website. Do you have any final thoughts on FedCM?
This is one of the things I'm most proud of. One of my personal inclinations early on was: how do we make it backwards compatible with the existing web? How do we make it retrofit into the existing web rather than replace it? To a large extent, a lot of FedCM's success has come from the fact that it augments an existing user experience in a complementary way. If it's not available, things still work the same way — it's just more effective when it's there. I think that was a good architectural choice, and it's led to a lot of good outcomes. Looking forward to seeing how this evolves, and hoping it will succeed.
Well, thank you so much. I really appreciate you taking the time to dig into this very interesting topic with us. And for everyone watching, thank you for joining us — we'll see you all later. Thanks.
