Re: [w3ctag/design-reviews] HTTP State Tokens (#297)

> Picking this up at our f2f meeting today...

Will you be posting minutes? Stalking through GitHub and the usual places didn't turn anything up for me...

> After reviewing your RFC and especially point 1.2, I remain puzzled as to why developers would switch to http state tokens at all if cookies still exist?

Technically, this proposal does some things that cookies can't (cookies don't do ports, for instance, nor can they directly assert provenance), which creates some security advantage to adoption. I know of ~3 places in Google that want some of these things, and I can imagine marginal adoption amongst the particularly savvy and beautiful developers.

Non-technically, resetting expectations is, IMO, best done with a new thing that has a new name. I tried to make that case in the section of the ID that you mentioned. It appears you didn't find that work compelling, but I'd like to understand why?

> Why not "fix" cookies so that they have the security behaviour you're describing.

We briefly touched on this in https://github.com/w3ctag/design-reviews/issues/297#issuecomment-480911736, and https://speakerdeck.com/mikewest/cookies-are-bad-at-http-workshop-2019:

1.  We should fix cookies when we can. For example, Chrome's current push to default to `SameSite=Lax` and require `Secure` along with `SameSite=None` (which y'all have in your queue at https://github.com/w3ctag/design-reviews/issues/373) can be seen as a step towards aligning cookies with this proposal. You could imagine more shifts in defaults that would bring us even closer.

2.  We should propose a replacement that folks can transition to because new names reset expectations and give us a clear migration path over time.

> Having said that, our proposal is that this should progress in the http working group rather than here and so we think this issue should probably be closed for now and then reopened when and if the http working group requests TAG review.

I'll defer to y'all on this, but it surprises me.

My impression has been that the TAG has generally been happier when looped into discussions that affect the underlying framework on which other things are built. I'd expect y'all to have somewhat authoritative opinions both about core concepts like authentication and state management. HTTPWG is clearly where standardization would happen, but it's not clear to me that there's as much of a liaison relationship there as you're suggesting (friendly folks like @mnot nonwithstanding!). I don't think the HTTPWG is in the habit of poking at the TAG for feedback.

For example, https://httpwg.org/http-extensions/draft-ietf-httpbis-header-structure.html seems like something that y'all could weigh in on, as it has pretty clear implications for the design of APIs at the application layer. So far, I haven't seen that happen. Perhaps @mnot was planning on asking y'all to weigh in as the document moves to last call?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/297#issuecomment-530280162