OIDC Browser Interactions Special Topics Call

2020-01-13

Attendees

• Tim Cappalli (Microsoft)
• Don Thibeau (OIDF)
• Tony Nadalin
• Tobias Looker (Mattr)
• Vittorio Bertocci (Auth0)
• Brian Campbell (Ping)
• Achim Schlosser (EnID)
• Chris Phillips (CANARIE)
• Adam Lemmon (Convergence Tech)
• Pam Dingle (Microsoft)
• Tom Jones
• Brock Allen (IdentityServer)
• Mike Varley (SecureKey)
• John Bradley (Yubico)
• Nic Roy (Internet2)
• George Fletcher (Verizon)

Agenda

• Quick intros
• Consensus on scope and goals
• Quick overview of CHAPI (Tobias)
• Known discussion items: Discovery the wallet invocation problem (SIOP) general account discovery WebID: need to scope this discussion

Notes

• Tobias Looker presented a short overview on CHAPI.
• Mike: Experience with CHAPI and helps the user bring their own provider to a relying party without the NASCAR problem
• Tom: IsLoggedIn is part of this conversation
• Vittorio: WebID and IsLoggedIn are berowser vendor's interpreations of how web identity should work. OpenID doesn't tell people how to use cookies. Identify the places where this may break and dig deeper into where we use cookies today
• Tom: Focus on trust, if the user decides some site is trusted or a family or sites, the browser shouldn't heckle the user every time they visit the site. Browser keeps track of user trust decision.
• Achim: agree on goals. Focus should mainly be on WebID. Holistic approach to federated login in the browser. IsLoggedIn is more of a signal; doesn't wrap a identity flow itself
• Vittorio: Mostly concerned about (IsLoggedIn), now I know the domain of the IdP, can treat cookies differently (potentially). Edge is also involved in IsLoggedIn
• Achim: Also related to Storage Access API
• Tobias: rough API that is available is very centric to OpenID and OAuth. Is that the intention going forward?
• George: SAML hasn't really been addressed yet
• Tobias: Expect WebID to accept multiple assertion formats?
• George: Sometimes we intentionally don't share data with the browser (ex: encrypted SAML assertion). Lots of implications
• Chris: Federation represents thousands of IdPs.
• Vittorio: Browser vendors are thinking of very specific scenarios and optimizing on those. WebID focused on specific Account Chooser scenario (short list of IdPs). Assumptions that there is a JS SDK. Many things result in "enterprise exceptions" (aka MDM or browser policy). SSO happens in all verticals and spaces including consumer. Working to enumerate scenarios (via IETF). Use this document during discussions to show these use cases exist and are very relevant.
• Tim: Educating on enteprise scenarios directly
• Vittorio: Get everyone to participate: Kantara, etc. Trying to create a framework to allow scenario contribution
• Tom: Go beyond use cases. Get test cases, set that browser would have to pass. When feature goes into Chrome Canary, you can file bugs against it
• Tim: tie use cases to test cases
• Brian: some feedback goes into the "enterprise use case" bucket
• Tom: Ken responds to the Github issues. Make specific individual objections in the Github
• Achim: Had some interactions on the issues over the past month. Some objections are being added to the backlog.
• Tom: 3 API owners have to accept changes in Chromium. And they check to see any of the developers object.
• Achim: Assertions and OIDC: they're aiming to address the high volume B2C use cases, relying on language from OIDC. Won't care about server2server flows, likely keep JWT-based approach
• Tobias: Authorization - seems focused on identity profile right now. Where do access tokens get married together
• George: Intentionally and explicitly separating authN and authZ. Intentionally trying to break combined flows to separate.
• Tobias: Goals around tracking/privacy; if there's no solution for authZ, you have to go back out and potentially undermind webid goals
• George: id_token sent back to the browser doesn't have to be the same as the id_token exchanged from a code. Might be better to make the browser a wallet
• Achim: boils down to that direction. You lock into the browser as the user and the id_token sits in a secure enclave. After user goes through basic id_token exchange, browser takes this as a signal that they don't have to mediate a token exchange.
• George: Started with prevent ad trackers using OIDC. "Are you sure you want to log in to this IdP?". Tackle problems individually might be faster
• Achim: Most dominant goal seems to be avoiding email sharing (directed identifier)
• Vittorio: end users understand emails. identifiers can be far more powerful and more precise. Problem of the user doing business with the domain is different than having an identifier with the domain. Different domains, same company is a perfectly valid use case. Email proxy feature is not feasible in practice. If everyone was forced to use it, there would be problems.
• George: Browser mediating sharing of email address doesn't prevent the site from asking for after login.

Work Streams

• George, Vittorio working use case framework at IETF

Next Call

• IsLoggedIn Overview (George)
• WebID (tbd, discuss on list)