Re: Some half-baked thoughts about cookies.

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

> Not sure I agree there, if UAs by default sent a different
> 64 bit randomly generated ID to each origin and kept those
> IDs for a long time, that seems worse to me than the current
> situation. (I'm not saying that's Mike's proposal, but
> just disagreeing with your "no big difference" statement.)


Then it seems that for uniqueID with purpose "authentication",
need mechanismim

* to server indicate that uniqueID for "authentication" is needed
  to be generated by Browser for that site because user is about
  to log in

* to server indicate that that uniqueID for "authentication" is
  no longer needed, because user is logged out

  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.
   )


So looks like uniqueID should not automatically generated before
they are needed. 

* When Sec-HTTP-State includes purpose, does that mean that
  there is several uniqueID for different purpose

  or

  is uniqueID always combining different porposes ?


/ Kari Hurtta

Received on Sunday, 19 August 2018 06:05:13 UTC