Re: [w3ctag/design-reviews] WebID (#622)

> Specifically looking at your explainer — we are having trouble working out what user need you are meeting (beyond "avoid the privacy pitfalls we've outlined"). 

I think "privacy" is the intended "user need", first and foremost. "security" is probably a second next: we expect that without WebID federation may not be viable, and the alternative of "usernames and passwords" or "native apps" to be a demotion in security norms, so preserving federation and making it viable in a more private web avoids that demotion.

Having said that (and full stop there: we think those are in and on themselves goals that stand on their own), I think that once the user agent is intermediating the provisioning of identification, it is in a unique place to solve a series of problems with federation that we haven't managed to address.

The most notable one, probably, is what the identity ecosystem calls [the nascar flag problem](https://github.com/WICG/WebID/blob/main/problems.md#the-nascar-flag-problem). For example, once the user agent is intermediating the exchange of identification, it is insisting on identity providers to **interoperate**, which sets the stage to solve the nascar flag problem.

![](https://raw.githubusercontent.com/WICG/WebID/main/static/mock12.svg)

> For example: Are you looking to make it smoother for a user to log in with a federated ID? 

This is an area of tension. 

With one of the variations, which we call the [mediated-oriented variation](https://github.com/WICG/WebID/blob/main/navigations.md#the-mediation-oriented-variation) the user agent is intermediating and mediating the exchange of identification. In doing so, arguably, the user agent is able to offer a more trustworthy and consistent experience across identity providers, but, on the other hand, constrains innovation / exploration by forming an opinion. 

We call this "The Ossification Problem".

![](https://github.com/WICG/WebID/raw/main/static/mock29.svg)

This is a clear tension,  most notably explained in the [extensible manifesto](https://github.com/extensibleweb/manifesto).  It is also a tension with precedence in auth for the web, namely "Basic Auth" `WWW-Authenticate: Basic` and how it ossified a norm to capture usernames/passwords which has long been surpassed by user land code.

In contrast, the [permission-oriented variation](https://github.com/WICG/WebID/blob/main/navigations.md#the-permission-oriented-variation) delegates most of the experience building to the identity provider (the status quo), at the cost of "permissions" (that we expect to be "on the way" rather than informative).

![](https://raw.githubusercontent.com/WICG/WebID/main/static/mock19.svg)

We don't know exactly what's the right trade-off here, but we are inclined to prefer the mediation-oriented variation compared to the permission-oriented variation: we think there is enough converge on **parts** of federated sign-in on the web where the ossification cost is lower compared to the privacy/security benefits.

Taking a slightly more longer term view, we believe that the [delegation-oriented variation](https://github.com/WICG/WebID#the-end-state) is the right variation long term.

There is a chance they are not mutually exclusive and that this tension is a tension that website authors can pick trade-offs.

That was a long answer, but hopefully gives you a sense of what are the tensions in the question of `Are you looking to make it smoother for a user to log in with a federated ID.

> Are you looking to display on the page "Hello Hadley, would you like to sign in with your Google* account?" (Other ID providers obviously are available.) 

Can you clarity what you mean here?
 
> Are you keen to make social buttons work better so the user can post/share a link to the site they're on?

We are primarily interested in preserving identity federation on the Web. 

We think that some of the "social button" use cases are better served by <[fencedframes](https://github.com/shivanigithub/fenced-frame)>.



-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/622#issuecomment-839256275