[blink-dev] Intent to Experiment: FedCM as a trust signal for the Storage Access API

[Chris Fredrickson]

Contact emails

johann...@chromium.org, cfred...@chromium.org, y...@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.

-- 
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+unsubscr...@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.

Re: [blink-dev] Intent to Experiment: FedCM as a trust signal for the Storage Access API

[Mike Taylor]

LGTM to experiment from 126 to 127 inclusive.

On 5/7/24 10:52 AM, Chris Fredrickson wrote:


Contact emails

johann...@chromium.org, cfred...@chromium.org, y...@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.


--
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+unsubscr...@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 
.


--
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+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e4cfab89-5510-4ce8-84f7-b7c4bbe071da%40chromium.org.

Re: [blink-dev] Intent to Experiment: FedCM as a trust signal for the Storage Access API

['Chris Fredrickson' via blink-dev]

FYI, we're going to extend this OT another 2 milestones, to 129 inclusive. 
(Existing OT tokens will still work, they won't expire IIUC.)

On Tuesday, May 7, 2024 at 11:02:03 AM UTC-4 Mike Taylor wrote:

> LGTM to experiment from 126 to 127 inclusive.
> On 5/7/24 10:52 AM, Chris Fredrickson wrote:
>
> 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.
>
> -- 
> 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
>  
> 
> .
>
>

-- 
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+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/0cfd4e4b-9f00-48b5-87b2-7cad43d9f80dn%40chromium.org.

Re: [blink-dev] Intent to Experiment: FedCM as a trust signal for the Storage Access API

[Mike Taylor]

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 4:03 PM, Chris Fredrickson wrote:
FYI, we're going to extend this OT another 2 milestones, to 129 
inclusive. (Existing OT tokens will still work, they won't expire IIUC.)


On Tuesday, May 7, 2024 at 11:02:03 AM UTC-4 Mike Taylor wrote:

LGTM to experiment from 126 to 127 inclusive.

On 5/7/24 10:52 AM, Chris Fredrickson wrote:


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.


-- 
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

Re: [blink-dev] Intent to Experiment: FedCM as a trust signal for the Storage Access API

[Chris Fredrickson]

Hi Mike,

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.

Chris

On Wednesday, July 24, 2024 at 1:52:53 PM UTC-4 Mike Taylor wrote:

> 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 4:03 PM, Chris Fredrickson wrote:
>
> FYI, we're going to extend this OT another 2 milestones, to 129 inclusive. 
> (Existing OT tokens will still work, they won't expire IIUC.)
>
> On Tuesday, May 7, 2024 at 11:02:03 AM UTC-4 Mike Taylor wrote:
>
>> LGTM to experiment from 126 to 127 inclusive.
>> On 5/7/24 10:52 AM, Chris Fredrickson wrote:
>>
>> 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.
>>
>> -- 
>> 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+.

Re: [blink-dev] Intent to Experiment: FedCM as a trust signal for the Storage Access API

[Mike Taylor]

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 :)

Thanks, I formally LGTM the request to M129 inclusive. :)
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.
Great - I think the OT team typically chases down LGTMs - so you should 
be set now.


Chris

On Wednesday, July 24, 2024 at 1:52:53 PM UTC-4 Mike Taylor wrote:

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 4:03 PM, Chris Fredrickson wrote:

FYI, we're going to extend this OT another 2 milestones, to 129
inclusive. (Existing OT tokens will still work, they won't expire
IIUC.)

On Tuesday, May 7, 2024 at 11:02:03 AM UTC-4 Mike Taylor wrote:

LGTM to experiment from 126 to 127 inclusive.

On 5/7/24 10:52 AM, Chris Fredrickson wrote:


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


Es