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