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.

Cheers,

1. https://httpwg.org/http-extensions/draft-ietf-httpbis-rfc6265bis.html#the-host-prefix



> On 5 Sep 2020, at 12:44 pm, Paolo Argentieri <paolo.argentieri@laserfiche.com> 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: __Origin-apps.contoso.com-accessToken=12345; 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   https://www.mnot.net/

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