Unidentified subject!

Here is my recommended revision to sections 4.3.5 and 7.1:

4.3.5  Sending Cookies in Unverifiable Transactions  Users must have
control over sessions in order to ensure privacy.  (See PRIVACY section
    
below.)  To simplify implementation and to prevent an additional layer
of complexity where adequate safeguards exist, however, this document
distinguishes between transactions that are verifiable and those that
are unverifiable.  A transaction is verifiable if the user, or a
user-		|
designated agent, has the option to review the request-URI prior to
its	|
use in the transaction.  A transaction is unverifiable if the user does
not have that option.  Unverifiable transactions typically arise when a
user agent automatically requests inlined or embedded entities or when
it resolves redirection (3xx) responses from an origin server.
Typically the origin transaction, the transaction that the user
initiates, is verifiable, and that transaction may directly or
indirectly induce the user agent to make unverifiable transactions.

When it makes an unverifiable transaction, a user agent must enable a
session only if a cookie with a domain attribute D was sent or accepted
in its origin transaction, such that the host name in the Request-URI of
the unverifiable transaction domain-matches D.

This restriction prevents a malicious service author from using
unverifiable transactions to induce a user agent to start or continue a
session with a server in a different domain.  The starting or
continuation of such sessions could be contrary to the privacy
expectations of the user, and could also be a security problem.

User agents may offer configurable options that allow the user agent, or
any autonomous programs that the user agent executes, to ignore the
above rule, so long as these override options default to ``off.''

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.								|

...

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.

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.
>)>)>)>)>)---------------------------------------->>>>>>>
Daniel Jaye                         djaye@engagetech.com    
Engage Technologies, Inc.                (508)684-3641 v
100 Brickstone Square, Andover MA 01810  (508)684-3636 f

Received on Tuesday, 25 March 1997 13:48:22 UTC