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

Re: P3P Generic Attribute for XML Applications

From: Mark Nottingham <mark.nottingham@bea.com>
Date: Sun, 25 Apr 2004 23:52:18 -0700
Message-Id: <42209BB2-974E-11D8-A23C-000A95BD86C0@bea.com>
Cc: public-p3p-spec <public-p3p-spec@w3.org>
To: Lorrie Cranor <lorrie@cs.cmu.edu>

Hi Lorrie,

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

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

Does this make sense? I've been away from P3P for a while, so I could 
be off-track.

Cheers,



On Apr 9, 2004, at 6:24 PM, Lorrie Cranor wrote:

> After discussing with Rigo, here is my proposed redraft of 2.5. The 
> P3P Generic Attribute for XML Applications.
>
> Comments?
>
> Lorrie
>
> <xml-generic.html>

--
Mark Nottingham   Principal Technologist
Office of the CTO   BEA Systems
Received on Monday, 26 April 2004 02:53:19 EDT

This archive was generated by hypermail pre-2.1.9 : Monday, 26 April 2004 02:53:21 EDT