Domains state purpose for being in First-Party Set
krgovind opened this issue · 3 comments
@johnwilander proposed during the F2F that domains should state their purpose for being in a set with the other domains. Specifically, this may be useful for domains that provide single-sign-on capability, and is something that could be surfaced to users within the context of storage access API and isLoggedIn.
Questions:
- Is the expectation for users to opt-in or opt-out per domain; and mostly use FPS membership information to show more user-friendly prompts? Or would storage access be granted automatically?
- What about domains that are separated for non-SSO reasons, such as ccTLD variants, or for security reasons (e.g. domains that host user-uploaded content)?
Some potential concerns to think about with regards to this might be:
-
Since there is a user agent policy for FPS, should the purpose provided by the organization be verified by the user agent during the policy verification process? Verifying something like this would likely require examining multiple user flows and checking the validity over time, which may be difficult to enforce.
-
Capturing some feedback from PrivacyCG call, there could be multiple domains serving the same purpose or a set of domains serving multiple purposes, which may be difficult to communicate to users in an understandable way.
-
It would also likely require defining meaningful categories to represent purpose in a consistent way to users. Terminology may not translate easily across industries, countries etc...
Got some clarification on use-cases from John, which answers some of the questions I posed in my initial post. They are primarily interested in login related domains: "It could help with SSO, bounce tracking prevention, Storage Access API prompts, Storage Access API cookie access scope beyond per-page, and auth flows that have an easy integration with IsLoggedIn."