Copyright © 2004 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
This document discusses how to handly privacy in WSDL 2.0 and shows a possible solution using the P3P generic attribute and a WSDL 2.0 feature in order to express a Web service provider entity's privacy policy.
This section describes the status of this document at the time of its publication. Other documents may supersede this document.
This document is made available for discussion by the community. Comments on this document should be sent to the www-ws@w3.org mailing list (www-ws public archive).
By publishing this document, Hugo Haas and Rigo Wenning have made a formal submission to W3C for discussion. Publication of this document by W3C indicates no endorsement of its content by W3C, nor that W3C has, is, or will be allocating any resources to the issues addressed by it. This document is not the product of a chartered W3C group, but is published as potential input to the W3C Process. Please consult the complete list of acknowledged W3C Team Submissions.
1 Introduction
2 Granularity and application of privacy policies in a service description
2.1 WSDL 2.0 component model
2.2 Privacy policies and components
2.3 Application of a privacy policy
3 Semantics of a privacy policy on WSDL 2.0
components
3.1 Type definitions
3.2 WSDL 2.0's input message reference component
and infault fault reference component
3.3 WSDL 2.0's interface operation component
3.4 WSDL 2.0's interface component
3.5 WSDL 2.0's binding operation component
3.6 WSDL 2.0's binding component
3.7 WSDL 2.0's endpoint component
3.8 WSDL 2.0's service component
3.9 WSDL 2.0 definitions
3.10 Other WSDL 2.0 components
4 Processing of a WSDL 2.0 document with attached P3P privacy policies
4.1 WSDL processing by the requester entity
4.2 Resolution of policy conflicts
5 Two ways of attaching P3P policies to WSDL 2.0 components
5.1 Use of the P3P generic attribute in WSDL 2.0
5.1.1 P3P generic attribute and attribute-based extensibility
5.1.2 Example of use of the P3P generic attribute
5.2 Use of a WSDL 2.0 feature
5.2.1 Definition of the P3P feature
5.2.2 Example of use of the P3P feature
6 References
A Acknowledgements (Non-Normative)
The same way Web sites have privacy policies, Web services may raise privacy concerns, as shown in section 2 and 4 of [P3PBH]. Users of Web services may want to know how and for what purpose their personal data will be used before deciding to use a service.
The Platform for Privacy Preferences Project (P3P) enables Web sites to express their privacy practices in a standard format that can be retrieved automatically and interpreted easily by user agents. P3P user agents will allow users to be informed of site practices (in both machine- and human-readable formats) and to automate decision-making based on these practices when appropriate. Thus users need not read the privacy policies at every site they visit.
The Web Services Description Language (WSDL) 2.0 [WSDL2.0] is an XML language for describing Web services. When used in combination with P3P, one can express the privacy policy of a Web service.
This document proposes two ways to express (3 Semantics of a privacy policy on WSDL 2.0 components) and process (4 Processing of a WSDL 2.0 document with attached P3P privacy policies) privacy policies in WSDL 2.0. One way is to use the generic P3P attribute of the Platform for Privacy Preferences 1.1 (P3P1.1) Specification [P3P1.1] to extend a WSDL 2.0 description to attach provider entities' privacy policies (5.1 Use of the P3P generic attribute in WSDL 2.0). The other way is to use a WSDL 2.0 feature (5.2 Use of a WSDL 2.0 feature).
The Web services terms used in this document are defined in the Web Services Glossary [WS Gloss].
A Web services interaction may require the transfer of personal information from a requester entity to a provider entity via messages exchanged between their corresponding requester and provider agents. The format and specifics of these message exchanges are described in WSDL 2.0 by use of the WSDL 2.0 Component Model. The Component Model defines several components:
the format of the messages exchanged are described using a schema language;
messages are associated with interface operations forming message exchange patterns;
interfaces describe sets of messages that a service sends and/or receives, and are expressed as a set of interface operations;
bindings represent the binding of an interface, which is abstract, with a concrete message format and transmission protocol (e.g. SOAP 1.2 over HTTP/1.1);
endpoints are network locations (URL) at which a binding of an interface is available;
finally, the set of endpoints described is logically grouped into a service.
In such a model, different components may have different privacy policies applying to them.
Different privacy policies may be attached to different WSDL 2.0 components.
For example, a message may contain information for which different policies apply, e.g. a DNS domain name versus a physical address (geographic location) versus a credit card number.
As another example, the implementation of a service might be done with different privacy policies. An endpoint might be collecting private information, while another, implementing the same interface with the exact same binding, might be logging access for audit purposes; a third one, still providing the same service, may not be keeping any kind of record of the transactions processed.
Also, one might want to specify a privacy policy of a particular binding to certain values, e.g. because of some characteristics of the implementation used by all the endpoints.
Therefore, for each WSDL 2.0 component requiring transfer of personal data, one might want to associate a privacy policy to describe the use of the data exchanged.
In the context of Web services, while the requester entity may have privacy concerns about the data that is being exchanged, the provider entity may also have similar concerns. The requester entity could indeed be itself a provider entity wanting to re-process the data received.
One can therefore imagine privacy policies applying to a a requester entity as well as privacy policies applying to a provider entity. In this case, the provider entity becomes a requester from the point of view of P3P.
For the purpose of this specification, we limit ourselves to privacy policies that constrain the provider entity. This is a limitation, and further work needs to be done to take requester entities into account from the point of view of privacy.
The privacy policies applied must mention all the purposes of the related operations and also the recipients of the data if the operation consists in passing on the data to third parties.
The corresponding categories and/or data elements have to be used. While categories of data are fixed and cannot be extended, P3P provides an exentsible data schema for unknown types.
If the data is an unique identifier, all data collection linked to that identifier must also be declared.
In WSDL 2.0, the type definitions property is a set of named type definitions, each one isomorphic to a simple or complex type as defined by XML Schema.
A privacy policy may be attached to the type definitions of XML elements or their descendants. When a privacy policy is attached to a type definition, it applies to the message data corresonding to that type definition, including any attributes and descendents.
input message reference component
and infault fault reference componentA privacy policy that is attached to an input or infault reference component applies to all data, sent from the requester agent to the provider agent, that corresponds to that input or infault.
A privacy
policy that is attached to an interface operation component applies to all data, sent from the requester agent to the provider agent, that corresponds to any input or infault of the interface operation,
i.e. included in any of the set of (ordinary and fault)
messages being exchanged as part of the operation and
represented by its input and infault,
children elements.
A privacy policy
that is attached to an interface component applies to all data, sent from the requester agent to the provider agent, that corresponds to any in input or infault of any interface operation defined for that interface.
A privacy policy that is attached to a binding
operation component applies to all data, sent from the
requester agent to the provider agent using the specified
concrete binding, that corresponds to
any input or infault of the interface
operation bound, including all network traffic data
collected along the exchange by the provider entity.
The policy applies both to the message and any headers that the concrete binding may define.
A privacy policy that is attached to a binding
component applies to all data, sent from the requester
agent to the provider agent using the specified concrete binding,
that corresponds to any in input or infault of any
interface operation defined for the interface bound, including all network traffic data
collected along the exchange by the provider entity.
The policy applies both to the message and any headers that the concrete binding may define.
A privacy policy that is attached to an endoint component applies to all data, sent from the requester agent to the provider agent, that is sent through the specified endpoint.
A privacy policy
that is attached to a service component applies to all data, sent from the requester agent to the provider agent, that is sent through any endpoint represented
by the service component's endpoint children elements.
A privacy policy that is attached to the definitions component applies to all components contained by that element.
A WSDL 2.0 feature component is an extensibility mechanism defined by [WSDL2.0] as "an abstract piece of functionality typically associated with the exchange of messages between communicating parties". Since the semantics of the feature are defined by the owner of the feature's namespace (rather than the WSDL 2.0 specification), it is unclear what a privacy policy would mean if it were attached to a feature component.
As explained in 2.3 Application of a privacy policy, for the purpose of
this document, a privacy policy cannot be attached to an
output message reference component nor an
outfault fault reference component.
This section explains how to process a WSDL 2.0 document containing privacy policies.
A WSDL 2.0 processor with support for P3P privacy policies must evaluate the P3P policies referenced in a WSDL 2.0 document before triggering a request or transferring data. If a request needs to be made before evaluation (e.g. to get the policy), the requester agent should conform to the requirements specified in the P3P 1.1 safe zone section.
If the policies found do not match the requester entity's privacy preferences, the requester agent must raise a fault.
As shown in 3 Semantics of a privacy policy on WSDL 2.0 components, privacy policies can be expressed on a number of components, and each component references other components that might themselves have a privacy policy associated with them.
When multiple P3P policy declarations are encountered for the same piece of data (e.g. on an interface operation and on the interface referencing this interface operation), the requester entity should assume that all of these policies apply as the provider entity must honor all of them, as per P3P's non-ambiguity requirement.
This section explains how to attach privacy policies to WSDL 2.0 components.
This section constrains the use of the P3P generic attribute that is used on WSDL 2.0 components.
Using WSDL 2.0's attribute-base extensibility mechanism, privacy policies can be attached to WSDL 2.0 components, as defined in 3 Semantics of a privacy policy on WSDL 2.0 components, using the P3P generic attribute defined in the P3P Generic Attribute for XML Applications section of [P3P1.1]. When used in this context, the P3P Generic Attribute for XML Applications indicates the privacy implications associated with the data transfer that is described by the information item to which it is attached, as explained in 3 Semantics of a privacy policy on WSDL 2.0 components.
This document does not specify precedence of policies yet, but future versions of it might privilege policies on outer elements over policies of sub-elements or vice-versa.
This section shows an example of use of the P3P generic attribute on a WSDL 2.0 document. The service provides simple update operations to a database containing personal information.
The following WSDL 2.0 document describes both the message format, protocol and end point used by the service, and the privacy policies applying to the information transferred from the requester agent to the provider agent:
<?xml version="1.0"?>
<definitions xmlns="http://www.w3.org/2003/11/wsdl"
xmlns:myns="http://example.org/myservice"
xmlns:mytypes="http://example.org/myservice-types"
xmlns:p3patt="http://www.w3.org/2004/02/P3Pv11"
xmlns:soap="http://www.w3.org/2003/06/wsdl/soap12"
targetNamespace="http://example.org/myservice" >
<documentation>
<div xmlns="http://www.w3.org/1999/xhtml">
<h1>Sample service definition showing the use of the P3P generic
attribute.</h1>
<p>This document describes a simple service allowing updates of
personal information (address, phone number) in a database.</p>
<p>The P3P generic attribute is used to express different
privacy policies.</p>
</div>
</documentation>
<types>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://example.org/myservice-types">
<xsd:complexType name="telMess">
<xsd:sequence>
<xsd:element name="id" type="xsd:anyURI"
p3patt:p3p="http://example.com/p3p-pol1.xml" />
<xsd:element name="phonenumber" type="xsd:anyURI"
p3patt:p3p="http://example.com/p3p-pol2.xml" />
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="addrMess">
<xsd:sequence>
<xsd:element name="id" type="xsd:anyURI"/>
<xsd:element name="address" type="mytypes:addrStruct"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="addrStruct">
<xsd:sequence>
<xsd:element name="name" type="xsd:string"/>
<xsd:element name="street" type="xsd:string"/>
<xsd:element name="city" type="xsd:string"/>
<xsd:element name="state" type="xsd:string"/>
<xsd:element name="zip" type="xsd:decimal"/>
</xsd:sequence>
<xsd:attribute name="country" type="xsd:string"/>
</xsd:complexType>
<xsd:simpleType name="statusCode">
<xsd:restriction base="xsd:anyURI">
<xsd:enumeration value="http://example.org/status/OK"/>
<xsd:enumeration value="http://example.org/status/Pending"/>
<xsd:enumeration value="http://example.org/status/Failed"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:complexType name="updateMess">
<xsd:sequence>
<xsd:element name="id" type="xsd:anyURI"/>
<xsd:element name="status" type="mytypes:statusCode"/>
</xsd:sequence>
</xsd:complexType>
<xsd:element name="telUpdate" type="mytypes:telMess"/>
<xsd:element name="addrUpdate" type="mytypes:addrMess"/>
<xsd:element name="updateResp" type="mytypes:updateMess"/>
</xsd:schema>
</types>
<interface
name="Interface">
<operation
name="OperationTel"
pattern="http://www.w3.org/2003/11/wsdl/in-out">
<input message="mytypes:telUpdate"/>
<output message="mytypes:updateResp"/>
</operation>
<operation
name="OperationAddr"
pattern="http://www.w3.org/2003/11/wsdl/in-out"
p3patt:p3p="http://example.com/p3p-pol1.xml">
<input message="mytypes:addrUpdate"/>
<output message="mytypes:updateResp"/>
</operation>
</interface>
<binding name="SoapBinding" interface="myns:Interface">
<soap:binding protocol="http://www.w3.org/2003/05/soap/bindings/HTTP/"/>
</binding>
<service
name="ExampleService"
interface="myns:Interface">
<endpoint
name="Endpoint1"
binding="myns:SoapBinding">
<soap:address location="http://ws.example.org/myservice" />
</endpoint>
</service>
</definitions>with privacy policy #1 (http://example.com/p3p-pol1.xml) expressing that HTTP logs are retained for system administration purposes:
<POLICIES xmlns="http://www.w3.org/2002/01/P3Pv1">
<POLICY name="nice"
discuri="http://example.com/pol1.html"
xml:lang="en">
<ENTITY>
<DATA-GROUP>
<DATA ref="#business.name">CatalogExample</DATA>
<DATA ref="#business.contact-info.postal.street">4000 Lincoln Ave.</DATA>
<DATA ref="#business.contact-info.postal.city">Birmingham</DATA>
<DATA ref="#business.contact-info.postal.stateprov">MI</DATA>
<DATA ref="#business.contact-info.postal.postalcode">48009</DATA>
<DATA ref="#business.contact-info.postal.country">USA</DATA>
<DATA ref="#business.contact-info.online.email">catalog@example.com</DATA>
<DATA ref="#business.contact-info.telecom.telephone.intcode">1</DATA>
<DATA ref="#business.contact-info.telecom.telephone.loccode">248</DATA>
<DATA ref="#business.contact-info.telecom.telephone.number">3926753</DATA>
</DATA-GROUP>
</ENTITY>
<ACCESS><nonident/></ACCESS>
<DISPUTES-GROUP>
<DISPUTES resolution-type="independent"
service="http://www.PrivacySeal.example.org"
short-description="PrivacySeal.example.org">
<IMG src="http://www.PrivacySeal.example.org/Logo.gif" alt="PrivacySeal's logo"/>
<REMEDIES><money/></REMEDIES>
</DISPUTES>
</DISPUTES-GROUP>
<STATEMENT>
<PURPOSE><admin/></PURPOSE>
<RECIPIENT><ours/></RECIPIENT>
<RETENTION><stated-purpose/></RETENTION>
<DATA-GROUP>
<DATA ref="#dynamic.interactionrecord"/>
</DATA-GROUP>
</STATEMENT>
</POLICY>
</POLICIES>while privacy policy #2 (http://example.com/p3p-pol2.xml) explains that phone numbers may be used for telemarketing purposes:
<POLICIES xmlns="http://www.w3.org/2002/01/P3Pv1">
<POLICY name="lessnice"
discuri="http://example.com/pol2.html"
xml:lang="en">
<ENTITY>
<DATA-GROUP>
<DATA ref="#business.name">Invisible Corp.</DATA>
<DATA ref="#business.contact-info.postal.street">Cloud 9</DATA>
<DATA ref="#business.contact-info.postal.city">The sky</DATA>
<DATA ref="#business.contact-info.online.email">invisible@example.com</DATA>
</DATA-GROUP>
</ENTITY>
<ACCESS><all/></ACCESS>
<DISPUTES-GROUP>
<DISPUTES resolution-type="independent"
service="http://www.PrivacySeal.example.org"
short-description="PrivacySeal.example.org">
<REMEDIES><correct/></REMEDIES>
</DISPUTES>
</DISPUTES-GROUP>
<STATEMENT>
<PURPOSE><contact/><telemarketing/></PURPOSE>
<RECIPIENT><public/></RECIPIENT>
<RETENTION><indefinitely/></RETENTION>
<DATA-GROUP>
<DATA ref="#user.home-info"/>
</DATA-GROUP>
</STATEMENT>
</POLICY>
</POLICIES>The WSDL 2.0 document indicates that privacy policy #1 applies to the address update operation, whereas, for the telephone update operation, the transfer of the telephone number is done under privacy policy #2, and therefore the number may be used for tele-marketing.
In all cases, the user's id is under privacy policy #1 and
is therefore not communicated to third parties.
This example illustrates that a message may contain information for which different policies apply.
This section describes how a WSDL 2.0 feature can be used to indicate the P3P privacy policy. The URI associated with this feature is "http://www.w3.org/2004/02/wsdl/features/P3Pv11".
The P3P feature has one property, "http://www.w3.org/2004/02/P3Pv11", and its value is constrained to "xs:anyURI", "xs" being the namespace prefix for "http://www.w3.org/2001/XMLSchema". The value is the URI of a P3P 1.1 privacy policy.
Setting this property for a WSDL 2.0 component allows one to attach the P3P privacy policy to the component as defined in 3 Semantics of a privacy policy on WSDL 2.0 components.
It has to be noted that this solution is more restrictive than the previous one as a property can only be defined for an interface (semantics defined in 3.4 WSDL 2.0's interface component), interface operation (semantics defined in 3.3 WSDL 2.0's interface operation component), binding (semantics defined in 3.6 WSDL 2.0's binding component) and binding operation (semantics defined in 3.5 WSDL 2.0's binding operation component).
If interfaces or bindings get complex, the lack of granularity leads to a higher complexity in P3P too as multiple steps of the operation or binding have to be aggregated into one P3P policy. The complexity of matching P3P data schema, the data transfer and processing, their respective purposes and recipients, and the attached aggregation lead to more imprecise statements with a tendency to overstate the privacy impact. This document prefers therefore the approach using the P3P generic attribute.
The example below shows how one would use the P3P feature to attach privacy policies to WSDL 2.0 components:
<?xml version="1.0"?>
<definitions xmlns="http://www.w3.org/2003/11/wsdl"
xmlns:myns="http://example.org/myservice"
xmlns:mytypes="http://example.org/myservice-types"
xmlns:soap="http://www.w3.org/2003/06/wsdl/soap12"
targetNamespace="http://example.org/myservice" >
<documentation>
<div xmlns="http://www.w3.org/1999/xhtml">
<h1>Sample service definition showing the use of the P3P feature.</h1>
<p>This document describes a simple service allowing updates of
personal information (address, phone number) in a database.</p>
<p>The P3P feature is used to express different
privacy policies.</p>
</div>
</documentation>
<types>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://example.org/myservice-types">
<xsd:complexType name="telMess">
<xsd:sequence>
<xsd:element name="id" type="xsd:anyURI" />
<xsd:element name="phonenumber" type="xsd:anyURI" />
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="addrMess">
<xsd:sequence>
<xsd:element name="id" type="xsd:anyURI"/>
<xsd:element name="address" type="mytypes:addrStruct"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="addrStruct">
<xsd:sequence>
<xsd:element name="name" type="xsd:string"/>
<xsd:element name="street" type="xsd:string"/>
<xsd:element name="city" type="xsd:string"/>
<xsd:element name="state" type="xsd:string"/>
<xsd:element name="zip" type="xsd:decimal"/>
</xsd:sequence>
<xsd:attribute name="country" type="xsd:string"/>
</xsd:complexType>
<xsd:simpleType name="statusCode">
<xsd:restriction base="xsd:anyURI">
<xsd:enumeration value="http://example.org/status/OK"/>
<xsd:enumeration value="http://example.org/status/Pending"/>
<xsd:enumeration value="http://example.org/status/Failed"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:complexType name="updateMess">
<xsd:sequence>
<xsd:element name="id" type="xsd:anyURI"/>
<xsd:element name="status" type="mytypes:statusCode"/>
</xsd:sequence>
</xsd:complexType>
<xsd:element name="telUpdate" type="mytypes:telMess"/>
<xsd:element name="addrUpdate" type="mytypes:addrMess"/>
<xsd:element name="updateResp" type="mytypes:updateMess"/>
</xsd:schema>
</types>
<interface
name="Interface">
<operation
name="OperationTel"
pattern="http://www.w3.org/2003/11/wsdl/in-out">
<feature uri='http://www.w3.org/2004/02/wsdl/features/P3Pv11'
required='false'>
</feature>
<property name='http://www.w3.org/2004/02/P3Pv11'>
<value>http://example.com/p3p-pol1.xml</value>
</property>
<input message="mytypes:telUpdate"/>
<output message="mytypes:updateResp"/>
</operation>
<operation
name="OperationAddr"
pattern="http://www.w3.org/2003/11/wsdl/in-out">
<feature uri='http://www.w3.org/2004/02/wsdl/features/P3Pv11'
required='false'>
</feature>
<property name='http://www.w3.org/2004/02/P3Pv11'>
<value>http://example.com/p3p-pol2.xml</value>
</property>
<input message="mytypes:addrUpdate"/>
<output message="mytypes:updateResp"/>
</operation>
</interface>
<binding name="SoapBinding" interface="myns:Interface">
<soap:binding protocol="http://www.w3.org/2003/05/soap/bindings/HTTP/"/>
</binding>
<service
name="ExampleService"
interface="myns:Interface">
<endpoint
name="Endpoint1"
binding="myns:SoapBinding">
<soap:address location="http://ws.example.org/myservice" />
</endpoint>
</service>
</definitions>