Intent to Ship: FedCM CORS requirement on ID assertion endpoint

[Nicolás Peña]

Contact emails

n...@chromium.org

Explainer

https://github.com/fedidcg/FedCM/issues/428 

Specification

https://github.com/fedidcg/FedCM/pull/547 

Summary

The fetches in the FedCM API are hard to reason about because of the properties required of them. While there is ongoing discussion regarding the accounts endpoint, there is broad consensus that the ID assertion endpoint should use CORS. This aligns security properties of this fetch more closely to other fetches in the web platform.

Blink component

Blink>Identity>FedCM

TAG review

Not requesting a TAG review. We have already had extensive discussions with Fetch experts.

TAG review status

N/A

Risks

Interoperability and Compatibility

This is a backwards incompatible feature, but one that is warranted due to consensus reached by our security reviewers as well as other browser vendor engineers. We have a manageable list of IDPs that we know are using the FedCM API and we have reached out to all IDPs that are currently deploying FedCM to make sure that they won’t break with this change.

Gecko: Positive based on TPAC discussions and https://github.com/fedidcg/FedCM/issues/428. Not filing a standards position request for small additions at the explicit request from Firefox (they prefer PRs).

WebKit: Positive based on TPAC discussions and https://github.com/fedidcg/FedCM/issues/428. Recently, standards position requests for smaller FedCM features have been closed, pointing to the (unresolved) main FedCM one in https://github.com/WebKit/standards-positions/issues/309 so not filing one for this.

Web developers: No signals

Other signals:

Ergonomics

N/A

Activation

N/A

Security

By adding CORS, we add a check that the IDP explicitly agrees for the browser to share the ID assertion response to the RP. In addition, having this fetch align with most other credentialed fetches in the browser means that any future protections are received by default, and we do not have to special case this fetch.

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

We surface errors when there is a network problem with the ID assertion fetch. This will help developers understand when this feature introduces a problem in their FedCM calls.

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

No. FedCM is not supported on Android WebView.

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

https://wpt.fyi/results/credential-management/fedcm-identity-assertion-nocors.https.html?label=experimental&label=master&aligned (will pass on Chrome once we ship)

Flag name on chrome://flags

None

Finch feature name

FedCmIdAssertionCORS

Requires code in //chrome?

True (because FedCM API does)

Tracking bug

https://issues.chromium.org/issues/40284123

Estimated milestones

DevTrial on desktop

120

DevTrial on Android

120

We want to ship on M124

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

https://github.com/whatwg/fetch/issues/1637

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5094763339710464

This intent message was generated by Chrome Platform Status.

[Mike Taylor]

LGTM1

--
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/1814484e-4a0c-4210-b936-29ead46f32c5n%40chromium.org.

[Yoav Weiss (@Shopify)]

On Mon, Mar 4, 2024 at 9:36 PM Mike Taylor <mike...@chromium.org> wrote:

LGTM1

On 3/4/24 1:33 PM, Nicolás Peña wrote:

Contact emails

n...@chromium.org

Explainer

https://github.com/fedidcg/FedCM/issues/428 

A few lines summarizing this issue would be most useful when evaluating this and understanding what y'all want to ship.

In particular, it'd be useful to understand the request flow, what is the request's origin (as IIUC, we're talking about requests issued from the browser), and what is the request destination that we may want IDPs to check.

Examples of the checks IDPs would have to make would also be helpful.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/91c26d40-ccc9-4abe-bf97-38cd9e48f684%40chromium.org.

[Yoav Weiss (@Shopify)]

On Wed, Mar 6, 2024 at 10:21 AM Yoav Weiss (@Shopify) <yoav...@chromium.org> wrote:

On Mon, Mar 4, 2024 at 9:36 PM Mike Taylor <mike...@chromium.org> wrote:

LGTM1

On 3/4/24 1:33 PM, Nicolás Peña wrote:

Contact emails

n...@chromium.org

Explainer

https://github.com/fedidcg/FedCM/issues/428 

A few lines summarizing this issue would be most useful when evaluating this and understanding what y'all want to ship.

In particular, it'd be useful to understand the request flow, what is the request's origin (as IIUC, we're talking about requests issued from the browser), and what is the request destination that we may want IDPs to check.

Examples of the checks IDPs would have to make would also be helpful.

Also, is the "identity assertion" endpoint the same as the token endpoint?

[Nicolás Peña]

On Wednesday, March 6, 2024 at 5:11:09 AM UTC-5 Yoav Weiss wrote:

On Wed, Mar 6, 2024 at 10:21 AM Yoav Weiss (@Shopify) <yoav...@chromium.org> wrote:

On Mon, Mar 4, 2024 at 9:36 PM Mike Taylor <mike...@chromium.org> wrote:

LGTM1

On 3/4/24 1:33 PM, Nicolás Peña wrote:

Contact emails

n...@chromium.org

Explainer

https://github.com/fedidcg/FedCM/issues/428 

A few lines summarizing this issue would be most useful when evaluating this and understanding what y'all want to ship.

In particular, it'd be useful to understand the request flow, what is the request's origin (as IIUC, we're talking about requests issued from the browser), and what is the request destination that we may want IDPs to check.

Examples of the checks IDPs would have to make would also be helpful.

Sure! From the spec, here is a sample request:

POST /fedcm_assertion_endpoint HTTP/1.1
Host: idp.example
Origin: https://rp.example/
Content-Type: application/x-www-form-urlencoded
Cookie: 0x23223
Sec-Fetch-Dest: webidentity
account_id=123&client_id=client1234&nonce=Ct60bD&disclosure_text_shown=true

 

With this change, Sec-Fetch-Mode will now be cors in this request and the IDP is expected to return the following in the response (no preflight is performed):

Access-Control-Allow-Origin: https://rp.example/

Access-Control-Allow-Credentials: true

 

Also, is the "identity assertion" endpoint the same as the token endpoint?

Yea. I think that explainer doc is not super up to date.

 

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

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1814484e-4a0c-4210-b936-29ead46f32c5n%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+unsubscribe@chromium.org.

[Chris Harrelson]

On Wed, Mar 6, 2024 at 8:28 AM Nicolás Peña <n...@chromium.org> wrote:

On Wednesday, March 6, 2024 at 5:11:09 AM UTC-5 Yoav Weiss wrote:

On Wed, Mar 6, 2024 at 10:21 AM Yoav Weiss (@Shopify) <yoav...@chromium.org> wrote:

On Mon, Mar 4, 2024 at 9:36 PM Mike Taylor <mike...@chromium.org> wrote:

LGTM1

On 3/4/24 1:33 PM, Nicolás Peña wrote:

Contact emails

n...@chromium.org

Explainer

https://github.com/fedidcg/FedCM/issues/428 

A few lines summarizing this issue would be most useful when evaluating this and understanding what y'all want to ship.

In particular, it'd be useful to understand the request flow, what is the request's origin (as IIUC, we're talking about requests issued from the browser), and what is the request destination that we may want IDPs to check.

Examples of the checks IDPs would have to make would also be helpful.

Sure! From the spec, here is a sample request:

POST /fedcm_assertion_endpoint HTTP/1.1
Host: idp.example
Origin: https://rp.example/
Content-Type: application/x-www-form-urlencoded
Cookie: 0x23223
Sec-Fetch-Dest: webidentity
account_id=123&client_id=client1234&nonce=Ct60bD&disclosure_text_shown=true

 

With this change, Sec-Fetch-Mode will now be cors in this request and the IDP is expected to return the following in the response (no preflight is performed):

Do you mean Sec-Fetch-Dest?

 

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/a349c863-9904-491f-9e9d-31227683d4ffn%40chromium.org.

[Nicolás Peña]

No, Sec-Fetch-Dest is not changing. Sec-Fetch-Mode is.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a349c863-9904-491f-9e9d-31227683d4ffn%40chromium.org.

[Yoav Weiss (@Shopify)]

<owner hat off>

I left a comment around potentially adding a CORS mode that would help IDP servers statically protect themselves from destination-change attacks. I don't *think* it's a blocker, but it's worth considering something along those lines to increase the solution's robustness to configuration errors, and ensure it fails closed. (and ask IDPs' security teams about their thoughts)

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

[Nicolás Peña Moreno]

Thanks for the suggestion, Yoav! It seems something fetch experts have some concerns about, so we do not plan to proceed with that suggestion at the moment.

I'd like to append a small addition to this I2S (mainly to avoid having an additional PSA since it is very related to this one): we would also like approval to only send Same-Site=None cookies in the accounts endpoint, instead of all cookies (so not Same-Site=Lax or Same-Site=Strict). This is also a breaking change but we do not anticipate IDPs to break, and also plan to work with them to ensure that they are aware of this change and are not caught by surprise.

[Mike Taylor]

On 3/12/24 11:33 AM, Nicolás Peña Moreno wrote:

Thanks for the suggestion, Yoav! It seems something fetch experts have some concerns about, so we do not plan to proceed with that suggestion at the moment.

I'd like to append a small addition to this I2S (mainly to avoid having an additional PSA since it is very related to this one): we would also like approval to only send Same-Site=None cookies in the accounts endpoint, instead of all cookies (so not Same-Site=Lax or Same-Site=Strict). This is also a breaking change but we do not anticipate IDPs to break, and also plan to work with them to ensure that they are aware of this change and are not caught by surprise.

To my non-FedCM expert brain, this doesn't feel like a small addition (happy to be wrong!), beyond not understanding the scale of the risk, the normal process questions come to mind i.e., is it specced, do we have tests, what do other vendors think about it?

[Nicolás Peña]

Regarding risk: we are going to implement this and test the IDPs we know are currently using FedCM, but we do not anticipate them to break since they are currently already relying on using third-party cookies in iframes. We also plan to have developer outreach/blogpost for this change so developers currently testing out FedCM are not caught by surprise.

Regarding vendor alignment: we have been working with Firefox and Apple to align on the correct behavior of the FedCM fetches: see https://github.com/fedidcg/FedCM/issues/320 and https://github.com/fedidcg/FedCM/issues/428. This I2S is a result of a lot of discussions, and the small addition was a result of a very recent discussion occurring on our FedCM CORS breakout session.

Regarding spec, during our breakout Anne also mentioned that the small addition is not possible to specify properly, as it depends on the ongoing cookie layering work. I will add a note on the spec in that fetch so IDPs know which cookies should be sent.

Anyways, I understand it is a bit late to add something to this I2S so if you prefer that we send a separate I2S/PSA for the SameSite change, we can do that instead.

[Yoav Weiss (@Shopify)]

On Tuesday, March 12, 2024 at 3:11:24 PM UTC-4 Nicolás Peña wrote:

Regarding risk: we are going to implement this and test the IDPs we know are currently using FedCM, but we do not anticipate them to break since they are currently already relying on using third-party cookies in iframes. We also plan to have developer outreach/blogpost for this change so developers currently testing out FedCM are not caught by surprise.

Regarding vendor alignment: we have been working with Firefox and Apple to align on the correct behavior of the FedCM fetches: see https://github.com/fedidcg/FedCM/issues/320 and https://github.com/fedidcg/FedCM/issues/428. This I2S is a result of a lot of discussions, and the small addition was a result of a very recent discussion occurring on our FedCM CORS breakout session.

Regarding spec, during our breakout Anne also mentioned that the small addition is not possible to specify properly, as it depends on the ongoing cookie layering work. I will add a note on the spec in that fetch so IDPs know which cookies should be sent.

Anyways, I understand it is a bit late to add something to this I2S so if you prefer that we send a separate I2S/PSA for the SameSite change, we can do that instead.

Is the accounts endpoint the same endpoint to which this intent applies? Or is it different from the ID assertion endpoint?

If it's different, a separate I2S would be best. If it's the same, then I think we can probably fold it into this intent.

 

On Tuesday, March 12, 2024 at 1:34:56 PM UTC-4 Mike Taylor wrote:

On 3/12/24 11:33 AM, Nicolás Peña Moreno wrote:

Thanks for the suggestion, Yoav! It seems something fetch experts have some concerns about, so we do not plan to proceed with that suggestion at the moment.

Thanks for considering! Anne makes a good point that active defense here (by filtering requests based on destination) would work better against timing attacks than passive defense (where the responses are blocked by the browser). Please make sure that IDPs are aware of the destination filtering requirement, by having it emphasized in developer facing documentation.

[Nicolás Peña]

On Wednesday, March 13, 2024 at 7:37:29 AM UTC-4 Yoav Weiss wrote:

On Tuesday, March 12, 2024 at 3:11:24 PM UTC-4 Nicolás Peña wrote:

Regarding risk: we are going to implement this and test the IDPs we know are currently using FedCM, but we do not anticipate them to break since they are currently already relying on using third-party cookies in iframes. We also plan to have developer outreach/blogpost for this change so developers currently testing out FedCM are not caught by surprise.

Regarding vendor alignment: we have been working with Firefox and Apple to align on the correct behavior of the FedCM fetches: see https://github.com/fedidcg/FedCM/issues/320 and https://github.com/fedidcg/FedCM/issues/428. This I2S is a result of a lot of discussions, and the small addition was a result of a very recent discussion occurring on our FedCM CORS breakout session.

Regarding spec, during our breakout Anne also mentioned that the small addition is not possible to specify properly, as it depends on the ongoing cookie layering work. I will add a note on the spec in that fetch so IDPs know which cookies should be sent.

Anyways, I understand it is a bit late to add something to this I2S so if you prefer that we send a separate I2S/PSA for the SameSite change, we can do that instead.

Is the accounts endpoint the same endpoint to which this intent applies? Or is it different from the ID assertion endpoint?

If it's different, a separate I2S would be best. If it's the same, then I think we can probably fold it into this intent.

This change is to the ID assertion endpoint, which is different from the accounts endpoint. Then based on your comment, we will keep those two in separate intents. Consider the small addition I suggested above removed.

 

 

On Tuesday, March 12, 2024 at 1:34:56 PM UTC-4 Mike Taylor wrote:

On 3/12/24 11:33 AM, Nicolás Peña Moreno wrote:

Thanks for the suggestion, Yoav! It seems something fetch experts have some concerns about, so we do not plan to proceed with that suggestion at the moment.

Thanks for considering! Anne makes a good point that active defense here (by filtering requests based on destination) would work better against timing attacks than passive defense (where the responses are blocked by the browser). Please make sure that IDPs are aware of the destination filtering requirement, by having it emphasized in developer facing documentation.

Yes, we will work with devrel to continue ensuring IDP best practices are easily discoverable.

[Yoav Weiss (@Shopify)]

LGTM1 to ship the ID assertion endpoint CORS requirements. 

[Yoav Weiss (@Shopify)]

LGTM2 actually..

[Christian Biesinger]

On Tue, Mar 12, 2024 at 1:34 PM Mike Taylor <mike...@chromium.org> wrote:
>
> On 3/12/24 11:33 AM, Nicolás Peña Moreno wrote:
>
> Thanks for the suggestion, Yoav! It seems something fetch experts have some concerns about, so we do not plan to proceed with that suggestion at the moment.
>
> I'd like to append a small addition to this I2S (mainly to avoid having an additional PSA since it is very related to this one): we would also like approval to only send Same-Site=None cookies in the accounts endpoint, instead of all cookies (so not Same-Site=Lax or Same-Site=Strict). This is also a breaking change but we do not anticipate IDPs to break, and also plan to work with them to ensure that they are aware of this change and are not caught by surprise.
>
> To my non-FedCM expert brain, this doesn't feel like a small addition (happy to be wrong!), beyond not understanding the scale of the risk, the normal process questions come to mind i.e., is it specced, do we have tests, what do other vendors think about it?

So I realized that a significant point was perhaps lost in the
argument for why this is a small change: because of how CORS works,
this change implicitly changes the *id assertion* endpoint to only
send SameSite=None cookies (and not send SameSite=Strict cookies).

Because of this change to the ID assertion endpoint, it seems like a
small change to *also* change the accounts endpoint to send the same
cookies. It is a small change because sending the same cookies in both
requests seems like a no-brainer -- the chance of an IDP expecting
different cookies for these two requests seems really low.

However, let me know if you want me to proceed with a new I2S for the
account endpoint cookies anyway.

(please also consider this as a ping for an lgtm3...)

Thanks,
Christian

>>>>> 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/1814484e-4a0c-4210-b936-29ead46f32c5n%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/91c26d40-ccc9-4abe-bf97-38cd9e48f684%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/a349c863-9904-491f-9e9d-31227683d4ffn%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/d0e70684-ee33-4e44-9ec3-6fcf3f0e96d3%40chromium.org.

[Daniel Bratell]

LGTM3

I'm also a bit concerned with the risk, but it sounds like you have it under control and will be able to handle the rollout appropriately.

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohS%2BpVCGJ-mtXpG1oT7VWPv9YhQqh%2BpPipFDhBwmoiTBLsQ%40mail.gmail.com.

[Nicolás Peña Moreno]

Thanks all! This is shipping in Chrome 125.