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? 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
<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
<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/dc56ab88-6eb8-40f9-9b32-0efcfcd6aab4%40chromium.org.
