Intent to Prototype: FedCM as a trust signal for the Storage Access API
Johann Hofmann
Contact emails
joha...@chromium.org, cfre...@chromium.org, yi...@chromium.org
Explainer
https://github.com/explainers-by-googlers/storage-access-for-fedcm
Specification
None
Summary
Reconciles the Federated Credential Management (FedCM) and Storage Access APIs by making a prior permission grant via FedCM a valid reason to automatically approve a storage access request.
When a user grants permissions to 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 identity-credentials-get 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 of the explainer.
Blink component
Motivation
FedCM is an API that mediates federated user identity flows through the application of (ideally) well-understood, purpose-driven user interfaces. Using the navigator.credentials API, it exposes a high-entropy user identifier (token) from an IdP to an RP.
This kind of token-based authentication/authorization is commonly used in federated identity flows, which FedCM intends to address. Other login schemes, particularly for Single-Sign-On (SSO), frequently rely on the presence of (cross-site) cookies.
These kinds of flows can currently be solved by the Storage Access API, which mediates permission for documents to access cross-site cookies. However, as SAA lacks additional context on the nature of the request for cross-site cookie access, its UI in browsers tends to be generic and unintuitive. It’s also primarily designed to solve use cases for authenticated embeds, which makes it difficult to fit seamlessly onto SSO flows (without sacrificing some of the anti-abuse mechanics of SAA such as the prior user gesture requirement).
Due to its arguably much more intuitive user experience for mediating user identity, FedCM would be a good fit to cover these login-oriented use cases instead. To do this, it needs to be compatible with identity flows that require cookies to work. This is where a well-designed integration with SAA can help, by providing secure access to cross-site cookies based on FedCM grants as an additional trust signal.
Initial public proposal
https://github.com/fedidcg/FedCM/issues/467
TAG review
None
TAG review status
Pending
Risks
Interoperability and Compatibility
None
Gecko: No official signal, positive initial thoughts.
WebKit: No signal
Web developers: Positive, some public support in FedID CG as well as in direct partner discussions.
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?
None
Debuggability
None
Is this feature fully tested by web-platform-tests?
No
Flag name on chrome://flags
None
Finch feature name
None
Non-finch justification
None
Requires code in //chrome?
True
Estimated milestones
No milestones specified
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5116478702747648
This intent message was generated by Chrome Platform Status.