-
Notifications
You must be signed in to change notification settings - Fork 55
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
Comments
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. |
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
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): 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: 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. |
For me personally, what I'd love to hear feedback on is:
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. |
こんにちは 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.
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:
¹ 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/.
The text was updated successfully, but these errors were encountered: