-
Moderator: Heather Flanagan
-
Scribe: Wendy Seltzer
- Administrivia
- Scribe volunteer(s)?
- Reminders:
- Recharter status
- Upcoming call schedule
- September 17 — Atlantic calls (if we have topics)
- September 23-27 — TPAC
- Lightweight FedCM
- FedID CG/WG Process Mechanics
- TPAC Agenda Planning
- Joint CG/WG: Monday, 23 September @ 16:30–18:00 — Draft Agenda
- Joint CG/WG: Tuesday, 24 September @ 11:00-12:30 — Draft Agenda
- WG only: Tuesday, 24 September @ 14:00-16:00 — Draft Agenda
- Breakout sessions: all day Wednesday (requests for breakouts open until 15 September)
- AOB
Heather: TPAC is coming. We have one more call pre-TPAC, that may be canceled.
Recharter status:
Heather: We have a Formal Objection against the charter revision to add Digital Credentials. Per Process, any member can register an FO. W3C Team has 45 days to review and then form a Council to determine if there’s a way to reach consensus or to overrule the objection. That timeline means that nothing will change for the FedID WG before TPAC. Simone Onofri is primary W3C Team member point of contact. Team report will document work to reach consensus.
Ben: Addressing the weirdness of the token field in Lightweight FedCM. What the “token” refers to. In Lightweight FedCM, less targeted, IDP provides some info alongside the credential. It’s nice because it adds some data, but it would have to be somewhat long-lived and RP-agnostic, so it would be URI
Erica: What do we expect RP to do with a credential it gets back? Provide a useful UI hint to the user, e.g., for storage access grant. Is there anything we expect to get done?
Ben: This is an alternative to a more general “communicate data out of band”. Question for IDPs: how stable are your endpoint URLs? I’d imagine very stable.
Heather: In federation context, academic, very stable, because changing requires updating a mass of metadata
Ben: Is there anything user-specific you’d need to know before engaging in identity flow?
Phil: I’ll think about this difference from the FedCM approach. If it’s not an authentication token like FedCM, not an audience… consent model may change. Lots of things change based on who the relying party is. What is the thing we send back, hint to UI, not anything to do with authentication token?
Ben: You’d get it in the UI after successfully finished the flow.
Phil: Endpoint is stable. Usually we hand around pseudonymous identifiers which wouldn’t be useful for UI
Ben: No immediate obvious use, so it seems fair to remove the token.
Erica: Any input from other folks from IDPs?
Johann: I like going minimal and adding things as needed.
Ben: I think there are reasonable alternatives for IDPs to use if they don’t have this. Pending any further input on issue 39, we’ll remove it.
Sam: Matches my intuition that we shouldn’t have a token. Two issues: what does RP get back from this flow? Maybe the IDP that the user selected? Maybe name, account picture? Second, the discussion about token makes me think navigator.credential.store is not the call we should make. If you want to close regarding the token, maybe we can spin off additional issues.
Ben: About to get to that issue next, issue 40. In Lightweight FedCM, Identity.credential is more like an account in FedCM. What do you get back from .get? In Lightweight FedCM, you get back a lightweight credential, which is different from FedCM. If they differ, should they be stored in the same object?
Sam: Conceptually speaking, the UI and affordances are the same, so it still feels correct. Regular FedCM uses Login Status API, changes appearance based on value there. Bit set doesn’t get shared with the RP. My intuition is that the account we’re storing in credentials.store is to be stored by Login Status API, used to construct UI prompt.
Ben: Assuming we do that, what do you get out of navigator.credentials.get?
Sam: in my mind, from a user comprehension perspective in account selection, agree to share that account with RP. Share the data registered with login status API. and 3d party cookies. Does that make sense?
Yi: Does it need to be navigator.credentials.get versus navigator.loggedin.get? We’re not getting credentials, but status.
Ben: That sounds like direct conflict with the constraints John (Apple) put into login status. Then this loses the benefits of integration with WebAuthn,
Yi: Calling .get should get something for account creation or registration.
Sam: The reason to reconcile with FedCM is so as not to duplicate other APIs, e.g., button mode, registration API. Useful for IDPs to be able to insert themselves into the same flows.
Johann: +1 to Sam. We have to work through the rough edges, but it’s important to keep the same shape. Better, consistent UX. Share the benefits of all the work going into FedCM UI, UX.
Erica: Agree. Let’s be clear on the compromise we’re making here. Note in the explainer, help implementers understand what needs to happen.
Ben: Explain to implementers, these are two different objects you could get back. I was envisioning something with .store, but if it makes compatibility sense between FedCM and Lightweight FedCM, I think Sam is onto something
Issue 40
Ben: In the TAG review, FedCM is better at getting UI freshness, so looking for how LWFCM can do it. Sam said there are 2 solutions he’s aware of. Web push but you have server infrastructure; or second, expire your UI hint, easy for IDP but users will see genericized UI rather than account information. “We heard from IDPs that their strict freshness requirements are on order of hours, not days”. I like the push model still, but I don’t have experience with the server infrastructure entailed.
Sam: I don’t want to discourage the push model. I like it too. Very large IDPs may have a different bar from smaller or research and education providers. It is worth having the option for IDP to make their own considerations, including legal requirements.
Ben: elf asked how push works. Spin up a service worker to listen for push events. Whenever you get an update, push to that endpoint, and sw will hear the event and re-store the credential.
Phil: A bit like managing identity provision in the browser. Rather than keeping RP up to date, updating the web browser.
Ben: Keeping the browser up to date with name and picture, not particularly that you have an active session.
Elf: Would notification still be shown to the user because it is required?
Ben: I think so. There may be a model of freshness that hybridizes the approaches. A different model, IDP chooser before account chooser. Could there be other ways to integrate with FedCM halfway, maintain freshness, and interop
Phil: So there's another 3d party service involved for web push? Are thousands of IDPs sending to web push service?
Ben: Each push goes through separately (rendezvous point); it is encrypted.
Sam: Push also has some permission prompts/notifications.
Ben: Worth looking at further
Elf: SW has to display the notification to the user. Different browsers have different limits. For example, if Safari is not displayed 3 times, the subscription is canceled.
Sam: Another suggestion from Yi is to open the login URL if it expires.
Ben: It depends on how many providers are on the list. If there are several, it could be less effective
Sam: Or show the account chooser with expired data, with a note that it’s expired, e.g., refresh button.
Ben: An interesting question for lawyers. Freshness requirements on large providers. Can anyone speak to those requirements?
Phil: I’ll look into it. I don't think we do.
Sam: Concrete legal requirement: Show the account chooser that if the user changes the metadata of the account, e.g., name change, then that should be reflected in the account chooser within a certain timeframe. If I had to guess, that requirement would also show up in academia.
Heather: Chair hat off, the legal requirements for when the display name needs to change across all services have never come up in the federated authentication context. If there’s a legal requirement, I’m unaware of it.
Sam: Maybe it wouldn't come up because of the pull rather than push model.
Heather: If a requirement existed, it would be on the IAM side.
Erica: A hybrid approach starting with an IDP selector might address this. Does this need to be “all singing, all dancing”? Does every IDP need to see this for it to be at all useful? Or is it useful to some, Can those who need more freshness use Full FedCM?
Sam: Not mutually exclusive, I agree.
Ben: It might be worth exploring a hybrid approach. Less bulk, but don’t have the first indicator…
Yi: +1 to support the light version for those who don’t have specific freshness requirements. Also, privacy concern re: notification, sends ack that shows the online status in the push model.
Phil: Also consider whether it was simpler to display information. E.g., organization.
Erica: Same thing from a different perspective.
Ben: Depending on lifetime.
Heather:
Heather: We encountered some challenges using this process, trying to move issues between GitHub “organizations”. If you haven’t yet reviewed this process linked above, please do and help us identify likely challenges. We’ll also put it on the TPAC agenda.
- TPAC Agenda Planning
Heather: TPAC is coming. CG and WG have joint meetings on Monday and Tuesday, Draft is at TPAC 2024 - FedID CG/WG Agenda Please take a look, add. Things aren’t yet ordered. We will also have lots of newcomers to the work, and will likely want to have demos and introductions to what has changed. We will also dive into issues. Use TPAC2024 tag in the repos
Sam: On the process, we ran an experiment with IDP registration API and it feels plausible. Moved related issues into the repo, as a container for the proposal. Can we start moving other things to this model? https://github.com/w3c-fedid/idp-registration Do we have to wait for TPAC?
Heather: Being conscious that the different orgs (WG or CG) have different participation sets. We need to see how that plays out.
Sam: Most of the things are not in spec form yet, not expecting PRs, but anyone can contribute to issues.
Simone: IPR bot uses w3c.json.
Sam: That works fine
Simone: The person has W3C account linked to GitHub account joins the group so the IPR bot can manage automatically. If not, the IPR bot sends an e-mail to them to sign the IPR commitment.
Sam: let’s follow-up offline
- Heather Flanagan (Spherical Cow Consulting)
- Ted Thibodeau (he/him) (OpenLink Software)
- Ben VanderSloot (Mozilla)
- elf Pavlik (independent, Solid CG)
- Nicolás Peña Moreno (Google Chrome)
- Chris Fredrickson (Google Chrome)
- Phil Smart (Shibboleth/Jisc)
- Wendy Seltzer (Tucows)
- Erica Kovac (Google Chrome)
- Brian Daugherty (Google Identity)
- Steffi Dobretzberger (DAASI International)
- Bjorn Helm (Yubico)
- Yi Gu (Google Chrome)
- Johann Hoffman (Google Chrome)
- Achim Schlosser (Bertelsmann, Co-Chair)
- Brian Campbell (Ping)
- Iris Ren (Huawei)
- Simone Onofri (W3C)