...

Are you suggesting that the session token should actually store session data?

As an alternative SessionManager, it appears to have some advatanges that others do not.

Hmmm. Please smack me if I'm wrong, but I'm not clear on how it differs much from not keeping session-related data in the token. I guess you could argue that a session token that holds application data is "more random" due to the nature of its composition, and due to that it can't be "guessed" as easily (I doubt anyone would even try). One of the purposes of the random element of the session token in the current implementation is to address this "token guessing" risk. However, in either case (app data in token or app data key in token), if the token is stolen, it can still be used by the "robber" to see the data that relates to it (made available by the application which relies on the server's unpackaging of the token). This is a different risk, the "token theft" risk. Example: if you get a tree tag token from somebody, and plug it into a URL on your browser, it'll work happily. Without a client-checking scheme (such as encoding the IP address in the token), a token theft attack is very easy. As voiced by others in the thread, client-checking is not reliable, should not be a default, and maybe shouldn't be included as an option at all. But all of these ponderings are kind of moot, because session data can be arbitrarily large (session data on the order of a megabyte will probably not be uncommon), so the data can't realistically be embedded in the token anyway.

Its also the only sensible option that lets you bookmark your place in a session, and return to it much later (which interests me more).

I don't understand what you mean... a session token that doesn't include application data has the same property. That's essentially its reason for being around at all. (If you're concerned that the session token isn't URL-compatible, it is... the current implementation lets the session token be transferred via a query string, inlined URL elements, or as a cookie value). Parts of the token *never* expire, so you can happily bookmark something with a token value embedded (or receive and continue to resend a persistent cookie).

Isnt the tree tag an example of one Session use case? It smells alot like a session to me.

Probably, yes. Although it will probably not be reimplemented to use the session machinery in the near future (dont fix it if it aint broke! :-).