Hi Yoav, with regards to the spec: As Johann suggests, this can't really be specified today and I am hoping we won't block on that as he suggests. (the cookie spec linked from the fetch spec does not mention SameSite at all... https://httpwg.org/specs/rfc6265.html#cookie)
with regards to the implementation: We do not send SameSite=Lax cookies Christian On Wed, Apr 24, 2024 at 11:04 AM Yoav Weiss (@Shopify) < yoavwe...@chromium.org> wrote: > fetch-accounts <https://fedidcg.github.io/FedCM/#fetch-accounts> says > that the origin for accounts requests is an opaque origin. What does that > mean for `Same-Site: Lax` cookies? Will they be sent or not? > > On Tuesday, April 23, 2024 at 9:08:33 PM UTC+2 Johann Hofmann wrote: > >> I wanted to chime in on fetch + cookies integration: Yes, it's very >> underspecified >> <https://fetch.spec.whatwg.org/#http-network-or-cache-fetch:~:text=If%20includeCredentials%20is%20true%2C%20then%3A> >> and leaves the computation of the actual SameSite status of cookies >> included in the request to the cookies RFC >> <https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-rfc6265bis/#name-same-site-and-cross-site-re>. >> This needs work on Fetch, 6265bis, HTML and Cookie Store specs (and now >> also needs to consider 3PC blocking!) which we're actively doing right now >> and hope to have some progress to share soon. I would not want to block >> this feature on it (and we haven't blocked other features in the past). I >> would expect the FedCM spec to adjust to the cookie layering work once that >> lands, and can work with the team to make sure that happens. >> >> Hope this helps, >> >> Johann >> >> On Tue, Apr 23, 2024 at 8:05 PM Christian Biesinger < >> cbiesin...@chromium.org> wrote: >> >>> Just wanted to ping this thread -- any lgtms? Or will it be discussed at >>> tomorrow's meeting? >>> >>> Christian >>> >>> On Thu, Apr 18, 2024 at 11:31 AM Christian Biesinger < >>> cbiesin...@chromium.org> wrote: >>> >>>> >>>> >>>> On Wed, Apr 17, 2024 at 10:13 PM Domenic Denicola <dome...@chromium.org> >>>> wrote: >>>> >>>>> >>>>> >>>>> On Thu, Apr 18, 2024 at 6:19 AM Christian Biesinger < >>>>> cbiesin...@chromium.org> wrote: >>>>> >>>>>> Contact emails >>>>>> >>>>>> cbiesin...@chromium.org >>>>>> >>>>>> >>>>>> Explainer >>>>>> >>>>>> See summary >>>>>> >>>>>> >>>>>> Specification >>>>>> >>>>>> https://fedidcg.github.io/FedCM/#fetch-identity-assertion >>>>>> >>>>> >>>>> I wasn't able to find the part of the spec that talks about which >>>>> cookies are sent. Probably I just don't understand Fetch + cookies >>>>> integration well enough. Could you help point it out? Or maybe link to the >>>>> PR that makes the change? >>>>> >>>> >>>> It turns out our implementation did not match the spec in this respect, >>>> so there was no PR (just an impl change). >>>> >>>> It is probably me who does not understand the fetch + cookies >>>> integration, but my thinking is that because we give an origin to the fetch >>>> algorithm (the RP's origin), which is not same-site with the identity >>>> provider (normally), fetch should not send SameSite=Strict cookies. >>>> >>>> Also cc'ing Dominic (Farolino) who has helped us in this area. >>>> >>>> [You may ask, what happens if the RP is indeed same-site with the IDP? >>>> I think we would send SameSite=Strict cookies in that situation, but that >>>> case is rare] >>>> >>>> Christian >>>> >>>> >>>>> >>>>> >>>>>> >>>>>> Summary >>>>>> >>>>>> We recently changed >>>>>> <https://chromestatus.com/feature/5094763339710464> FedCM to send ID >>>>>> assertion requests with CORS. As a side-effect, that change also meant >>>>>> that >>>>>> we no longer send SameSite=Strict cookies to the ID assertion endpoint >>>>>> (we >>>>>> still send SameSite=None). Since it does not make sense to send a >>>>>> different >>>>>> set of cookies to the accounts endpoint and the ID assertion endpoint, >>>>>> this >>>>>> change makes them consistent – they both should get the same credentials >>>>>> as >>>>>> they identify the user in the same way. >>>>>> >>>>>> Not sending SameSite=Strict cookies is also consistent with >>>>>> requestStorageAccess >>>>>> behavior >>>>>> <https://developers.google.com/privacy-sandbox/3pcd/related-website-sets-integration#cookie_requirements> >>>>>> and cross-site requests in general. >>>>>> Blink component >>>>>> >>>>>> Blink>Identity>FedCM >>>>>> <https://issues.chromium.org/issues?q=status:open%20componentid:1456331&s=created_time:desc> >>>>>> Search tags >>>>>> >>>>>> fedcm <https://chromestatus.com/features#tags:fedcm>, samesite >>>>>> <https://chromestatus.com/features#tags:samesite>, cookies >>>>>> <https://chromestatus.com/features#tags:cookies> >>>>>> >>>>>> >>>>>> TAG review >>>>>> >>>>>> None >>>>>> >>>>>> >>>>>> TAG review status >>>>>> >>>>>> Not applicable >>>>>> >>>>>> >>>>>> Risks >>>>>> >>>>>> >>>>>> >>>>>> Interoperability and Compatibility >>>>>> >>>>>> There should be no interop risk because no other browser has shipped >>>>>> FedCM yet and this change was requested by Webkit, with Gecko supporting >>>>>> the request. >>>>>> >>>>>> With regards to compatibility, we have tested the known IDPs that use >>>>>> FedCM and this is not an issue. In addition, for any IDP that supports >>>>>> "Sign in with X" on the web without FedCM, cookies must already be >>>>>> SameSite=None because these requests are cross-origin by definition. >>>>>> >>>>>> Gecko: Positive. Change supported by Gecko >>>>>> (https://github.com/fedidcg/FedCM/issues/320#issassessment >>>>>> the team has done assessment the team has done uecomment-2012070115 >>>>>> <https://github.com/fedidcg/FedCM/issues/320#issuecomment-2012070115>). >>>>>> Not filing a standards position request for small additions at the >>>>>> explicit >>>>>> request from Firefox (they prefer PRs). >>>>>> >>>>>> WebKit: Positive. Change requested by WebKit (in a VC, no link >>>>>> available). 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: >>>>>> >>>>>> >>>>>> 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 >>>>>> >>>>>> None >>>>>> >>>>>> >>>>>> >>>>>> Will this feature be supported on all six Blink platforms (Windows, >>>>>> Mac, Linux, ChromeOS, Android, and Android WebView)? >>>>>> >>>>>> No >>>>>> >>>>>> Supported on all platforms except Webview, where FedCM is not >>>>>> supported in general >>>>>> >>>>>> >>>>>> >>>>>> Is this feature fully tested by web-platform-tests >>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>>>> ? >>>>>> >>>>>> Yes: >>>>>> https://wpt.fyi/results/credential-management/fedcm-same-site-none/fedcm-same-site-none.https.html?label=experimental&label=master&aligned >>>>>> >>>>>> >>>>>> >>>>>> Flag name on chrome://flags >>>>>> >>>>>> None >>>>>> >>>>>> >>>>>> Finch feature name >>>>>> >>>>>> FedCmSameSiteNone >>>>>> >>>>>> >>>>>> Requires code in //chrome? >>>>>> >>>>>> False (but FedCM in general does) >>>>>> >>>>>> >>>>>> Tracking bug >>>>>> >>>>>> https://crbug.com/329145816 >>>>>> >>>>>> >>>>>> Estimated milestones >>>>>> >>>>>> Shipping on desktop >>>>>> >>>>>> 125 if possible, otherwise 126 >>>>>> >>>>>> DevTrial on desktop >>>>>> >>>>>> 124 >>>>>> >>>>>> Shipping on Android >>>>>> >>>>>> 125 if possible, otherwise 126 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> 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/5092883024838656 >>>>>> >>>>>> >>>>>> 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/CAPTJ0XGWV%3Dw4So1cgzyMonge2_3aSAHYUJuRnY98vHD%3DDDOZhg%40mail.gmail.com >>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPTJ0XGWV%3Dw4So1cgzyMonge2_3aSAHYUJuRnY98vHD%3DDDOZhg%40mail.gmail.com?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/CAPTJ0XFRwwWmpJHVP1Y%3Dh1vBP4WemS9b1DtEaR07uK%2Bfi9sEpg%40mail.gmail.com >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPTJ0XFRwwWmpJHVP1Y%3Dh1vBP4WemS9b1DtEaR07uK%2Bfi9sEpg%40mail.gmail.com?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/CAPTJ0XF4vv%2Bjw3KszQhYDT%2B8QZzXSVFdNxSsee82qN9WiWq_fg%40mail.gmail.com.
