[VK Company Feedback] Domain limitations in FPS

[NekR]

Hello!

We're looking into all the docs and specs related to FPS to understand if it fits our business requirements.
Current spec says FPS should contains domains which are controlled only by "common owner" and it isn't clear how exactly this would be verified and what is exactly "common owner". How and when this is planned to be defined?

Here is an example which we worry about:
Site x.example is owned by company X. X company is a joint venture of some other companies: A and B.
If company A has a First Party Set, would it be able to contain x.example?

Another example on top of the last one -- what if both companies, A and B, would want to include x.example into their First Party Sets? Right now documentations says that a website could be only in one FPS, but it doesn't solve business use case from above, when one product/company is part of 2 ecosystems.

Thanks

[dmarti]

There are several existing issues that cover how a "common owner" requirement is impractical, considering the many different real-world ownership structures that could affect domains. PR #56 suggests a simpler alternative that should be more practical to enforce.

Besides the problem you mention, there are several other related ones, including

• Most people don’t know which of the sites they use have common ownership, and in the case of independently operated subsidiaries with different data usage practices, common ownership does not change how the user's data is handled. Arbitrary/opaque nature of "organizations" as the arbiter of first-party sets · Issue #14 · privacycg/first-party-sets

• Browsers and enforcement organizations do not have experts in corporate ownership documents in all possible jurisdictions in which an FPS could operate. Enforcement of organizational structure within FPS · Issue #18 · privacycg/first-party-sets

• A new entity could be purposefully designed to comply with an ownership requirement without adding any meaningful privacy protections for users, but while increasing costs and risks for sites. MERS for web properties · Issue #49 · privacycg/first-party-sets

• A browser or enforcement entity might break a valid FPS if unable to verify ownership, or if ownership were misrepresented by an attacker. FPS as an attack surface · Issue #55 · privacycg/first-party-sets

More Q&A in minutes from the 9 Sep meeting (2nd item). Comments and suggestions on #56 welcome, thank you.

[krgovind]

@NekR Thanks for the question!

Could you say a little bit more about the types of services that may be hosted on x.example, and how users interact with those services on/across the domains in A's set? If the intention is to simply allow for subresources from x.example to be embedded with session-state on sites owned by "A", and also independently on sites owned by "B"; but there is no workflow spanning those two sets, the right solution may be for x.example to use partitioned cookies (see our CHIPS proposal), and not First-Party Sets.

[NekR]

We're mainly looking in SSO scenario here, so that x.example would be able to sign in with the same UX as other services in A's FPS.

There are other cases, when x.example may want to do CORS requests to A or embed <iframe>s from A, in this cases in might be enough to just use partitioned cookie, instead of having access to first-party cookie, since x.example already would've gotten tokens from SSO.
Important note here is that having only tokens from SSO is not enough -- another independent verification must be stored in A's storage/cookie and not be directly accessible by x.example. Hence partitioned or first-party cookie would work, as far as they aren't purged like in 3 days.

[krgovind]

We're mainly looking in SSO scenario here, so that x.example would be able to sign in with the same UX as other services in A's FPS.

There are other cases, when x.example may want to do CORS requests to A or embed <iframe>s from A, in this cases in might be enough to just use partitioned cookie, instead of having access to first-party cookie, since x.example already would've gotten tokens from SSO. Important note here is that having only tokens from SSO is not enough -- another independent verification must be stored in A's storage/cookie and not be directly accessible by x.example. Hence partitioned or first-party cookie would work, as far as they aren't purged like in 3 days.

@NekR - Sorry, it's not entirely clear to me whether this establishes that First-Party Sets is not needed in this scenario or not? Can we close this issue if you think that partitioned cookies are sufficient?

FYI, another related proposal is the Federated Credentials Management API (formerly known as WebID), which is intended for federated login use-cases. This may be appropriate if you intend for a service in either A on x.example to act as an identity provider.

[NekR]

Can we close this issue if you think that partitioned cookies are sufficient?

It isn't sufficient for seamless authentication, which is main use case we expect from FPS. Other cases, yes, somehow could be used with partitioned cookie.

FYI, another related proposal is the Federated Credentials Management API (formerly known as WebID), which is intended for federated login use-cases. This may be appropriate if you intend for a service in either A on x.example to act as an identity provider.

Do you mean that use case described in the first comment isn't considered by FPS and won't be supported?

In our understanding, x.example supposed to have the same seamless authentication experience as any other website in A's FPS. We're trying to understand if that would be possible with FPS or maybe FPS isn't the right tool for seamless authentication, as you mentioned WebID and we should look into that instead.

[krgovind]

@NekR - Could you expand on what you mean by "seamless authentication"? For example, do you mean that if the user has logged in to x.example as janedoe@x.example, they should be automatically logged into the domains contained in A's FPS, as well as across the domains in B's FPS with the same identity? Or is a user action / prompt involved?

[NekR]

@krgovind if a1.example and a2.example are in FPS A and user logged into a1.example, then we expect user would be automatically logged into a2.example. If x.example is in A's FPS, then the same behavior would be expected for x.example.

as well as across the domains in B's FPS with the same identity?

This probably would be strange I guess :)
Point here is to have user automatically logged into an ecosystem of websites, if they are logged into at least one of those websites. So if x.example is in 2 ecosystems and user is logged into one of them, then x.example may be logged automatically with that ecosystem's account.

But I guess if user is logged both into A and B ecosystem, then x.example could detect that and ask user how they would like to proceed. Or maybe x.example have multi-dimensional user system or something :)

At least, this is how it can work right now with third-party cookie.

[krgovind]

Thanks for the details, @NekR!

It does sound like x.example is acting like an identity provider (IdP), so I would suggest looking into the FedCM API. Perhaps some work is needed to make sure that x.example conforms to the OAuth/Open ID style IdP interface that FedCM is being designed around. With this solution, users may then use their identity onx.example to sign in to either the set A or set B. Once the user is logged in to a1.example, you may use First-Party Sets and SameParty cookies to seamlessly log the user in to a2.example (and other domains within the same FPS as a1.example).

Alternatively, you might consider allowing x.example to have partitioned identity, so that it cannot correlate user identity across the A and B ecosystems. I understand that it currently works this way with third-party cookies, but we will need to re-consider the system's functioning given the cross-site tracking restrictions that are being developed within this community group.