_ provide further abstraction of browser cookies_
- "typed" cookies
- uuids
- jwts
- gell concepts would abstract the parsing/serialization process
- something still doesn't seem right with this implementation
- should be able to turn any State into a cookie
- "cookie" or "browser" perspective
- does this mean that there would also be a "server" perspective?
- could also be thought of as "reference" cookies, meaning they identify some entity on the server
- should this be renamed "claim set" or seomthing similar
- idea here is that jwt is just the underlying tech
- stateless set of "claims" transmitted between client and server
- and a claim set is really just an abstraction of a "user"
- store arbitrary State that can be de/serialized
- another name might be "authority"
- i like this better to avoid confusion with JWT issuer
- manages the issuance and lifecycle of a cookie
- all cookies issued would share some properties
- initial expiration
- goal would be to extend this concept to materialize the State the cookie represents
- for "reference" cookies (uuid), this might lookup the corresponding entity
- for "encoding" cookies (JWT), this might decode the cookie value
- the materialized State would be a projection of the cookie
- perhaps the "materializing" would be its own sequence
- not a property of this issuer
- generator (call to next) would issue new cookies
- would I want to do this all in one?
- then "commit" the user? or call "flush"?
- this would do all the work of generating the JWT, setting cookie header, etc
- i kind of like this...it's kind of like hibernate
- could also commit changes to persistent store
- commit event handlers
- session cookie
- session persistence
- token cookie
- user persistence
- could bind different implementations based on scenario
- cookie
- header
- POST
- in this case the cookie is a separate State from the user
- this should probably be fromCookie or fromBrowser
- user.fromBrowser(req, res)