- From: Dave Kristol <dmk@bell-labs.com>
- Date: Wed, 26 Mar 1997 10:40:32 -0500
- To: "Jaye, Dan" <DJaye@engagetech.com>
- Cc: http-wg@cuckoo.hpl.hp.com
Jaye, Dan wrote: > [...] > A user agent may verify that the request-URI comes from a trusted | > domain by placing a request to a certificate authority to get the | > credentials of the domain. Those credentials may be persistently | > cached by the user agent to reduce overhead of repetitive verification > | > The user agent may have the default behavior of sending and accepting | > cookies from the request-URI domain if the credentials indicate that > the | > domain is trusted and the credentials have not expired. The user should > | > have the ability to explicitly override the user agent verification for > a | > specific domain. | > Sorry, I'm not willing to entertain the idea of credentials and trusted parties for this version of the spec. Maybe it's reasonable for the future, but lacking a complete description of the credentials infrastructure, your proposal isn't practical now. > ... > > 7.1 User Agent Control > > ... > > A user agent usually begins execution with no remembered state > information. It should be possible to configure a user agent never to > send Cookie headers, in which case it can never sustain state with an > origin server. (The user agent would then behave like one that is > unaware of how to handle Set-Cookie2 response headers.) > > The user agent should allow the user to specify whether state > information > should be retained each time the user agent terminates; the default | > should be "yes." If the user chooses to retain state information, | > it would be restored the next time the user agent runs. | > > NOTE: User agents should probably be cautious about using files to store > cookies long-term. If a user runs more than one instance of the user > agent, the cookies could be commingled or otherwise corrupted. > > ------------------------------------------------------------------------ > ---------------------------------- > > My objective here is to provide a more explicit definition of how a > certificate authority would "verify" an otherwise unverifiable > transaction. Perhaps, but you've only made reference to a now-non-existent facility. > > In addition, there has been no discussion in this forum on the item in > 7.1 that effectively eliminates persistent cookies. I believe that the > current wording could allow a browser to provide an "invisible default" > where a user could have a default that cookies are not persistent and > the user would never know. My recommendation is that we make it > explicit that the user be prompted and the default should be positive. > Once again, this provides consistency with the current implementations > in terms of default behavior yet provides the user with control. I disagree that 7.1 eliminates persistent cookies. The current wording is: ==== When the user agent terminates execution, it should let the user discard all state information. Alternatively, the user agent may ask the user whether state information should be retained; the default should be ``no.'' If the user chooses to retain state information, it would be restored the next time the user agent runs. ==== Note the wording: "should *let*". And "may ask". The spec says the UA should give the user the choice of what to do. The default in the *dialog* should be ``no'' (i.e., did not retain). I see no invisible control. (:-) Dave Kristol
Received on Wednesday, 26 March 1997 08:17:42 UTC