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

[Chris Fredrickson]

Contact emails

joha...@chromium.org, cfre...@chromium.org, yi...@chromium.org

Explainer

https://github.com/explainers-by-googlers/storage-access-for-fedcm

Specification

https://github.com/privacycg/storage-access/pull/206

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

https://github.com/w3ctag/design-reviews/issues/992

TAG review status

Pending

Chromium Trial Name

FedCmWithStorageAccessAPI

Origin Trial documentation link

https://github.com/explainers-by-googlers/storage-access-for-fedcm

WebFeature UseCounter name

kFedCmWithStorageAccessAPI

Risks

Interoperability and Compatibility

None

Gecko: Positive (https://github.com/mozilla/standards-positions/issues/1065)

WebKit: No signal (https://github.com/WebKit/standards-positions/issues/390)

Web developers: Positive (https://github.com/w3c-fedid/FedCM/issues/467#issuecomment-1735911894)

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

This feature requires that the identity-credentials-get permissions policy is provided.

• If the policy is not provided, document.requestStorageAccess() falls back to its normal control flow (i.e. checking for a user gesture, checking for RWS autogrant, checking for a previous top-level interaction, and finally showing a prompt).

• If a policy is provided but misspelled, Chrome prints "Unrecognized feature: <feature name>." in the console.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

No

FedCM and Storage Access API are not supported on Android WebView.

Is this feature fully tested by web-platform-tests?

Yes

https://wpt.fyi/results/fedcm/fedcm-storage-access-api-autogrant.tentative.https.sub.html?label=experimental&label=master&aligned

(WPTs are currently failing on wpt.fyi due to an unrelated error that we're fixing.)

Flag name on chrome://flags

fedcm-with-storage-access-api

Finch feature name

FedCmWithStorageAccessAPI

Requires code in //chrome?

True

Estimated milestones

Origin trial desktop first

126

Origin trial desktop last

131

Origin trial extension 1 end milestone

129

Origin trial extension 2 end milestone

131

DevTrial on desktop

125

Origin trial Android first

126

Origin trial Android last

131

DevTrial on Android

125

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

None

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5116478702747648?gate=5070701733347328

Links to previous Intent discussions

Intent to Prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAD_OO4iogs7O60r0YcVnDB5aCvs9WUYjWFcuHqcFi5bXLRBOig%40mail.gmail.com

Intent to Experiment: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/9a75fe74-ca55-4ddc-93d7-120adfdee49en%40chromium.org

Intent to Extend Experiment 1: https://groups.google.com/a/chromium.org/g/blink-dev/c/LwgSKPBivuM/m/0dRsXWhBAgAJ

Intent to Extend Experiment 2: https://groups.google.com/a/chromium.org/g/blink-dev/c/LwgSKPBivuM/m/0dRsXWhBAgAJ

This intent message was generated by Chrome Platform Status.

[Domenic Denicola]

From what I understand this had an Origin Trial. Did you get any results you are able to share from the trial?

On Thu, Oct 3, 2024 at 2:48 AM Chris Fredrickson <cfre...@chromium.org> wrote:

Contact emails

joha...@chromium.org, cfre...@chromium.org, yi...@chromium.org

Explainer

https://github.com/explainers-by-googlers/storage-access-for-fedcm

Specification

https://github.com/privacycg/storage-access/pull/206

It isn't required, but is there a chance this PR could get at least reviewed, and ideally merged, before we ship? I realize that the Mozilla standards position only became positive last week, but with that in hand I think merging should be possible, right?

 

--
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/5486dcaf-3ff6-4d97-a081-9626f97e2e03n%40chromium.org.

[Chris Fredrickson]

Yes, we ran an OT with 15+ registrants. The feedback we got was positive - that this feature allowed for better UX via a context-specific FedCM prompt, rather than the generic Storage Access API prompt.

One piece of feedback we got on the API was a question on whether `navigator.credentials.preventSilentAccess()` should or should not "disable" access via the Storage Access API. That said, they didn't have a strong opinion either way at the moment. We've added metrics to see if this question needs to be revisited in the future, but for now would like to ship the conservative approach. (Note that we could backward-compatibly relax this decision in the future, if needed.)

Re: reviewing the spec PR, it'd be nice to review/merge the PR, I'll work with the editors as soon as they have bandwidth to review. In the meantime, I'd like to provide to users the well-let path that supports the use cases identified in the explainer sooner rather than later, to give sites as much time as possible to adopt new features before 3P cookies become less available in Chrome.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Alex Russell]

LGTM1

[Domenic Denicola]

LGTM2. Please work to get the spec PR landed as soon as possible.

[Johann Hofmann]

Thanks both! We had some bandwidth issues on the editor's side with TPAC and other meetings going on, but I'm working with Chris to get this reviewed and merged now.

LGTM1

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/5486dcaf-3ff6-4d97-a081-9626f97e2e03n%40chromium.org.

--

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/92533e0a-f1ee-4d28-9831-f4c2c5bf4cfdn%40chromium.org.

[Mike Taylor]

LGTM3 % the spec PR landing (since it seems to be close).

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAD_OO4ijrksVTkgyb_RSYgXwAH7CAfQ-sN2kEJkPvXPo5iYT8A%40mail.gmail.com.