[Openid-specs-ab] Fwd: [blink-dev] Intent to Prototype: WebID

[Tom Jones]

This is not auspicious! Sam went ahead without even responding to some of
the comments provided. Note that at its core this proposal would add some
requirements on IdP to provide metadata that could be absorbed by the
browser. It has been suggested that the user would need to be involved in
the process.  Both George & I have suggested that the browser password
manager needs to be modified to assure that if the user is hassled, that
the user's response be stored and they not be hassled again.

My suggestion is that we work on a user experience doc and send that as a
CR (bug) to the blink mailing list or perhaps as a comment to the
WICG m/l.  I or John could do that.

In the meantime, I will try to collect a user experience plan. If anyone
has suggestions, please forward them to me.
Can we put this on the agenda for next week?
Peace ..tom


---------- Forwarded message ---------
From: Sam Goto <goto at chromium.org>
Date: Fri, Oct 9, 2020 at 12:21 PM
Subject: [blink-dev] Intent to Prototype: WebID
To: blink-dev <blink-dev at chromium.org>
Cc: Brad Lassey <lassey at chromium.org>, David Benjamin <davidben at chromium.org>,
<mjv at chromium.org>, Justin Toupin <jtoupin at google.com>, <kenrb at chromium.org>,
Majid Valipour <majidvp at chromium.org>, <balfanz at google.com>, <
mknowles at chromium.org>, Sam Goto <goto at google.com>


Contact emails

goto at google.com <goto at chromium.org>, jtoupin at google.com

Explainer

Link to explainer <https://github.com/WICG/WebID/> (in HTML
<https://wicg.github.io/WebID>).

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
<https://blog.chromium.org/2020/01/building-more-private-web-path-towards.html>
(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 <https://github.com/WICG/WebID/>.

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/>

https://www.chromestatus.com/feature/6438627087220736

Requesting approval to ship?

No

-- 
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+unsubscribe at chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALdEk-z%2BNtVPWBsU9M2c0P5Kg%2BQxMZbQxD%3D-st0E0zGrBui5mA%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALdEk-z%2BNtVPWBsU9M2c0P5Kg%2BQxMZbQxD%3D-st0E0zGrBui5mA%40mail.gmail.com?utm_medium=email&utm_source=footer>
.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20201009/7f654943/attachment.html>