Intent to Experiment: Agentic Federated Login
Sam Goto
Contact emails
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
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
Web Feature ID
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).
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.
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?
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
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5141084139290624?gate=6018425698779136
This intent message was generated by Chrome Platform Status.