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

Allow user agents to use "Connected Accounts Set" with flexibility #517

Open
yi-gu opened this issue Nov 21, 2023 · 2 comments · May be fixed by #523
Open

Allow user agents to use "Connected Accounts Set" with flexibility #517

yi-gu opened this issue Nov 21, 2023 · 2 comments · May be fixed by #523

Comments

@yi-gu
Copy link
Collaborator

yi-gu commented Nov 21, 2023

Currently the spec will treat an account "connected" if a user has explicitly used that account to create a connection between an RP and an IdP. e.g. when a user uses account foo to sign in to rpOrigin with idpOrigin, the user agent should add the tuple {rpOrigin, idpOrigin, "foo"} to the Connected Accounts Set as a sign that the user agent has observed a "sign-in" moment.

For features that require an account being connected, e.g. auto re-authentication, the user agent currently only trusts its own connected accounts set even though it could be incorrect. e.g. if a user has created a federated account on the RP with the IdP without the user agent knowing it (e.g. via another user agent), then the user will be treated as a new user on the RP and therefore won't be eligible for those features. Even if an IdP as the source of truth has claimed that the user has created an account on the RP via approved_clients, the user agent would still ignore that signal. The design was mainly from privacy's perspective.

However, the privacy benefit of the design may be lost if the IdP has third-party cookies (3PC) access on the RP site. e.g. pop-up heuristics is (to be) implemented in many major browsers even though it's meant to be temporary. If an IdP has gained 3PC access via heuristics, they could communicate with themselves using 3PC and the privacy bar that FedCM sets would make less sense.

Therefore we should revisit the decision and see if user agents could have some flexibility when using the "Connected Accounts Set" to determine whether to trigger "returning user only" features.

Note: we should not change how "Connected Accounts Set" is calculated to keep it in a clean state such that when user agents remove 3PC access from the IdPs in the future (e.g. deprecating heuristics) we can still hold the high privacy bar.

@yi-gu yi-gu added the agenda+ Regular CG meeting agenda items label Nov 21, 2023
@achimschloss
Copy link
Contributor

However, the privacy benefit of the design may be lost if the IdP has third-party cookies (3PC) access on the RP site. e.g. pop-up heuristics is (to be) implemented in many major browsers even though it's meant to be temporary.

Is there a proposal/discussion how/where these heuristics are to be implemented?

@yi-gu
Copy link
Collaborator Author

yi-gu commented Nov 21, 2023

@asr-enid
Firefox
Safari
Chrome (to be prototyped)

@npm1 npm1 linked a pull request Nov 29, 2023 that will close this issue
@yi-gu yi-gu removed the agenda+ Regular CG meeting agenda items label Nov 30, 2023
@samuelgoto samuelgoto added the agenda+ Regular CG meeting agenda items label Dec 8, 2023
@npm1 npm1 removed the agenda+ Regular CG meeting agenda items label Jan 2, 2024
@wseltzer wseltzer added the FPWD label Aug 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants