Re: [blink-dev] Intent to Ship: FedCM: Credentialed requests will no longer send SameSite=Strict cookies

[Christian Biesinger]

Thanks everyone for the approvals! This will ship in 125.

Christian

On Wed, Apr 24, 2024 at 3:30 PM Mike Taylor  wrote:

> LGTM3
> On 4/24/24 9:38 AM, Chris Harrelson wrote:
>
> 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  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
> 
> and leaves the computation of the actual SameSite status of cookies
> included in the request to the cookies RFC
> .
> 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
>  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 

Re: [blink-dev] Intent to Ship: FedCM: Credentialed requests will no longer send SameSite=Strict cookies

[Mike Taylor]

LGTM3

On 4/24/24 9:38 AM, Chris Harrelson wrote:

LGTM2

On Wed, Apr 24, 2024 at 9:29 AM Yoav Weiss (@Shopify) 
 wrote:


LGTM1

On Wed, Apr 24, 2024 at 5:46 PM Christian Biesinger
 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)
 wrote:

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


and leaves the computation of the actual SameSite
status of cookies included in the request to the
cookies RFC

.
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
 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  wrote:



On Wed, Apr 17, 2024 at 10:13 PM Domenic
Denicola  wrote:



On Thu, Apr 18, 2024 at 6:19 AM Christian
Biesinger  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 

Re: [blink-dev] Intent to Ship: FedCM: Credentialed requests will no longer send SameSite=Strict cookies

[Chris Harrelson]

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  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
 
 and leaves the computation of the actual SameSite status of cookies
 included in the request to the cookies RFC
 .
 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
  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
 

Re: [blink-dev] Intent to Ship: FedCM: Credentialed requests will no longer send SameSite=Strict cookies

[Yoav Weiss (@Shopify)]

LGTM1

On Wed, Apr 24, 2024 at 5:46 PM Christian Biesinger 
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  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
>>> 
>>> and leaves the computation of the actual SameSite status of cookies
>>> included in the request to the cookies RFC
>>> .
>>> 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
>>>  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
>>> 
>>> and cross-site requests in general.
>>> Blink component
>>>
>>> Blink>Identity>FedCM
>>> 

Re: [blink-dev] Intent to Ship: FedCM: Credentialed requests will no longer send SameSite=Strict cookies

[Christian Biesinger]

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  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
>> 
>> and leaves the computation of the actual SameSite status of cookies
>> included in the request to the cookies RFC
>> .
>> 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 
 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
>>  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
>> 
>> and cross-site requests in general.
>> Blink component
>>
>> Blink>Identity>FedCM
>> 
>> Search tags
>>
>> fedcm , samesite
>> , 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 

Re: [blink-dev] Intent to Ship: FedCM: Credentialed requests will no longer send SameSite=Strict cookies

[Yoav Weiss (@Shopify)]

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 
> 
>  
> and leaves the computation of the actual SameSite status of cookies 
> included in the request to the cookies RFC 
> .
>  
> 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  
>>> 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 
>  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 
> 
>  
> and cross-site requests in general.
> Blink component
>
> Blink>Identity>FedCM 
> 
> Search tags
>
> fedcm , samesite 
> , 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 

Re: [blink-dev] Intent to Ship: FedCM: Credentialed requests will no longer send SameSite=Strict cookies

['Johann Hofmann' via blink-dev]

I wanted to chime in on fetch + cookies integration: Yes, it's very
underspecified

and leaves the computation of the actual SameSite status of cookies
included in the request to the cookies RFC
.
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 
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 
>> 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 
 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
 
 and cross-site requests in general.
 Blink component

 Blink>Identity>FedCM
 
 Search tags

 fedcm , samesite
 , 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
 ).
 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

Re: [blink-dev] Intent to Ship: FedCM: Credentialed requests will no longer send SameSite=Strict cookies

[Christian Biesinger]

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 
> 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 
>>> 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
>>> 
>>> and cross-site requests in general.
>>> Blink component
>>>
>>> Blink>Identity>FedCM
>>> 
>>> Search tags
>>>
>>> fedcm , samesite
>>> , 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
>>> ).
>>> 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
>>> 
>>> ?
>>>
>>> Yes:
>>> https://wpt.fyi/results/credential-management/fedcm-same-site-none/fedcm-same-site-none.https.html?label=experimental=master
>>>
>>>
>>>
>>> Flag name on chrome://flags
>>>
>>> None
>>>
>>>
>>> Finch feature name
>>>
>>> FedCmSameSiteNone
>>>
>>>
>>> Requires code in //chrome?
>>>
>>> False 

Re: [blink-dev] Intent to Ship: FedCM: Credentialed requests will no longer send SameSite=Strict cookies

[Christian Biesinger]

On Wed, Apr 17, 2024 at 10:13 PM Domenic Denicola 
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 
>> 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
>> 
>> and cross-site requests in general.
>> Blink component
>>
>> Blink>Identity>FedCM
>> 
>> Search tags
>>
>> fedcm , samesite
>> , 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
>> ).
>> 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
>> 
>> ?
>>
>> Yes:
>> https://wpt.fyi/results/credential-management/fedcm-same-site-none/fedcm-same-site-none.https.html?label=experimental=master
>>
>>
>>
>> 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 

Re: [blink-dev] Intent to Ship: FedCM: Credentialed requests will no longer send SameSite=Strict cookies

[Domenic Denicola]

On Thu, Apr 18, 2024 at 6:19 AM Christian Biesinger 
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?


>
> Summary
>
> We recently changed 
> 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
> 
> and cross-site requests in general.
> Blink component
>
> Blink>Identity>FedCM
> 
> Search tags
>
> fedcm , samesite
> , 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
> ).
> 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
> 
> ?
>
> Yes:
> https://wpt.fyi/results/credential-management/fedcm-same-site-none/fedcm-same-site-none.https.html?label=experimental=master
>
>
>
> 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
> .
>
> --
> 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