A Web Platform API that allows users to login to websites with their federated accounts in a manner compatible with improvements to browser privacy.
In this origin trial, we are interested in experimenting with an account chooser for federated accounts, which we expect to be a foundational infrastructure for the Web going forward.
Spec review: https://github.com/w3ctag/design-reviews/issues/718
Early review: https://github.com/w3ctag/design-reviews/issues/622
Zero compatibility risk (new API)
Interoperability risk not yet known, currently working on getting formal signals.
Gecko: No Signals. standards position filed
WebKit: No Signals. standards position filed
Web developers: No signals. We have been proactively working with Identity Providers and expect much of the origin trial experimentation to be a determining factor on their position.
Other signals: No signals. This API is being developed within the FedID CG with attendance of identity providers, browser vendors and standards experts. We are working on a community report https://github.com/fedidcg.
We made a deliberate and concerted effort to make as many backwards
compatible changes as we possibly could to facilitate the adoption of FedCM.
When it wasn’t possible, we favored changes impacting Browsers and Identity
Providers and reduced changes impacting websites and users.
So far, we think we maintained backwards compatibility with website’s server-
side Infrastructure, which we expect to be a meaningful activation lever.
We believe we found a structure that would make it easy for websites to adopt, but that's one of the risks that we are trying to mitigate as soon as we possibly can as part of the origin trial.
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
This API does not deprecate or change behavior of existing APIs.
To learn about:
requirements: what aspects of federated identity are going to be affected by phasing out third party cookies?
demand: who is going to be affected? and how important is it for them?
deployment viability: is it a practical solution?
user acceptance: does our implementation perform well with users?
The following are current technical constraints that we expect to resolve as we go along (i.e. we are actively working on these known constraints):
Android only implementation (here is the desktop implementation tracking bug)
Only ID tokens provided, no access or refresh tokens (access tokens PR in progress)
Front-channel logout designed and implemented, but disabled for origin trials (HOWTO try it)
Only available in top level frames
Basic devtools integration supported. More to come as we learn.
We expect the feature to be available on all platforms (Windows, Mac, Linux, ChromeOS and Android) except WebView. The current implementation is currently only supported on Android, with Desktop (Windows/Mac/Linux/ChromeOS) coming before our I2S.
You can track our progress here:
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 blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/adcda1fc-b000-4b8e-a0eb-3104b21879a3n%40chromium.org.