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: minimalist attempt at a fix for
Thanks for the review NAME I've incorporated all your suggestions.
Thanks NAME and NAME I dare say it's okay merge? (thinking about the I-D submission cutoff in a few hours but admittedly don't know what else could/should go into -15 or if publishing that today is even on the table)
I don't believe this example given in particularity well reflects the situation that precipitated the behavior described in : It's only an explanatory example so arguably doesn't even really matter. But RFCs are forever and they are often cited so it'd be nice to have this bit of the historical narrative better reflect the realities at the time (I say this mostly from perspective of having experienced some of the difficulties caused by the introduction of SameSite cookies and their default enforcement mode and, to this day, continuing to have challenging conversations on the topic). As best I can recall, login type flows were the main driver for the "Lax-allowing-unsafe" default mode but the need manifested itself more in the later part of the flow where the authenticating site (IDP) caused the browser to make a POST request callback to the site requesting authentication (RP). At the start of the flow, prior to sending the user to the IDP, the RP would typically set a cookie with or referencing some transaction specific state and use that info during processing of the callback for validation of the token provided by the IDP. Cookies with Lax as the default enforcement mode would not be sent with the callback POST request and the whole login flow would fail. The "Lax-allowing-unsafe" default mode (aka "Lax + POST mitigation") allowed those flows to not break for a while and gave RPs (and their vendors, frameworks, etc.) a little grace period to update to explicitly designate those cookies as SameSite=None. Could we augment or replace the example described in to account for all that? The cookie age stuff in , I think, makes more sense in the context of the above too. I'm (obviously) having trouble articulating some of this so including some "helpful links" here too, which may or may not describe some of this better.