WebID

[samuelgoto]

Ya ya yawm TAG!

I'm requesting a TAG review of WebID.

TL;DR; This is an active exploration to react to the ongoing privacy-oriented changes in browsers and preserve identity federation (e.g. OpenID, OAuth and SAML) on the web.

• Explainer¹ (minimally containing user needs and example code): url
• Security and Privacy self-review²: TODO(goto): will do. In the meantime, what we have this privacy threat model.
• Primary contacts (and their relationship to the specification):
  • goto@chromium.org, http://github.com/samuelgoto, https://twitter.com/samuelgoto, Google
• Organization/project driving the design: Google/Chrome
• External status/issue trackers for this feature (publicly visible, e.g. Chrome Status):
  • WICG proposal
  • chromestatus
  • Intent To Prototype
  • devtrial

Further details:

• I have reviewed the TAG's Web Platform Design Principles
• The group where the incubation/design work on this is being done (or is intended to be done in the future): WICG
• The group where standardization of this work is intended to be done ("unknown" if not known): unknown (WebAppSec seems the closest, OpenID foundation seems close too)
• Existing major pieces of multi-stakeholder review or discussion of this design: many discussions are happening at many standards bodies, most notably the OpenID foundation and the OAuth WG
• Major unresolved issues with or opposition to this design:
• This work is being funded by: Google

You should also know that...

• this is really early and we have a series of open questions.
• we are probably more interested in an evaluation / validation in exponentially decreasing interest:
  • First and foremost, did we get the problem right?
    • are we solving a real or a hypothetical problem?
    • did we interpret the direction that browsers are going correctly?
    • is there any precedence or comparable problem (beyond ads)?
    • the tag is in a unique position to get a holistic perspective across browsers, where does it stand on this problem?
  • Second, assuming that you agree with the problem statement and that identity federation is more secure compared to usernames/passwords, does the end state look directionally correct?
  • Third, assuming that you agree with the problem and the direction that we are going is directionally correct, does the sequence strategy make sense?
• if you are inclined to evaluate the solutions (rather than the problem), just wanted to provide some context: we haven't run into any easy solutions and most of the options come in the form of alternatives with trade-offs: a broad-but-shallow evaluation of the surface area (e.g. an assessment of blind spots in multi-browser positions) is probably more effective to us now than than a narrow-but-deep evaluation of a specific formulation (e.g. API shape). In case you are lost in the many links, here are the specific APIs we are building to give a sense of what WebID looks like in practice:
  • stage 1 : Things we believe we need to preserve federation without 3p cookies
  • stage 2: Things we believe we'll need to preserve federation under preventions against navigational tracking
  • stage 3: Where we expect to park long term.
• if you meet over a VC and would welcome us joining, we are very happy to come and answer questions / clarify in real ti me

We'd prefer the TAG provide feedback as (please delete all but the desired option):

💬 leave review feedback as a comment in this issue and @-notify @samuelgoto

[cynthia]

This name overlaps with existing work in W3C, which isn't ideal.

[samuelgoto]

This name overlaps with existing work in W3C, which isn't ideal.

Ack, and on it. My mistake for missing the conflict. The very first line of the explainer contains the context, the status, our intent and how we are acting on it:

not to be confused with this WebID whose authors have graciously allowed us to use this as a codename until we find a better one

[hadleybeeman]

Hi @samuelgoto! We are looking at this in our W3C TAG virtual face-to-face.

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"). For example: 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.) Are you keen to make social buttons work better so the user can post/share a link to the site they're on?

It would be great if you could help us understand what user needs you are focusing on. (It would also be great if you could put them in the explainer too.) Thanks!

[samuelgoto]

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

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: it is hard to calculate the game play here, we need to think about what's smoother with second-order and third-order unintended consequences.

With one of the variations, which we call the mediated-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".

This is a clear tension, most notably explained in the extensible manifesto.

There is solid precedence of ossification in auth for the web, most notably "Basic Auth" WWW-Authenticate: Basic. It ossified a norm to capture usernames/passwords which was long been surpassed by the ability of multiple websites to innovate and compete in an open market in user land.

In contrast, 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).

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

[hadleybeeman]

Hi @samuelgoto — we are revisiting this in our break-out session. We understand that you are considering creating a community group around this? We are very supportive, and are keen to see this space investigated further. Please do keep us in the loop as you develop designs for new web features — we'd love to review and help with them.

In light of that, we propose closing this issue.

[samuelgoto]

Hi @samuelgoto — we are revisiting this in our break-out session. We understand that you are considering creating a community group around this?

Yes. Here is how this is staring to form.

We are very supportive, and are keen to see this space investigated further. Please do keep us in the loop as you develop designs for new web features — we'd love to review and help with them.

Will do.

In light of that, we propose closing this issue.

SGTM!

Thanks for the early review, much appreciated! We will kick off with more in-depth and specific full reviews for parts of the API surface!

Thanks all, Sam