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.
