I think it is important to step back and determine what exactly the needs
of the content provider are. The original session-id proposal was put
forth primarily as a means of tracking a single user over a single session.
The Netscape proposal, on the other hand, clearly has more ambitious
goals. Shopping baskets (a metaphor I really despise) may be one of them,
but there are many other things that the proposal does.
We've used the embed-an-id-in-the-url hack on several sites before. We did
it on http://www.firstnight.org/firstnight/ so that we could keep track of
a user intinerary and let people come back to the site later on with all of
their preferences still set. That's roughtly akin to the shopping basket
model. On the other hand, we're doing it on http://www.wcrb.com/wcrb/ and
http://www.mighty.com/mighty/ so that we can provide a user-registration
mechanism that doesn't require remembering a user-name/password
combination. It's a hack and I don't like it, and I play a number of games
to try and make sure that the same ID isn't getting used from multiple
users (it's not a big concern from a security standpoint - if it was we'd
require passwords, but it's a concern nonetheless). I also have to handle
lost IDs of course - it makes life interesting.
I do believe the session-id needs to be server generated - that way we can
use an ID that makes sense to our user-tracking system. The Netscape
proposal for an optional expiration date is also very nice, since it allows
trial periods and the like, something that is very common on the Web. Path
specific ids are also a requirement, many providers host multiple web sites
that will have different id name spaces. It also needs to be possible to
defeat cacheing - and in that respect I see the cookie proposal as very
much akin to the standard name/password mechanism.
What I really want to avoid is the HotWired/NewsPage problem of "what was
my username and password on *this* site". That's just not acceptable,
particularly for sites which you may not use regularly. You could partially
solve this by having the browser cache name/password pairs over multiple
runs, but I think what I really want is to put the control over identifying
the user totally in the hands of the content provider. And that means the
ability to start a user session without requiring explicit user
interaction.
It does seem to me that the magic-cookie design is very closely tied to
existing password systems, and in that respect I think it's worth
considering whether the two mechanisms might be tied together more tightly
(a user password system with expirations makes perfect sense, for
instance). I haven't delved into that side of the protocol enough to say
any more.
Shopping carts embedded in ids is a cute hack, but it's a red herring. The
real goal in my mind is to find a way to identify a user without requiring
them to carry a separate ID for every store they walk into.
Kee Hinckley Utopia Inc. - Cyberspace Architects=81 617/721-6100
[email protected] http://www.utopia.com/
I'm not sure which upsets me more: that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.