Re: Some half-baked thoughts about cookies.

Mike West <mkwst@google.com>: (Mon Aug 27 12:19:06 2018)
> On Sun, Aug 19, 2018 at 8:04 AM Kari Hurtta <hurtta-ietf@elmme-mailer.org>
> wrote:
> > https://lists.w3.org/Archives/Public/ietf-http-wg/2018JulSep/0217.html
> > https://github.com/mikewest/http-state-tokens/pull/2
> > https://github.com/mikewest/http-state-tokens/blob/60e9066f39d345679bbf5bf0151575652e90d9cb/README.md

> >   Perhaps these are on Sec-HTTP-State-Options:
> >
> > Perhaps these may be usefull to compine with /.well-known/ URL
> > to browser signal
> >
> >   - uniqueID for site is allocated
> >   - uniqueID for site is destroyed
> >
> > to help site maintain site wide database
> >
> > Yes there was Javascript
> >
> >  let resetChannel = new BroadcastChannel('http-state-reset'));
> >  resetChannel.onmessage = e => { /* Do exciting cleanup here. */ };
> >
> >    ( I understand that javascript does not see that uniqueid
> >      and anyway because Sec-HTTP-State header start with "Sec-"
> >      browser needs add it to requests generated by Javasript.
> >      Javascript can not add that header.
> >    )
> >
> 
> In a browser context, I'm imagining that a Service Worker would handle this
> state change, and could ping back to the server if desired in order to
> update any backend. I'm not sure why it would be desirable to bake such a
> ping into the user agent itself. What use cases do you think it would serve?

Hmm. I was thinking more http centric. ( And that there is just one fixed
registeration / deregisteration path per site. )

I do not know about Service Workers, so I do not try image how that works.
So that http-state-reset thing and Service Worker things are run
totally before state is destroyed?  Something on Javascript needs generate 
that http "deregister" -request (perhaps POST request). Browser needs
still automatically add that "Sec-HTTP-State" to that request generated
by javascript (https://github.com/mikewest/http-state-tokens states:
 "The token will only be available to the network layer, 
 not to JavaScript (including network-like JavaScript, such as 
 Service Workers).").  So that whole chain must run before event and 
not after.




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

> For some servers, the client-generated token will be enough to maintain state. They 
> can treat it as an opaque session identifier, and bind the user's state to it 
> server-side. Other servers will require additional assurance that they can trust the 
> token's provenance. 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

So I image, 

∙  "register of token / unique-id" is request where there is
   just

   Sec-HTTP-State: token=*xxxxxxxx*

∙  response of registeration gives always new key, even
   when token is already seen. On response there is

   Sec-HTTP-State-Options: key=*xxxxxx*

∙  If http client token genaration algrithm is _poor_, then
   there is collisions on token.  However collision produces
   different keys.

   If there is lot (10? or 100?) of collisions then threat this as attack
   and do not generate key. 

∙  Few collisions is probably just retrying of interrupted reguest

∙  Collided tokens can be differentiated because there is sig on request
   when registered token is used

   Sec-HTTP-State: token=*xxxxxxxx*, sig=*yyyy*

/ Kari Hurtta

Received on Sunday, 2 September 2018 08:12:44 UTC