Cookie layering

[annevk]

While most cookies don't have layers in my experience (turns out that is limited), some layering would be appropriate for the HTTP State Management Mechanism. I touched upon this last year in #1430, but thought I would raise it again after the W3C Privacy CG had a discussion about this yesterday.

I thought I'd describe my idea for how this could work as a conversation starter. But to be clear, I'm open to alternatives. What I'd like to see is that the cookie specification describes cookies (as a concept/object) and how to parse and serialize Set-Cookie and Cookie headers. We'd continue to define new attributes and anything syntax-related in the cookie specification. (Through revisions, essentially as it's maintained now.)

That leaves storage and some amount of logic around that. For web browsers in particular we need to get a better hold of that to define document.cookie, Fetch, and in general websites better. That doesn't necessarily mean that the cookie specification shouldn't touch them at all and I think it should continue to describe a default model there, especially given non-web-browser clients. But web browser specifications (Fetch, HTML) should be allowed to define a model that integrates more tightly, perhaps as long as certain base requirements in the cookie specification aren't violated. In turn, that would also allow the cookie specification itself to be more agnostic of browsers as the current draft contains a lot of logic particular to subresources of HTML documents, workers, etc.

Any thoughts about this would be greatly appreciated!

[sbingler]

Just adding my support (and couple tags) for this proposal, I like the idea of putting pieces in the layers they belong.
I'd like to spend more time on this once 6265bis is out the door.

[annevk]

#1593 has some good ideas for this.