1 |
|
2 |
|
3 |
HTTP Working Group Daniel Jaye |
4 |
INTERNET DRAFT Engage Technologies |
5 |
|
6 |
|
7 |
<draft-ietf-http-jaye-trust-state-01.txt> |
8 |
October 23, 1997 Expires April 23, 1998 |
9 |
|
10 |
|
11 |
HTTP Trust Mechanism for State Management |
12 |
|
13 |
|
14 |
Status of this Memo |
15 |
|
16 |
This document is an Internet-Draft. Internet-Drafts are |
17 |
working documents of the Internet Engineering Task Force |
18 |
(IETF), its areas, and its working groups. Note that other |
19 |
groups may also distribute working documents as Internet- |
20 |
Drafts. |
21 |
|
22 |
Internet-Drafts are draft documents valid for a maximum of six |
23 |
months and may be updated, replaced, or obsoleted by other |
24 |
documents at any time. It is inappropriate to use Internet- |
25 |
Drafts as reference material or to cite them other than as |
26 |
``work in progress.'' |
27 |
|
28 |
To learn the current status of any Internet-Draft, please |
29 |
check the ``1id-abstracts.txt'' listing contained in the |
30 |
Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), |
31 |
nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), |
32 |
ds.internic.net (US East Coast), or ftp.isi.edu (US West |
33 |
Coast). |
34 |
|
35 |
This is author's draft 2.06. |
36 |
|
37 |
|
38 |
ABSTRACT |
39 |
|
40 |
HTTP TRUST MECHANISM PROPOSAL FOR STATE MANAGEMENT |
41 |
October 23, 1997 |
42 |
|
43 |
1. ABSTRACT |
44 |
|
45 |
This document specifies an addition to the state management protocol |
46 |
specified in draft-ietf-http-state-man-mec-03[Kristol]. The intent is |
47 |
to provide a mechanism that allows user agents to determine the privacy |
48 |
practices of a server and to accept or reject cookies based on those |
49 |
practices. Allowing the user to establish preferences for how to handle |
50 |
cookies based on the server's practices provides a practical mechanism |
51 |
|
52 |
|
53 |
|
54 |
Jaye draft-ietf-jaye-trust-state-01.txt [Page 1] |
55 |
|
56 |
|
57 |
INTERNET DRAFT HTTP Trust Mechanism for State Mgt October 23, 1997 |
58 |
|
59 |
|
60 |
to provide users control over the privacy implications of cookies. |
61 |
|
62 |
To provide verification of server privacy practices, we assume the |
63 |
existence of one or more independent Trust Authorities. The authority |
64 |
establishes PICS ratings representing server privacy practices. It then |
65 |
issues trust-labels, in the form of digitally signed PICS labels, to |
66 |
organizations for specific domains and paths based on the server privacy |
67 |
practices. The Trust Authority must be able to audit domains to |
68 |
verify their adherence to a given level. Passing these trust-labels |
69 |
along with cookies allows the user agent to support cookie handling |
70 |
preferences based on trusted privacy practices. |
71 |
|
72 |
This document describes how PICS-headers are used in conjunction with |
73 |
Set-Cookie or Set-Cookie2 headers in [Kristol] to provide trust-labels |
74 |
to communicate the privacy practices of servers regarding cookies. |
75 |
|
76 |
|
77 |
2. TERMINOLOGY |
78 |
|
79 |
The terms user agent, client, server, proxy, and origin server have the |
80 |
same meaning as in the HTTP/1.1 specification [RFC 2068]. The terms |
81 |
domain-match, verifiable transaction, and unverifiable transaction are |
82 |
defined in [Kristol], and those definitions are also used here. |
83 |
|
84 |
The term trust-label is used to mean a PICS label [PICS] used to |
85 |
communicate the cookie-related privacy practices of a server. |
86 |
The term Trust Authority refers to the PICS label rating service for |
87 |
trust-labels who may issue digitally signed trust-labels to domains. |
88 |
|
89 |
|
90 |
3. OUTLINE |
91 |
|
92 |
The server sends a Set-Cookie and/or a Set-Cookie2 header to the user |
93 |
Agent along with a PICS-Label header containing the trust-label. The |
94 |
user agent may then use that information to guide the acceptance or |
95 |
rejection of the cookie. If the trust-label has a digital signature, |
96 |
the user agent may use the well-known public key of the Trust |
97 |
Authority to decrypt the signature of the trust-label to verify the |
98 |
identity and practices of the server and scope of the trust-label. |
99 |
|
100 |
3.1 Syntax: General |
101 |
|
102 |
This specification describes how the PICS-Label header, described in |
103 |
[PICS], is used to convey the privacy practices of the server to the |
104 |
user-agent The new PICS-Label header syntax is specified below: |
105 |
|
106 |
trust-label = "PICS-Label:" labellist |
107 |
|
108 |
The header is recognized as a trust-label by the existence of the |
109 |
cookieinfo extension. This trust-label applies to cookies in the |
110 |
response that are compatible (as described in section 3.3.1) with |
111 |
the domain and path of the "for" labelattr of the PICS-Label header. |
112 |
|
113 |
|
114 |
|
115 |
Jaye draft-ietf-jaye-trust-state-01.txt [Page 2] |
116 |
|
117 |
|
118 |
INTERNET DRAFT HTTP Trust Mechanism for State Mgt October 23, 1997 |
119 |
|
120 |
|
121 |
The specific cookies are listed in the cookieinfo extension to the |
122 |
PICS label or to all compatible cookies if no cookies listed in the |
123 |
cookieinfo extension. "labellist" is as specified in the PICS 1.1 label |
124 |
syntax in [PICS], except for the following changes: |
125 |
an extension to include a list of the specific cookies to |
126 |
to which the trust-label applies; |
127 |
an optional extension according to the digital signatures |
128 |
working draft [DSIG]; |
129 |
the optional label attributes "by" "gen" "for" "on" and "exp" |
130 |
are required. |
131 |
|
132 |
The modified PICS label syntax is listed here. |
133 |
|
134 |
labellist = "(" version 1*service-info ")" |
135 |
version = "PICS-1.1" |
136 |
service-info = serviceID "label" 1*label |
137 |
serviceID = quotedURL |
138 |
label = labelattr "ratings" "(" privacy-practice ")" |
139 |
cookieinfo |
140 |
[sigblock] |
141 |
labelattr = "by" quotedname |
142 |
"gen" boolean |
143 |
"for" quotedURL |
144 |
"on" quoted-ISO-date |
145 |
"exp" quoted-ISO-date |
146 |
privacy-practice |
147 |
= "noexchange 1" |
148 |
| "anonymousexchange 1" |
149 |
| "noshare 1" |
150 |
| "thirdpartyexchange 1" |
151 |
| rating |
152 |
cookieinfo = "extension" "(" "mandatory" <"> |
153 |
"http://www.w3.org/PICS/extensions/cookieinfo-1_0.html" |
154 |
<"> *cookiename ")" |
155 |
cookiename = NAME |
156 |
|
157 |
"quotedname", "quotedURL", "rating", and "quoted-ISO-date" are as |
158 |
defined in the PICS specification [PICS]. |
159 |
ServiceID references a quoted URL that defines and describes the rating |
160 |
service and references the rating system. |
161 |
"for" is the URL or root URL for which this label applies. |
162 |
"by" is the email address of the issuing trust authority. |
163 |
The "gen" boolean indicates whether the label is generic to the web site |
164 |
or for a specific page. A value of "True" indicates that the label |
165 |
is generic for all cookies with a Path attribute for which the path |
166 |
component of the URL in the "for" attribute is a prefix. |
167 |
"on" is the date the label was issued. |
168 |
"exp" is the date the label expires. |
169 |
"mandatory" in cookieinfo causes legacy browsers to ignore the label. |
170 |
cookiename is the "NAME" of each cookie to which this label applies. |
171 |
sigblock is the digital signature extension as described in the digital |
172 |
signature working draft[DSIG]. |
173 |
|
174 |
|
175 |
|
176 |
Jaye draft-ietf-jaye-trust-state-01.txt [Page 3] |
177 |
|
178 |
|
179 |
INTERNET DRAFT HTTP Trust Mechanism for State Mgt October 23, 1997 |
180 |
|
181 |
|
182 |
The sigblock must contain the SigCrypto token within the SigData block. |
183 |
The SigCrypto token must contain the encrypted trust-label-data |
184 |
described below. |
185 |
|
186 |
trust-label-data = labelattr-data privacy-practice [cookielist] |
187 |
labelattr-data = gen-boolean for-URL exp-date |
188 |
gen-boolean = boolean |
189 |
for-URL = quotedURL |
190 |
exp-date = quoted-ISO-date |
191 |
|
192 |
"gen-boolean", "for-URL", and "exp-date" refer to the values of the |
193 |
"gen", "for", and "exp" attributes in the "labelattr" section. |
194 |
"cookielist" refers to the list of cookie names in the cookieblock |
195 |
extension. |
196 |
|
197 |
Four well-known privacy-practice values are described here to provide |
198 |
recognized values that should be handled by user agents. |
199 |
|
200 |
The "noexchange 1" rating indicates that the Trust Authority has |
201 |
verified that the server will not use the cookie to collect persistent |
202 |
user information. |
203 |
|
204 |
The "anonymousexchange 1" rating indicates that the Trust Authority has |
205 |
verified that the server will not use the cookie to collect or transmit |
206 |
personally identifying information (e.g., name, address, telephone |
207 |
number, email address, etc.) but may collect anonymous or aggregated |
208 |
personal information (e.g., gender, geographic region, approximate age, |
209 |
derived data such as clickstream, etc.) or implicit information (such as |
210 |
web usage patterns) as long as it will never be associated with |
211 |
personally identifying information. The server may collect IP Addresses |
212 |
but they must not be associated with personally identifying information |
213 |
to be elegible for this rating. |
214 |
|
215 |
The "noshare 1" rating indicates that the Trust Authority has verified |
216 |
that the server may use the cookie to collect or transmit personally |
217 |
identifying information (e.g., name, address, telephone number, email |
218 |
address, etc.) but will never share that information with companies |
219 |
other than the company to which the user provided the information. |
220 |
|
221 |
The "thirdpartyexchange 1" rating indicates that the Trust Authority has |
222 |
verified that the server may use the cookie to collect or transmit |
223 |
personally identifying information (e.g., name, address, telephone |
224 |
number, email address, etc.) and may share that information with |
225 |
third parties. |
226 |
|
227 |
All other items above are as described in the PICS label syntax [PICS] |
228 |
or in the Digital Signatures working draft [DSIG]. |
229 |
|
230 |
3.2 Server Role |
231 |
|
232 |
A server communicates its privacy practices by sending an unsigned or |
233 |
signed trust-label in the same response as the cookie header(s). |
234 |
|
235 |
|
236 |
|
237 |
Jaye draft-ietf-jaye-trust-state-01.txt [Page 4] |
238 |
|
239 |
|
240 |
INTERNET DRAFT HTTP Trust Mechanism for State Mgt October 23, 1997 |
241 |
|
242 |
|
243 |
Any server wishing to provide a digitally signed trust-label must |
244 |
request the label from a Trust Authority. The Trust Authority must have |
245 |
the ability to evaluate the server and determine the trust rating |
246 |
for which a label will be issued. That evaluation takes place outside |
247 |
the protocol described here, as does the actual granting of the label |
248 |
to the origin server. |
249 |
|
250 |
The labels should expire no more than thirteen months and no less than |
251 |
one month after they are issued. The server should store the trust |
252 |
labels and only request a new trust-label from the Trust Authority when |
253 |
the current trust-label is about to expire. |
254 |
|
255 |
3.3 User Agent Role |
256 |
|
257 |
The user agent receives a cookie headers and trust-labels from |
258 |
an origin server. |
259 |
|
260 |
3.3.1 Interpreting the trust-label |
261 |
User agents interpret cookies as described in RFC 2109. In addition |
262 |
to the cookie attributes, the user agent must now interpret the |
263 |
trust-labels as well. If the user agent receives a PICS label with a |
264 |
serviceID from a recognized label service for trust-labels, it is |
265 |
assumed to be a trust-label for all "compatible" cookies, as defined |
266 |
below. |
267 |
|
268 |
A trust-label and a cookie are defined as "compatible" if the following |
269 |
conditions are met: |
270 |
1) The domain portion of the URL specified in the "for" attribute of |
271 |
labelattr domain-matches the Domain attribute of the cookie |
272 |
response header, according to the matching rules in [Kristol]. |
273 |
2) The path portion of the URL specified in the "for" attribute of |
274 |
labelattr is either a), a prefix of the Path attribute of the cookie |
275 |
if the trust-label is generic or, b), an exact match with the Path |
276 |
attribute of the cookie if the trust-label is not generic. |
277 |
|
278 |
If the cookieinfo extension does not contain any cookie names, then |
279 |
the trust-label applies to all cookies in the response that are |
280 |
compatible. |
281 |
|
282 |
A trust-label is ignored if the "exp-date" attribute of labelattr |
283 |
is less than or equal to the current date. |
284 |
|
285 |
To help verify the trustworthiness of the server, the user agent may |
286 |
look for a digital signature and use the Trust Authority's well known |
287 |
public key to decrypt the trust-label-data from the SigCrypto term. |
288 |
|
289 |
The user agent obtains that public key outside this protocol. Given |
290 |
that we expect only a few well-known Trust Authorities, the user agent |
291 |
implementer should cache public keys from standard trust authorities |
292 |
to avoid extra network traffic. |
293 |
|
294 |
|
295 |
|
296 |
|
297 |
|
298 |
Jaye draft-ietf-jaye-trust-state-01.txt [Page 5] |
299 |
|
300 |
|
301 |
INTERNET DRAFT HTTP Trust Mechanism for State Mgt October 23, 1997 |
302 |
|
303 |
|
304 |
The labelattr-data, privacy-practice, and cookielist in the decrypted |
305 |
trust-label-data from the sigblock must match the plaintext labelattr, |
306 |
privacy-practice, and cookielist for the signature to be valid. |
307 |
|
308 |
If the digital signature is invalid, then the trust-label should be |
309 |
ignored and the cookie should not be set. |
310 |
|
311 |
If the user agent is set to accept all cookies then all trust-label |
312 |
processing can be skipped. |
313 |
|
314 |
3.3.2 Accepting or rejecting Cookies |
315 |
|
316 |
In addition to the rules for rejecting cookies specified in [Kristol], a |
317 |
user or a user-designated agent should be able to designate preferences |
318 |
for accepting or rejecting cookies based on the privacy-practice of the |
319 |
server, whether the transaction is verifiable or unverifiable, and |
320 |
whether the privacy-practice is signed by a recognized Trust Authority. |
321 |
|
322 |
For example, a user may have a preference to accept all cookies from |
323 |
verifiable transactions or rated "anonymousexchange 1" and signed by a |
324 |
recognized Trust Authority. |
325 |
|
326 |
User agents should have the following default preferences: |
327 |
"noexchange 1", "anonymousexchange 1", and "noshare 1" rated cookies |
328 |
from verifiable transactions are accepted; |
329 |
"noexchange 1" and "anonymousexchange 1" rated cookies from |
330 |
unverifiable transactions are accepted; |
331 |
"thirdpartyexchange 1" cookies from unverifiable transactions are |
332 |
rejected. |
333 |
|
334 |
3.3.3 User intervention |
335 |
The user agent may prompt the user to verify that it wishes to reject a |
336 |
cookie in conditions where the cookie is being rejected based on |
337 |
a default preference or no preference applies. |
338 |
|
339 |
User agents that solicit user input for cookie handling may wish to |
340 |
display the URL of the rating service to better inform the user of the |
341 |
meaning of the privacy ratings for the server. |
342 |
|
343 |
3.3.4 Cookie request header syntax |
344 |
The syntax for the Cookie request header has not been modified. |
345 |
|
346 |
3.4 Trust Authority Role |
347 |
|
348 |
The Trust Authority referred to in this document must be a neutral third |
349 |
party that can be trusted to accurately characterize the privacy |
350 |
behavior of web sites. The issuing of trust-labels occurs outside the |
351 |
scope of this protocol. However, the protocol depends on user trust in |
352 |
the Trust Authority. The Trust Authority must understand the scope to |
353 |
which a trust-label applies to ensure that for all situations in which |
354 |
the trust-label would be deemed to be applicable, the server(s) are in |
355 |
fact operating in accordance with the specified privacy rating. |
356 |
|
357 |
|
358 |
|
359 |
Jaye draft-ietf-jaye-trust-state-01.txt [Page 6] |
360 |
|
361 |
|
362 |
INTERNET DRAFT HTTP Trust Mechanism for State Mgt October 23, 1997 |
363 |
|
364 |
|
365 |
3.4.1 Issuing trust-labels |
366 |
On receiving a request for a signed trust-label, the authority should |
367 |
verify the privacy practices of the site requesting the trust-label and |
368 |
issue the appropriate trust-label. To issue the trust-label, the Trust |
369 |
Authority assembles the trust-label-data, it canonicalizes whitespace |
370 |
for the trust-label-data, and it encrypts the trust-label-data for the |
371 |
site request using its private key and the algorithm specified in the |
372 |
attribution of the digital signature. The encryption method must be a |
373 |
public-private key pair with a well-known public key to eliminate |
374 |
round-trips to the Trust Authority. |
375 |
|
376 |
3.4.2 Revocation of trust-labels |
377 |
Trust-labels must have expiration dates. When a trust-label is issued, |
378 |
the Trust Authority must receive agreement from the requesting |
379 |
organization that the privacy practices for which the trust-label was |
380 |
assigned will be maintained until the trust-label expires, the domain |
381 |
becomes inactive, or those cookies are no longer set or examined by the |
382 |
organization's servers. |
383 |
|
384 |
3.4.3 Discovery of privacy-practice ratings |
385 |
Privacy-practice ratings are defined in the PICS label rating system |
386 |
referenced by the Trust Authority's label rating service. One |
387 |
well-known rating system is proposed in this document. |
388 |
|
389 |
|
390 |
4. EXAMPLES |
391 |
|
392 |
4.1 Example 1 |
393 |
|
394 |
1. User Agent preferences: |
395 |
|
396 |
In this example, the user agent has a preference for automatically |
397 |
accepting cookies from domains that have valid ratings of |
398 |
"anonymousexchange 1" or "noshare 1". |
399 |
|
400 |
2. User Agent -> Server |
401 |
|
402 |
POST /acme/login HTTP/1.1 |
403 |
Host: www.acme.com |
404 |
[form data] |
405 |
|
406 |
User identifies self via a form. |
407 |
|
408 |
3. Server -> User Agent |
409 |
HTTP/1.1 200 OK |
410 |
Set-Cookie2: Customer="WILE_E_COYOTE"; Max-Age = 94608000; |
411 |
Version="1"; Path="/acme" |
412 |
PICS-Label: (PICS-1.1 "http://www.aaa.org" label |
413 |
by "auditor@aaa.org" gen true |
414 |
for "http://www.acme.com/" |
415 |
exp "1998.12.31T23:59-0000" |
416 |
|
417 |
|
418 |
|
419 |
|
420 |
Jaye draft-ietf-jaye-trust-state-01.txt [Page 7] |
421 |
|
422 |
|
423 |
INTERNET DRAFT HTTP Trust Mechanism for State Mgt October 23, 1997 |
424 |
|
425 |
|
426 |
extension |
427 |
(mandatory |
428 |
"http://www.w3.org/PICS/extensions/cookieinfo-1_0.html") |
429 |
ratings (noshare 1)) |
430 |
|
431 |
A cookie that includes the user's identity and an unsigned trust |
432 |
label header are sent back to the user agent with the request. The |
433 |
cookie is accepted because rating "noshare 1" is acceptable |
434 |
according to the privacy preferences of the user agent. |
435 |
|
436 |
4.2 Example 2 |
437 |
|
438 |
1. User Agent preferences: |
439 |
|
440 |
In this example, the user agent has a preference for automatically |
441 |
accepting cookies that are rated "noexchange 1", |
442 |
"anonymousexchange 1", or "noshare 1" or from cookies in |
443 |
unverifiable transactions that are rated "noexchange 1" or |
444 |
"anonymousexchange 1" by www.aaa.org. |
445 |
|
446 |
2. User Agent -> Server |
447 |
|
448 |
POST /acme/login HTTP/1.1 |
449 |
Host: www.acme.com |
450 |
[form data] |
451 |
|
452 |
User requests page with embedded IMG SRC reference to |
453 |
"http://www.roadrunnermaps.com/cgi-bin/maps?TER=deserts&FE=cliffs" |
454 |
|
455 |
3. Server -> User Agent |
456 |
HTTP/1.1 200 OK |
457 |
Set-Cookie2: Customer="0000000123"; Max-Age = 94608000; |
458 |
Version="1"; Path="/birds" |
459 |
PICS-Label: (PICS-1.1 "http://www.aaa.org" label |
460 |
by "auditor@aaa.org" gen true |
461 |
for "http://www.acme.com/" |
462 |
exp "1997.12.31T23:59-0000" |
463 |
extension |
464 |
(mandatory |
465 |
"http://www.w3.org/PICS/extensions/cookieinfo-1_0.html") |
466 |
ratings (noshare 1)) |
467 |
|
468 |
A Cookie reflecting the users identity is transmitted with an |
469 |
unsigned trust-label back to the user agent. The Cookie is accepted |
470 |
by the user agent because the rating "noshare 1" is compatible with |
471 |
the user agent privacy preference. |
472 |
|
473 |
4. User Agent -> Server |
474 |
|
475 |
GET cgi-bin/maps?TER=deserts&FE=cliffs HTTP/1.1 |
476 |
Host: www.roadrunnermaps.com |
477 |
|
478 |
|
479 |
|
480 |
|
481 |
Jaye draft-ietf-jaye-trust-state-01.txt [Page 8] |
482 |
|
483 |
|
484 |
INTERNET DRAFT HTTP Trust Mechanism for State Mgt October 23, 1997 |
485 |
|
486 |
|
487 |
User requests an image via CGI script from a third party map |
488 |
provider. This is an unverifiable transaction. |
489 |
|
490 |
5. Server -> User Agent (unverifiable transaction) |
491 |
HTTP/1.1 200 OK |
492 |
Set-Cookie2: Customer="0000000123"; Max-Age = 94608000; |
493 |
Version="1" |
494 |
PICS-Label: (PICS-1.1 "http://www.aaa.org" label |
495 |
by "auditor@aaa.org" gen true |
496 |
for "http://www.roadrunnermaps.com/" |
497 |
exp "1997.12.31T23:59-0000" |
498 |
extension |
499 |
(optional |
500 |
"http://www.w3.org/PICS/extensions/cookieinfo-1_0.html" |
501 |
Customer) |
502 |
extension |
503 |
(mandatory "http://www.w3.org/PICS/DSig/sigblock-1_0.html" |
504 |
("AttribInfo" |
505 |
("http://www.w3.org/PICS/DSig/X509.html" |
506 |
"base64-x.509-cert")) |
507 |
("Signature" "http://www.aaa.org/trust.html" |
508 |
("byName" "aaapublickey") |
509 |
("SigCrypto" |
510 |
"8E53B19D35A3F198930E5D815B235A38930E53FDA815B2158"))) |
511 |
ratings (anonymousexchange 1)) |
512 |
|
513 |
A cookie containing the user's system generated id number is |
514 |
transmitted with a signed label back to user agent. The cookie is |
515 |
accepted by user agent because a cookie rated "anonymous 1" in |
516 |
an unverifiable transaction signed by "http://www.aaa.org" is |
517 |
acceptable to the user agent and the Customer Cookie |
518 |
|
519 |
|
520 |
5. SECURITY CONSIDERATIONS |
521 |
|
522 |
5.1 Revocation of trust-labels |
523 |
|
524 |
A site could receive a trust-label for a particular trust level rating |
525 |
and later change its policies before the trust-label has expired. To |
526 |
address this Trust Authorities should execute agreements with trust |
527 |
label recipients to provide legal remedies to discourage this behavior. |
528 |
|
529 |
5.2 False representation |
530 |
|
531 |
A site could state a privacy practice that it either intentionally or |
532 |
unintentionally does not follow. If the trust-label is not signed by a |
533 |
recognized trust authority, there is no independent verification of the |
534 |
site's adherence to its stated privacy practice. |
535 |
|
536 |
|
537 |
|
538 |
|
539 |
|
540 |
|
541 |
|
542 |
Jaye draft-ietf-jaye-trust-state-01.txt [Page 9] |
543 |
|
544 |
|
545 |
INTERNET DRAFT HTTP Trust Mechanism for State Mgt October 23, 1997 |
546 |
|
547 |
|
548 |
6. SUMMARY |
549 |
|
550 |
This document presents an extension to the state management protocol |
551 |
defined in RFC2109. It describes only changes to that protocol. Any |
552 |
parts of the state management mechanism not explicitly described here |
553 |
are assumed to remain as defined in RFC 2109. |
554 |
|
555 |
The protocol described here allows a user agent to verify that the |
556 |
origin server is using cookies in a manner consistent with the privacy |
557 |
expectations of the user, by providing a trust-label which may be signed |
558 |
by a Trust Authority. |
559 |
|
560 |
|
561 |
7. ACKNOWLEDGEMENTS |
562 |
|
563 |
This document represents contributions by Toby Bloom, as well as input |
564 |
from Dave Kristol, Yaron Goland, Jonathan Stark, and Dan Connolly. |
565 |
|
566 |
|
567 |
8. REFERENCES |
568 |
|
569 |
[PICS] Jim Miller et al, PICS Label Distribution Label Syntax and |
570 |
Communication Protocols, Version 1.1, REC-PICS-labels-961031 |
571 |
http://www.w3.org/PICS/labels.html |
572 |
|
573 |
[Kristol] Kristol, David M., Montulli, Lou, HTTP State Management |
574 |
Mechanism (Rev 1). |
575 |
Internet Draft <draft-ietf-http-state-man-mec-03.txt> |
576 |
ftp://ietf.org/internet-drafts/draft-ietf-http-state-man-mec-03.txt |
577 |
|
578 |
[DSIG] Philip DesAutels et al, DSIG 1.0 Signature Labels, Version 1.0, |
579 |
WD-DSIG-label-970605 |
580 |
http:/www.w3.org/TR/WD-DSIG-label.html/ |
581 |
|
582 |
|
583 |
9. AUTHOR'S ADDRESS |
584 |
|
585 |
Daniel Jaye |
586 |
Engage Technologies |
587 |
100 Brickstone Square, 1st Floor |
588 |
Andover, MA 01810 |
589 |
djaye@engagetech.com |
590 |
978 684-3641 voice |
591 |
978 684-3636 fax |
592 |
|
593 |
|
594 |
|
595 |
|
596 |
|
597 |
|
598 |
|
599 |
|
600 |
|
601 |
|
602 |
|
603 |
Jaye draft-ietf-jaye-trust-state-01.txt [Page 10] |
604 |
|