20190424 追記
IETFに提案仕様が提出されました
https://tools.ietf.org/html/draft-west-http-state-tokens-00
Cookieの様々な問題を解決するために、Webセキュリティー界隈で活躍されるMike West氏から「Tightening HTTP State Management」というCookieに変わるHTTPにおいてステートを扱う仕組みが提案されています。
現在はIETFのHTTPbis WGのMLに投稿されただけで仕様が正式にinternet-draftとして提出されたものではありません。まだまだどうなるかは全然わからない状態です。
この提案では、現在のCookieはセキュリティと非効率性とプライバシーの問題があると言っています。
現在のcookieは、Same-Origin-Policyとは異なりオリジンを超えて共有されたり、パスを指定して共有されたりもします。また、Secure属性やHttpOnly属性の利用率は10%以下であり、SameSite属性では0.06%以下となっています。使用されているデータ量も多く、ブラウザによる統計の中央値ではドメインあたり409バイト、99パーセンタイルでは4,601バイトにもなります。
Sec-HTTP-Stateヘッダ
Cookieの持つ様々な問題を解決するために、「Simple HTTP State Management Mechanism」の仕様では、ブラウザがセキュアなオリジン(HTTPS, WSS)にアクセスする際に256bitのトークンをSec-HTTP-Stateヘッダに付加して送信します。
Sec-HTTP-State: token=*J6BRKagRIECKdpbDLxtlNzmjKo8MXTjyMomIwMFMonM*
サーバはこのトークンを用いてステート管理を行うことになります。
このSec-HTTP-Stateヘッダは以下の特徴を持ちます。
- Clientがトークンを発行します
- このトークンはJavaScriptやService Workersからはアクセスできない
- この256bitのトークンはオリジン毎に生成され、そのオリジンのみに送信されます
- 非セキュアなオリジン(HTTP, WS)では生成されない
- same-siteへのリクエスト時のみ送信される(Third-Partyには送信されない)
- トークンはサーバ、ユーザ、ブラウザによってリセットされるまで保持される
もちろん、サーバ側からトークンを発行可能にするかなどの議論はされるでしょう。
Sec-HTTP-State-Optionsヘッダ
サーバ側からトークンのオプションを指定する事もできるようになっています。HTTPレスポンスでSec-HTTP-State-Optionsヘッダで指定します。すでにいくつか考えられています。
Cross-Siteアクセス
Sec-HTTP-State-Options: ..., delivery=cross-site, ...
Sec-HTTP-State-Options: ..., delivery=same-origin, ...
TTL
Sec-HTTP-State-Options: ..., ttl=3600, ...
Sec-HTTP-State-Options: ..., ttl=0, ...