Copyright © 2003 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
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.
This is an editors' draft with no standing.
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
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:
- AC020
- 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.
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.
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:
Their interaction in the DNS context is the adopting application that will make use of [P3P].
Throughout this document the following namespaces and identifiers are used.
p3p:Privacy
element that is used in
SOAP headers.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
- may be located in a predefined "well-known" location, or
- a document may indicate a policy reference file through an HTML
link
tag, or- a document may indicate a policy reference file through an XHTML
link
tag, or- 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' xmlns:xsd='http://www.w3.org/2001/XMLSchema' xmlns:my='http://registrar.example.com/2003/ns1' xmlns:xforms='http://www.w3.org/2002/xforms/cr' xmlns='http://www.w3.org/2002/06/xhtml2' 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-REFERENCES> <POLICY-REF about="/w3c/policy-register.xml"> <INCLUDE>/register</INCLUDE> </POLICY-REF> </POLICY-REFERENCES> </META>
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:
link
element as a
recognized indicator of a policy reference file, as is already done for
[XHTML1] in The XHTML
link tag ([P3P], section
2.2.4).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].
rel
attribute to "P3Pv1"href
attribute to the URI of the relevant P3P
policy reference fileNote 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' xmlns:xsd='http://www.w3.org/2001/XMLSchema' xmlns='http://www.w3.org/2002/06/xhtml2' xmlns:xforms='http://www.w3.org/2002/xforms/cr' xmlns:my='http://registrar.example.com/2003/ns1'> <link rel='P3Pv1' href='http://registrar.example.com/w3c/p3p.xml'/> <title>XForms: Order Form</title> <xforms:model id='data'> <xforms:instance> <my:OrderInfo> <my:Privacy my:rel='P3Pv1' my:href='http://registrar.example.com/w3c/p3p.xml'/> <my:PersonalInfo> <my:Name> <my:First/> <my:Middle/> <my:Last/> </my:Name> <my:Address> <my:Street/> <my:City/> <my:State/> <my:Zip/> </my:Address> </my:PersonalInfo> <my:DomainInfo> <my:TLD/> <my:DomainName/> </my:DomainInfo> </my:OrderInfo> </xforms:instance> <!--Submit Info--> <xforms:submission id='submit1' method='post' action='http://registrar.example.com/register'/> </xforms:model> </head>
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'/> <PersonalInfo> <Name> <First>Joseph</First> <Middle>M.</Middle> <Last>Reagle Jr.</Last> </Name> <Address> <Street>200 Tecnology Square</Street> <City>Cambridge</City> <State>MA</State> <Zip>02139</Zip> </Address> </PersonalInfo> <DomainInfo> <TLD>com</TLD> <DomainName>reagle.example</DomainName> </DomainInfo> </OrderInfo>
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.
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-GROUP
s 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:
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.
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:
p3p:recipient
field, P3P itself is not
necessarily used to mediate those subsequent interactions. A P3P
interaction is one-to-one with a focus on the user solicitation.One can consider three variables with respect to the flow of information within a network:
my:Privacy
element.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:
p3p:recipient
.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' xmlns='http://www.w3.org/2003/06/wsdl' xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance' xmlns:my='http://www.w3.org/P3P/2003/p3p-beyond-http/' xmlns:soap='http://www.w3.org/2003/06/wsdl/soap12' targetNamespace='http://registry.example.com/wsdl/register' xsi:schemaLocation='http://www.w3.org/P3P/2003/p3p-beyond-http/ http://www.w3.org/P3P/2003/p3p-beyond-http/wsdl-p3p-extension.xsd http://www.w3.org/2003/06/wsdl http://www.w3.org/2003/06/wsdl/wsdl12.xsd http://www.w3.org/2003/06/wsdl/soap12 http://www.w3.org/2003/06/wsdl/soap12/wsdl12-soap.xsd'> <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> <message name='RegisterDomainNameOutput'> <part element='my:RegistrationStatus' name='body'/> </message> <interface name='RegisterDomainNamePortType'> <operation name='RegisterDomainName' pattern='m2p'> <input message='tns:RegisterDomainNameInput'/> <output message='tns:RegisterDomainNameOutput'/> </operation> </interface> <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'/> <input> <soap:body/> </input> <output> <soap:body/> </output> </operation> </binding> <service name='RegisterService' interface='tns:RegisterDomainNamePortType'> <documentation>Register Service</documentation> <endpoint binding='tns:RegisterDomainNameSoapBinding' name='RegisterDomainNamePort'> <soap:address location='http://registry.example.com/register'/> </endpoint> </service> </definitions>
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' xmlns:xsd='http://www.w3.org/2001/XMLSchema' 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:complexType> <xsd:attribute type='xsd:string' name='rel' use='required'/> <xsd:attribute type='xsd:anyURI' name='href' use='required'/> </xsd:complexType> </xsd:element> </xsd:schema>
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.
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:
INCLUDE
element, the URI of the Web Service's endpoints
[WSDL]..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:
The
Recipient
Element ([P3P], section 3.3.5) provides the following
definition:
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.
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:
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'> <env:Body> <OrderInfo> <Privacy xmlns='http://www.w3.org/P3P/2003/p3p-beyond-http/' rel='P3Pv1' href='http://registrar.example.com/w3c/p3p.xml'/> <PersonalInfo> <Name> <First>Joseph</First> <Middle>M.</Middle> <Last>Reagle Jr.</Last> </Name> <Address> <Street>200 Tecnology Square</Street> <City>Cambridge</City> <State>MA</State> <Zip>02139</Zip> </Address> </PersonalInfo> <DomainInfo> <TLD>com</TLD> <DomainName>reagle.example</DomainName> </DomainInfo> </OrderInfo> </env:Body> </env:Envelope>
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' xmlns:env='http://www.w3.org/2003/05/soap-envelope'> <env:Body> <p:RegistrationStatus> OK </p:RegistrationStatus> </env:Body> </env:Envelope>
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:
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'> </Privacy> </env:Header>
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:
p3p:PURPOSE
's beside p3p:other
are the
most likely to need adaptation to an application context.