FedCM Auto Re-authentication API

[yi-gu]

Wotcher TAG!

I'm requesting a TAG review of FedCM Auto Re-authentication API .

An extension to the existing FedCM API that provides a streamlined UX when users return to websites. The API requires that the user has already granted permission for the RelyingParty (RP) and Identity Provider (IdP) communication in the browser through a previous FedCM call.

• Explainer¹ (minimally containing user needs and example code): [url]
• Security and Privacy self-review²: [url]
• GitHub repo (if you prefer feedback filed there): [url]
• Primary contacts (and their relationship to the specification):
  • [Yi Gu] (@yi-gu), Google
  • [Sam Goto] (@samuelgoto), Google, spec editor
• Organization/project driving the design: [Google Chrome / FedCM]
• External status/issue trackers for this feature (publicly visible, e.g. Chrome Status):
  • Chrome Status

Further details:

• [x] I have reviewed the TAG's Web Platform Design Principles
• The group where the incubation/design work on this is being done (or is intended to be done in the future): FedID CG
• The group where standardization of this work is intended to be done ("unknown" if not known): unknown
• Existing major pieces of multi-stakeholder review or discussion of this design: N/A
• Major unresolved issues with or opposition to this design: N/A
• This work is being funded by: Google Chrome

You should also know that the initial FedCM TAG review is https://github.com/w3ctag/design-reviews/issues/718. We're requesting a review specifically on the addition: auto re-authentication.

We'd prefer the TAG provide feedback as (please delete all but the desired option): 💬 leave review feedback as a comment in this issue and @-notify @yi-gu

[hadleybeeman]

Hi @yi-gu. Thanks for opening this review. If you'd like our feedback, could you please draft us a quick explainer to cover how you'd like this to work and why you've chosen that approach above the other approaches you've considered?

If it helps, our explainer template and explainer explainer are posted.

We look forward to hearing more from you.

[samuelgoto]

Hey @hadleybeeman thanks for reviewing this! I replied to @torgo over email, but figured it would be useful to give context here more publicly in case we run into this again.

Hi @yi-gu. Thanks for opening this review. If you'd like our feedback, could you please draft us a quick explainer to cover how you'd like this to work and why you've chosen that approach above the other approaches you've considered? If it helps, our explainer template and explainer explainer are posted.

We did originally have proposals to extend FedCM in the form of explainers that follow the template (you can still see some of them here), but we got feedback from Mozilla that it would help their reviews if these were filed as github Issues as opposed to standalone markdown files: making comments in github issues is a much lower hurdle to pay to engage than it is to kick off new github issues or submit pull requests.

file issues followed by proposals followed by spec PRs, as opposed to explainers, to substantially decrease the cost of engagement (much easier to comment on github issues than to comment on explainers)

https://github.com/fedidcg/FedCM/issues/431#issuecomment-1425025469

That overall makes sense to us (we'll follow whatever makes our reviewers life easier), so we started to slowly port our explainers into github issues.

So, what @yi-gu pointed you to in the TAG request here is, in fact, the place in which we explain the problem, the alternatives we considered and the proposal we have an inclination to go for.

I'm sorry if this causes extra work for you all, and we'd be happy to adapt to find ways to make reviews (mozilla's and yours included) as effective as possible, but just wanted to give context as to why these aren't standalone markdown files.

Since we do expect to send you all a few more reviews in the next few weeks/months, let me know if you feel like this isn't a reasonable format and we can work together with Mozilla to figure out something that works, Sam.

[plinss]

@maxpassion and I looked at this during our Tokyo F2F. One question that came up is about getting user consent for the re-auth flow. It seems like in addition to the RP opting-in to this flow, perhaps the user should also have the option to (or be required to) opt-in during the initial login flow. e.g. when prompted for intiial permissions have to choice of 'Remember me' or 'Only for this session' or such. Our concern is if a user uses FedCM to log in to a service on a public terminal, would the next person using the same terminal be able to sign back in to the original service without knowing the user's credentials? (or at least gain some knowledge about the previous user having an account on the service and possibly login name.)

[yi-gu]

Thank you for the feedback!!

Quick update: in general we are moving towards to a direction to resue the existing mechanism for "automatically returning credentials" defined in Credential Management API. In particular, the mediation requirement and preventSilentAccess as discussed in the initial issue (we'll request another round of review when the proposal is updated).

For the concern regarding public terminal, here are some quick notes:

• If the user has signed out of their identity provider before leaving the terminal (which they are expected to), auto re-authn won't be triggered because the browser cannot get any account from that identity provider.
• If not, the next person that uses the same terminal already has access to the previous user's IdP data which provides them the capability to access the federated accounts.
• Suppose the second user is not an attacker and won't try to steal anything from the first user. The concern is that the second user will automatically authenticated to the website unintentionally and learn about the first user by accident, right? In this case, if the website uses Credential Management API (with IdentityCredential, PasswordCredential etc.), it's expected to invoke preventSilentAccess() upon user signing out. So if the user has signed out of the RP, then auto re-authn won't be triggered; if not, the second user has access to the first user's RP account already. Unless the website does not invoke preventSilentAccess() in which case the second user will see auto re-authn with the first user's account (assuming the user is NOT signed out of their IdP). But at this point, we think this should be a rare case similar to other credential types that rely on preventSilentAccess().

Does it make sense?

[yi-gu]

Hello again!

We have finalized our proposal to support auto re-authentication. As mentioned earlier, we decided to reuse the existing mediation requirements and preventSilentAccess from the CredentialManagement API. i.e. no new web API will be introduced for this feature.

The spec PR has been merged after we aligned with Firefox on the proposal.

Since there's no new API, should we close this review? Please let us know if anything else is needed from us.

Thank you!

[torgo]

Given the above info we're happy to close. As Peter commented above, we generally remain concerned about scenarios involving public terminals so we encourage you to take those into account. Thanks! ✨