LGTM2
On Wed, Apr 24, 2024 at 9:29 AM Yoav Weiss (@Shopify)
<yoavwe...@chromium.org> wrote:
LGTM1
On Wed, Apr 24, 2024 at 5:46 PM Christian Biesinger
<cbiesin...@chromium.org> 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)
<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
<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
<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
<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
<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
<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/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 blink-dev+unsubscr...@chromium.org.
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
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw9oOzx-5fYojNYZZHKK2ZAxyW60uUknRqRx8TzkX4q_Ew%40mail.gmail.com?utm_medium=email&utm_source=footer>.
