Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
1 task done
cbiesinger opened this issue Apr 15, 2024 · 3 comments
Open
1 task done

Comments

@cbiesinger
Copy link

こんにちは 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):
  • 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:

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
Copy link
Member

torgo commented Jun 17, 2024

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
Copy link

samuelgoto commented Jul 8, 2024

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
Copy link
Author

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.

@torgo torgo modified the milestones: 2024-08-05-week, 2024-08-12-week Aug 8, 2024
@torgo torgo removed this from the 2024-08-12-week milestone Aug 29, 2024
@torgo torgo added this to the Post TPAC milestone Aug 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment