RE: comments on jaye-trust-state-01

I have made changes per your comments except where noted...

-----Original Message-----
From:	dmk@research.bell-labs.com [SMTP:dmk@research.bell-labs.com]
Sent:	Tuesday, August 19, 1997 5:42 PM
To:	Jaye, Dan
Cc:	http-state@lists.research.bell-labs.com; 
http-wg@cuckoo.hpl.hp.com
Subject:	comments on jaye-trust-state-01

Following are my comments for Dan Jaye's recently posted
(pre-) draft-ietf-http-jaye-trust-state-01.txt.

....

Although a server may emit PICS-Label immediately after Set-Cookie2, 
it
may not be in that position at the client, due to proxy header
shuffling.  The only guarantee is that the relative order of
Set-Cookie2 headers will be preserved, as will the relative order of
PICS-Label headers.  But they well may get separated (particularly 
with
header folding).

The goal here is to work within the constraints of the current 
PICS-Label header syntax and the cookie syntax.   I will propose that 
we make a trust-label apply to all cookies that match the "for" 
attribute of the PICS-Label as opposed to specifically enumerating all 
cookies for which the PICS-Label applies.  In the end...the trust 
label is issued for a URL-space... not a specific cookie.

There would appear to be a possible danger with using "PICS-Label".
Suppose the origin server wants to emit one PICS-Label to label the
content, and another to label the cookie.  Header folding would group
all PICS-Label headers together, making it harder to pick out which
ones apply to cookies, and which to content.

The key issue is how does the user agent determine which PIC-Label 
headers it needs to interprete to process the cookies.  At this point 
they will look for ServiceID's that correspond to trust-labels.  I 
propose that the browser will have a list of these ServiceID's 
available.  ServiceID's are modified so they now point to a URL that 
describes the rating system rather than a specific Trust Authority.

....


There seems to be the implication that the privacy-practice values
form a partial ordering, and that a more-stringent privacy-practice
in a trust label should be acceptable to a user agent that is set to
accept less-stringent ones, but that ordering and treatment isn't
spelled out explicitly and should be.

There is no sensitivity to ordering.  The ratings are independent. 
 The numeric values are merely an artifact of the PICS rating spec 
that requires a "string number" format.  The fact that there are 
different rating strings rather than one string with four levels is 
intended to convey that they are independent.  The examples at the end 
also convey this by describing privacy preferences that enumerate all 
acceptable ratings.


[...]

One of the contentious issues with RFC 2109 has been the concept of
"related servers" (although it isn't called that) to which a user 
agent
can send a cookie.  That's the business with the domain-matching, the
"two-dot rule", etc.  The trust-label mechanism is even *more*
restrictive, since the label applies to a single host.  Won't that
restriction be even more objectionable?

The assumption is that each host obtains a separate trust-label.  This 
does not prevent cookie-sharing (where acceptable to the user-agent).

[...]

> The User Agent should have a default preference to reject 
"third-party-
> exchange" cookies from unverifiable transactions.

Need a definition of "third-party-exchange"; or omit this statement, 
since
it appears in RFC 2109.

Should be "thirdpartyexchange", i.e., the well known rating value 
described in 3.1.

>
> For example, a user may wish to accept cookies rated 
anonymousexchange by
> a recognized trust authority, rather than relying on an unsigned 
trust
> label or a trust label signed by an unrecognized entity.

I don't understand the point this statement is trying to make.

The intent was not to require the site to pay for a signed trust 
label... so unsigned labels are allowed.  In some jurisdictions, 
consumer protection laws about "truth in advertising" may be 
sufficient for enforcement.  Also, many parties point out that 
REQUIRING small web sites to pay for auditing and verification is too 
onerous.  Allowing the implementors / market to decide whether 
third-party verification is necessary seemed to be a fair compromise 
as long as the user can override the default.

Received on Thursday, 11 September 1997 21:30:46 UTC