I'm confused. Do you mean to say you want session-id renegotiation by
the client for the case that two servers want to push the same
session-id value on the client?
If you are, under a `one server only' session-id scheme, this does not
make any sense. If server B knows that the browser is using
session-id 31415 on server A, B can compromise privacy without being
able to set its own session-id on the browser to 31415 too. It can
just set it to 27182, or accept the 27182 proposed by the browser, and
log
`the browser that uses 31415 on server A uses 27182 on server B'.
This information can then be used later to match clicktrails between A
and B.
[...]
>Allowing the client to insist on it being allowed to generate the
>session id solves any privacy problems associated with
>server-generated session ids.
I still think that with `one server only' restrictions, both client
generated and server generated have exactly the same privacy problems.
Could you give a counterexample?
[...]
>Yes, this allows clients to create a single session ID and use it when
>talking to all servers. That's a bad idea. Does that mean we have to
>require that a client not do that?
No, we do not need to require that. Browsers on single user machines
that are not behind proxies could use the same session-id for every
server without compromising privacy much more, as they already provide
such a constant session-id: their IP address.
> <mike
Koen.