Skip to content

Latest commit

 

History

History
649 lines (385 loc) · 17.4 KB

2024-01-09-notes.md

File metadata and controls

649 lines (385 loc) · 17.4 KB
Raw

FedID CG call note (Atlantic), 9 January 2024

  • 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

  • Note: Update to Code of Conduct (linked above)

  • New members joined over the past

    • Oliver (PM at Atypon - Access Control)

    • Theo (Liquid - Social Link data)

      • Interested in how FedCM can improve SOLID

      • Discussed with Sam Goto on GitHub #240

    • Shannon Roddy (Higher-Ed space since 2007)

      • Currently at UC Berkeley - general interest

    • Jan (Liquid)

      • Working with Theo / same general interests

  • Call format

    • Currently 3 weeks Atlantic / 1 week Pacific

    • Proposal is to have Atlantic calls every week and *add* a Pacific call once a month if / as needed

    • Encourage people in Pacific / Asia times to participate in Pacific calls

  • Standardization / WG

    • CGs incubate ideas / determine what is most useful to deploy to web

    • Need to create WG to actually standardize specs

    • Have been working with W3C to create WG since ~Sep last year

    • Working with Phillipe? on this – taking a bit longer than usual due to W3C backlogs

    • Draft Charter exists – (Heather will post link)

  • FedCM Issues

    • (Multi-IDP Updates and Button-Mode Updates today)

    • Use cases for Cross-Site Cookie Access through Storage Access API after FedCM grant? - issue 467

      • (nothing immediate to report back on here, this week)

    • Multi-IDP

      • Allow multiple IDPs to be used - issue 319

      • People in the past noting that Multi-IDP doesn’t work at all in current FedCM/Chrome implementation

      • Array version of Multi-IDP now working in Chrome Canary builds

      • <demo by Nicolas>

      • multi idp demo: https://multi-idp-demo.glitch.me/

      • mark login idp1 https://webid-fcm-idp.glitch.me/mark-login.html

      • choose accounts shown by idp1 https://webid-fcm-idp.glitch.me/login.html

      • mark login idp2 https://webid-fcm-other-idp.glitch.me/mark-login.html

      • choose accounts idp2 https://webid-fcm-other-idp.glitch.me/login.html

      • Enable FedCMMultiIDP Chrome flag

      • Reload browser

      • Demo in webid-fedcm-idp.glitch.me

      • Two accounts from 1st IDP and one account from 2nd IDP

      • All are shown

      • Choose any of them

      • If account has never been used before, it will present usual FedCM confirmation flow

      • Or if account has been used before, will attempt auto-reauthn flow

      • Also mismatch UI - where there is a mismatch between the IDP’s state of that account being logged into the site vs. the Browser’s understanding of that state

      • Prompts the user to sign into the IDP

      • (demoed the IDP user sign-in flow)

      • Also: Can have scenario where none of the IDPs have any accounts for that RP

      • In that case, it just shows the Sign Into IDPs buttons for each IDP and user can choose the IDP and then the user can sign into that account and it will show the accounts for that IDP

    • Question: How does IDP discovery work?

    • Nicolas:

      • Have to do that before calling FedCM

      • Will not work super-well if you have hundreds of IDPs

      • Have to send fetches for every IDP

      • For that scenario we have an IDP registration API (Sam working on this)

    • Comment from Chat (Matthew Economu)

      • Have 5509 IDPs to choose from

    • Nicolas:

      • IDP Registration is a possible solution to that

      • But will probably need some sort of filtering to handle that scenario

    • Phil

      • Fixes previous problem where IDPs that the user has not previously signed into would not show up

      • When it says “sign into IDP” it’s not getting fetches to all those IDPs?

    • Nicolas

      • It is, but this is for the mismatched IDP case

      • Room for improvement of that UI - still thinking about it

      • Generally unrelated to Multi-IDP, but still important and want to improve it

      • If IDP status is Logged Out, wer don’t need to do those fetches

      • But we still can’t support 3000+ IDPs

      • Esp. first time, where status of all of IDPs weill be “unknown” and so it will do initial fetches on all of those

      • So a registration API would be better in that case

    • Phil

      • Previously it was either: let’s pop-up some windows OR show some accounts

      • New UI seems to be more nuanced and mixes both of those in one UI

    • Nicolas

      • Yes - because different IDPs might have different signed-in states

      • So previously we would have either just accounts or mismatched

      • But we could have both with multi IDPs

      • Have accounts list + “use another account from <IDP1>” + “use another account from <IDP2>” …

      • Or “use another account *besides* the accounts that are currently being show”

      • In general - try it out and report bugs and Nicolas will fix them

    • A not-yet logged in IDP has no route to success with this flow - issue 442

      • For button flow - making lots of progress

      • Trying to get best UX for this button flow

      • Unlike Widget Flow - in FF it’s on right side

      • BUtton flow is more critical for user journey

      • Trigger the flow from user clicking on a login to IDP button

      • Probably should be “loud” / possibly modal

      • Currently trying to implement the that UX in M122 and users can try it out

      • Will document in GitHub

      • We have some button mode today

      • Chrome Flags ButtonMode flag and AddAccount flag

      • Enables adding a new account in the Button Mode flow

      • Will have a more stabilized version soon (in Chrome Canary) for people to try out

      • Lots of design question – how should Button Flow work with Auto-Reauthn??

      • How should it work wrt Modality???

      • Plan to use Pop-Up window currently being used with Login Status API

      • Also, for feature detection - developers need to know if the browser supports this button flow or not

      • To be discussed to see what is best / most ergonomic for developers

    • Nicolas

      • If we have questions on whether IDPs would use this

    • Yi

      • For Button flow if you click “Continue with IDP” button what would you expect?

      • Some IDPs do top-level navigation

      • Button Flow si slightly different - no top-level navigation 0- browser mediated IDP sign-in flow

      • Don’t rely on Link Decoration or 3P cookies

      • How to best provide sign-in flow with a Browser mediated flow

      • Ben has been looking into this recently / comments in GitHub

    • Ben

      • Nothing particularly new at this time on this topic

    • Heather

      • Possible to show demo in the call?

    • Yi

      • Thought I showed demo in the past

      • Next week we should have more functionality

      • Chrome Canary behind flag – currently the widget will show up on Top Right Corner

      • But that’s not what we intend for the future – want something more int he middle and “louder”

      • We’ll definitely add it to agenda once that UI is better-refined

    • Phil

      • Browser Mediated Flow question:

      • Trust that the IDP has is on the origin that is sent by FFedCM because typically the trust would have been on the return endpoint for IDP connect

      • What if there was something malicious that sat alongside? The origin

      • And the IDP has to respond to FedCM

    • Yi

      • Same as current widget flow which is browser-mediate

      • Browser will send Sec-... header that only browser can send

    • Phil

      • Client could say any client

      • Origin isn’t something that can be manipulated.

      • Concern over trustworthiness of flow if it isn’t possibly same-origin

      • Compromised RP (rp.com is malicious)

      • Pretends it is the client-id of trusted RP

      • Token endpoint will only get client-id

    • Sam

      • It gets a client-id which is specified by RP

      • But also get origin of RP which is not controlled by RP

      • Controlled by Browser

      • So RP can’t self-declare / impersonate an origin

    • Phil

      • Thinking of scenario where there was a compromised RP that sat beside a legit RP on the same origin

      • Wouldn’t be very easy to do that

      • Just thinking about completely browser-mediated vs. redirect

    • Sam

      • Component that is changed is that redirect UI is not necessary with browser-mediate

    • Phil

      • Redirect flow is a big part of trust model in OIDC

      • The origin that is receiving has to do the matching of client-id and RP origin

    • Sam

      • Occurred to us too, but seems like a good change

      • Seems like it will also be better in terms of potential attack vectors related to the redirect flow

    • Phil

      • In the case of SAML case it has metadata that matches the client-id

      • In this case if you faked a different client the concern is whether it can be spoofed in some way

    • Sam

      • Yes - please dig as deeply as possible to try to see if there are still gaps

  • Revisiting the Interaction Model between the Relying Party, End User and IDP - issue 240

    • Sam

      • Update: Actively interested in

      • Changes a lot of properties

      • Increases of diversity of IDPs in the overall system

      • Less a question of Why and more of How

      • Permission / User Comprehension models are the difficulty

      • Prototype now working in Chrome Canary that doesn’t yet have a Permission Model

      • Most obvious permission model is to prompt the user for registration

      • Similar to how websites can register themselves as handlers for different protocols (eg., mailto://…)

      • And then browser would ask websites if they would like to handle those

      • So, for example registering as Identity Handlers

      • Websites could take any previously registered Identity Handlers

      • Current formu;lation

      • But we don’t think that is sufficient

      • Still working on it

      • Current status is probably at a stage a couple of steps before where Multi-IDP is currently

      • And this depends on the Multi-IDP API and so can only exist once Multi-IDP is available

      • Finding a viable audience / which developers are willing to experiment with this / put it into production is critical and we’re searching for.

      • Working with SOLID community at the moment

    • Heather

      • We have two SOLID people on the call!

    • Sam?

      • Who

    • Heather

      • Theo and Jan

    • Theo

      • thhck@ on GitHub

      • Have tried latest Canary

      • Going in the right direction

      • Hopefully in 2024 we have more time

      • Were looking at how people will use it and wanting to ensure that it is a feature that most people will use

    • Sam

      • As a rule of thumb, Browser engineers are worried about working on something that never gets used

      • So at every step of this process, we are always re-assessing demand

      • So early APIs have a lower bar

      • But it has to have enough initial usage / interest to invest more into further development

      • SOLID seems like it could be helped by this work (not millions of users, but still seems to be substantial)

      • Also presumably FF is interested in exploring this further too

      • The way we assess demand is we build prototypes and then look for usage / experimentation of those prototypes (and feedback from that experimentation)

    • Theo

      • Another question

      • Google is a company that has strong auth presence

      • By doing IDP feature - allowing smaller IDP to use FedCM

      • Not necessarily interest of Google to keep its advantage

      • Question about whether Google developing feature that has no direct

    • Sam

      • Can’t speak for all of Google - obviously complex

      • Google isn’t always thinking about just Google

      • The more people using the Web in general, better it is for Google in general

      • So, not a conflict in that way, Chrome would like to improve whatever makes the Web better.

      • We (Google Chrome) would like to seem more IDPs in the world

    • Zacharias:

      • Confirming Sam – API for registration - that is something that our community (Seamless Access) could use to register IDPs for use with FedCM

    • Sam:

      • Yes, in general

      • Not sure that is compatible with Seamless Access right now, but that is the

      • So, please build prototypes and send us feedback on any issues

      • Realize there are already some prototypes, but keep going and sending us issues

      • Best way to make sure we are solving a problem that exists

      • If Seamless Access and SOLID communities continue to send feedback, it provides

    • Ben:

      • Giving the direction of an Auth specific API that doesn’t rely on 3P cookies is definitely of interest to FireFox and providing the right solution for that is something FF wants.

  • Heather:

    • Will discuss with chairs on whether we want separate Pacific calls and/or Atlantic calls

Demos

Attendees (sign yourself in)

  • Zacharias Törnblom (Sunet / SeamlessAccess)

  • Phil Smart (Shibboleth)

  • Zachary Tan (Google Chrome)

  • Michael Knowles (Google Chrome)

  • Christian Biesinger (Google Chrome)

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

  • Sam Goto (Google Chrome)

  • Alan Buxey (MyUNiDAYS Ltd.)

  • Ben VanderSloot (Mozilla)

  • Wendy Seltzer (Tucows)

  • Brian Daugherty (Google Identity)

  • Oliver Rickard (Atypon)

  • Gary Windham (Cirrus Identity)

  • Jan Schill (Liquid)

  • Heather Flanagan (Spherical Cow Consulting, chair)