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. 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/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://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/ >>>> chromium.org/d/msgid/blink-dev/1814484e-4a0c-4210-b936- >>>> 29ead46f32c5n%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/ >>>> chromium.org/d/msgid/blink-dev/91c26d40-ccc9-4abe-bf97- >>>> 38cd9e48f684%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/ec0981ce-8c6c-4a6e-a8b7-1cdd57394e83n%40chromium.org.
