[Openid-specs-ab] 3rd party and SameSite cookies (was Browser Interactions STC - Meeting Notes - 2021-05-05)

Sat May 8 18:55:40 UTC 2021

their efforts at collaboration are documented here
https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-rfc6265bis-07

This is all mixed up (even more) by the cross-origin HTTP flags. Which i
have been (trying) to document here
https://tcwiki.azurewebsites.net/index.php?title=Cross-Origin_iFrame

Be the change you want to see in the world ..tom

On Fri, May 7, 2021 at 10:44 PM David Waite via Openid-specs-ab <
openid-specs-ab at lists.openid.net> wrote:

> > (As best I understand it anyway) a previously set cookie with
> SameSite=None will be sent by the browser on such a top-level cross-site
> POST request. Some folks have suggested that that will change with 3rd
> party cookies going away and that even a SameSite=None cookie will no
> longer be sent in that situation. But in my mental model of this stuff, the
> situation will be unchanged by 3rd party cookies going away - it's a
> cross-site request but because it is a top-level navigation the cookies are
> 1st party. SameSite enforcement is in place so SameSite=None cookies will
> be sent. But it's not 3rd party so is not impacted by disappearance or
> partitioning of 3rd party cookies.
>
> SameSite applies in navigation capacities as well, e.g. the first HTTP
> request to the new site on link, redirect, or post. None and the temporary
> chromium default workaround behavior would be the only ones that would send
> state along with a HTTP POST. A world with just lax and strict would
> require more complex server acrobatics.
>
> I’m (also) not Sam, but I can try to supply a bit of color:
>
> SameSite is meant to limit state outside first-party contexts, e.g. limit
> XSRF-style attacks by having the browser not send state for request
> originating from outside your domain. It was NOT intended as a privacy
> restriction.
>
> SameSite is a per-cookie setting when interacting outside your current
> context. Examples would be cookies not being sent when following links,
> when being redirected, on cross-domain POSTs (manual or javascript) - in
> addition to embedded resources (images, iframes) and XHR/fetch.
>
> The current behaviors of SameSite are:
>
> Setting.            Behavior
> ---------               -----------
> None               Always send cookies
> Lax                  Send on ’Safe’ requests (GET, HEAD, OPTIONS)
> “Chromium”     Lax but send also on POST when cookie < 2 minutes old
> Strict                Never send
>
> Chromium-based applications will typically default to the implicit
> “Chromium” behavior if SameSite is not set and the cookie is set to Secure,
> otherwise Strict.  This temporary default behavior is specifically to avoid
> immediately breaking SSO software, but will still break if you need state
> older than two minutes - including if your login process winds up taking a
> bit longer due to a slow emailed OTP or mandatory password change.
>
> Other browsers have other defaults - they may default to None, or default
> to None only for Secure cookies. Chrome also unfortunately mandated
> SameSite=None for legacy behavior before it was part of any officially
> proposed standard - other browser makers did support it, but there are some
> not-super-old environments which have to be detected so you don’t send an
> illegal SameSite value of None (and thus have your attempt to set a cookie
> be rejected).
>
> My understanding is that even with Strict-mode causing cookies to be
> omitted on a cross-domain form post, the _next_ server response within the
> context of the domain will have these cookies sent. Catching the form and
> doing a redirect for processing would be one way to get state back.
>
> SameSite settings are meant to control cross-site usability of your
> domain, and are more in the family of CORS restrictions than privacy
> restrictions. However, it does make several tracker integration strategies
> more complex (e.g. javascript processing of inbound decorated links, XHR
> calls, iframe embedding)
>
> Restricting SameSite as a privacy setting brings up piles of edge cases
> that I just don’t know about. E.g.:
> - on first page load on a new site, would the javascript have cookie
> access?
> - would there be corresponding limitations for javascript access to local
> storage?
> - are cookies still settable, and does _that_ depend on same site at all?
> - wouldn’t leaving ‘lax’ as an option be a large loophole for data on GETs?
>
> As such, I suspect removing SameSite=None is really being talked about as
> a potential part of a suite of changes. Unfortunately, I have not found a
> reference to that for Chromium, let alone a reference that makes me think
> all browsers are collaborating on a gameplan in the open. If others know of
> one, please share!
>
> -DW
>
> > On May 7, 2021, at 3:37 PM, Brian Campbell via Openid-specs-ab <
> openid-specs-ab at lists.openid.net> wrote:
> >
> > My apologies for joining this call late and in the middle of discussions
> on a topic that I'm hoping to reconcile understanding on. I said I'd send a
> message seeking clarification on that topic. So here is that message. But
> I'm struggling to articulate it so please bear with me.
> >
> > In identity protocols, a cross-site navigation resulting in a POST
> request is typically happens by the first site returning an HTML page that
> has a form that is auto-submitted via javascript to the second site. That's
> how SAML Post binding works. And so does the OIDC/OAuth form post response
> mode.
> >
> >
> > Anyway, that's what I'm hoping Sam can provide clarification on. Mostly
> for the benefit of my own understanding but also for the benefit of the
> group here as recent discussions have suggested that folks have divergent
> understanding and expectations of things.
> >
> > That behaviour changing would be problematic, for example and as others
> have pointed out, because OIDC RPs receiving an ID token via the form post
> response mode need the 'nonce cookie' value (which ties the ID token to the
> browser the SSO flow was initiated on) at that point in validating the
> token. Maybe further confusing things is that at least in Chrome there was
> a temporary(?) exception made for the nonce cookie case with the rollout of
> the SameSite default change to Lax - the "Lax + POST mitigation" section at
> https://www.chromium.org/updates/same-site/faq and it looks like there's
> an attempt to capture that in the coming update to RFC 6265
> https://github.com/httpwg/http-extensions/pull/1435/files
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > On Wed, May 5, 2021 at 12:49 PM Tim Cappalli via Openid-specs-ab <
> openid-specs-ab at lists.openid.net> wrote:
> > Hey all,
> >
> > Here are the meeting notes from today's special topic call. Please feel
> free to add or correct anything.
> >
> > openid / connect / wiki / Browser Interactions Special Topics Call -
> 20210505 — Bitbucket
> >
> > Next meeting is in two weeks on May 19th (UTC).
> >
> > Tim
> >
> > _______________________________________________
> > Openid-specs-ab mailing list
> > Openid-specs-ab at lists.openid.net
> > http://lists.openid.net/mailman/listinfo/openid-specs-ab
> >
> > CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you._______________________________________________
> > Openid-specs-ab mailing list
> > Openid-specs-ab at lists.openid.net
> > http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20210508/f0ecc1ed/attachment.html>