LGTM1 per discussion in today's API OWNERs meeting. 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 - We're OK with this pegged to 100% of applicable users because we know that population will be low across all impacted browsers - 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? Or am I missing more? > > (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? > > 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). 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? > > > 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/822636f5-03af-4b03-83ae-8df2c07c4344n%40chromium.org.
