You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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?
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 torpOrigin
withidpOrigin
, 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.
The text was updated successfully, but these errors were encountered: