Contact emails
joha...@chromium.org, cfre...@chromium.org, yi...@chromium.org
Explainer
https://github.com/explainers-by-googlers/storage-access-for-fedcm
Specification
None (TBD)
Summary
Reconciles the FedCM and Storage Access APIs by making a prior FedCM grant a valid reason to automatically approve a storage access request.
When a user grants permission for using their identity with a 3rd party Identity Provider (IdP) on a Relying Party (RP), many IdPs require third-party cookies to function correctly and securely. This proposal aims to satisfy that requirement in a private and secure manner by updating the Storage Access API (SAA) permission checks to not only accept the permission grant that is given by a storage access prompt, but also the permission grant that is given by a FedCM prompt.
A key property of this mechanism is limiting the grant to cases explicitly allowed by the RP via the FedCM permissions policy, enforcing a per-frame control for the RP and preventing passive surveillance by the IdP beyond the capabilities that FedCM already grants, as outlined in the Privacy Considerations.
Blink component
Blink>StorageAccessAPI
TAG review
None
TAG review status
N/A
Risks
Interoperability and Compatibility
None
Gecko: No public signals, positive initial signals. We will request a formal position.
WebKit: No signal. We will request a formal position.
Web developers: Positive
Other signals:
WebView application risks
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
N/A, not shipping on Android WebView.
Goals for experimentation
Evaluate the implementation, and the usability of the feature to ensure it adequately solves the problem.
Ongoing technical constraints
None
Debuggability
None
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?
No. It will not be supported in Android WebView.
Is this feature fully tested by web-platform-tests?
No. The implementation is primarily in permissions code in //chrome, which cannot be tested in WPTs since WPTs use a fake permission manager in Chromium.
Flag name on chrome://flags
#fedcm-with-storage-access-api
Finch feature name
FedCmWithStorageAccessAPI
Non-finch justification
None
Requires code in //chrome?
True
Estimated milestones
M126 through M127 (inclusive).
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5116478702747648
Links to previous Intent discussions
Intent to prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAD_OO4iogs7O60r0YcVnDB5aCvs9WUYjWFcuHqcFi5bXLRBOig%40mail.gmail.com
This intent message was generated by Chrome Platform Status.
LGTM to experiment from 126 to 127 inclusive.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/9a75fe74-ca55-4ddc-93d7-120adfdee49en%40chromium.org.
Hey Chris,
Per the process, you'll need to formally request an extension, rather than treat this as an FYI.
(Also, I just double checked and
https://developer.chrome.com/origintrials/#/register_trial/4008766618313162753
is only available until M127. Note there's a 2 month "grace
period" where it will continue to work for users on 126 or 127
that haven't upgraded to M128 or higher - but it should not work
in 128 or 129.)
thanks,
Mike
On 7/24/24 8:06 PM, Chris Fredrickson wrote:
My apologies, I misunderstood the process here. I hereby formally request an extension for this OT, through M129 :)
Re: the OT dashboard, I've already requested an OT extension through the chromestatus entry; I believe the OT dashboard will be updated to reflect that once the OT team approves that request.