Intent to Prototype: WebID
Sam Goto
Contact emails
go...@google.com, jto...@google.com
Explainer
Design doc/Spec
We will update this thread when our design doc firms up.
We will kick off a TAG review and update this thread as we go along.
Summary
Provide a new API that mediates the exchange of identity-related data between websites (relying parties) and identity providers (e.g. Google Sign In, Apple Sign In, Facebook Login, etc) while mitigating cross-site tracking risks.
Motivation
Over the last decade, identity federation has played a central role in raising the bar for sign-in on the web, in terms of ease-of-use (e.g. password-free sign-on), security (e.g. improved resistance to phishing and credential stuffing attacks) and trustworthiness compared to its preceding common pattern: per-site usernames and passwords.
However, it has relied on general-purpose primitives (namely top-level redirects, popups and third party cookies) which are subject to identity-agnostic browser policies (e.g. blocking popups used in identity flows). These policies are increasingly getting tightened due to cross-site tracking (e.g. by constraining third-party cookies and disabling navigational tracking). In addition to that, federated login distributes global user identifiers (most notably email addresses) which can be joined by multiple relying parties to build a shared profile of the user's activity across those sites.
In this exploration, we plan to prototype a high-level login-oriented API with the goal of ensuring federation on the Web is better streamlined, separable from other types of cross-site information exchanges, and more private for users by default.
We are engaging with identity providers in this process, for both consumers and enterprises.
Risks
Interoperability and Compatibility
This is a hard problem because of the diversity of stakeholders, requirements and existing protocols that exist in the identity ecosystem. Accordingly, we are starting not with a defined solution but rather a framework that can accommodate different levels of browser mediation, each with different sets of usability, privacy and deployment trade-offs. We expect to refine this into an API specification as discussions progress with other browsers, identity providers and relying parties.
Edge: No Signals
Firefox: early discussions
Safari: No Signals
Framework developers: early discussions with the Google Sign-In team
Web developers: early discussions with relying parties, No Signals
We have also engaged with the OpenID foundation, and there is ongoing public discussion in the WICG repository.
Activation
We expect this project to go through design, implementation and rollout over a long period of time, in conjunction and coordination with IDPs, RPs, browser vendors and evolving privacy enhancements.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes.
Link to entry on the feature dashboard
https://www.chromestatus.com/feature/6438627087220736
Requesting approval to ship?
No