CHIPS: Need Partitioned flag for CookieOptions

[explunit]

Microsoft.Owin.CookieOptions lacks the Partitioned flag needed to support CHIPS:
https://developers.google.com/privacy-sandbox/blog/cookie-countdown-2023oct

[blowdart]

This project is not in active development.

We make only critical security and compatibility fixes here.

All feature development has moved to ASP.NET Core which already has an issue for this - dotnet/aspnetcore#53224

[jeffshirley]

I’d argue that this qualifies as a critical compatibility issue.

[explunit]

For anybody else who finds this issue later...

It's not as simple as a middleware that intercepts outgoing headers and adds ; Partitioned to certain Set-Cookie statements. That's only half the solution.

Regular cookie expiry from OWIN (e.g. owinContext.Response.Cookies.Delete( cookieName ) does not use Secure, SameSite, etc. even if the original cookie was created with it, for example:

Let's say the original cookie was created like this:
Set-Cookie: MyCookieName=somevalue; path=/foo; HttpOnly; Secure; SameSite=None

The call to owinContext.Response.Cookies.Delete( cookieName ) will generate a response header like this:
Set-Cookie: MyCookieName=; path=/foo; expires=Thu, 01-Jan-1970 00:00:00 GMT

This apparently works fine for clearing non-partitioned cookies, but not for partitioned ones. For those we have to do more like:
Set-Cookie: MyCookieName=; path=/foo; expires=Thu, 01-Jan-1970 00:00:00 GMT; Secure; SameSite=None; Partitioned

But of course we have no way of knowing from the server side which variant the browser has in storage, so we have to send both kinds of Set-Cookie for the same cookie name. And since "session" cookies live forever these days, we have to assume the old ones are hanging around out there.

Also, I agree with @jeffshirley -- when a browser with the majority of the web traffic switches their standard, it's a critical compatibility issue.