13J/ The Web Platform, Privacy and Federation (thoughts on WebID)

From IIW

WebID: The Web Platform, Privacy and Federation


Wednesday 13J

Convener: Sam Goto, Dick Hardt, Vittorio Bertocci, George Fletcher, Aaron Parecki

Notes-taker(s): George Fletcher


Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps


[Sam will share his slides used for introducing the topic]

https://docs.google.com/presentation/d/1rnFtThP-drlMKdDDcxknWI1BcswcFZ0LrTMqODoMJrM/edit#slide=id.g831751c125_1_829

Premise: federation is good, we want to preserve it, it’s certainly better than username/password.

Framework for evaluating priorities

  • User’s first

  • Developers second (RPs and IDPs)

  • Frameworks third (browser engines)

  • Technical purity fourth

    • ?Where does compatibility with existing processes come in?

Current federation is built using browser primitives like iframes, cookies, redirects, popups, etc. Browsers need to apply the lowest common denominator policies to these primitives.

Tracking on the web has also been built using these primitives.

E.g. facebook comment widgets on different blogs mean facebook knows all the blogs you visit

Goal is to prevent RPs colluding to track users, and also prevent IdPs from knowing everywhere the user logs in.

In regards to privacy… even “users” need a gradient of protections as implemented by the browser. Maybe use an opt-in model as opposed to an opt-out one.

RP tracking problem:

  • Use directed identifiers

  • Separate authentication and authorization (don’t combine them as OIDC/OAuth do today)

Options for solutions

  • The permission-oriented variation

    • Browser provides interstitials to ensure the user wants to use that IDP and the browser can also inspect the user data flowing back through the browser to provide help to the user that globally correlatable identifiers are being shared

    • If user agrees to interstitials, the rest of the UI is under the control of the IDP

  • The mediation-oriented variation

    • No IDP UI, browser managed the UI

    • Browsers can control defaults

    • Browsers only mediate in the exchange of the tokens but not in the authentication of the IDP

    • User authenticates to IDP without knowing where the user wants to login (no knowledge of the RP)

  • The delegation-oriented variation

    • Not covered in this session