Intent to Prototype: WebID

604 views
Skip to first unread message

Sam Goto

unread,
Oct 9, 2020, 3:21:08 PM10/9/20
to blink-dev, Brad Lassey, David Benjamin, m...@chromium.org, Justin Toupin, ke...@chromium.org, Majid Valipour, bal...@google.com, mkno...@chromium.org, Sam Goto

Contact emails

go...@google.com, jto...@google.com 


Explainer


Link to explainer (in HTML).


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


Reply all
Reply to author
Forward
0 new messages