On 3/25/26 6:38 p.m., Sam Goto wrote:
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
<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
<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).
Cool - thanks for confirming.
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
<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.
Great - I'm glad to hear you're willing to change things and are setting
the right expectations with partners around that.
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.
Cool - have fun, good luck, etc. :)
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
<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
<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/074a77f4-f437-43fc-a2f3-76dc16915f43%40chromium.org.
