1. OpenID Foundation Avatar OpenID Foundation
  2. WGs
  3. connect

Wiki

Clone wiki

connect / Browser Interactions Special Topics Call - 20210127

View History

OIDC Browser Interactions Special Topics Call

2020-01-27

Attendees

  • Tim Cappalli (Microsoft Identity)
  • Brian Campbell (Ping)
  • Vittorio (Auth0)
  • Nic Roy (Internet2)
  • Don Thibeau (OIDF)
  • Heather Flanagan
  • Edmund Jay
  • Bjorn Hjelm (Verizon)
  • Anthony Nadalin
  • Brock Allen
  • Achim Schlosser (EnID)
  • Mike Varley (SK)
  • Melanie Richards (Microsoft Edge)
  • David Waite (Ping)

Agenda

Notes

  • Tim showed demo of WebID in Chrome Canary. Link to a similar demo
  • [Tim] No cookies sent to IdP
  • [Achim] Storage access in these calls may be priviliged, allowing the IdP to maintain permanent session state
  • [Brock] How does the user know they're not being phished? UX is important here.
  • [Tim] UI/UX is definitely changing
  • [Brock] How does MFA work at the IdP? The browser prompting seems like a problem.
  • [Brian] +1 to Brock
  • [Tim] Haven't tested whether FIDO, etc work in the webview
  • [Brock] What if the IdP wants to federate to upstream IdPs? More UI workflow issues, IMO
  • [Achim] Might treat equally to storage access
  • [Achim] WebID is part of the bigger priv sanbox discussion project. Focuses on tracking and things that are potentially not permissable with SSO scenarios. That's where the RP and IdP tracking problems come from. If the browser knows a login is happening, it can allow the the flow. Then solve other problems:
  • [Achim] RP tracking: email addresses are defacto stnd for usernames, used for communications, this is the genesis of the problem. Potential to use to join data across services without user consent. Federated login can lead to global identifiers and could be exploitable by providers.
  • [Achim] IdP tracking: when users are leveraging SSO, IdP is aware of sites the user is accessing and could be using to monetize or for other means. How can you avoid the IdP from learning which sites user is accessing.
  • [Achim] https://github.com/WICG/WebID/blob/master/privacy_threat_model.md lays out the threat model and attack scenarios including collusion between RPs and IdPs.
  • [Achim] Solution space for consumers: permission-oriented, mediation-oriented and delegation-oriented https://github.com/WICG/WebID/blob/master/consumers.md
  • [Brian] it's interesting that the threat model is only about privacy concerns
  • [Tim] enterprise customers pay IdPs for login auditing and tracking
  • [Achim] naturally there's friction between browser-side and server-side
  • [Vittorio] Try to engage with browser folks, but can be challenging with feature discussions. Concerns being raised on all these calls. Maybe in IETF we can change tactics. Place in a single place/catalog, all of the scenarios in use in mainstream.
  • [Vittorio] Template to propose a scenario. Designed to capture characteristics. Scenario, mechanics, privacy considerations. Feedback from Sam from Chrome who seemed to be supportive of the idea https://mailarchive.ietf.org/arch/msg/oauth/1ID0IsvTfU6Wnk9FKKb6tkfIj6M/.
  • [Vittorio] Decision to do this was made during an OAuth interim meeting after George and Vittorio presented IsLoggedIn and WebID and folks started to understand the threat of some of these new features and changes.
  • [Tony] Have you looked at the use case for privacy-pass?
  • [Vittorio] No
  • [Tony] IETF + W3C. Goal to replace CAPTCHA. Should look at what's going on there.
  • [Tom] the point of privacy pass is to avoid id - not clear how that relates to us
  • [Vittorio] hope that the doc will facilitate conversation
  • [Tom] Are others welcome (outside of IETF)
  • [Vittorio] yes, framework is meant to be consumed by anyone with a scenario. Scenarios are meant to be current practice. Ex: cookie for saving nonce in OIDC flows
  • [Heather] Absolutely anyone can participate in the IETF. Just be aware of the Note Well before you submit anything to a draft, mailing list, or meeting
  • [Tom] Real cases or cases the browser can't deal with yet?
  • [Vittorio] real cases. easy to consume and communicate outside our groups. Having a document we can refer to offline and avoid common pushback like "this is enterprise, use policy"
  • [Mike] +1
  • [Achim] +1
  • [Brian] Since Heather is on, can you help us understand what are the plans to bring standardization to this effort. Seems trending towards Chrome doing what they want to do.
  • [Heather] Went to WICG because they needed an IPR framework to cover what was being discussed. CG vs WG, anyone can partipate. WG only invited and members. Plans for standardization: obsveration: Sam is onboard with bringing in the use cases, but not clear if he is working on the standardization. Can't be building a Chrome-only thing.
  • [Achim] CG for protoyping and experimentation, WG only involved once standardized effort has started
  • [Heather] Not clear on direct effects of other specs/standards that need to be accounted for. Talking to Google itself as an enterprise IdP
  • [Vittorio] Looks like Chrome has goals that m
  • [Tim] Personl observation from previous engagements: Google internal IT tends to assume all devices are managed which often drives product decisions based on that assumption
  • [Tim] Should we actively reach out as a group?
  • [Don] Previously OIDF has acted as an aggregator (Apple as an example). Google has representation on the board.
  • [Heather] having an aggregator will be very helpful. They're gettign a firehose of stuff int he WICG github issues. Conslidated list will help them consume it.
  • [Don] OIDF may be in a useful position to suggest a coarse of action. Neutral party, workshop, etc.
  • [Tim] Bit of a tug of war with public code vs comments from Google
  • [Vittorio] Sam has been very open. May be other pressure. Maybe ask for a more formal engagement
  • [Tom] strong identity across websites that doesn't look like ad tracking
  • [Tim] Should we invite Sam and crew to call?
  • [Vittorio] we should spend some time amongst ourselves. Define our scope for them before being them in again. What do we want them to do
  • [] lots of agreement
  • [Tim] Goal for next meeting is to start reviewing use cases
  • [AChim] take a look at permission and mediation in the consumer flows. Delegation is a bit further out.

Work Streams

  • George, Vittorio working use case framework at IETF
  • Contribute use cases for discussion here

Next Call

Updated