Code change:
requests with "unsafe" HTTP methods (as was the case prior to the introduction of the "SameSite" attribute). <del> For example, a login flow may involve a cross-site top-level "POST" request to an endpoint which expects a cookie with login information. For such a cookie, "Lax" enforcement is not appropriate, as it would cause the cookie to be excluded due to the unsafe HTTP request method.  On the other hand, "None" enforcement would allow the cookie to be sent with all cross-site requests, which may not be desirable due to the cookie's sensitive contents. </del> <ins> For example, the concluding step of a login flow may involve a cross- site top-level "POST" request to an endpoint; this endpoint expects a recently created cookie containing transactional state information, necessary to securely complete the login.  For such a cookie, "Lax" enforcement is not appropriate, as it would cause the cookie to be excluded due to the unsafe HTTP request method, resulting in an unrecoverable failure of the whole login flow. </ins> The "Lax-allowing-unsafe" enforcement mode described in lax-allowing- unsafe retains some of the protections of "Lax" enforcement (as <del> compared to "None") while still allowing cookies to be sent cross- site with unsafe top-level requests. </del> <ins> compared to "None") while still allowing recently created cookies to be sent cross-site with unsafe top-level requests. </ins> As a more permissive variant of "Lax" mode, "Lax-allowing-unsafe" mode necessarily provides fewer protections against CSRF.

Related discussion:
text: For someone who is not super familiar with SAML authentication flows ( , it's me), what exists in the draft text today feels like a fuzzier higher-level description than: It's entirely possible that's the only pattern that motivated Lax-allowing-unsafe, but maybe not - the web is messy. Maybe a compromise here is to tweak the text to cover your example generally (as well as other examples sitauations to ~POST w/ a cookie expecting some login information), and go super precise in the commit message. Just a thought.
It'd be a bit more involved than just the first sentence but I'm happy to take a stab at reworking that paragraph and maybe a few other very minor related things, if the authors/WG are amenable to the idea? Not to be expected :) The OpenID Connect flow is probably more salient but familiarity there isn't expected either. The important distinction (to me anyway) is where the cookie in question would be sent (or not sent), the associated failure mode, and the effectiveness of the mitigating default mode. With what exists in the draft text today, the cookie is holding/referencing login state that's sent to the site that will authenticate the user (maybe based on an existing session identified by that cookie). If the cookie isn't sent (due to default of Lax and a x-site POST style redirect), the failure mode will usually be the user needing to enter their login credentials again. Which is annoying but recoverable. Also the Lax-allowing-unsafe applicability to "cookies which were created recently [~2 mins]" doesn't help in many many cases for cookie that's used for login state due to such cookies being relatively long lived (not created recently) and/or the user not having even visiting the site recently. With the pattern I'm (trying) to describe, the cookie is holding transactional state that's sent back to the site requesting authentication after user authentication. If the cookie isn't sent (due to default of Lax and a x-site POST style redirect back to the originating site), the failure mode will usually be an unrecoverable error for the whole login flow.