Harmonizing draft-west-cookie-prefixes-05 with the web origin concept

== Issues with draft-west-cookie-prefixes-05 ==

1) As currently written, the __Secure- prefix is not as secure as the
__Host- prefix because it supports the Domain attribute.  For example, if
you wanted to recommend the most secure way to use cookies (including this
feature), you'd recommend using __Host- rather than __Secure-.  In order
for the names of the protocol elements to be self-describing, we should use
__Secure- for the most secure option.

2) Even with these extensions, there's still no way to use cookies in a way
that matches the web origin concept.  Specifically, even if you use __Host-
and set all the attribute correctly, your cookies are still shared between
all the ports on a given host, which is different than web origins because
web origins are determined by the scheme, host, and port.  Security
problems commonly arise because these sorts of "cracks" between different
security models.  For better security, there should be a way to use cookies
with a security model that matches up with web origins.

== Proposal ==

I'm sure there will be endless bikeshedding about the syntax for cookie
prefixes, but I'd like to make a proposal for a slightly different syntax
(with different semantics) that addresses the issues I've raised above:

Set-Cookie: ['self']-SID=12345; Secure; Path=/
Set-Cookie: [*.example.com]-SID=12345; Secure; Domain=example.com
Set-Cookie: [*.example.com:*]-SID=12345; Secure; Domain=example.com
Set-Cookie: [/foo/bar]-SID=12345; Secure; Path=/foo/bar

In this approach, the cookie prefix indicates the scope of the cookie:

 * In the first example, the prefix ['self']- restricts the scope of the
cookie to the scheme, host, and port from which the cookie was set.
 * In the second example, the cookie's scope is example.com and all of its
subdomains, but restricted to the original port.
 * In the third example, the scope is expanded to include all the ports.
 * In the fourth example, the scope is the current scheme, host, and port
as well as the path /foo/bar.

I've borrowed the syntax from CSP's source-list: <
http://www.w3.org/TR/CSP2/#source-list-syntax>.  Specifically, the grammar
for what goes inside the brackets would be roughly:

"'self'" / host-source / path-part

Obviously, we can continue to bikeshed the syntax, but this syntax also
lets you use a short sequence when you want to match the web origin
exactly: [/]-

More controversially, we might want to make these prefixes *authoritative*
for the scope, meaning they would override any scope-related cookie
attributes.  In the near term, we would still recommend that servers send
the cookie attributes as well as the prefixes, but having the prefixes
override the attributes gives us the flexibility in the future to
depreciate the scoping attributes.

Adam