Re: "Origin locked" cookie prefix - draft-ietf-httpbis-rfc6265bis-06

Hi Paolo,

Are you familiar with the __Host prefix?[1]

Describing what you want to do in relation to it might be more helpful.

Also, from a procedural standpoint, we have a pretty high bar for adding new features to cookies in the current work; the proposals that are current in-scope needed to gain consensus for inclusion before we started the work. So, we'd need to see some pretty strong support for a new feature, given the state of the work.



> On 5 Sep 2020, at 12:44 pm, Paolo Argentieri <> wrote:
> Hi all, first post here.
> I'd like to propose a new "__Origin-" cookie prefix with "origin locked" semantic.
> While it is possible to implement these cookies today, standardized user agent support would add a layer of optimization and security.
> The cookie name begins with prefix "__Origin-" followed by the domain that served the parent page (the origin) and, optionally, a name postfix. Example:
> Set-Cookie:; Secure; HttpOnly; SameSite=None
> A conformant user agent would ensure that the cookie will have been set with a "Secure" attribute and the domain following "__Origin-" matches the request Origin.
> In addition, a conformant user agent would not send an "__Origin-" cookie if the domain in the cookie name does not match the Origin, excluding port.
> A server should ignore "__Origin-"  cookies whose name doesn't match the Origin request header. This combination yields cookies that are pinned to a specific origin thus well suited to roundtrip session ids or JWTs (immune to XSS session hijacking attack).
> Regards,
> Paolo Argentieri

Mark Nottingham

Received on Monday, 7 September 2020 07:49:59 UTC