Skip to content

Latest commit

 

History

History
659 lines (386 loc) · 16.8 KB

2024-02-06-notes.md

File metadata and controls

659 lines (386 loc) · 16.8 KB
Raw

FedID CG call notes (Atlantic), 6 February 2023

  • Moderator: Heather Flanagan

  • Scribe: Michael Knowles

Call-in details: see https://www.w3.org/groups/cg/fed-id/calendar/

Charter: https://github.com/w3c/fedidcg

Agenda

Notes

  • Security Primer / Best Practices / Guidelines for using FedCM - issue 536

  • Heather

    • Not much documentation on how everything interacts with OAuth

    • Wanted to start conversation on how FedCM interacts with OAuth

    • Next meeting is in March

    • Chairs of OAuth would read through FedCM (last time they looked was ~3 years ago)

    • Re-familiarize themselves

    • Mention it in OAuth WG meeting in Brisbane

    • Then submit something to OAuth Security Workshop in April in (Rome, April 10-12) https://oauth.secworkshop.events/

    • Would be good time to focus on privacy implications between OAuth and FedCM

    • Also: Focus time & attention at IIW (week after in Mountain View, April 16-18) https://internetidentityworkshop.com/

Specifically https://www.eventbrite.com/e/internet-identity-workshop-iiwxxxviii-38-2024a-tickets-775719386567?aff=oddtdtcreator

  • Want to take advantage of unconference format of IIW to determine what is missing / what additional conversations have to happen

  • Maybe have interim meeting with OAuth WG - virtual format, use IETF infrastructure

  • Might be useful once we have a better plan on what we want to do

  • Still TODO: OpenID Connect aspect of things

  • OIDC is a profile on top of OAuth

  • Making sure there is awareness and engagement in OIDC

  • 95% overlap of people in OAuth and OIDC - so cross-pollination shouldn’t be too different

  • Sam

    • That's exactly right – had initial meeting with OAuth chairs

    • Lots of alignment and common interest

    • Not sure how to navigate between Open ID Foundation and OAuth WG

    • Layering it seems to be the right approach

    • Workshop in Rome is in-person only

    • Tim kicked off a thread to get us into the schedule – not sure if that will succeed - waiting to hear back

    • And IIW

    • Also would like to do something a bit scrappier in this CG

    • IETF work might be a bit slower due to increased rigor

    • Maybe we can kick of discussion early here in CG to sanity check basic ideas

    • We’re starting to see smaller IDPs in the wild

    • Not sure we have appropriate recommendations to give those smaller IDPs

    • Security properties, etc. in particulars

    • Delegated a lot of this to Ecosystem, historically, but want to steer Ecosystem in the right direction.

    • Would like to incubate some of the major ideas here, as we have the experts here

  • Heather

    • Incubate ideas – suggesting that we start a document?

  • Sam

    • Yes start a document with our collective knowledge of OAuth and FedCM and OIDC

    • And Chrome would point devs at that doc

    • FedCM is opinionated about the protocol that happens through it

    • No mention of JWTs, Nonces, how to prevent replay attacks, etc.

    • By design FedCM gets out of the way of those

    • But developers don't have a basis on how to use FedCM (from those perspectives)

    • In contrast, OIDC / OAuth experts in this CG have been deploying these systems for decades.

  • Heather

    • Additional thoughts or ideas?

    • Under the impression that there are a lot of different ways that the OAuth protocol (and SAML) could be used

    • Here’s a way to do it to respect proper Privacy and Security principles we might want a reference architecture on how to do it properly to preserve those principles (out of potentially multiple alternatives)

    • Is that correct?

    • If we wanted to create documentation that from the FedCM perspective here’s how to avoid particular security issues …

    • Not sure how to scope this in a reasonable way

  • Sam

    • Was thinking a document that could eventually turn into an IETF RFC

    • Forms meat and bones of eventual RFC

  • Heather

    • Not worried about format, worried about he scope

  • Sam

    • RFC would be the scope

    • THinking of it as a “binding” to OAuth

    • In OAuth spec - do a top-level navigation to IDP, then do a top-level nav with redirect URL, or open an iframe (similar examples from OIDC spec)

    • Might imagine an extra clause that if you were operating with a FedCM capable user agent, make this JS call to FedCM instead of those redirects

    • Conceptually, from a layering perspective, a binding to SAML or OAuth

  • Phillip

    • For SAML that would be the right thinking (a new binding to SAML)

    • In Open ID you have response modes where you can post back to a redirect URL

  • Sam

    • Not sure what final answer is, but seems like we have the experts in this CG

      • (George / Tim / John Bradley / etc.)

  • Achim

    • Idea is generally correct, having said that having a binding to FedCM to OIDC

    • Redirects and URL parameter are fundamental core concepts down to Oauth

    • Long-term you’d have to add a specific segment in OAuth because the flow is now different

    • Agree to the problem statement that the FedCM does not describe at all how the login process actually does in depth (OIDC or SAML)

    • So, guidance can be helpful

  • Sam

    • Some people are of opinion that FedCM is conceptually different than top-level redirects or iframes, that just being a “binding” is not necessarily appropriate because top-level assumptions are fundamentally change to those protocols’ flows

    • FedCM has a lot of UX involved, whereas OIDC / OAuth / SAML do not typical

    • Implicit flows have been frowned upon for a while in OAuth due to, in part, concerns about redirects getting into URL history / bookmarks, etc.

    • No guarantee that payload will be returned to originating origin

    • Should start to get FedCM as part of OAuth rather than starting something completely new

  • Ben

    • Raises potential utility to have binding of FeDCM to OAuth that may not have as much as its own UX that exercises IDP control that more-quickly tries to step out of the way

    • Maybe try to carve that out?

    • Will get harder and harder to do with the arrival of more smaller adopters

    • So maybe do it sooner than later

  • Heather

    • Question for Ben: Firm believer in simpler is better and getting out of the way

    • HOw to get there from where we are?

    • Whiteboard session to hash it out?

    • Proposal that Ben had from a while ago

  • Ben

    • Hasn’t changed much – haven’t put all newest context back

    • Maybe a whiteboard session would be good

    • Would be good to see what this might look like if we wanted a minimal

  • Heather

    • Next week is Pacific call - Atlantic session would normally be canceled

    • Maybe use the normal Atlantic time slot to do that whiteboard session?

    • Seems like Yes

    • Will reach out to George and Tim and John Bradley to see if they can help

    • So, consider next week’s Atlantic time slot to draw out some of the ideas Ben has in his head

  • Sam

    • Point that Ben raised is very valid

    • Actively interested in working on

    • Materializing more in terms of Auto-Granting Storage Access API call

    • Part of the intersection is based on Auto-Granting SAA after FedCM consent has happened

    • Other idea with Johann Hofmann about finding a way to decrease cost of operating FedCM by not requiring IDP to spin up endpoints for fedCM

    • Intersection of that – would like to have folks like Johann and maybe Kaustubha Govind there too

    • Somewhat orthogonal to autogranting vs OAuth binding

    • Whiteboard session is perfectly valid but won’t be sufficient to form guidelines to the Ecosystem

  • Ben

    • Johann has mentioned an idea like that previously but not details yet

    • Would like to see how / where this bumps into SAA

    • Thinking about alternative designs would be good while still in incubation stage

  • Heather

    • Will reach out to Johann to see if he is available next week

  • Sam

    • Johann was worried about taking too many steps back

    • Other group working on Lightweight Credentials is Digital Identities CG that is thinking about wallets

    • Also thinking about thinking of storing credentials in wallets without having to spin up servers

    • But that’s in much earlier stages of incubation

    • Sense of urgency exists in terms of 3PCD which is closer to our work than Digital Identities CG

  • Heather

    • Def area of consideration, but don’t want to re-litigate things that have been settled already in FedCM

    • Lots of overlap between FeDCM and DigID CG

    • Maybe let’s wait for that a little bit

  • Achim

    • Same topics are cropping up in Wallets space too as they operate on top of OAuth as well

    • Schemes are similar – protocols use redirects

    • Allows you to claim something that looks like a redirect but actually isn’t one (?)

    • Also more fruitful to think in terms of deployments

    • Where are similarities for deployments if you push something through FeDCM

    • How can you deploy with least amount of work with as much infra you already have in context of OAuth where you already have a token

    • Which checks can be done where?

    • Could be better than plain redirect?

    • Similar topics in both CGs and following WGs

    • Fundamental change if you have these types of APIs (FedCM and Digital Identity APIs)

  • Why does Privacy Sandbox's FedCM explainer say SAML is not well-supported by FedCM?

  • Heather

    • Questions recently about SAML

    • Question about whether SAML will be broken by 3PCD

    • No specification about in SAML about #P cookies

    • Global logout might be affected

    • Seamless access which is part of IDP discovery heavily used by SAML community

    • Might be part of where people are getting confused

    • Talking about SAML in a very narrow way

  • Sam

    • Messages we are getting from SAML operators is that they are depending on 3P cookies

    • Feel like Authentication mechanism is one of the large number of services they provide

    • So we’ve been told SAML doesn’t break with 3P Cookie Deprecation

    • But all the operators are coming back saying “no no it actually does break because of these auxiliary operations”

  • Achim

    • Depends on definition of “break”

    • If it doesn’t technically break but it is a horrible user experience

  • Heather

    • In terms of practical implications, a lot of that is what Phil has been testing

  • Phil

    • Gets involved with tracking mitigations with proxies

    • When you combine the whole store, it gets more involved

    • If your IDP operates in an embed that could be issue

  • Sam

    • We’re getting these comments that even today tbat SAML servers’ operations “break” with the 3PCD that is starting to roll out

    • Embedded uses are outside of SAML proper but are part of the overall deployment

    • So if this community could provide guidance that would be great

  • Nicoals

    • If we could have examples of user flows that actually break (SAML) in particular, that would help

  • Heather

    • Would like to take this offline with Shannon Zaccharias Mathew and Phil to come up with a reasonable presentation on what this looks like from SAML communities

    • And comb back in 2 weeks

  • Matthew

    • Would need to get everything done before 15th of Feb due to external constraints

  • Heather

    • Good

    • Any Questions / Comments?

    • Segue to AOB: Multi-IDP update from Phil

  • Phil

    • Issues if you had two idps and neither was logged in it would pop up window for first and then second and had to authenticate to both

    • No longer happens with Multi-IDP which is good

    • Seems to work relatively well

    • Still have 1000 IDP issue

    • But for the limited case we are discussing works well

    • FedCM dialog is in top right hand corner sometimes it popped up another dialog in middle of browser window

    • Picture is in the issue

    • Was different / unexpected dialog in the middle

    • Also crashed occasionally

    • Is it getting confused with other experimental features?

    • In general it did work in expected way

  • Nicolas

    • Looks like Button Mode API

    • Had flag enabled and did call with that

    • That would probably result in crashes

    • Don’t have multiple iDP support with button mode

  • Avhim

    • Saw this when you are signed in with one IDP signed out of another IDP

    • Doesn’t match sign-in state

  • Nicolas

    • That’s not how mis-matched UI looks

    • That is the button account chooser UI

    • Wondering if you are using the Get call even with the button

    • SHouldn’t happen on its own though

    • If both the flag and the API have the button mode that is expected

    • Would be quite bad if both conditions were being met

  • Phil

    • Will definitely try to strip that out and try it

  • Nicolas

    • Specific use-case for Multi-IDP in mind?

    • Would that use-case use button mode or would widget mode be sufficient?

  • Phil

    • Button flow would probably be more useful

    • If we were doing it with 5000 IDPs would use Seamless access first to select the IDP ad then use FedCM with the selected IDP

    • Couldn’t put 5000 IDPs into that FedCm UI

    • Progress too - but we’d have to do IDP selection first

    • Some discussion on register-your-idp

    • But even then it would be federation of 5000 IDPs

    • So probably unworkable - don’t have the capability for FedCM gto represent the scale that we typically have in R&E

  • Nicolas

    • You’d want the user to select the IDP once and then for later RPs that use similar flow to use that IDP?

  • Phil

    • Yes - currently done by redirect and 3P cookie

  • Nicollas

    • Yes - good point that it requires more

    • In your case it is showing no UI

    • Widget could do that too

    • Wondering if that would be acceptable?

    • Would have to have a fallback

    • And wouldn’t know if showing UI or not

  • Phil

    • If browser would know that that his is the user’s IDP

    • IF there was a way for users to register IDP or select IDP that would help with selection issue

    • But don’t want to preclude the user to select an alternate IDP

    • That’s inside something else

    • Having the browser understand that this is your IDP is not a bad thing at all

    • Can’t use it or have RP say which IDPs have registered with the browser (privacy issues)

    • No good answer there

    • Certainly need to handle multiple IDPs, and remember the users’ selection

    • 20 years of experimentation to make this work so far…

  • Heather

    • At end now

    • Will reach out to Johann and others to turn next week into an informal whiteboard session

Attendees (sign yourself in)

  • Heather Flanagan (Spherical Cow Consulting, chair)

  • Phil Smart (Shibboleth)

  • Christian Biesinger (Google Chrome)

  • Achim Schlosser (European netID Foundation, co-chair)

  • Michael Knowles (Google Chrome)

  • Nicolás Peña Moreno (Google Chrome)

  • Brian Daugherty (Google Identity)

  • Zachary Tan (Google Chrome)

  • Alan Buxey (MyUNiDAYS Ltd)

  • Wanpeng Li (University of Aberdeen)

  • Zacharias Törnblom (SUNET)

  • Wendy Seltzer (Tucows)

  • Oliver Rickard (Atypon/Wiley)