Thanks Alex and Mike for the review, some comments inline! On Wed, Mar 25, 2026 at 8:31 AM Alex Russell <[email protected]> wrote:
> LGTM1 per discussion in today's API OWNERs meeting. Sweet, thanks you all, much appreciated, especially for the quick turnaround! > From that conversation, wanted to capture a few points: > > - You're approved for the requested 6 releases, although it would be > good if there were a check-in on how it's going after, say, 3 months > > For sure. We'll report back as soon as we learn more. > > - We're OK with this pegged to 100% of applicable users because we > know that population will be low across all impacted browsers > > That matches our intuition too. It's hard to make predictions in this space, since it is moving so fast, but we do expect that it will take a while before the population becomes uncontrollably large. > > - We decided this doesn't need 3 LGTMs for the same reason (as outlined > in the process > > <https://www.chromium.org/blink/launching-features/#:~:text=Experimentation%20on%20higher%20percentages%20of%20Stable%20channel%20population%20(%3E%201%25)%20should%20be%20considered%20exceptional,%20and%20requires%203%20LGTMs%20from%20API%20owners.> > ) > > Best, > > Alex > > On Wednesday, March 25, 2026 at 5:59:41 AM UTC-7 Mike Taylor wrote: > >> Hey Sam, >> On 3/23/26 5:35 p.m., 'Sam Goto' via blink-dev wrote: >> >> Contact emails >> >> [email protected] >> >> Explainer >> >> https://github.com/samuelgoto/agentic-federated-login >> >> Specification >> >> Not yet >> >> Summary >> >> This is a proposal to experiment with a set of FedCM extensions to >> provide a structured tool to allow agentic browsers to log users in to >> websites safely using their federated accounts. >> >> Each individual proposal is independent from each other but are all >> necessary to enable agentic federated login: >> >> https://github.com/samuelgoto/agentic-federated-login >> >> It's not super clear to me how many proposals are associated with this >> experiment after reading the explainer - I think it's >> "potentially_approved_sites" and https://github.com/fedidcg/idp-initiated, >> is that right? >> > That's correct. Specifically, as you said: https://github.com/fedidcg/idp-initiated and https://github.com/w3c-fedid/potentially-approved-sites Note that these two were just recently accepted for incubation in the FedID CG, where we expect most of the discussion to happen, so no longer in my personal repo (as I originally posted this). Or am I missing more? >> > I think it is worth reinforcing (as we noted in the explainer https://github.com/w3c-fedid/agentic-federated-login) that we still believe that the following will play a role: https://github.com/fedidcg/login-element We are not including this in this origin trial yet, because we want to see how well this https://github.com/w3c-fedid/potentially-approved-sites performs, but we think it might be necessary at some point (and a better end state). If we get to it, we'll notify this thread. > (The "The Proposal" section is where I think I'm missing something...) >> >> >> We could I2E each FedCM extension independently, but because they are >> needed all together (and abide to the same experimentation structure we >> describe below), we have bundled them here. Just let us know if that’s a >> preferred way to review them, and we'll break them apart. >> >> Blink component >> >> Blink>Identity>FedCM >> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EIdentity%3EFedCM%22> >> >> Web Feature ID >> >> fedcm <https://webstatus.dev/features/fedcm> >> >> TAG review >> >> https://github.com/w3ctag/design-reviews/issues/1184 >> >> TAG review status >> >> Pending >> >> Goals for experimentation >> >> We are planning to run this experiment with the same properties we expect >> from origin trials: >> >> >> - >> >> We intend this to be a time-limited experiment of an extension of a >> Web Platform API (likely using the full extent of the 6 milestones that is >> given to origin trials) >> - >> >> We intend to reserve the right to make breaking API changes in the >> period of experimentation >> - >> >> We intend to experiment it with a small percentage of the user base >> - >> >> We intend to collect the data that we need to I2S if the experiment >> succeeds >> >> >> However, we are planning to deviate from the typical original trial in a >> couple of important ways. >> >> First, because these are extensions to FedCM that are primarily motivated >> to help agentic browsing, we would like to enable this origin trial to 100% >> of the users using agentic browsing, but to 0% of the users of regular >> browsing. This helps us isolate the experimentation of the APIs to agentic >> browsing, which is a significantly smaller and safer and controlled subset >> of users compared to non agentic browsing. We believe that, as we progress >> through this experiment, we’ll figure out how the APIs can be deployed to >> agentic browsing *and* to non-agentic browsing, and we believe that serving >> agentic browsers first is a prerequisite to addressing non-agentic browsing >> too (from a design of incentives perspective for IdPs). >> >> I don't know how big the population of agentic browsing is, but how >> should we think about burn-in here? I think you could squint at this and >> call it a launch? >> > We want to frame this as an experiment as much as we possibly can because we want to learn from deployment and reserve the right to make backwards incompatible changes. There are few IdPs (and even fewer FedCM IdPs) compared to website authors, so we think it is a bit easier to set expectations regarding breaking changes and experimentation. > Second, there are parts of the browser implementation that we still don’t >> know how to generalize and onboard an IdP in a self-servicing manner, >> namely, the account chooser UX and the machine learning models to detect >> federated login buttons on websites. Because of that, instead of using >> self-servicing origin trial tokens, we are planning to allow IdPs to submit >> a Google form to show their interest in participating in this experiment >> and manually onboard them (we’ll create a Google Form if this I2E gets >> LGTM-ed). >> >> Just to report back on this thread, here it goes: https://forms.gle/NLYucXSXFeeD1L4cA > We believe that, as we make progress in this experiment, we’ll figure out >> how to onboard any IdP and website without any manual review, and we >> believe that the manual process is a step that is required for us to learn >> how to generalize. >> >> What happens after a submission is approved? Is a token then given to the >> IdP, or is an origin hard-coded somewhere else? >> > The latter, hardcoded. We do believe, however, that by the end of this experiment, we will have figured out how to onboard IdPs in a self-service manner, but that's probably too soon to tell. > >> Having said that, the goal of this experiment is to see if users are >> satisfied with the experiences that we can construct for the agentic >> browser, and if identity providers have the incentives / capacity to >> support that. >> >> Here are concrete goals with each specific API that we’ll be >> experimenting with: >> >> - The IdP-Iniated API: for developers, we'll be monitoring any >> implementation errors that might occur as users use agentic browsing across >> many websites. We think we covered most cases, but we still expect many >> unknown unknowns to show up. >> >> - The potentially_approved_sites: we'll be monitoring the rate of false >> positives and how users are going through them. False negatives are harder >> to quantify programatically, so we are planning to quantify them manually. >> >> Risks >> >> >> Interoperability and Compatibility >> >> No information provided >> >> Gecko: No signal >> >> WebKit: No signal >> >> Web developers: No signals >> >> Other signals: >> >> Ergonomics >> >> The proposals being evaluated move all of the work required to the >> identity provider and out of websites (since there are many orders of >> magnitude more of the latter compared to the former). For consumers, >> identity providers are typically well funded and sophisticated web >> developers, and so far we have not identified any ergonomic risk that >> concerns us. >> >> Activation >> >> We managed to find a way to pull all of the responsibility to the >> Identity Provider rather than to the websites, so we expect we'll be able >> to activate a large part of the web without having to redeploy it. It >> remains to be seen if/how IdPs are going to proactively support logging in >> with agentic browsers. >> >> Security >> >> We are aware of a false positive and false negative aspect of one of the >> proposals we have, but we think we have a mechanism that degrades >> gracefully when we detect these (we do not actually create an account and >> instead we stop the agent and let the user take over). We are going to be >> monitoring the experiment to understand the extent that these are happening >> and if users can go through the fallback. >> >> WebView application risks >> >> Does this intent deprecate or change behavior of existing APIs, such that >> it has potentially high risk for Android WebView-based applications? >> >> No information provided >> >> >> Ongoing technical constraints >> >> None >> >> Debuggability >> >> No information provided >> >> Will this feature be supported on all six Blink platforms (Windows, Mac, >> Linux, ChromeOS, Android, and Android WebView)? >> >> No. Just desktop (Windows, Mac, Linux and ChromeOS). >> >> Is this feature fully tested by web-platform-tests >> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >> ? >> >> Yes, >> https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/external/wpt/fedcm/fedcm-navigation-interception/continue-on-redirect-POST.https.html >> >> >> We’ll add more as we go along. >> >> >> Flag name on about://flags >> >> No information provided >> >> Finch feature name >> >> FedCmEmbedderInitiatedLogin >> >> Non-finch justification >> >> No information provided >> >> Requires code in //chrome? >> >> True >> >> Estimated milestones >> >> Origin trial desktop first >> >> 148 >> >> Origin trial desktop last >> >> 154 >> >> DevTrial on desktop >> >> 148 >> >> >> Link to entry on the Chrome Platform Status >> >> https://chromestatus.com/feature/5141084139290624?gate=6018425698779136 >> >> This intent message was generated by Chrome Platform Status >> <https://chromestatus.com/>. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "blink-dev" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMtUnc7FM0-e_zdX0S0US%3DhiG5e%2B51r%3DTfjR4%3DfW-TJbqrMS9A%40mail.gmail.com >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMtUnc7FM0-e_zdX0S0US%3DhiG5e%2B51r%3DTfjR4%3DfW-TJbqrMS9A%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> >> -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMtUnc5Tg7GoVKiB_Ex7V1SyCN4mat1Vy0-ihcPT%3DVjS0c-%2B1A%40mail.gmail.com.
