In short, this feature will allow developers of FedCM to utilize the Storage Access API (based on the prior user permission given to share cross-site identifiers), conversely, it allows developers using the Storage Access API to more easily upgrade to FedCM which may offer a better user experience in many cases.
We're looking to ship this API in Chrome within the next few releases
The group where the work on this specification is currently being done:
PrivacyCG / FedID CG
The group where standardization of this work is intended to be done (if different from the current group): WHATWG
Major unresolved issues with or opposition to this specification: One thing that we still have to fully figure out is how to make this work well with Storage Access Headers, given that the privacy properties of this proposal mandate the use of the FedCM permissions policy which would limit utility of SAH for some developers.
This work is being funded by: Google
You should also know that...
The Lightweight FedCM work driven by @bvandersloot-mozilla et al integrates with this feature to ensure developers using the API get access to cross-site cookies upon completing the proposed user permission flow.
Guten TAG!
I'm requesting a TAG review of FedCM as a trust signal for the Storage Access API.
In short, this feature will allow developers of FedCM to utilize the Storage Access API (based on the prior user permission given to share cross-site identifiers), conversely, it allows developers using the Storage Access API to more easily upgrade to FedCM which may offer a better user experience in many cases.
From the explainer, note the key use cases as well as a discussion of the slightly different privacy and security properties of the two APIs and how we chose to reconcile them.
Further details:
You should also know that...
The Lightweight FedCM work driven by @bvandersloot-mozilla et al integrates with this feature to ensure developers using the API get access to cross-site cookies upon completing the proposed user permission flow.