W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1997

Re: unverifiable transactions (was: Unidentified subject!)

From: Dave Kristol <dmk@bell-labs.com>
Date: Wed, 26 Mar 1997 10:40:32 -0500
Message-Id: <33394370.FF6D5DF@bell-labs.com>
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 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:32:33 EDT