Abstract

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:

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.

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:

• S030 Third party intermediary scenario of the Web Services Architecture Usage Scenarios [WSAUS], and
• The IETF Provision Registry Protocol's (PROVREG) privacy scenario

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.

http://registrar.example.com/2003/ns1

The namespace of the example order form from the registrar.

http://registrar.example.com/w3c/p3p.xml

The location of the registar's P3P policy reference file

http://registrar.example.com/P3P/policy-register.xml

The location of the registrar's P3P policy

http://registry.example.com/wsdl/register

The targetNamespace for the registry's WSDL

http://registry.example.com/P3P/policy-register.xml

The location of the registry's P3P policy.

http://registry.example.com/RegisterService/RegisterDomainName

The namespace of the registry's SOAP response.

http://www.w3.org/P3P/2003/p3p-beyond-http/

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

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:

• A future version of P3P SHOULD include the [XHTML2] 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.

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

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:

• In the Platform for Privacy Preferences [P3P], a user's information is solicited by providing it with a privacy policy, which the user's client evaluates in light of the user privacy preferences. While the released information must be redistributed in accordance with the 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.
• In the Provision Registry Protocol [PROVREG], a privacy policy governs the interaction between services (one or more registrars and the final registry). While the information exchanged my include user data, the user solicitation is out of scope.
• In the Enterprise Privacy Authorization Language [EPAL], "While P3P formalizes privacy promises to be advertised (i.e., business to consumer), EPAL formalizes privacy authorization for actual enforcement within an enterprise or for business-to-business privacy control."

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.

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

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

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:

Recipient

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.

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:

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>

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'>
 </Privacy>
</env:Header>

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.

References

EPAL

Enterprise Privacy Authorization Language (EPAL). Paul Ashley, Satoshi Hada, Günter Karjoth, Calvin Powers, and Matthias Schunter. IBM Research Report, 2003-05-05.

HTTP

Hypertext Transfer Protocol -- HTTP/1.1. R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, and T. Berners-Lee. 1999-06.

P3P

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.

PROVREG

Extensible Provisioning Protocol. S. Hollenbeck. IETF Draft, 2003-03-11.

TLS

The TLS Protocol (1.0). T. Dierks, and C. Allen. IETF Proposed Standard, 1999-01.

SOAP

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

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.

WSAUS

Web Services Architecture Usage Scenarios. Hugo Haas, and David Orchard. W3C WD, 2003-05-14.

WSDL2

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.

WSG

Web Services Glossary. Allen Brown, and Hugo Haas. W3C WD, 2003-05-14.

XENC

XML Encryption Syntax and Processing. Donald Eastlake, and Joseph Reagle. W3C REC, 2002-12-10.

XForms

XForms 1.0. Roland Merrick, T. V. Raman, Micah Dubinko, and Leigh L. Klotz. W3C CR, 2002-11-12.

XHTML1

XHTML 1.0 The Extensible HyperText Markup Language (Second Edition). Steven Pemberton et al. W3C REC, 2002-08-01.

XHTML2

XHTML 2.0. Ann Navarro, Steven Pemberton, Jonny Axelsson, Beth Epperson, Masayasu Ishikawa, and Shane McCarron. W3C WD, 2003-05-06.

XLink

XML Linking Language (XLink) Version 1.0. Steven DeRose, Eve Maler, and David Orchard. W3C REC, 2001-06-27.

XML

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

XPointer Framework. Paul Grosso, Eve Maler, Jonathan Marsh, and Norman Walsh. W3C REC, 2003-03-25.