W3C home > Mailing lists > Public > public-p3p-spec@w3.org > May 2004

Re: P3P Generic Attribute for XML Applications

From: Lorrie Cranor <lorrie@cs.cmu.edu>
Date: Mon, 3 May 2004 21:07:15 -0400
Message-Id: <6200E33E-9D67-11D8-A400-000A95DA3F5A@cs.cmu.edu>
Cc: public-p3p-spec <public-p3p-spec@w3.org>
To: Mark Nottingham <mark.nottingham@bea.com>


On May 3, 2004, at 6:51 PM, Mark Nottingham wrote:

> Hi Lorrie,
>
>>> P3P 1.0 was designed to associate XML-encoded privacy policies with 
>>> data submitted to Web resources, which are identified by URIs or 
>>> bound to cookies.
>>
>> I think the word "submitted" is too limiting, as P3P also covers log 
>> data that is created as a result of a transaction but might not 
>> really be considered to be submitted, as well as data collected by 
>> client-side scripts. I also think we really are binding a policy to a 
>> URI, or maybe a policy to a URI and all the data associated with it? 
>> I  would be happy with:
>>
>> P3P 1.0 was designed to associate XML-encoded privacy policies with 
>> Web resources, which are identified by URIs or bound to cookies.
>
> Log data is sourced from aspects of the request (e.g., IP address, 
> referer header, etc.), so it's still targeted at the incoming data. 
> How about:
>
> P3P 1.0 was designed to associated XML-encoded privacy policies with 
> data collected by Web resources, which are identified by URIs or bound 
> to cookies.
>
> ?


Hmm... I'm still pondering whether it is accurate to say that P3P binds 
a policy to data as opposed to binding a policy to a URI. I'm hoping 
others will weigh in on this.

>
>>> However, P3P 1.0's mechanisms for identifying the target data for 
>>> privacy policies are limited; in general, they only allow one to 
>>> identify data submitted to a Web resource, and only on the 
>>> granularity of an entire message (e.g., a HTTP request). In some 
>>> cases, this is not sufficient; for example while P3P 1.0 can be used 
>>> to apply a P3P policy to an entire form specified by XForms, it 
>>> cannot be used to apply the policy to a single field on that form.
>>>
>>> To allow for increased granularity, as well as for situations when 
>>> content is not identified with a URI, the P3P 1.1 specification 
>>> provides a new mechanism for associating policy with data in 
>>> XML-based resource description languages such as WSDL and XForms.
>>
>> I think something like that is ok.
>
> Given the above, it might need some tweaking in the second clause half 
> of the first sentence; perhaps
>
> ... in general, they only allow one to identify data associated with 
> HTTP requests, and only on the granularity of an entire message.
>
>
>>> I think you also need to require people who use this attribute in 
>>> their formats to explicitly identify who is required to conform to 
>>> the policy (#1).
>>
>> Wouldn't that be covered by the ENTITY element? Or are you thinking 
>> of something beyond that?
>
> Ah, yes; that should do it. Does ENTITY have some mechanism for 
> identifying an anonymous party (e.g., "Anyone I send THIS message to 
> me MUST conform to this privacy policy)? I'd imagine there are cases 
> where people using this attribute won't want to explicitly enumerate 
> the entity responsible for conforming to the policy.
>

I think it is important that the party responsible for the policy be 
identified. If they are not identified, then it is difficult to find 
them if you have a problem with the way they are following the policy.

Also, P3P is not designed for telling data collectors how to treat 
data; it is designed for data collectors to describe their policies. 
That was part of the point we were trying to make in the XML Generic 
Attribute section. If you have a chunk of XML that you are sending 
around to different places and you want them all to respect your 
privacy you need something other than P3P to describe this (perhaps 
EPAL, perhaps some language based on P3P).

Lorrie
Received on Monday, 3 May 2004 21:07:49 EDT

This archive was generated by hypermail pre-2.1.9 : Monday, 3 May 2004 21:07:50 EDT