Explainer: Tightening HTTP State Management

https://github.com/mikewest/http-state-tokens

> It might be reasonable instead to send something like Sec-HTTP-State: ? to advertise the feature's 
> presence, and allow the server to ask for a token by sending an appropriate options header 
> (Sec-HTTP-State-Options: generate, or something similar).

Yes. In that case Sec-HTTP-State-Options can also indicate how many bits
server wants (32 - 128 bits perhaps is acceptable) for uniqueID/token.

> Slowly and gradually. User agents could begin by advertising support for the new hotness by appending a 
> Sec-HTTP-State header to outgoing requests (either setting the value by default, or allowing developers to 
> opt-in, as per the pivot point discussion above)


Servers may need then also Set-Cookie: flag telling "Do not send this cookie,
if you generate Sec-HTTP-State: -header".

Servers need some motivation so that not just Set-Cookie: is used.

So perhaps this is useful  to compine with /.well-known/ URL
to browser signal

  - uniqueID/token for site is allocated
  - uniqueID/token for site is destroyed

to help site maintain site wide database. This is motivation
for Sec-HTTP-State: -header.


> To that end, servers can generate a unique key, associate it with the session identifier on the server, and 
> deliver it to the client via an HTTP response header:
> 
> Sec-HTTP-State-Options: ..., key=*ZH0GxtBMWA...nJudhZ8dtz*, ...

That key may be returned from

 /.well-known/ which browser calls when uniqueID for site is allocated.

> Sec-HTTP-State: token=*J6BRKa...MonM*, sig=*(HMAC-SHA265(key, token+metadata))*

Sig can be just hash from uniqueID/token and key. That may be 
proof that /.well-known/ URL is visited. If metadata is considered
that goes too complex (and there is too many design considerations).

Hash from key is needed, or otherwise this allows site
store arbitary data as cookies allow. Purpose is not
allow to store arbitary data to browser.

/ Kari Hurtta

Received on Sunday, 19 August 2018 08:17:00 UTC