OIDC Browser Interactions Special Topics Call

2021-03-24

Attendees

• Tim Cappalli (Microsoft Identity)
• Tom Jones
• Sam Goto (Google)
• Brian Campbell (Ping)
• David Waite (Ping)
• Tony Nadalin
• George Fletcher (Verizon)
• Andrii Deinega
• Heather Flanagan
• John Bradley (Yubico)

Agenda

• Intros and Reintros
• Review known use case list and request contributions [15m]
• Review submitted use cases (Vittorio/George) [10m]
• 3P Cookies + CORS (Brian) [5m]
• Sam Goto Quick Intro [5m]
• Topics for next call
• Open Discussion

Notes

Use Case Brainstorming List

• Move list to GitHub (instead of Google Docs)
• [Vittorio] Read the contribution doc
• [Heather] like the idea of indicating what they're working on
• [Tim] Create issues for the use cases
• [Vittorio] recap the use case effort: list of identity-related scenarios that leverage the browser in some capacity. Prioritize the ones known to be affected, but good to have a library for future reference. Not just login, could be AT/RT and leveraging the existing session, etc. Template should make it easy to tease out the pieces that are relevant. Which part of the browsers are being leveraged, decorated links, triggering JS posts, etc. Template also looks at privacy considerations. Ex: assertions encrypted or sensitive data handled server side, are important to the conversation. Sequence diagrams are very useful.
• [George] OIDC in a first party use case, start chaining flows together and end touching on many different areas. Try to separate and focus on the core element of the use case. That's why authentication methods are broken out in the list. May not be part of the protocol, but are used.
• [Heather] May be helpful to highlight existing broken experiences
• [George] What about pulling out the known implementations that have broken flows and link them back to individual use cases. Ex: this use case is broken with this browser
• [Heather] that serves the purpose
• [George] can start that effort based on the existing list
• [Vittorio] did a bunch of that already in last year's Identiverse preso
• [George] May not be able to reproduce certain things (like Safari putting cookies into strict mode for one person and not another).
• [Vittorio] Qualify the scenario (response mode, type, etc)
• [John] Flow not mentioned, POST message flow (mostly used by Fb/Goog). Standardization never caught on. Might want to capture it. (tim create issue)
• [Vittorio] Many folks don't realize they're using WS-Fed
• [Heather] Willing to help with content and sequence diagrams
• [George] recommend websequencediagrams.com
• [Vittorio] Best thing we can do is make clear as possible what we're trying to preserve
• [Tom] Sam: is this approach helpful?
• [Sam G]: Yes, constructive. Seems like the best way to do it. These docs help with terminology mismatches. Appreciated from my side.

CORS + 3P Cookies

• [Brian] Some scenarios, like an auth API, rely on the 3P cookies being sent cross-origin. Not directly part of any of these standards. OIDC/OAuth may make use of CORS in a code exchange flow, but not cookies. Implementations may be using 3P cookies with APIs. Could an exception for CORS be carved out? Sounds like CORS requests will be subject to the same restrictions as other 3P requests.
• [George] Put those in the authentication section of the use cases
• [Brian] Levels of abstraction can be challenging
• [George] write it up and we'll figure out where to put it
• [DW] Changes how people consider CORS. People use CORS to protect API, which doesn't always make sense. Fine grained CORS header control. Things behind the firewall (ex: employees accessing a website)
• [Heather] One of the use cases I submitted is about IdP discovery. This scenario may match some of the concerns. It is in a PR
• [Sam G] If it's a use case that is important for you, I want to hear about it.
• [Tom] ADFS use cases? Are token translators still in use?
• [Tony] Think they're still used quite a bit
• [Vittorio] Decorated redirects and JS that does self POSTs. WS-Fed there weren't the equivalents of a nonce or similar. Old deployments may not set SameSite.
• [George] Form POST response type in OIDC requires a cookie to be present to ensure the response from the RP is coming through the same browser that initiated. Browsers added a temp solution that said if the cookie was set within 2 minutes, we'll still send it. Always labeled temporary. Many form POST response types depend on it. Something that needs a lot of lead time. A lot of things will break.
• [Sam G] I'll take a closer look at this. Browser must have been Safari. Believe it would fall into link decoration prevention. Don't believe it would be broken by 3P cookies deprecation.
• [George] SAML. RP redirects to the IdP. 200 with HTML content and JS that runs and submits. From browser view, looks like auto submission from domain 1 to domain 2 and so the cookies went away. Possible it is only broken in Safari.
• [Vittorio] Bigger than that. Certain it was a problem with Chrome as well.
• [George] Default rules of lax, cookie is only sent if there is an explicit user action. Defaulting to lax because people aren't setting the default value.
• [Sam G] I believe this is a mechanism to track on the web so Chrome would likely want to control it. Think it falls into link decoration, not 3P cookie deprecation challenges.
• [George] Because it got flagged as temporary, very scary; when is it over. Better clarity on when it will end.

Topics for Next Call

• Sam G Intro
• Tom - PWA presentation
• Start reviewing submissions