Intent to Prototype: FedCM as a trust signal for the Storage Access API

288 views
Skip to first unread message

Johann Hofmann

unread,
Mar 21, 2024, 6:50:49 AMMar 21
to blink-dev, Chris Fredrickson, yi...@chromium.org

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

Blink>StorageAccessAPI


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.


Reply all
Reply to author
Forward
0 new messages