Add support for Partitioned Cookies

[blowdart]

Is there an existing issue for this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

CookieBuilder should support the new Partitioned property from the CHIPS (Cookies Having Independent Partitioned State) spec. to avoid users having to fall back to the extensions property.

Both Chrome and Safari have indicated their support.

Describe the solution you'd like

A true or false property on CookieBuilder much like SameSite has today.

If the Paritioned property is set to true the cookie should be emitted with Partitioned;

Set-Cookie: Beans=baked; SameSite=None; Secure; HttpOnly; Path=/; Partitioned;

The Partioned attribute can only be used with a Secure attribute, and the spec says browsers MUST reject a partitioned cookie if Secure is not present, so the builder could throw an exception on build.

A cookie that does not have SameSite=None but is partitioned really isn't partitioned at all, it's not going to be seen by third parties, but in that case the spec says Browsers MAY, so a debug message may be useful in that circumstance to help users track down that mistake.

Additional context

No response

[ghost]

Thanks for contacting us.

We're moving this issue to the .NET 9 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[Ajay100000]

My company uses azure and we use partition cookies for our httponly cookies. However Azure is a problem as shown in the attached screenshot.

The Azure cookies need to be partitioned please.

[kimsey0]

If Partitioned is added to CookieBuilder and CookieOptions, it would also be nice to have it added to CookiePolicyOptions so it can be set automatically by the CookiePolicyMiddleware (UseCookiePolicy).

[blowdart]

@Ajay100000 Those cookies are not set by ASP.NET they are set by Azure Websites. We cannot change those. You should open a ticket for your Azure subscription asking for that feature.

[amcasey]

AFAICT, CookieBuilder, CookieOptions, and SetCookieHeaderValue cheerfully accept any combination of settings without complaint. The validation I can find for SameSite is in ResponseCookies and logs a warning.

[halter73]

@blowdart Has Firefox announced that it's going to support this? Given the simplicity of the Extensions workaround, and the fact that this is only supported by chromium-based browsers, and that the spec is only in expired draft currently, it's really tempting to hold off on adding this. We're just talking about being able to do this:

options.Cookie.Partitioned = true;

vs.

options.Cookie.Extensions.Add("partitioned");

What are we rushing here for? If nothing changes like we hope, options.Cookie.Extensions.Add("partitioned") will continue to work indefinitely.

[amcasey]

On MDN they seem to contrast it with their own related experiment and indicated that it's not (yet?) supported.

[amcasey]

@blowdart Has Firefox announced that it's going to support this? Given the simplicity of the Extensions workaround, and the fact that this is only supported by chromium-based browsers, and that the spec is only in expired draft currently, it's really tempting to hold off on adding this. We're just talking about being able to do this:

options.Cookie.Partitioned = true;

vs.

options.Cookie.Extensions.Add("partitioned");

What are we rushing here for? If nothing changes like we hope, options.Cookie.Extensions.Add("partitioned") will continue to work indefinitely.

It seems like all you're losing with the Extensions approach is a warning log if you use it incorrectly?

[amcasey]

In the event that we add support to aspnetcore before it's standardized, it feels like we'd still rather hold off on updating Katana until things are set in stone?

[amcasey]

#55371 is a viable fix with an approved API, but we're reluctant to lock in the name before the feature is standardized.