P3P: Beyond HTTP

P3P Task Force Report 18 April 2003

This version:
$Revision: 1.49 $ on $Date: 2003/08/06 03:20:01 $ GMT by $Author: hung $
Latest version:
Previous version:
Joseph Reagle <reagle@w3.org>
Patrick C. K. Hung <Patrick.Hung@csiro.au>
Hugo Haas <hugo@w3.org>; Rigo Wenning <rigo@w3.org>; Lorrie Cranor <lorrie@research.att.com>


This document specifies requirements and scenarios of using the Platform for Privacy Preferences [P3P] in contexts other than the Hypertext Transfer Protocol [HTTP], specifically Extensible Markup Language [XML] applications and Web Services, as described on the Beyond HTTP (P3P-BH) Task Force page.

Status of this document

This is an editors' draft with no standing.

Table of Contents

1. Introduction

2. Introducing A Web Application Scenario

2.1 Scenario Definitions

2.2 Namespaces and Identifiers

3. Soliciting Data from the User and Referencing Policies

3.1 XForms and Associating an XML Instance with a P3P Policy

3.2 XForms and More Granular Specification

4. Transferring Data to a Third Party

4.1 The Movement of Information

4.2 Associating with an (Optional) WSDL Description

4.3 The Redundancy of the Policy Reference File in the WSDL Context

4.4 The Scope of the P3P Service Provider and Recipients

4.5 The Scope of Layers and Bindings (HTTP and SOAP)

4.6 Intermediaries

5. Adapting the P3P Vocabulary for the Adopting Application

1. Introduction

Web services are based on a set of XML standards such as Universal Description, Discovery and Integration (UDDI) [UDDI], Web Services Description Language (WSDL) [WSDL2], and Simple Object Access Protocol (SOAP) [SOAP]. The Web Services Architecture Requirements [WSA-REQS] includes specific privacy requirement:

enables privacy protection for the consumer of a Web service across multiple domains and services.
  • AR020.1 the WSA must enable privacy policy statements to be expressed about Web services.
  • AR020.2 advertised Web service privacy policies must be expressed in P3P [P3P]
  • AR020.3 the WSA must enable a consumer to access a Web service's advertised privacy policy statement.
  • AR020.5 the WSA must enable delegation and propagation of privacy policy.
  • AR020.6: Web Services must not be precluded from supporting interactions where one or more parties of the interaction are anonymous.

This document hopes to present a scenario in which these requirements are satisfied via [P3P], or a future version. It includes guidelines for those applications using [P3P] and recommendations for future versions of [P3P] that would make its reuse in those contexts easier.

2. Introducing A Web Application Scenario

An interesting/difficult requirement for Web applications is that of initial data solicitation under a privacy policy and subsequent delegation/propagation of the solicited data under the policy. Our scenario is inspired by:

Our scenario is not intended to be a completely accurate representation of real world requirements, nor does our document necessarily provide a satisfactory solution. Instead, this scenario is intended to be sufficiently representative to serve our primary purpose of exploring generic Web application privacy issues and providing recommendations towards [P3P] reuse in that context.

2.1 Scenario Definitions

Quoting from the PROVREG Charter:

Administration of Domain Name Service (DNS) registration increasingly distinguishes between the operation of a "back-end" registry data base service for registrations, versus "front-end" support services by registrars who interact with registrants and with the registry.  Especially for various Top-Level Domains, the desire is to permit multiple registrars to share access to the database.  Conversely, there is a desire to allow a registrar to access multiple registries via the same protocol, even if the registries differ in operational models.

This scenario has three participants:

User (registrant)
A Web Service End User [WSG] acting as a registrant in order to register the domain name "me.example.com". The User has privacy preferences that govern the circumstances under which he is willing to release. The user interacts with a Web Service via his agent which might be a local Client [WSG] or network proxy which acts in his interest, see An Agent or a Service? [R98].
Soliciting Service (registrar)
A Web Service [WSG] that offers an interface to users for requesting domain name registration. The registrar acts as an intermediary between the User and subsequent ("onward") Recipient and can offer other value added services associated with the registry. The service has privacy policies that govern the use of collected user data.
Recipient Service (registry)
A Web Service [WSG] that offers an interface to registrars for registering and maintaining domain name registrations. The registry is the participant responsible for managing the database for a DNS Top-Level Domain (TLD) such as ".com". This service has privacy policies as well.

Their interaction in the DNS context is the adopting application that will make use of [P3P].

2.2 Namespaces and Identifiers

Throughout this document the following namespaces and identifiers are used.

The namespace of the example order form from the registrar.
The location of the registar's P3P policy reference file
The location of the registrar's P3P policy
The targetNamespace for the registry's WSDL
The location of the registry's P3P policy.
The namespace of the registry's SOAP response.
The namespace of the p3p:Privacy element that is used in SOAP headers.

3. Soliciting Data from the User and Referencing Policies

In our scenario, information is solicited from the User by the Soliciting Service (registrar) so as to register the user's domain name. This section describes how a policy can be made known to the user agent.

Referencing Policies ([P3P], section 2) provides four mechanisms for indicating the privacy policy of a site, the policy reference file

  1. may be located in a predefined "well-known" location, or
  2. a document may indicate a policy reference file through an HTML link tag, or
  3. a document may indicate a policy reference file through an XHTML link tag, or
  4. through an HTTP header.

In our scenario, the Soliciting Service has a P3P Policy Reference at the following URI:

<link xmlns:ev='http://www.w3.org/2001/xml-events' 
      rel='P3Pv1' href='http://registrar.example.com/w3c/p3p.xml'/>

Adopting applications that rely upon a data format other than The Extensible Hypertext Language 1.0 [XHTML1] to solicit information SHOULD support the first (well known location) and fourth (HTTP header) mechanisms; adopting applications MUST NOT ever (mistakenly) release information to an application it is not familiar with on the basis of P3P mechanisms that it is familiar with. Adopting applications MAY provide a means of associating a policy reference file with their own format.

The P3P Policy Reference (p3p.xml) specifies the URLs for which the policy applies:

<META xmlns="http://www.w3.org/2002/01/P3Pv1">
  <POLICY-REF about="/w3c/policy-register.xml">

3.1 XForms and Associating an XML Instance with a P3P Policy

In our scenario, information is solicited from the user via [XForms], a powerful means of specifying a form for data collection, validation, and transmission to a service.

[XForms] is expected to be adopted by [XHTML2] which itself includes a link tag. Consequently:

However, the exact specification of the [XHTML2] link element has not yet been resolved. Originally, [XHTML2] defined a link element in its own namespace. However that community is now considering the requirements and features of [XLink] in the [XHTML2] context. Applications other than XHTML2 will also be able to take advantage of XForms, or different solicitation mechanisms, and MAY also define their own indication mechanisms. If they do so, such applications SHOULD follow the results of the XHTML2 and XLink discussion.

In any case, adopting applications from the XHTML family using version "1.0" of P3P SHOULD employ the resulting link tag as indicated in [P3P].

Note the link tag in the following example fragment (xhtml-xform.html) of a P3P policy associated with an XHTML2 document with an XForm:

<head xmlns:ev='http://www.w3.org/2001/xml-events' 
 <link rel='P3Pv1' href='http://registrar.example.com/w3c/p3p.xml'/>
 <title>XForms: Order Form</title>
 <xforms:model id='data'>
    <my:Privacy my:rel='P3Pv1' my:href='http://registrar.example.com/w3c/p3p.xml'/>
  <!--Submit Info-->
  <xforms:submission id='submit1' method='post' action='http://registrar.example.com/register'/>

Not only is the URI of the policy reference included in the soliciting link, but in our example scenario it's associated with the return of data below, as indicated by the Privacy element in the resulting serialized XML from the form submission (order.xml):

<?xml version='1.0' encoding='UTF-8'?>
<OrderInfo xmlns='http://registry.example.com/2003/ns1'>
 <Privacy rel='P3Pv1' href='http://registrar.example.com/w3c/p3p.xml'/>
   <Last>Reagle Jr.</Last>
   <Street>200 Tecnology Square</Street>

If this feature of "tagging" collected information becomes common, future versions of P3P should consider whether the tag should be the URI of the policy reference file, or the policy itself. Though not reflected in the example above because the policy reference file only has one policy, we recommend that the URI of the actual policy be indicated, otherwise it can be ambiguous to subsequent recipients as to which of many policies specified in a policy reference file apply to a given set of data. However, if this is to be implemented via XForms (as above), this requires the actual Form to specify the relevant policy; this is counter to the feature of the policy reference file that permits the content of a site (i.e,. Web pages) to be abstracted from the management of the corresponding privacy policies for that site. Perhaps one way to maintain a level of indirection for the purposes of management, but also identify the specific policy which data was collected under would be to add an id attribute to the POLICY-REF element, which then could be referenced in "tagged" data as it is redistributed. Further discussion of "tagging" collected information is out of scope for this document.

3.2 XForms and More Granular Specification

As specified in Applying a Policy to a URI ([P3P], section 2.3.3), a policy applies to all data resulting from instantiating a method (e.g., GET, PUT, POST) for a URI:

A policy reference file specifies the policy which applies to a given URI. In other words, the indicated policy describes all effects of dereferencing the given URI (in some cases, with the appropriately specified METHOD).

DATA-GROUPs and DATA elements must be used to enumerate all data yielded; it does not provide a mechanism to associate subsets of that data with different policies. However, some have expressed an interest in such a feature. For example, in our scenario one might want to associate the my:PersonalInfo element and its children with a different policy than that of the my:DomainInfo element and its children, even though they are submitted to the same URI. A number of approaches to implementing this feature have been proposed:

  1. Maintain the existing [P3P] specification and require different data subsets to use a different form.
  2. Alter the Policy Reference File specification such that it not only specifies the URI to which a policy applies, but also the data subsets via something like [XPointer].
  3. Provide a mechanism whereby the a policy can be associated with data subsets via their schema. However, it's not yet clear how much demand is for this requirement.

4. Transferring Data to a Third Party

So far in our scenario, data has been solicited by the Soliciting Service (registrar) from the User using somewhat traditional mechanisms: XHTML and XForms are not yet very common but are also not that different from how P3P expects to work with present day HTML forms. This section addresses the subsequent exchange of that information between the Soliciting Service (registrar) and the Recipient Service (registry) using Web Service mechanisms.

4.1 The Movement of Information

In an intermediary scenario, data (defined broadly to include service privacy privacies, and personal information and privacy preferences) may move in many directions between the parties of the transaction. There are numerous models of interaction between the participants and the flows of information. For example:

One can consider three variables with respect to the flow of information within a network:

Direction of Flow
In [P3P], policies flow to the user agent, preferences stay local to the user agent, and information flows to services. One can also conceive of an exchange in which a user publishes his preferences and services must agree to them, or user preferences accompany user information in its journey — as we've also done in our example scenario via my:Privacy element.
Points of Decision
In [P3P], the user's agent (the point of decision) is typically his network client. However, one can also imagine a trusted network service acting as the user's agent (managing the user's identity, information and enforcing his preferences). In [PROVREG] and [EPAL], " services themselves are exchanging policies and making decisions.
Points of Aggregation
A service which solicits information from a user for redistribution to other services might choose to first collect and combine the policies of its peers and represent the p3p:recipients as having the "same" policy, or it might ask for separate parcels of information under a different policy corresponding to each of the recipients which it transfers data to.

The adopting application should make the interaction with respect to these information flows as simple as possible to the user:

  1. Where information flows to multiple recipients applications via node-to-node exchanges, applications SHOULD present a single interface to the user and aggregate recipient policies if possible or otherwise disclose their policies with p3p:recipient.
  2. Where the information flows in an end-to-end relationship through various intermediaries with inoffensive policies and the user has a relation with that single end point, applications CAN also present the policies of the final recipient with themselves as transparent intermediaries. (See Intermediaries below.)

4.2 Associating with an (Optional) WSDL Description

An optional feature a Web service is to offer potential clients a Web Service Definition Lanaguage [WSDL2] description of its capabilities prior to interaction. Or, it might list itself in a Universal Description Discovery & Integration [UDDI] directory such that user agents can peruse a description in order to select the most appropriate service. For example the Recipient Service (registry) might use its describe its capabilities for use by a Soliciting Service (registrar).

An obvious question in these circumstances is should a privacy statement be included in a [WSDL2] description or [UDDI] entry? This would certainly be useful to web service clients that want to select services on the basis of a privacy practice.

Given that a WSDL description or UDDI entry is OPTIONAL to the Web Service, associating a privacy policy with these descriptions is OPTIONAL. However, when optional associations are provided, the adopting applications MUST ensure that multiple associations do not conflict with each other or the normative declaration from the application, via the Non-ambiguity requirement of ([P3P], section 2.4.1), "Sites MUST be cautious in their practices when they declare multiple policies for a given URI, and ensure that they can actually honor all policies simultaneously."

The following is an WSDL service description (wsdl-eg.xml):

<?xml version='1.0' encoding='UTF-8'?>
<definitions xmlns:tns='http://registry.example.com/register.wsdl' 
 <import namespace='http://www.w3.org/P3P/2003/p3p-beyond-http/' location='wsdl-p3p-extension.xsd'/>
 <my:Privacy rel='P3Pv1' href='http://registry.example.com/P3P/policy-register.xml'/>
 <message name='RegisterDomainNameInput'>
  <part element='my:OrderInfo' name='body'/>
 <message name='RegisterDomainNameOutput'>
  <part element='my:RegistrationStatus' name='body'/>
 <interface name='RegisterDomainNamePortType'>
  <operation name='RegisterDomainName' pattern='m2p'>
   <input message='tns:RegisterDomainNameInput'/>
   <output message='tns:RegisterDomainNameOutput'/>
 <binding name='RegisterDomainNameSoapBinding' interface='tns:RegisterDomainNamePortType'>
  <soap:binding transport='http://www.w3.org/2003/05/soap/bindings/HTTP/'/>
  <operation name='RegisterDomainName'>
   <soap:operation soapAction='http://registry.example.com/RegisterService/RegisterDomainName'/>
 <service name='RegisterService' interface='tns:RegisterDomainNamePortType'>
  <documentation>Register Service</documentation>
  <endpoint binding='tns:RegisterDomainNameSoapBinding' name='RegisterDomainNamePort'>
   <soap:address location='http://registry.example.com/register'/>

Note that the WSDL description includes the P3P policy of the Recipient Service (registry). The following is the schema for our WSDL Privacy extension (wsdl-p3p-extension.xsd):

<?xml version='1.0' encoding='UTF-8'?>
<xsd:schema xmlns:wsdl='http://www.w3.org/2003/06/wsdl' 
            elementFormDefault='qualified' targetNamespace='http://www.w3.org/P3P/2003/p3p-beyond-http/'>
 <xsd:import namespace='http://www.w3.org/2003/06/wsdl' schemaLocation='http://www.w3.org/2003/06/wsdl'/>
 <xsd:element name='Privacy' substitutionGroup='wsdl:globalExt'>
   <xsd:attribute type='xsd:string' name='rel' use='required'/>
   <xsd:attribute type='xsd:anyURI' name='href' use='required'/>

Note, that creating our WSDL privacy extension (i.e., understanding and testing it given the various tool on hand) was more difficult than expected; the editors also understand the WSDL extension mechanism is under discussion by the WSDL WG for this same reason.

4.3 The Redundancy of the Policy Reference File in the WSDL Context

In the immediately preceding example the WSDL description directly references a policy, not a policy reference file. A P3P Policy Reference includes an EXPIRY element that designates the life-time of the policy reference file (this element is also available in the policy itself to describe its expiration), and actual policies as they apply to a collection of paths on a web site via the INCLUDE and EXCLUDE elements. This is appropriate for browsing a Web site, but may be redundant when it comes to Web services in which their interfaces can already be explicitly specified (and any associated features) via a Web Service Definition Lanaguage [WSDL2].

Future versions of P3P should consider whether the policy reference file should be deprecated in the Web Service context. Presently, we feel it's premature to provide a strong recommendation but note that:

4.4 The Scope of the P3P Service Provider and Recipients

There are two concepts within [P3P] that affect the scope of identity for participants in our scenario: the Service Provider and the Recipient.

Terminology ([P3P], section 1.3) provides the following definition:

Service Provider (Data Controller, Legal Entity)
The person or legal entity which offers information, products or services from a Web site, collects information, and is responsible for the representations made in a policy.

The Recipient Element ([P3P], section 3.3.5) provides the following definition:

Each STATEMENT element that does not include a NON-IDENTIFIABLE element MUST contain a RECIPIENT element that contains one or more recipients of the collected data. Sites MUST classify their recipients into one or more of the six recipients specified.

The adopting application should carefully consider the delineation of participants in multi-party and intermediary scenarios as either a constituent of the Service Provider and disclosed via p3p:ours, or a different entity treated under one of the other p3p:Recipient values.

4.5 The Scope of Layers and Bindings (HTTP and SOAP)

Does the P3P policy belong at the SOAP level, or HTTP? In the majority of cases SOAP will be transported over HTTP, what happens if both collect data? Given that a higher level application will likely know its dependencies, but its dependencies will not know the characteristics of those using them:

Adopting applications MUST specify where relevant P3P statements can be found. We RECOMMEND that normative association (not including WSDL or UDDI) be limited to the higher/application layer. We RECOMMEND that a higher/abstract layer MAY include the privacy policy of layers it is dependent upon, but that lower layers SHOULD NOT represent the policies of higher layers. For example, an application that transfers data with SOAP over HTTP that uses cookies, SHOULD specify:

  1. the P3P policy associated with SOAP is normative and includes the HTTP cookie usage, or
  2. there are distinct P3P policies associated with the SOAP and HTTP layers.

In either case, the privacy policy associated with SOAP might be represented explicitly within the SOAP XML instance (RECOMMENDED), or its HTTP binding. (In the second case of distinct policies, and if the SOAP feature is represented in the HTTP binding, there might be two P3P related HTTP headers! one from the SOAP binding and another from [P3P] governing the use of the cookie.) Again, the Non-ambiguity requirement of ([P3P], section 2.4.1) MUST be respected, "Sites MUST be cautious in their practices when they declare multiple policies for a given URI, and ensure that they can actually honor all policies simultaneously." Furthermore, SOAP Features ([SOAP], section 1.3) states that:

The processing of SOAP envelopes in accordance with the SOAP Processing Model (see 2. SOAP Processing Model) MUST NOT be overridden by binding specifications. It is recommended that, where practical, end-to-end features be expressed as SOAP header blocks, so that the rules defined by the SOAP Processing Model can be employed.

The registrar makes a request of the registry (soap-registrar2registry.xml):

<?xml version='1.0' encoding='UTF-8'?>
<env:Envelope xmlns='http://registry.example.com/2003/ns1' xmlns:env='http://www.w3.org/2003/05/soap-envelope'>
   <Privacy xmlns='http://www.w3.org/P3P/2003/p3p-beyond-http/' rel='P3Pv1' href='http://registrar.example.com/w3c/p3p.xml'/>
     <Last>Reagle Jr.</Last>
     <Street>200 Tecnology Square</Street>

The response (soap-registry2registrar.xml) may look like this:

<?xml version='1.0' encoding='UTF-8'?>
<env:Envelope xmlns:p='http://registry.example.com/RegisterService/RegisterDomainName' 

4.6 Intermediaries

Even before data makes it to the Service Provider and its p3p:Recipients, if any, the information might travel through various intermediaries in order to reach its destination. P3P Policies ([P3P], Section 1.1.3) speaks to these cases as follows:

P3P policies represent the practices of the site. Intermediaries such as telecommunication providers, Internet service providers, proxies and others may be privy to the exchange of data between a site and a user, but their practices may not be governed by the site's policies. In addition, note that each P3P policy is applied to specific Web resources (Web pages, images, cookies, etc.) listed in a policy reference file. By placing one or more P3P policies on a Web site, a company or organization does not make any statements about the privacy practices associated with other Web resources not mentioned in their policy reference file, with other on-line activities that do not involve data collected on Web sites covered by their P3P policy, or with off-line activities that do not involve data collected on Web sites covered by their P3P policy.

This semantic continues to stand in circumstances "beyond HTTP." However, we may now make the following recommendation:

  1. Adopting applications that want to ensure the privacy of user information SHOULD take steps to ensure that no information is released to a network intermediary that is not covered by its P3P policy. This may be expressed via policy (such as [SOAP] headers) or ensured via various end-to-end mechanisms such as session security (e.g., Transport Layer Security [TLS]) or document security (e.g., XML Encryption [XENC]).
  2. A future version of P3P SHOULD consider specifying a privacy policy that should be used by transparent active intermediaries. For example, a "P3P Policy for SOAP intermediaries" that only permits the data to be used for the "current purpose/admin and no retention" that SOAP intermediaries MUST use?

For example, the following SOAP envelope (soap-registrar2intermediary2registry.xml) contains a header indicating that SOAP intermediaries MUST respect the privacy policy of the registrar during transport because of the Privacy element in the env:Header:

<env:Header xmlns='http://www.w3.org/P3P/2003/p3p-beyond-http/' 
            xmlns:env='http://www.w3.org/2003/05/soap-envelope' id='header'>
 <Privacy rel='P3Pv1' env:role='http://www.w3.org/2003/05/soap-envelope/role/next' 
          env:mustUnderstand='true' href='http://registrar.example.com/w3c/p3p.xml'>

5. Adapting the P3P Vocabulary for the Adopting Application

It is likely that in many web service scenarios applications will wish to adapt the P3P vocabulary to their own circumstances. From our brief and informal review of such reuse (i.e., P3P and Other Vocabulary Differences) we make the following comments:

  1. A future version of P3P SHOULD provide guidance on extending and restricting the P3P 1.0 [P3P] vocabulary via schema mechanisms.
    1. p3p:PURPOSE's beside p3p:other are the most likely to need adaptation to an application context.
  2. Adopting applications MUST never change the meaning of any semantic from the [P3P] namespace and SHOULD use its syntax semantics whenever possible.


Enterprise Privacy Authorization Language (EPAL). Paul Ashley, Satoshi Hada, Günter Karjoth, Calvin Powers, and Matthias Schunter. IBM Research Report, 2003-05-05.
Hypertext Transfer Protocol -- HTTP/1.1. R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, and T. Berners-Lee. 1999-06.
The Platform for Privacy Preferences 1.0 (P3P1.0) Specification. Lorrie Cranor, Massimo Marchiori, Martin Presler-Marshall, and Joseph Reagle. W3C REC, 2002-04-16.
Extensible Provisioning Protocol. S. Hollenbeck. IETF Draft, 2003-03-11.
The TLS Protocol (1.0). T. Dierks, and C. Allen. IETF Proposed Standard, 1999-01.
SOAP Version 1.2 Part 1: Messaging Framework.Martin Gudgin, Marc Hadley, Noah Mendelsohn, Jean-Jacques Moreau, and Henrik Frystyk Nielsen. W3C WD, 2003-06-24.
UDDI Version 3.0. Tom Bellwood, Luc Clément, David Ehnebuske, Andrew Hately, Maryann Hondo, Yin Leng Husband, Karsten Januszewski, Sam Lee, Barbara McKee, Joel Munter, and Claus von Riegen. Oasis Committee Specification, 2002-07-19.
Web Services Architecture Usage Scenarios. Hugo Haas, and David Orchard. W3C WD, 2003-05-14.
Web Services Description Language (WSDL) Version 1.2 Part 1: Core Language. Roberto Chinnici, Martin Gudgin, Jean-Jacques Moreau, and Sanjiva Weerawarana. W3C WD, 2003-06-11.
Web Services Glossary. Allen Brown, and Hugo Haas. W3C WD, 2003-05-14.
XML Encryption Syntax and Processing. Donald Eastlake, and Joseph Reagle. W3C REC, 2002-12-10.
XForms 1.0. Roland Merrick, T. V. Raman, Micah Dubinko, and Leigh L. Klotz. W3C CR, 2002-11-12.
XHTML 1.0 The Extensible HyperText Markup Language (Second Edition). Steven Pemberton et al. W3C REC, 2002-08-01.
XHTML 2.0. Ann Navarro, Steven Pemberton, Jonny Axelsson, Beth Epperson, Masayasu Ishikawa, and Shane McCarron. W3C WD, 2003-05-06.
XML Linking Language (XLink) Version 1.0. Steven DeRose, Eve Maler, and David Orchard. W3C REC, 2001-06-27.
Extensible Markup Language (XML) 1.0 (Second Edition). Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, and Eve Maler. W3C REC, 2000-10-06.
XPointer Framework. Paul Grosso, Eve Maler, Jonathan Marsh, and Norman Walsh. W3C REC, 2003-03-25.