-
Moderator: Heather Flanagan
-
Scribe: elf Pavlik
- Administrivia
- Scribe volunteer(s)?
- Reminders:
- Recharter Formal Objection status
- FedCM PR Review
- Status of FPWD-identified Issues
- AOB
- Stages are unaligned with TC39 and WHATWG conceptually - Admin Issue 11
- Recharter FO status
- Council is discussing it, hopefully more to report soon
- Open PRs
- Specify "Use another account" - PR 678
- Christian: spec change to show another account available at the idp, minor editorial change requested by Ted
- Ben: About adding more IdP in the browser UI, concerned that we’re having the API do more than it should
- Christian: Even with lightweight, wouldn't you want the ability to log in to another account?
- Ben: I would need to look more closely, user could reject it if they don’t want to use the current account
- Christian: In principle, even LW FedCM could use it
- Ben: Why it couldn’t be optional
- Christian: Some IdPs don’t allow concurrent user accounts. The principle of passive mod is more unobtrusive.
- Ben: I have to think about this one.
- Ted: I looked at the comment. Common use of "in parallel" means doing the listed things at the same time. WHATWG wants to use it to execute the listed sequence in parallel with other things. The other small thing is two uses of "The user agent may use options context", where one left out "options".
- Christian: I will fix the second one
- Nicolas: I agree that in parallel is not the best naming. I think about it as executing all the DOM updates and things like that at the same time. So not in the main thread.
- Ted: That might be understandable in this conversation, but not by the spec reader.
- Christian: …
- Ted: Please add comments to the WHATWG thread linked from PR678. This way it may raise the priority in WHATWG.
- Christian: I’ll take your comments and go from there.
- Heather: I’m hearing high level concerns, what are the next steps? Do we wait or do we move forward and note the need to change the wording?
- Christian: We can take time to think about it first.
- Heather: We will come back to this one
- Specify account labels - PR 669
- Christian: It lets the IdP give an internal label to each account, which could be filtered on the browser side to show only some accounts. We use it in FedCM to show only accounts taking into account privacy … This could be relevant for LW FedCM. Our partner needed this feature not to show certain accounts in a certain context.
- Zacharias: Would this be account types? Like different credentials in wallets that could be called for by the service provider?
- Christian: I think so but I might be missing a certain context
- Ben: I thought we were talking about multiple config URLs
- Christian: multiple config URLs is needed for this
- Ben: That sounds like a third mechanism to do a similar thing.
- Christian: It is not identical, it is specified by the config file and internal to IdP, not exposed to the RP
- Ben: When we discussed ??? I recall you were suggesting not to add similar futures any more.
- Nicolas: I'm not sure if labels can be used for this. (in response to Zacharias)
- Nicolas: This is FedCM not Digital Credentials, not sure if this is intended use case. I’m not sure what account types even mean.
- Heather: This can take us off track, let’s pick it up later. You can also chat about it on Slack first.
- Phil: This is done in the accounts endpoint. IdP might respond with labels, without knowing who the RP is.
- Christian: yes, …
- Specify multiple configURLs - PR 667
- Christian: LW FedCM doesn’t use config URLs so it doesn’t apply there. We only allow a single config url. The only thing that needs to be one url is the accounts endpoint, this PR proposes only limiting accounts endpoint and login url to one. This lets you offer different branding with different urls, also different session endpoints — this was a primary use case for our partner. The way this works with accounts labels. Different config urls can specify different account labels, but it can be used independently.
- elf: is there a use case for this?
- Christian: Not all IDPs will need this. One partner has an endpoint for authN and another for authZ; if you’re in such a situation that your backend has two different endpoints, then this would be useful.
- Nicolas: Multiple configs could be also useful for testing, e.g., geographic region separation; we had this proposal already. This could introduce a privacy leak, because of this, this is a compromise. If we fix the credentials endpoint to be the same, we can enable multiple configs without introducing the privacy issues.
- Yi: Another example, some IdPs have parent and child accounts, or enterprise and consumer accounts. In this case, IdP should be able to filter those accounts. In this case, IdP could have two configure URLs — one for consumers and one for enterprises. This would allow achieving it without letting anyone know the IdP which RP is visiting.
- Heather: Are there any concerns with merging it? Not hearing any!
- Christian: How do we proceed with it?
- Heather: There was some good discussion, it seems enough for 667 but not the other two issues.
- Status of FPWD-identified Issues
- Heather: I was updating the wiki to keep track of the progress. Nicolas is there anything that needs to be updated there?
- Nicolas: Let me get back to you, the list is pretty long. We all agree this is important, also our team has its own set of priorities. We are happy to help with any of those issues, I’m happy to guide anyone who would like to take a stab at one of those issues.
- Heather: Nicolas and team have action items to check if anything needs to change stage. For everyone you have action to go over those issues and consider if you would like to submit a PR.
- AOB
- Ben: Something that came up in an internal Mozilla standards meeting. Trying to make sense of what makes Stage 3 since the wording is a bit ambiguous. Three people working on the engines … knew what it meant. It seems different from what we have as Stage 3. We try to align the stages; they should mean the same across contexts.
- Heather: I think this is a good idea. We want to avoid the requirement of inside knowledge for those who want to come and contribute. I’m supporting proposing a change to our text.
- Nicolas: Is it basically Stage 3 becomes Stage 2?
- Heather: Stage 3 needs to be more tightly specified about requirements for existing implementations.
- Ben: Stage 3 is more like a CR while Stage 4 is more REC.
- Nicolas: We should wait for Sam to review before me merge changes to stages.
- Yi: Stage 3 is like a CR, in that case how much is the WG blocked by lack of implementations?
- Heather: Lack of implementations is a blocker in W3C process. If there is only one browser implemented, it is a problem regardless of whether or not we clean up the spec text.
- Heather: I take an action item to work on the revised text.
Next hour Credentials Community Group () is meeting and I will provide feedback from FedCM group.
- Yi: Last week we spoke about fields API
- Heather: I will get it back on the agenda as soon as we are ready to talk about it.
- Heather Flanagan (Spherical Cow Consulting)
- Benjamin VanderSloot (Mozilla)
- Zacharias Törnblom (SUNET)
- Erica Kovac (Google Chrome Privacy Sandbox)
- Christian Biesinger (Google Chrome)
- Nicolás Peña Moreno (Google Chrome)
- Phil Smart (Shibboleth/Jisc)
- Aaron Parecki (Okta)
- elf Pavlik (independent, Solid CG)
- Chris Fredrickson (Google Chrome)
- Ted Thibodeau (he/him) (OpenLink Software)
- Yi Gu (Google Chrome)
- Alan Buxey (MyUNiDAYS Ltd)
- Iris Yuping Ren(HUAWEI)