Re: P3P Generic Attribute for XML Applications

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.

?

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

Regards,

--
Mark Nottingham   Principal Technologist
Office of the CTO   BEA Systems

Received on Monday, 3 May 2004 18:51:54 UTC