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 <https://www.w3.org/2024/03/breakouts-day-2024/#b-15220813-651d-4795-98ae-a17434c1e50f> . 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 <https://github.com/fedidcg/FedCM/pull/550> 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. 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. 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? On Monday, March 11, 2024 at 6:39:14 AM UTC-4 Yoav Weiss wrote: <owner hat off> I left a comment <https://github.com/fedidcg/FedCM/issues/428#issuecomment-1980469172> 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) On Wed, Mar 6, 2024 at 5:51 PM Nicolás Peña <n...@chromium.org> wrote: No, Sec-Fetch-Dest <https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-Fetch-Dest> is not changing. Sec-Fetch-Mode <https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-Fetch-Mode> is. On Wednesday, March 6, 2024 at 11:31:35 AM UTC-5 Chris Harrelson wrote: 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 <https://fedidcg.github.io/FedCM/#idp-api-id-assertion-endpoint>, 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? Access-Control-Allow-Origin: https://rp.example/ Access-Control-Allow-Credentials: true Also, is the "identity assertion" endpoint the same as the token endpoint <https://github.com/fedidcg/FedCM/blob/main/explainer.md#token_endpoint>? Yea. I think that explainer doc is not super up to date. 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 <https://g-issues.chromium.org/issues?q=status:open%20componentid:1456331&pli=1&authuser=0> 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/Fed CM/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://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> ? 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 <https://chromestatus.com/>. -- 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/ch romium.org/d/msgid/blink-dev/1814484e-4a0c-4210-b936-29ead4 6f32c5n%40chromium.org <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1814484e-4a0c-4210-b936-29ead46f32c5n%40chromium.org?utm_medium=email&utm_source=footer> . -- 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/ch romium.org/d/msgid/blink-dev/91c26d40-ccc9-4abe-bf97-38cd9e 48f684%40chromium.org <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/91c26d40-ccc9-4abe-bf97-38cd9e48f684%40chromium.org?utm_medium=email&utm_source=footer> . -- 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 <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a349c863-9904-491f-9e9d-31227683d4ffn%40chromium.org?utm_medium=email&utm_source=footer> . -- 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/736232c3-ae2b-45c0-b2aa-4aee6226db1dn%40chromium.org.
