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:
https://github.com/fedidcg/FedCM/issues/555

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

Parameters API:
https://github.com/fedidcg/FedCM/issues/556

This lets RPs pass additional data to the ID assertion endpoint

Scope API:
https://github.com/fedidcg/FedCM/issues/559

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

Scaling well-known:
w3c-fedid/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:
w3c-fedid/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  w3c-fedid/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  w3c-fedid/FedCM#477
• Major unresolved issues with or opposition to this design: scopes are somewhat controversial (Authorizing non-profile oauth scopes  w3c-fedid/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/.

[torgo]

Hi folks - in order to proceed with a review we really need an explainer that more-or-less follows the guidelines we've laid out here: https://tag.w3.org/explainers/. A single explainer that talks about these 5 features would be fine. To be clear: the explainer allows us to contextualize this which facilitates the review, and starts with user needs.

[samuelgoto]

These extensions just recently entered origin trials, and the blog post chrome recently published may be useful in understanding what each of these extensions do:

https://developers.google.com/privacy-sandbox/blog/fedcm-chrome-126-updates#continuation-api

A single explainer that talks about these 5 features would be fine.

This may be something that we could use your guidance in requesting wide reviews across the W3C, but the FedID CG has, intentionally, moved away from single-file README.md explainers towards github issues for incremental extensions to FedCM, largely based on the observation from @martinthomson that github issues are easier to comment on than single-file explainers (this turned out to be true: every issue we filed has gathered way more community feedback than explainers we wrote in the past):

w3c-fedid/FedCM#431 (comment)

In this process, the issues all start from a problem statement (all representing user needs, some transitively as developer needs), many alternatives are considered and at some point arrive at a proposal. You'd be right in noting that the issues are harder to review (because you have to read the whole thread), but they do seem to work well as far as development goes, with a much richer participation.

We'd be happy to learn about better ways to manage change here.

FWIW, we recently formed a FedID WG, to work in conjunction with the FedID CG, and we are starting to figure out how to structure the process here:

https://docs.google.com/document/d/1-FQccf3A2w4EuB5e4Z12oRsJEZvDo4hbzm_Td3yvNg8/edit#heading=h.6cj8b6eh4vk6

I think it is likely that, going forward, we'd organize things in a structure that would be more easily recognized by the TAG, so I think that this will get easier going forward.

[cbiesinger]

For me personally, what I'd love to hear feedback on is:

• For the parameters API, how to best send the parameters to the server (see discussion in the github issue) -- prefix the builtin parameters, prefix the custom parameters, do some sort of json encoding, ...? also -- should we allow JSON for parameter values and if so how to send that to the server
• For the fields API, is this the best design for this purpose? Should we try to integrate somehow with the contacts API as suggested in the issue?

IMO both of those are fairly well described in their respective explainers in the linked issue.

I'm fairly comfortable with the design of the other parts of this explainer, though if you have feedback on how we communicate back from the popup to the FedCM API in the continuation API I'd be interested in that.