FedCM bundle: Continuation API, account labels, custom parameters, scopes

[cbiesinger]

こんにちは TAG-さん!

I'm requesting a TAG review of FedCM bundle: Continuation API, account labels, custom parameters, scopes.

This bundles a few features that we would like to launch at the same time:

Continuation API:
fedidcg/FedCM#555

This lets the IDP open a popup window to finish the sign-in flow after potentially collecting additional information.

Parameters API:
fedidcg/FedCM#556

This lets RPs pass additional data to the ID assertion endpoint

Scope API:
fedidcg/FedCM#559

This lets RPs bypass the data sharing prompt in favor of the IDP prompting

Scaling well-known:
fedidcg/FedCM#552

This lets IDPs use different config files in different contexts without weakening FedCM privacy properties, by allowing one accounts endpoint for the eTLD+1 (instead of one config file, which is more limiting than necessary)

Account labels:
fedidcg/FedCM#553

Combined with the previous proposal, this allows filtering the account list per config file without providing additional entropy to the IDP.

We are bundling them because each of them is fairly small on its own but they combine to be pretty powerful for IDPs.

• Explainer¹ (minimally containing user needs and example code): see above
• User research: n/a
• Security and Privacy self-review²: url: same as the general one for FedCM because I think the answers are the same. Let me know if you have questions or if I have missed something though!
• GitHub repo (if you prefer feedback filed there): https://github.com/fedidcg/FedCM
• Primary contacts (and their relationship to the specification):
  • Christian Biesinger (@cbiesinger), Google Chrome
  • Yi Gu (@yi-gu), Google Chrome
  • Sam Goto (@samuelgoto, Google Chrome)
• Organization/project driving the design: Google Chrome
• External status/issue trackers for this feature (publicly visible, e.g. Chrome Status): Authorizing non-profile oauth scopes  fedidcg/FedCM#477 and the explainer links above (explainers are in github issues for easier commenting)

Further details:

• 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): FedID WG
• Existing major pieces of multi-stakeholder review or discussion of this design: some discussion in Authorizing non-profile oauth scopes  fedidcg/FedCM#477
• Major unresolved issues with or opposition to this design: scopes are somewhat controversial (Authorizing non-profile oauth scopes  fedidcg/FedCM#477 (comment))
• This work is being funded by: Google Chrome

You should also know that...

[please tell us anything you think is relevant to this review]

---

CAREFULLY READ AND DELETE CONTENT BELOW THIS LINE BEFORE SUBMITTING

Please preview the issue and check that the links work before submitting.

In particular:

• if anything links to a URL which requires authentication (e.g. Google document), please make sure anyone with the link can access the document. We would prefer public documents though, since we work in the open.

¹ For background, see our explanation of how to write a good explainer. We recommend the explainer to be in Markdown.

² Even for early-stage ideas, a Security and Privacy questionnaire helps us understand potential security and privacy issues and mitigations for your design, and can save us asking redundant questions. See https://www.w3.org/TR/security-privacy-questionnaire/.