Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WebID #622

Closed
1 task done
samuelgoto opened this issue Apr 2, 2021 · 6 comments
Closed
1 task done

WebID #622

samuelgoto opened this issue Apr 2, 2021 · 6 comments
Assignees
Labels
Mode: breakout Work done during a time-limited breakout session privacy-tracker Group bringing to attention of Privacy, or tracked by the Privacy Group but not needing response. Progress: propose closing we think it should be closed but are waiting on some feedback or consensus Review type: CG early review An early review of general direction from a Community Group Topic: identity & credentials Topic: privacy Venue: WICG

Comments

@samuelgoto
Copy link

samuelgoto commented Apr 2, 2021

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.

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

@samuelgoto samuelgoto added Progress: untriaged Review type: CG early review An early review of general direction from a Community Group labels Apr 2, 2021
@rhiaro rhiaro self-assigned this Apr 19, 2021
@torgo torgo added Big chunk of work privacy-tracker Group bringing to attention of Privacy, or tracked by the Privacy Group but not needing response. Topic: identity & credentials Topic: privacy Venue: WICG and removed Progress: untriaged labels Apr 21, 2021
@torgo torgo added this to the 2021-04-26-week milestone Apr 21, 2021
@atanassov atanassov self-assigned this Apr 26, 2021
@cynthia
Copy link
Member

cynthia commented Apr 27, 2021

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

@samuelgoto
Copy link
Author

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
Copy link
Member

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!

@hadleybeeman hadleybeeman self-assigned this May 11, 2021
@samuelgoto
Copy link
Author

samuelgoto commented May 11, 2021

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
Copy link
Member

hadleybeeman commented Jun 14, 2021

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.

@hadleybeeman hadleybeeman reopened this Jun 14, 2021
@hadleybeeman hadleybeeman added the Progress: propose closing we think it should be closed but are waiting on some feedback or consensus label Jun 14, 2021
@samuelgoto
Copy link
Author

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

@rhiaro rhiaro added Mode: breakout Work done during a time-limited breakout session and removed Big chunk of work labels May 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Mode: breakout Work done during a time-limited breakout session privacy-tracker Group bringing to attention of Privacy, or tracked by the Privacy Group but not needing response. Progress: propose closing we think it should be closed but are waiting on some feedback or consensus Review type: CG early review An early review of general direction from a Community Group Topic: identity & credentials Topic: privacy Venue: WICG
Projects
None yet
Development

No branches or pull requests

8 participants