HTTP State Tokens
A new Internet draft by Google's security architect Mike West proposes to replace current HTTP cookies RFC 6295 with a new state mechanism that can be only described as "return to the roots".
HTTP cookies have many problems, but the main ones are that they have so many options that they are usually implemented insecurely, they often are bulky and that they enable third-party tracking. The draft-west-http-state-tokens-latest draft proposes a mechanism based on HTTP header
Sec-Http-State which would pass a random session token to the server, pretty much as modern session cookies do.
There's however a number of key differences:
- The client controls the token’s value, not the server.
- The user agent will generate only one token per origin, and will only expose the token to the origin for which it was generated.
- Tokens will not be generated for, or delivered to, non-secure origins.
- By default, token delivery and configuration is constrained to same-site requests.
- Each token persists for one hour after generation by default. This default expiration time can be overwritten by servers, and tokens can be reset at any time by servers, users, or user agents.