Meeting minutes
<martinthomson> wow, there is definitely a party going on here
Kaan: Welcome everyone. Discussing FedCM. What we are and will continue working on
Kaan: Handing over to Sam for demo and presentation
<martinthomson> that is some FIERCE jitter
Sam: <presenting FedCM slides>
<martinthomson> loading...
Sam: Thanks all for coming. Lots of familar names. Appreciate the time.
Sam: Mostly a followup, status report, from last TPAC
<martinthomson> save me from the whining about 7am meetings
Sam: Will walk through what was discussed last TPAC. Will focus on something narrow in objectives and mechanims we're spending time on and skip motivation
Sam: Frame talk and make sure on same page. Will point to things as go along. Framing the discussion.
Sam: Overall scope is in Federation (Identity federation). Overloaded word means different things for differnt people
Sam: Go to website and login with identity provider. 2 ways no, federation or passwords (broadly speaking). Context we're in federation deployed over many years and very useful
Sam; Under stress and conflcit with privacy features of browswers. Project anchored in we like federation and privacy and want both. Looking for ways to make them not conflict
When say RP, mean relying part (website like pintrest, etc) IDP == Identity provider, (Facebook, Google, Apple, etc). Ask to take for granted that federation is safer then username/password
Sam: Problem, federation designed on top of low level primitives. Didn't ask browser permission to exist or evovle. Built on top of iframe, 3rd party cookies, navigations.
Challenge, browser classification problem. Same primitives allow cross site tracking. Browser problem to narrow down low level primitives and make less powerful
can't tell difference between good/bad use of primitives.
Classification problem. Same affordances for federation enables tracking.
Sam: Federation depends on many low level primitives. Most essential is link decoration or top level navigation. More fundamentally breaks federation. Lots of community discussion around that issue.
Sam: From chrome perpsective, blocking 3rd party cookies is happingin sooner, so need way to work around
Went to ecosystem and looking for folks to speak up if break when 3rd party cookies are blocked
Sam: This talk assumes 3rd party cookie are going away, other forums to discuss if they _should_ go away. We're assuming they are and want alternatives.
Sam: If you're a consumer, will recoginize 2nd and 3rd mock (social widgets, profile picture social button, etc) uses iframes and 3rd party cookies
Signin widgets with social accounts is also 3rd party cookies and expected to break.
For enterprise, something called front channel logout where IDP is able to log user out of all RPs at once
Mechanism to do is iframes and 3rd party cookies. IDP embeds 100 iframes poiting to relying partings with 3rd party cookies and lets RP clear storage.
Sam: Federation doesn't break extenstentially but it breaks enough that the ecosystem wants to see preserved and wants to see alternative.
Sam: Subproblme of bigger problem, but good stepping stone.
Sam: That's motiviation and way, if want more context and deeper understanding see the TPAC from last year which was more motivation oriented. Workshop notes and explainer
Sam: Focus into what we're doing, as far as Chrome is concerned
Sam: Umbrella project FedCM (originally WebID but renamed to FedCM to fix name conflict)
Sam: Federated Credential Management API. High level API. Chnages the attitude toward problem solving
Sam: As opposed to iframes or 3rd party low level APIs. Those are general purpose and enable a lot of use cases. This approach takes high level approach which is federation/identity specific
Sam: Hoping we can take different tradeoffs
Sam: Mental model where the browser/user-agent was unaware that identity was happening, our approach is to insert the browser into this situation to enable affordances.
Sam: As followup, last time told you big problem and we don't know how to solve. Have about 3 classes of solutions we've found.
Sam; Permission oriented, mediation oriented and delegation oriented model.
Sam: Want to show progress on 1 specific variation we think is useful. Mediation.
Sam: Mediation refers to idea of browser taking a bigger role in the federation UI and in doing so having a more meaningful moment at the cost of osssification more then it normally wold
Sam: Other options have different trade offs. None of them seem to be perfect, always a cost. Started with mediation as seemed the pros more compelling then cost.
Sam: First time introduction of UA between RP and IDP. Previously UA unaware of what hwas going on.
Sam: API Presuposes RP and IDP are interested in making federation survive. API does not require 0 effort. Finding easier to change IDP then RP. Try to put load onto IDP and UA and offload from RPs
Sam: Will succeed if no websiites have to change and no users saw any change but still had working federation without 3rd party cookies
Sam: Don't know if that's possible but it's a goal. As backwards compat as possible.
Sam: There are fewer UAs and IDPs then RPs in teh consumer space. Not true for enterprise or EDU.
Sam: Requries IDP and browser to work together
Sam: Asks IDP to expose URLs that allows JS to have APIs that an RP can call that allows the UA to intermediate.
Sam: Designed such that can be used by IDP but not effective way to track users. Designed such that tracker can't impersonalte IDP. Can't use effectively as a tracking system.
Sam: Goes other way as well. Set of APIs such that IDP can call UA and UA calls RP for session management.
Sam: Generally: statemachine in browser that transitions users from place to place.
Sam: As transition, unlocks capabilities that were not otherwise avaialble
Sam: Start as unregistered user without 3rd party cookies. Call account creation/signup api
Sam: Mediated by browser
Sam: First time identities are joined so important moment. Once have id can sign in / sign up/ sign out, refresh session
Sam: Very federation specific APIs.
Sam: To anchor <showing picture of browser screens>
Sam: See mediated accoutn chooser. The browser is aware and immediates the change of info from IDP and website.
Sam Shouldn't look foreign, most have seen account choosers. Most important no 3rd party cookies. Things are feched such that IDP can not track user went to websiter without user gesture.
Sam: Also not very useful as tracking mechanism as if i'm a tracker it's very visible. Not something that can be done unnoticed. Harder to be useful from tracking as compared to iframes
Sam: <showing mock with personalization> Federation is bigger then one compay. Shows big players on consumer side.
Sam: Can start thinking about how to fix nascar flag problem. Baby steps. The personalization is constrained, not arbitrary HTML/JS. Pick colour/icon. Not sure if points are sufficient but starting point.
Sam: Yi joining to give a demo.
Yi: <demo>
Yi: Goign to show how FedCM helps with signup flow in 3rd party cookie less world
Yi: User comes to Canada and wants to find a place to live. Searches for apartments and clicks on website.
Yi: Shows 'sign in' on top of page. User browses and finds house they like, taps star button.
Yi: Normally action requires an account. User navigated to signin/up page.
Yi: Builtin API allows showing prompt for user concent. User then sees they can sign into acount with one tap through IDP.
Yi: Continue button is customizable. Idealy done on the IDP side, no changes hopefuly needed by website.
Yi: User taps contiue, website takes over signup flow from FedCm and user is logged in and the apartment is starred.
Sam: Moving on, was a demo, enabled in Chrome canaries (or large chunks) can send instructions later. What we have so far.
Sam: For sense of direction, why some of us are excited. Constructive stepping stone for identity on the web. <showing Mock> compelling as close enough/familiar enough to feel concrete
Sam: Shows some initial ideas on pulling nascar flags into browser and giving user to remember accounts used most/less.
Sam: See UI affordances for multiple IDPs to exist in same account chooser and maybe making user experience a bit better
Sam: Havent' spent too much time here yet as it's beyond 3rd party cookie deprecation but we think it sets up a good path
Can imagine how can extend past web auth credentials and password.
Sam: From single to multiple IDp is one stepping stone and then coherent authentication mechanism is another step.
Sam: All of this written down into a spec. wicg.github.io/FedCM
Sam: Would love collaboration.
Sam: Lots of anxiety in ecosystem on when things will happen. Want to decrease changes of breaking the web as adding privacy.
Sam: Rough sense of how expect to roll out. Many of us thinking 10-15 year long project for all ambitions. More direction then checkpoint. 3rd party cookie deprecation is a close enough checkpoint to look at in isolation.
Sam: In itself hard enough. Couple years ago started thinking (2020) and went over last TPAC talk. We're somewhere towards end of 2022
started with real partners engaged with IDPs and in process for most of 2021.
Chrome has announced 3rd party cookie deprecation sometime beyond 2023. Lookign at that date, think need to be ready before that time.
Not just available, but productgion experience and some adoption.
Sam: Sometime beginning of 2022 (devtrial started beginning 2021) expect to have IDPs that are broken by 3rd party cookies to raise hands and say approach would work.
Sam: Origin Tirals somewhere middle of 2022. Will probaly find out things are broken and 2022 will give feedback on deployment and experience.
Sam: Hopefully 2nd half of 2022 will have found working forumation. So, 2023 something in chrome stable to be depended on.
Sam: More of a random walk. Part of the process. Looking for folks to help steer in the right direction.
Wanted to prime with questions to anchor to somethign concrete
Please introduce yourself and let us know how 3rd party cookie deprecation breaks you. What else concerns you when 3rd party cookies are blocked.
Sam: Askign for direction/guidance, if want course correction love to hear.
<martinthomson> I don't see Zakim in this room, is there a queue?
Sam: Would love to help, if some of this is helpful to other browsers as we find it useful to Chrome.
Asking browser venders to join FedID CG where discussion is happeing
Would love to hear about other concerns about 3rd party cookie deprecations.
Dmitri: Question about signup process. How do IDPs get on that list. Noticed in screen shot how branding would work only had 1 IDP per screen. Presumably would all exist in one list. So, why that screenshot, why separate in list, How does IDP get in list.
Sam: Start with 2nd question, is UX affordance for multiple IDPs. Yes, but not yet. Mock on future direction slide, shows accounts on Google Facebook and Twitter on same affordance.
Sam: 1st question, spent a lot of time on. trying as much as possible to avoid redeployment in ecosystem. Hooking into existing flow for users and RPs. Today, mostly, federation nascar problem is affordance from webiste not browser.
We're plugging into that point, so backwards compat by plugging into existing deployment.
Sam: Having nascar flag problem pulled into browser requires website to change. How does IDP get into the list, trying to avoid deployment challenges. Right now website or RP pre-registers with IDP to get client_id and they decided IDps they want to work with
Sam: To tap into existing deployment, it's a function of choice of the RP. Goign forward should find ways to change that. Like idea of working more like email addresses wehre you can bring your own IDP.
For 3rd party cookie deprecation starting from what we were given and trying to avoid as much change as possible.
Kristen: At Salesforce, intereste as both RPand IDP and as Saas business for clients.
Kristen: Know focusing on mediation but wondering is there somethign concret with permissions or delegation or reasons why not going with those and focusing on mediation? Some sort of pros/cons?
Sam: Delegation is easy to scratch off due to things urgent and important. Urgent but not important, somethign for 5 years for now. Directionally correct but ignored.
Sam: Then most of tension between permission and mediation. Tension struggeld with most. Discussion of trade offs and prototyping each.
Sam: Built permission prototype. None of prototypes compelling. Some didnt' meet requirements. Sometimes needed zero-tap personalization (no-user gesture personalization). If have permission in front it's a gesture
So, can't do requestStorageAccess as you ahve to impose a permission before allowing.
Sam: So purely based on non-satsifying of requirements. Frontchanell logout <missed> permission on.
Sam: From mental model, attack from users frist, author second, browser third. Permission puts onus on User instead of RP or UA. Mediation puts work on IDP instead of User.
So, think mediation better approach as better place to put pressure. 7billion users, few thousand IDPs. So right place to put pressure
Largely to be seen how will play out. Matches intution for consumers where small number of IDPs.
Different for enterprise, EDU and Gov.
Dan: Want to clarify how IDP becomes IDP. Architecture doesn't involve some kind of allow list within the UA? Want to better understand if that is correct?
Sam: Yes, no allow list in the UA. The website signals based on code. <Showing example> In this example Medium has setup to enumerate the IDPs they want to work with. So medium makes a choice to allow users to sign in with this list of IDPs.
The allow list is in the website, not UA.
Dan: Want to maek sure vision is to enable whole web. When talkign IDPs often talk Google, Apple, Twitter. Want to also talk about other IDPs.
Sam: 2 points to make, companies in east use IDPs in east (Yahoo Japan big one). Make choice themselves, from UA perspective, global not something browser chooses.
Sam: Also architectural problem to make IDPs interoperable so users can choose which IDP so list isnt' made by website but picked by user
Sam: Closer to how email works. Website doesn't have list of email providers it works with. From vision perspective one way to potentialy go.
Dmitri: Is the protocol classic OpenID connect (get back idToken) or does also include requesting arbitrary credentials with OpenId connect
Sam: Very much OpenID connect. Endpoints, termonology, nomenclature, tried best to find analogies and metaphors which map into that world.
Sam: example idtoken_endpoint which is OpenID concept. Metadata API to give client_id metadata. When get back idToken can be introspected by browser.
Sam: Well defined webtoken, can open and introspect if wanted too.
Sam: For authorization and larger scopes, something we have to deal with, haven't made much progress as we'd like. Dont' now how much breaks with 3rd party cookie deprecations and scopes. Know we can't mediate oauth scopes as there are too many and defined in user land.
Sam: Combination of mediation for account choosing and 2nd step for other oauth scopes.
Dmitri: To clarify previous question, to get on list will user have same list of IDPs registered to the browser from RP to RP.
Dmitri: So if i have Google and Twitter account will it showup everywhere or does RP need a relationship?
Sam: The latter, not changing that element. Website already has pre-existing relationship with IDP.
Sam: Not that we shouldn't but in order to unblock 3rd party cookies we don't have to change that relation ship. Could in future but to unblock 3rd party cookie deprecation need to plug into existing deployment.
Sam: To look at what is vs what ought to be.
Christian: RP passes URL of IDP to JS call. Website provides IDP URL.
Sam: More specifically, a list of IDPs (from an API perspective) then nascar flag built into the browser.
Sam: Built today assumes 1 elemetn with 1 IDP.
Dmitri: Any plans to allow user to provide list instead of the RP?
Sam: Have a desire to do that, seems like righ tthing to do. Workign with OpenID Connect folks. Our understanding the economic structures and design there is a by design prearrangement. If we can break that OpenID assumpiton we will but if we can't will have to figure something out.
Sam: Agree with goal and think this doesn't need to be built into the website.
Sam: Go back to email analogy. When sign up to website with email the website does not enumerate email providers it supports. Think that's the federation way forward, if that fits into OpenID or not is TBD.
Sam: But that isnt' needed to unblock 3rd party cookies. So, not paying attention right now as working on unblocking 3rd party cookies.
Christian: In todays world, all IDPs require RP pre-registers. If move into browser, going to be much bigger project
Sam: Precisely how we make assessent. Things backwards compat goes to top of list, backwards incompat with current deploymetn goes to bottom of list.
Sam: Backwards compat with billions of users, millions of websites, thousands of IDPs and 10s of UAs
Sam: Billions of users accept IDP has relationsship with RP. If millions of RPs have pre relationship with IDPs will keep that.
Tim: Would love bring own identifier, but don't believe byoi and federation are same construct. Federation implies relationship. Important conversation but differnt. Security model for OidConnect and Oauth the tokens are opaque and should not be introspected.
Are you going to update the security settings in those specs? Are you going to introspect hte tokens?
Sam: I don't know. Want to give mechanism if we want to do so. I don't know in the future, but in the present does not require introspection to unblock 3rd party cookies. What we need for 3rd party cookies does not require global identifiers to be passed around.
Sam; Personally believe we should make sure users are protected from tracking and passing global IDs is part of the job.
Sam: So, no for unblocking 3rd party cookies but longer term think we should.
Martin: Won't be able to do that without major OID change. Wouldn't make any claims to that effect. That takes additional information and not planning on carrying it.
Sam: Goign to cross that bridge when we get there.
David: Introspecting is useful at 1 level but tring to prevetn backend correclation can use uniquness of signature as signal. Don't want to push people to start talking about the user on the backend because limited the frontend as it doesn't really help.
Sam: Would love to chat more. Thanks all.
Achim: Wondering about auto-signin which has notion around RP knowing there is a login/signin so can use this information to do a pass through as it knows things have been approved previously. The spec talks about hte user has choosen a preferred identity provider
Achim: So the user says Im' using this api on both websites, now I'm coming back and on site b what would auto-sign in do? Would it auto-sign as soon as the IDP does pass through?
Sam: It's per-website. Does not go across websites.
Browser updates state machine if you'ved signd into a website. Different website, different state, different auto-signin setting.
Achim: So preference is per website?
Sam: Yes, to be precise, per first-party-set.
Achim: So maintaining auto-signin state per website and IDP has approvals in place the user comes back and is already signed in the API can trigger the signin.
Achim: For these IDPs to show should have been signed into another site.
Martin: Don't have to be logged in, browser needs to know you have an account.
Achim: Account info pulled from IDP.
Sam: Can be pushed
Achim: Information user has an account has previously been established.
Sam: When user logs into IDP can push to browser storage to say user has these accounts. When logging out of IDP account can be used
Sam: Haven't implmented but think it's possible.
Sam: Currently account list is requested but could be pushed. Has privacy benefits don't run into timing attacks. Pushing the envolope of what we should do.
Managing access lists on browser is more and more complicated. Need users name, profile and keeping up to date.
Starting with pull because it's eaiser and sufficiently private as not useful for building a tracker. Push is better for privacy.
and performance
Achim: So more private as you aren't polling the IDP so doesn't know RP
Sam: Designed account api as IDP doesn't know which site user is at. Credentialed pull as cookies are sent but it's a controlled request as browser doesn't revieal where request comes from.
Martin: The timing potentially reviels user is involved in an action. User interactions can expose
Sam; RP and IDP can collude to sync clocks to chat. Pull model is vulnerable to timing attack. We think it's sufficiently private.
Sam: Wondering, do you think timing attack is sufficiently private is weak?
Martin: Pretty weak, same time lots of things to be exploted. Maybe wrong question.Better question, what is it IDPs concretly need and what does the browser need to have. What things are you depending on, IDPs register as such. Assuming IDP has well known interface to pull this information
Martin: Depends on browser knowing user logged inwith IDPs otherwise dealing with endpoints at arbitrary times to determien user info. More sensible IDP registers its ability to deal with API. I'm an IDP and here are hte identities I'm able to provide and here is where you can get metadata.
Sam: Wanted to clarify, this schema, the IDP doesn't register/announce, the RP calls a JS api that has enumerated the IDPs that already comply.
Martin: Don't get email analogous operation. RP can't say I don't care who provides ID I'll take anything
Sam: Doesn't corner us, because we come up with email analogy will have to ask RPs to redeploy
Sam: Only works with IDps with certain capabilities.
Martin: Depending on someone logging onto IDP providing information I'd like to use X to loggin.
Sam: That's the email analogy, you enter you email address.
Martin: Looking for the useful side of this. Could be anyone from an RP perspetive. Instead of asking user to remember email address and type in.
Sam: Fair, making more strict analogy. Reasonable for htem to have well known ids inwallet.
Martin: Diffrence is the user attendees, or RP, knows the set of IDPs. Gives first stage of identity selection and lets narrow down to something mangeable.
Martin: I'm talking about when IDP registers itself browser knows about all identiies, which leads to larger nascar problem if showing all of them, but saves user from trying to enter email address to log into existing site.
One of problems seeing is people using different email addresses.
Sam: Having IDPs register is <missed>. Synchronizing databases isnt' easy which pushes us away from registering and having a cononical source of truth. That sync is hard.
Martin: Sync desktop and phone?
Sam: No IDP and UA is hard.
Martin: Could probalby do registration with fair degreee of confidence isn't going to change.
Sam: Identity is more stable then user counters, yes, you don't change your name more the X times, maybe properties are more stable and makes sync less comfortable.
Achim: I think registration and election is a different dimension. Need to re-think relation between UA, IDP and user. Also from a legal perspective. Does the IDP allowed to send that information?
Achim: Could basically integrate SSI assuming people have things setup. Don't think that would be an issue to deal with that. Different ways of how this could be specified could be provided to user. Possbly no IDP involved.
Sam: Like Martins idea about pseudo random functions.
Achim: Work in OpenID to integrate SSI in the cetner protocol.
Dmitri: In the sufficient Open id connect work main pain point is lack of acocun tpicker. If some way for FedCM to work with signup everyone would be happy.
Martin: a registration model is potentially a pain. How you discover way your sovereign stuff comes from. iF in browser pre-registered.
Achim: The caBLE security if on mobile and want on desktop. Whole different thing around security where identity lives on different device. Whole other thing to consider.