My earlier thoughts on privacy revolved around the idea that privacy online was largely illusory (a server can trace you to an IP, and that IP can be reasonably correlated with other information to identify you to some extent, and the ISP can be made to reveal the mapping from that IP/port to a legal person). Therefore, it was better to make identity absolute, by identifying every request with a source entity, and having the cluster hosting that entity sign it.

But, I feel I have under-estimated the sheer level of insidious surveillance that has become possible with centralisation of logs from different organisations, and so I need to change this stance.

So, therefore, I suggest that MERCURY requests are *not* authenticated by default, but a flag in the EID (or a rejection of the request by the far end, replying with the demand for authentication), much like is proposed for handling encryption, can be used to request it. Unlike encryption, however, authentication requests additional information from the client, so by default it will be rejected and the request will fail. To enable it, the client must provide a callback to the MERCURY request initiation that is called if authentication is required, and whose return value will cause the acceptance or rejection of that authentication request. If the EID has the "please authenticate" flag, then rejection of that by the callback will cause an attempt to perform the request without authentication; if that is rejected, the request fails. Some entities may not require authentication, but offer extra services if authentication is provided; to support this, a MERCURY request may explicitly demand authentication, in which case the callback is NOT invoked.

A "request to authenticate" (which is the return value of the callback, or passed directly to the MERCURY request when explicitly requesting authentication) consists of a base identity - either electing to use the initiating entity's own identity, or a supplied "independent public-key identity" object containing a keypair - and a chain of zero or more proxy certificates, leading from the entity's identity or an independent public-key identity, granting it the (time-limited) right to act "as" another entity.

The intention is that user-interface code will, when the user performs an interaction with an entity that requires authentication, pop up a dialog requesting permission and allowing the user to select from a number of available identities. As the request comes from a UI entity, rather than the user's own UA entity, the request will usually need to involve the proxy certificate granted to the UI by the UA to allow the UI to execute it.

This is better than the browser cookie mess, while also offering privacy by default.

We must also, in the design of MERCURY, execute great care as to what other information about the user we might leak, that could be used to identify them. Although identifying their UI entity (which will actually be generating the MERCURY requests) is not as bad as identifying their UA, we should still be careful to make the MERCURY protocol not leak identifying information. Also, unnecessary bulk in the packets increases network overhead.