Re: Some half-baked thoughts about cookies.

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

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?


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

This question is captured in
https://github.com/mikewest/http-state-tokens#opt-in, and it seems to me
that there are reasonable arguments on both sides. I fully agree that we'll
need to hammer it out one way or the other.

* When Sec-HTTP-State includes purpose, does that mean that
>   there is several uniqueID for different purpose
>
>   or
>
>   is uniqueID always combining different porposes ?
>

We don't have consensus on this point (nor, really, do we have consensus on
whether a "purpose" is a reasonable thing to add in the first place! :) ).

I believe Rigo's proposal in
https://github.com/mikewest/http-state-tokens/pull/2 is to bind multiple
purposes to a single identifier. I think we'd be better served if the user
agent minted distinct identifiers for a (very) small number of purposes
whose intentions are publicly described. Either way, there's room for
healthy debate on the topic.

-mike