LGTM2 On Wed, Apr 24, 2024 at 9:29 AM Yoav Weiss (@Shopify) < [email protected]> wrote:
> LGTM1 > > On Wed, Apr 24, 2024 at 5:46 PM Christian Biesinger < > [email protected]> wrote: > >> 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) >> > > Yeah, I'm convinced that this entire area is not currently specified, and > that y'all are making strides towards that, and we shouldn't block this > particular change on them. > I just wanted to verify that what y'all are planning to ship aligns with > my understanding of what we'd want to eventually specify here. > > >> >> with regards to the implementation: We do not send SameSite=Lax cookies >> > > That makes sense. Thanks! > > >> >> Christian >> >> On Wed, Apr 24, 2024 at 11:04 AM Yoav Weiss (@Shopify) < >> [email protected]> 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 < >>>> [email protected]> 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 < >>>>> [email protected]> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Wed, Apr 17, 2024 at 10:13 PM Domenic Denicola < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, Apr 18, 2024 at 6:19 AM Christian Biesinger < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> Contact emails >>>>>>>> >>>>>>>> [email protected] >>>>>>>> >>>>>>>> >>>>>>>> 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 [email protected]. >>>>>>>> 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 [email protected]. >>>>> >>>> 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSJ7OT1oD2BKAFBcpxr8A5%2BaArcr%3DF5q-oTHdBizC3cUNQ%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSJ7OT1oD2BKAFBcpxr8A5%2BaArcr%3DF5q-oTHdBizC3cUNQ%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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw9oOzx-5fYojNYZZHKK2ZAxyW60uUknRqRx8TzkX4q_Ew%40mail.gmail.com.
