Skip to content

Latest commit

 

History

History
681 lines (410 loc) · 19.1 KB

2024-01-30-notes.md

File metadata and controls

681 lines (410 loc) · 19.1 KB
Raw

FedID CG call notes (Atlantic), 30 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

  • Heather

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

  • Yi:

    • Currently designing the Button Flow API

    • FedCM Button Flow Chrome mocks

    • Break down the flow into several CUJs

    • First one — signing in with single active account

    • First mock shows RP page with multiple buttons

    • Browser will open a modal and when it is present the user cannot interact with underlying browser area

    • Similar to Passkeys UI — opens a modal Account Chooser

    • In the Widget Flow for FFedCM we have something similar; however, in that case, it is non-modal

    • But in the Button flow, it is triggered by a User Gesture

    • Want them to sign into RP with IDP

    • We believe at this phase, at the top of the mock there is a dinosaur logo, which represents the IDP icon to indicate that it is the IDP

    • After account selection, user will be presented with a permission dialog

    • Same strings as Widget Flow but focusing more on the RP (and the icon changes to the RP’s logo)

    • Here the user can go back to the previous state or the user can continue in which case FedCM fetches the token from the IDP and forwards it to the RP

  • Wanpeng

    • If the users haven’t signed into the IDP?

  • Yi

    • Stay tuned — coming up below

    • CUJ 2 - Showing multiple accounts instead of one

    • Similar to Widget flow

    • Selection of account and then similar to previous

    • CUJ 3 — not signed into IDP

    • When you click a button on the first mock

    • Affordance same as Login STatus API where it opens pop-up window to actually sign into the IDP

    • Opens a pop-up window provided by IDP where user can sign into the IDP

  • Wanpeng

    • What happens with multi-IDP (e.g., 3 IDPs)

  • YI

    • Multi-IDP is somewhat special, but in this case the user chooses a specific IDP by clicking on that IDP’s button

    • Eventually we’d like to get rid of the NASCAR screen on RPs and just replace it with one “Continue with Federation” which could bring up FedCM’s IDP chooser UX for users to continue from there

    • We’re imagining a UX affordance for users to go from that chooser to the usual login flow

  • Wanpeng

    • For Multiple IDP providers, but users haven’t logged into any of them, how will this UI be shown?

  • Yi

    • From user’s first click on RP to trigger FedCM, FedCM would bring up pop-up window Browser UX to allow user to choose the IDP to choose from and then it would proceed from there

    • This presentation will focus on single IDP

    • So, if there is no login session, then no user is signed in and then the user signs in and then the user can see user accounts and sign in

    • CUJ 4 – choose different account

    • So, if you’ve already signed into two accounts with the IDP but you have others and you want to use a different account

    • When user wants to use a different account, they can click “Use different account” button and that also pops up the IDP sign-in window to allow the user to sign in

    • When the user has finished that flow, it automatically shows only the newly signed-in account in the account chooser and doesn’t show the previous two accounts

    • But the user always has the option to press the Back button if they change their mind and actually want to choose one of the existing two accounts

  • Achim

    • So if the user pressed on Back, it would then show 3 accounts?

  • Yi

    • Yes — it will show 3 accounts

    • This also handles IDPs that only allow one account to be “active” at a time, even if the user has previously signed into the IDP with multiple accounts

    • CUJ 5 — user triggering button flow during widget flow

    • User is in Widget flow, but that’s over the existing Button / NASCAR chooser dialog

    • In that case, when the user presses one of the buttons, FedCM will auto-dismiss the Widget, since the user’s intention is to actually continue with the Button Flow and not the Widget Flow

    • CUJ * — handling slow networks / slow IDPs

    • The user might have a slow network, be at train station, etc., or IDP might be overloaded / slow

    • So, if the user clicks continue with IDP, browser is unable to show any accounts and needs to fetch accounts list from IDP

    • If network is slow, fetch could take several seconds / 5 seconds

    • Not showing any UX during that 5 seconds is not acceptable — browser should react immediately after user clicks on the button

    • Current thinking is to show the modal with some animation to indicate that accounts are being fetched / loading

    • When accounts arrive, it will fill out the dialog with those accounts and IDP icons, as necessary

  • Achim

    • Seems like a good idea, as UX principles established to provide user feedback

    • Another approach is in Multi-IDP case as IDPs could be replying at different speeds, so if you fill info in as it arrives that could be clunky; having some sort of placeholders would be better

  • Yi

    • Yes — in Multi-IDP case, we don’t want the UX to be too “jumpy”, inserting information into the IDP as it arrives in a disruptive way

  • Matthew

    • High latency / low bandwidth question — what if someone is on 64Kb satellite connection?

  • Yi

    • We’ll show UI in the middle ("loading…") and if it takes a long time, the user can cancel the request and opt, for example, to choose a different IDP

    • So, the modal is, in general, cancellable

  • Sam

    • In many ways, these UIs can change over time

    • Don’t need to have a fixed formulation. Expect to be doing a lot of A/B tests over the next few years

    • These proposals are a starting point, and Firefox and other browsers will likely have different formulations

    • So still fluid

    • And we are also comparing this to status quo (pop-up windows / top-level navigations)

    • Opening pop-up windows are typically blank to begin with

    • So, not necessarily final UX at all

    • Because they operate at different layers, they have advantages that cannot be accomplished with status quo

  • Achim

    • Deep dive results: When you iterate on UIs need to make sure that not all elements change

    • Need to be careful about which icons are presented at which points and maintain those things

    • Need to maintain core elements

    • All UX elements that are in existing flows are there for good reasons, and can’t necessarily be arbitrarily changed

  • Sam

    • Good points — icons, fonts / prominence are definitely required

    • So we’d be happy to work with everyone to ensure that FedCM UX complies with IDP expectations

  • Achim

    • Sounds good — want to make sure these guarantees can be maintained when IDPs are no longer fully in control of their UX

  • Yi

    • Also when there are new design proposals, we’ll always present in this group to get feedback

    • That’s it for the Button Flow issue

  • Heather

  • Nicolas

    • Some discussion in last call on Multi-IDPs

    • Just wanted to look back on those discussions / points

    • Question about how to ensure RP knows which IDP(s) a token belongs to (in Multi-IDP case where RP makes single JS call with an array of desired IDPs)

    • Proposal was that RPs could just inspect the returned id-token

    • But that seems to make a lot of assumptions on the format of the id-token and assumes that all IDPs have the IDP somehow included in the id-token

    • So, maybe including the IDP identifier separately in the returned values would better

  • Achim

    • Yes — agreed that this is a complication

    • Don’t want to get into situation where RP would try to finalize the login procedure with any of the IDPs

    • With OIDC and SAML you get more info than just the supplier so if you want to generalize this you need to not assume that IDPs are coordinating

  • Nicolas

    • So you agree?

  • Achim

    • Yes — in order to assume the API is totally generic, you need to include that other iDP identifier information

    • No privacy concerns with that

    • To finalize the procedure, the IDP needs to know the RP anyway, so that’s fine

    • At worse it’s redundant information

  • Nicolas

    • Yes — but in some cases it could be useful to provide a generic / consistent way for RPs to be able to identify the IDP

    • I.e., have an explicit way for RPs to identify the IDP

    • 2nd point — feedback from Achim on tests with Multi-IDP

    • Has anyone else had the opportunity to experiment with the Multi-IDP flag turned on in Chrome (Canary builds)?

    • If anyone wants to try it, please do so and ping Nicolas on the Slack or put feedback on the GitHub issue

      • Allow multiple IDPs to be used — issue 319

    • Also have plans to implement Button Mode with Multi-IDP but want to let the Button Mode UX to settle a bit before combining those

    • So — next is to fix bugs reported so far (e.g., there being no delay when token is rejected — Privacy issue)

      • And also improved UX in general

      • And then Button Mode Support

  • Achim

    • Hold off with the UI stuff

    • Happy path seems to work fine so far

    • Didn’t get to nitty gritty for example ordering changes or what happens if you use the mediation flags or auto-selection behavior

    • WIll be doing those experiments next

  • Nicolas

    • Implemented so far is similar to single-IDP in which we try to prioritize Returning Accounts at the top of the accounts list

    • If there are multiple returning accounts from multiple IDPs we’ll present those returning accounts in the order provided in the array from the RP

    • For auto-Sign-In, that will only work if there’s just one returning account from just one IDP

    • Iff there are multiple returning accounts (e.g., even if one per IDP from multiple IDPs) then Auto Re-Authentication will not trigger

  • Heather

    • What is next?

  • Sam

    • Have we gone over same-site Login Status API?>

  • Christian

    • We did discuss this last week

  • Achim

    • BenVS said it generally seems fine, but would need deeper investigation to specific scenarios

  • Sam

    • On revisiting user interactions issue

    • Not much progress there

  • Achim

    • Phil brought up good point but if you use IDP registration path assume relationship between RP and IDP

    • If you think about IDP registration path, you can’t actually know the client-id to engage in the future

    • SOLID folks wouldn’t care because there *IS* no pre-existing relationship between the IDP and the RP

    • It’s a self-sovereign thing and so the user is just asserting their own identity (self-signed)

    • Different for some IDPs that are part of (same group of IDPs) and it’s the same client-id across all of those IDPs

  • Sam

    • Yes — just trying to get an initial / basic prototype for people to play with and then let folks try it and see where mismatches crop up

    • One CL away from that MVP at the moment

  • Achim

    • Hardest part is first gate of Legal Reviews — always tricky for new APIs

  • Sam

    • Any ETA to share?

  • Achim

    • From our perspective — the things Nicolas brought up in terms of button mode are important

    • For completeness for our flows, need to ensure case where users are not logged into any IDP still work

    • Apart from that nitty gritty things of which flag influences which UX items

    • Authorizing access through Pop-Up window (AuthZ support) is also important as well

    • Even if the user is not fully logged in, but provides Authorization for access to specific scopes for a given RP

    • Means of replacing standard UI with something that can provide more (in terms of Authorizing additional scopes by the user)

    • Even if that is a louder UI than basic FedCM

  • Sam

    • Hardest part of the work is to find the sequencing strategy

    • Too easy to paralyzed by analysis — if you wait until everything is (theoretically) perfect it will take forever

    • So, initial implementation will definitely have some flaws / deficiencies, but only way to make forward progress is to try it out

  • Achim

    • Totally fine with that approach but those things are big items

  • Sam

    • Understand and we’d like next steps for the little things of current MVP

    • So — is the basic system as-is good enough for minimally viable?

  • Achim

    • Yes — current system is minimally viable

  • SAm

    • So — what would be good next steps?

  • Achim

    • We can follow up on that, no prob

  • Nicolas

    • BenVS isn’t here, but will still ask

    • Ben was reviewing Error API PR (498) w3c-fedid/FedCM#498 (review)

    • Noticed that we’re using code that overwrites attribute for DomException

    • Could cause confusion / backwards incompatibility

    • Different code from code in DomException

    • Want to rename that attribute but no great name so far

    • Any opinions from the group with good potential attribute names?

    • It’s for some error code that the IDP is including in error response

    • Might be used by browser for generic error response, but could also be used by IDP (for error processing)

    • Would like to avoid waiting for too long / rename sooner rather than later

    • If you have any opinions you can add comments to the PR linked to the Issue

    • “Error Code” / “Server Error” / ‘Credential Error” are all potential ideas

  • Heather

    • RPs will probably have to do something

    • Is this specific to IDP errors?

  • Nicolas

    • This is for the ID Assertion fetch

    • So this specifically would be an IDP error

    • Not sure if RP also wants to surface an error, but this is from the IDP

  • Achim

    • Fine to call it

  • Heather

    • “IDP Error Code” seems to be the (emerging) consens…

  • Matthew

    • Isn’t “Error Code” redundant? Short & Sweet / Direct is maybe better

  • Nicolas

    • Yes — a bit redundant

    • “IDP Error” seems reasonable

    • Any objections?

  • Sam

    • What was the problem of just calling it “Error”?

    • Would be somewhat equivalent to what OAuth uses

    • Uses “Error” and adds and object with the error details

    • Would be good, not just because it is shorter, but because of precedence in OAuth

    • Because the contents / enumeration are based on the OAuth enumeration (it should match OAuth)

  • Nicolas

    • Anything could go there

  • Sam

    • In the spec there is an enumeration of errors

  • Achim

    • Yes but you can extend with custom errors

  • Sam

    • Would be still useful to use same language as OAuth

  • Achim

    • No objection (to match OAuth)

  • Nicolas

    • Just want to make sure it doesn’t re-introduce ambiguity

    • But in this case it is probably clear enough

  • Heather

    • Reached out to Phil on Multi0-IDPs

    • He will iterate on testing that

Attendees (sign yourself in)

  • Wanpeng Li (University of Aberdeen)

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

  • Michael Knowles (Google Chrome)

  • Tim Cappalli (Okta, co-chair)

  • Ted Thibodeau (OpenLink Software)

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

  • Wendy Seltzer (Tucows)

  • Brian Daugherty (Google Identity)

  • Zachary Tan (Google Chrome)

  • Christian Biesinger (Google Chrome)

  • Heather Flanagan (Spherical Cow Consulting, chair)

  • Oliver Rickard (Atypon/Wiley)

  • Matthew Economou (ResearchData)

  • Shannon Roddy

  • Philippe Le Hégaret (W3C)

  • Sam Goto (Google Chrome)