Re: P3P Generic Attribute for XML Applications

Thanks for these comments Mark. A few thoughts...

On Apr 26, 2004, at 2:52 AM, Mark Nottingham wrote:

> To clarify my thoughts a bit, I think there are two interesting things 
> to specify;
>   1) who will conform to the policy
>   2) what data the policy applies to
>
> In P3P 1.0, #1 was always the Web site, and #2 was data submitted to 
> the Web site, as laid out by the various policy reference mechanisms, 
> etc.
>
> When I made the distinction between interfaces and data, I think that 
> what I was trying to say (and hadn't fully thought through) was that 
> in P3P 1.0, #2 is always in relation to an interface, as identified by 
> a URI; ultimately, the policy still applies to data. This effort, as I 
> see it, is to allow greater flexibility in specifying #2, because of 
> that.
>
> So,
>
>> P3P 1.0 was designed to associate XML-encoded privacy policies with 
>> URIs,  sets of URIs, or cookies. P3P 1.0 it well suited for use with 
>> HTML  and XHTML content transmitted over [HTTP] .
>
> I think this would be better stated as:
>
>> 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.


>
> I.e., P3P tells you how a site will handle the data (e.g., form 
> fields, HTTP headers, TCP/IP connection information) sent to a 
> particular interface, which is identified by a URI. The data itself is 
> NOT identified by this URI; there's been talk at the TAG about how you 
> identify the data in a POST, for example; it's clearly separate from 
> the resource identifier.
>
> P3P 1.0 also allows you to refine by method, etc., which I think 
> supports this view.
>
> If that's the case, this:
>
>> However,  P3P 1.0 cannot be used in situations where content is not 
>> associated  with a URI, for example, some applications of Web 
>> Services and XMLP/Soap. In addition,  P3P 1.0 cannot be used in 
>> situations where policies apply to only a  subset of the content 
>> associated with a given URI. 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 only a single form field.
>>
>> The P3P 1.1 Specification provides a new binding mechanism to  allow 
>> for increased granularity beyond the URI level and to allow  policies 
>> to apply to content not associated with a URI.
>
> should be something like:
>
>> 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.

>
> and so forth.
>
> 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?

Lorrie

Received on Monday, 3 May 2004 16:37:48 UTC