Use cases for Cross-Site Cookie Access through Storage Access API after FedCM grant?

[shuranhuang]

FedCM solves a number of federated user identity flows through new, purpose-built APIs that do not expose 3p cookies to IDPs. However, there are a number of capabilities and technological patterns that are currently in use by the (federated) identity ecosystem currently dependent on the login state that is stored in 3p cookies after the FedCM flow.

Based on what we’ve heard from FedID CG meetings and partner conversations, some enterprises or edu IDPs might be able to adopt FedCM, but probably could not drop reliance on 3p cookies in all of their users flows without custom-built FedCM extensions, and so would otherwise need to guide their users to re-enable 3p cookies.

We'd like to propose a seed of an idea: what if IDPs that are granted user consent through FedCM are permitted to access their 3p cookies using the Storage Access API (SAA), without requiring an additional permission prompt from SAA, with RPs’ explicit opt-in? We suspect this could help a broader audience of developers adopt the user-friendly FedCM flow, and also remove the design / maintenance burden for less common data / interaction flows for FedCM.

Our question to this group: would this help resolve any so far unaddressed use cases in the identity space? To what extent do you feel this is helpful compared to a longer term outlook of additional higher-level APIs in FedCM? To browser vendors implementing FedCM: does that seem right directionally? Any concerns / recommendations? The idea is still in the exploratory stage and thoughts are welcome!

[samuelgoto]

We'd like to propose a seed of an idea: what if IDPs that are granted user consent through FedCM are permitted to access their 3p cookies using the Storage Access API (SAA), without requiring an additional permission prompt from SAA, with RPs’ explicit opt-in?

@timcappalli I think I heard from you before that re-enabling 3p cookies based on the FedCM flow would help with some of your deployment pains. Would this be a constructive idea to you?

To browser vendors implementing FedCM: does that seem right directionally? Any concerns / recommendations?

@martinthomson any thoughts on this? is this something worth exploring further?

[martinthomson]

@johannhof and I have been discussing this idea for some time. The basic idea is reasonable.

The logic is simple: once a site has used FedCM successfully[^1], that site can match identities with the IdP. They can know that user X at the RP is the same person as user Y at the IdP. There is no material gain from us trying to further isolate the two.

To that end, if we grant the IdP access to its first-party state in the RP context, then there is no additional privacy harm. But there is potentially a great deal of utility in being able to use all that accumulated state. The current thinking is that this might be a simple case where Storage Access requests are automatically granted.

I am of the hope that this might eventually be the only place where Storage Access requests are ever granted, but there's a lot that needs to happen first.

However, this probably isn't the specification to do this work in. Storage Access is moving to various WHATWG specs and so changes belong primarily there. Again @johannhof is probably in a better position to advise on how to execute that maneuver.

[^1]: ...or even unsuccessfully, past the point that a user chooses to allow the use of the IdP.

[johannhof]

Thanks for chiming in here Martin, I agree with what you're saying. I've been working on this with Shuran and I think generally we share the same idea that we want to encourage identity-related data flows (which is likely the vast majority of SAA use cases) to surface the more relevant user experience provided by FedCM.

So, while this seems like a good step for SAA and an easy utility increase for FedCM, there were some concerns raised internally, e.g. around lowering the effort required to achieve exposure to 3P cookies on the side of the IDP. So there seems to be at least some tradeoff to this idea, which motivated us to check in with the ecosystem on its utility before turning it into a full proposal.

However, this probably isn't the specification to do this work in. Storage Access is moving to various WHATWG specs and so changes belong primarily there. Again @johannhof is probably in a better position to advise on how to execute that maneuver.

Yeah, if we end up agreeing on this I think we'll find a way to make it happen. We're still so preoccupied with whether we should that we're not talking "could" yet. But given that SAA is permissions-based we have a lot of flexibility, for better or worse. FedCM could set a storage access permission or SAA could read the FedCM granted state / permission in its own permission grant algorithm.

[timcappalli]

@timcappalli I think I heard from you before that re-enabling 3p cookies based on the FedCM flow would help with some of your deployment pains. Would this be a constructive idea to you?

Somehow I missed this tag/issue. Yes, absolutely @samuelgoto, this would help with many of our embedded scenarios.

[DavidScales]

I suspect this could also help my use case, which is documented in here.

SAA works nearly perfectly for me in ways that I don't think FedCM will. For example, by allowing state to maintained - sometimes our iframe embed needs to pop a user out into a new tab (to gain more visual space) and SAA enables the user to remain in the same cookie-based session. Even within the iframe, to maintain state that isn't associated with sign-in status, CHIPS/partitioned cookies are required and while that may be more privacy friendly long term, it is another lift for developers if they choose FedCM over SAA.

However, the UX of SAA is not ideal. My users (in the education space) are often children and we want to avoid any kind of Chrome consent prompts (for privacy and legal reasons, and because kids are likely to get confused). FedCM seems like it offers a much clearer intention in the UX; the user can tell it's just signing them in instead of asking if a site can "use information they saved about you" or "know that you've visited [a parent site]" which might be an issue for students/teachers even if it is technically accurate.

[DavidScales]

Re-reading this, I see the proposal wording is for Identity Providers to be granted cross site cookie access upon successful FedCM usage, not RPs. For my use case I have a 3P embed in my 1P site, and the 3P embed needs to authenticate with an IdP (distinct from both 1P and 3P).

One of the weaknesses of the 3P embed authenticating directly with the IdP via FedCM, is that the 3P embed state won't persist if the user is popped into a new tab on the 3P site from the 3P embed. If the IdP is allowed cross site cookie access, I interpret that to mean the IdP can access it's own cookies in the embed or top level context. This would imply sign-in state would persist between the two contexts, assuming the IdP uses cookies for this.

However, this wouldn't allow the 3P to have cross site cookie access, so I think session state would be lost between the two contexts.

As an example, if I'm on the 1P site, and I sign into the 3P embed with Google via FedCM, then click a link in the embed that opens a new tab onto the 3P site, I could expect to still be "signed in" with Google, but the new tab / top level request to the 3P wouldn't have the embed session cookie, nor vice versa.

@remko does that sound right to you and would that be problematic?

[remko]

@DavidScales Yes, this is also how I read the proposal and understand its consequences.

At best, the fact that the IdP can access its cookies from the 3P embed would mean that the new (toplevel) tab at the 3P site (without a session) can be immediately authenticated without user interaction, but I'm not sure if a re-authenticated tab loses other capabilities (e.g. communicating back to the iframe so the iframe can communicate with its parent 1P site using e.g. postMessage)

[johannhof]

To follow up here, based on feedback in this group and from partner conversations we wrote up a concrete proposal for what this could look like in technical details here: https://github.com/explainers-by-googlers/storage-access-for-fedcm

The one thing we tried to pay special attention to is to maintain exactly the same privacy boundaries that FedCM establishes today, specifically when it comes to preventing tracking on the IdP side without explicit RP collaboration.

@hlflanagan I dropped this into the Explainers by Googlers repo as a default placeholder, but if you'd like to adopt this explainer in the FedID CG I'm happy to transfer / add to wherever is best. Because of the way this is designed virtually all of the spec changes will need to happen on Storage Access side, and I'm going to file an issue for that on https://github.com/privacycg/storage-access as well, but it seems more relevant for FedCM users and thus appropriate to discuss in this group.

cc @bvandersloot-mozilla @yi-gu @cfredric ^

[hlflanagan]

@johannhof I think dropping it into FedCM makes sense.

[johannhof]

Note that @hlflanagan and I chatted separately where she expressed that after additional review the chairs would prefer the explainer to live in Privacy CG, so I filed https://github.com/privacycg/proposals/issues/46 for that. We'll just have to deal with the dual-CG working mode for now :)

[wseltzer]

Discussed at TPAC 2024 https://github.com/fedidcg/meetings/blob/main/2024/2024-09-24-TPAC-notes.md#saa-auto-grant

SAA Auto-Grant proposal advanced to Stage 2