<a name="title" id="title"> Web Services Architecture Requirements

deleted text: <a name="IDA4NA2B" id="IDA4NA2B"> </a> 2.2.1 Mission, Vision, and Values </h4> <div class="div4"> <h5> <a name="IDAAOA2B" id="IDAAOA2B"> 2.2.1.1 3.1.1 Mission </h5>

The mission of the Web Services Architecture Working Group is to develop and maintain a standard reference architecture for Web Services.

2.2.1.2 Vision </h5> 3.1.2 Users of Web Services Architecture

The W3C Web Services Reference Architecture is intended primarily for the W3C Web Services Architecture Working Group to analyze, prioritize and characterize the technologies that are needed to fully realize an interoperable and extensible realization of the promise of Web Services. It is also intended for the use of other working groups specifying the components technologies identified and described in the architecture, secondarily architecture. A secondary target audience for the architecture are the developers implementing the components, specified technologies, and deleted text: incidentally for end users of those components. The exposition of the reference architecture must, wider IT community that uses these technologies to deploy Web Services.

3.2.1 Top-level Goals

The Working Group has determined that at the greatest extent possible, highest level, its goals can be understandable by an experienced software designer or developer: it should use a minimum divided into 6 categories. Each of specialized jargon, employ simple declarative sentences wherever possible, and be organized these is associated with the CSFs and illustrated requirements listed in a way to minimize section 3.2.2

Top-level Goals for the amount of effort required to understand it. Web Services Architecture

• D-AG0001 Interoperability

  The reference architecture Web Services Architecture should specify as few components and relationships as are absolutely necessary. The provide a reference architecture should contain examples intendedto clarify how an application programmer would use its components to build typical applications that utilize web services. platform for the development of interoperable Web Services across a wide array of environments.

  deleted text: </div> </div> <div class="div3"> <h4> <a name="IDAGOA2B" id="IDAGOA2B"> </a> 2.2.2 Goals </h4> <div class="note"> <p class="prefix" style="font-weight: bold"> Note:

  Critical Success Factors for this goal:

  • DAC0001

  • A few words on the naming convention used here DAC0004

  • DAC0016

  
  
  

• D-AG0002 Reliability

  The Web Services Architecture must be reliable and throughout stable over time.

  Critical Success Factors for this document: all goals, critical success factors goal:

  • DAC0007

  • DAC0018

  • DAC0019

  
  
  

• D-AG0003 Web-friendly

  The Web Services Architecture must be consistent with the current and requirements are labelled according to future evolution of the following convention: World Wide Web.

  [D-]A(G|F|R|UC)nnnn Critical Success Factors for this goal:

  • D-AC0009

  • [D-] indicates that the item is in D-AC0010

  • D-AC0011

  
  
  

• D-AG0004 Security

  The Web Services Architecture must provide a draft state secure environment for online processes.

  A indicates that Critical Success Factors for this is an architectural item. goal:

  • D-AC0006

  • [G|F|R|UC] is one of Goal|Critical D-AC0020

  
  
  

• D-AG0005: Scalability and Extensibility

  The Web Services Architecture must be scalable and extensible.

  Critical Success Factor|Requirement|Use Case. Factors for this goal:

  • D-AC0002

  • nnnn indicates D-AC0003

  • D-AC0005

  • D-AC0017

  
  
  

• D-AG0006 Team Goals

  The Web Services Architecture Working Group will work to ensure that the sequence number Architecture will meet the needs of the item. user community.

  Critical Success Factors for this goal:

  • D-AC0008

  • D-AC0012

  • D-AC0013 (and D-AC0014)

  • D-AC00015

  
  
  

3.2.2 Critical Success Factors and Requirements

Proposed Goals lower-level goals and CSFs for the Web Services Architecture Working Group> Group

(Each of the following goals is stated as a predicate to the following statement.)

To develop a standard reference architecture for web services Web Services that:

D-AG0001 D-AC0001

provides a complete reference framework that encourages the development of interoperable software products from multiple vendors and provides a defensible basis for conformance and interoperability test suites

• AC011-A D-AC0001.1 - Encourage the development of interoperable software products.

  • AC0111-A D-AC0001.1.1 - Ensure that no individual implementor is favored over others.

  • AC0112-A D-AC0001.1.2 - Identify all interfaces and messaging protocols within the architecture in a standardized way.

• AC0012-A D-AC0001.2 - Develop a means of identifying conformance so that testing software can be constructed.

  • AC0121-A D-AC0001.2.1 - The WSAWG should co-ordinate with WS-I on development of conformance test suites

• AC0013-A D-AC0001.3 - Clearly define and publish a standard reference architecture document for implementors.

  • AC0131-A D-AC0001.3.1 - Clearly define specific factors that determine conformance, while leaving sufficient slack in the system for vendors to add value.

<img src="D-AG0001-CSF.gif" alt="Goal D-AG0001 CSF Analysis" /> <br /> <br />

D-AG0002 D-AC0002

provides modularity of web services Web Services components, allowing for a level of granularity sufficient to meet business goals

• AC0021 D-AC0002.1 - Provide conceptual clarity to allow developers to share ideas and code

  • AC0211 D-AC0002.1.1 - Reduce complexity by decomposition of the components's functionality and its position within the architecture

  • AC0212 D-AC0002.1.2 - Ease development, testing, and maintenance by providing a logical, easy to understand, and consistent organization

    • AC2121 D-AC0002.1.2.1 - Decrease debugging time by localizing errors due to design changes

    <br /> <br />
    
    

  • AC0213 D-AC0002.1.3 - Allow the creation of generic rules, methods, and procedures to aid in consistent development practices

  <br /> <br />
  
  

• AC0022 D-AC0002.2 - Support object-oriented design principles by encouraging encapsulation and information hiding by components of the architecture

  • AC0221 D-AC0002.2.1 - Encourage reuse by creating well-defined modules that perform a particular task

  • AC0222 D-AC0002.2.2 - Allow the creation and deployment of configurable objects that the end user can tailor for different purposes in a standard way.

• AC0023 D-AC0002.3 - Provide for Increased flexibility and maintainability because single components can be upgraded or replaced independently of others

  • AC0231 D-AC0002.3.1 - Support a variety of end-user interface and deployment environments by allowing standardized subsets and supersets

<img src="D-AG0002-CSF.gif" alt="Goal D-AG002 CSF Analysis" /> <br /> <br />

D-AG0003 D-AC0003

is sufficiently extensible to allow for future evolution of technology and of business goals

• D-AR3001 separates the transport of data or means of access to web services Web Services from the web services Web Services themselves

• D-AR3002 description of web services Web Services be clearly separated into abstract descriptions ("what") ("what") from their concrete realizations ("how"), ("how"), or put another way, separate design time aspects from run-time aspects

• technologies using this architecture should allow for extensibility via inheritance, i.e., deriving one type from another </p> </li> <li> <p> D-AR3003 technologies following this architecture should not impede the development of complex interaction scenarios likely for future business interactions

• security policies, handling various QoS aspects, negotiation of service level agreements (SLAs) D-AR3004 modules that are orthogonal must be facilitated by technologies conforming allowed to this evolove indepently of each other and still work within the architecture

• D-AR3005 modularity must support common business functions such as reliability, security, transactions, etc.

• D-AR3006 specs that are created in conformance with the architecture do not have to go through a formal process to be considered conformant

<br /> <br />

D-AG0004 D-AC0004

ensures platform and device independence of web services components Web Services in a way that does not preclude any programming model nor assume any particular mode of communication between the individual components

• D-AC0004,1 Focus on using platform independent development tools and languages.

• D-AC0004,2 Interfaces to web components resources must be properly defined and designed.

• D-AC0004,3 Focus on defining the architecture in terms of components and the relationships between them. Components are defined in terms of interfaces, that defines define their inputs and outputs and also the form and constraints on those inputs and outputs. The relationships between components are described in terms of messages and the protocols by means of which these messages are transmitted among the interfaces of the components that make up the architecture.

deleted text: <br /> <br /> <p> Derived Requirements

The Web Services Architecture should:

• a. Consistent D-AR4001 provide consistent definition of web components resources

• b. Good definition of web component Interfaces their inputs/outpus and their constraints. D-AR4002 provide well-defined interfaces for Web Services

• c. Use D-AR4003 use XML based techniques for defining messages/protocols for invoking web components resources

<br /> <br />

D-AG0005 D-AC0005

Make sure applies the reference architecture is as simple as possible principle of simplicity and is defined such that it does not impose high barriers to entry for its intended audience

<ul> <li>

The reference architecture should be easily understandable by the target audience. deleted text: </p>

• D-AC0501 does it avoid specialized jargon not familiar to ordinary software designers?

• D-AC0502 is it stated in simple declarative sentences?

• D-AC0503 is it organized in a way that allows important points to be located?

• D-AC0504 does it use illustrations to visually describe key components and relationships?

<br /> <br /> </li> </ul> <br /> <br />

The reference architecture should be as minimal as possible deleted text: </p>

• D-AC0505 How many components does it describe?

• D-AC0506 How many relationships among the components does it describe?

• D-AC0507 How do these figures compare to those of notable exemplars of good reference architectures?

• D-AC0508 Could any components or relationships be removed without significantly limiting the value of the architecture?

<br /> <br />

The reference architecture should simplify the task of a programmer writing interoperable implementations of specifications of components described by the architecture. deleted text: </p>

• D-AC0509 is the role played by each component in the overall architecture stated clearly?

• D-AC0510 are the interdependencies among components noted explicitly?

• D-AC0511 are existing specs that fufill the role of a given component referenced?

• D-AC0512 are the resulting implementations actually interoperable?

<br /> <br />

The reference architecture should simplify the task of an application programmer using the specifications it describes. deleted text: </p>

• D-AC0513 does the reference architecture not force a programmer to use exotic constructions?

• D-AC0514 Can the architecture be implemented without large amounts of code?

• D-AC0515 Does it allow simple invocations as well as elaborations with more functionality when building web services Web Services or applications that employ web services?

<br /> <br />

D-AG0006 AC0006

addresses the security of web services Web Services across distributed domains and platforms

1) AC0006.1 The construction of a Web Services Threat Model based on thorough analysis of existing and foreseeable threats to Web Service service endpoints and their communication.

2) AC0006.2 The establishment of a set of Web Services Security Policies to counter and mitigate the security hazards identified in the thread model.

3) AC0006.3 The construction of a Web Services Security Model that captures the security policies (to be executed by security mechanisms).

4) AC0006.4 The realization of the security model in the form of a Web Services Security Framework that is an integral part of the Web Services Architecture (which is the ultimate deliverable of this working group).

Requirements

General </p> <p> WSAGenReq011 D-AR6011 The architecture MUST must provide an interface for web services Web Services to directly communicate with their underlying infrastructure.

The interface is for negotiating services that an infrastructure may provide to, or perform on behalf of, a requesting web services. Web Services. Such value-added services may include: security, content delivery, QoS, etc. For instance, a web Web service may instruct (via the interface) the security agents of its infrastructure to defend against DOS/DDOS attacks on its behalf.

Editorial note
The WG has not yet reached consensus on the merits of D-AR6011 and there is still considerable debate

<p> See also WSASecReq001. </p> <p> Security </p>

There are six aspects in the security framework for web services Web Services architecture: Accessibility, Authentication, Authorization, Confidentiality, Integrity, and Non-repudiation. Together they form the foundation for secure web services. Web Services.

WSASecReq001 D-AR6001 Accessibility to a web Web service can be impaired by DOS/DDOS attacks. It is understood that there's little a web Web service residing well above the transport layer of a network stack can effectively detect such transgression, let alone deploy countermeasures. Therefore, the security framework MUST must provide recourse for web services Web Services to mitigate the hazard.

Editorial note
The WG has not yet reached consensus on the merits of D-AR6001 and there is still considerable debate

WSASecReq002.1 D-AR6002.1 The security framework MUST must include Authentication for the identities of communicating parties.

WSASecReq002.2 D-AR6002.2 The security framework MUST must include Authentication for data (sent and received by communicating parties).

WSASecReq003 D-AR6003 The security framework MUST must include Authorization, with allowance for the coexistence of dissimilar authorization models.

WSASecReq004 D-AR6004 The security framework MUST must include Confidentiality.

WSASecReq005 D-AR6005 The security framework MUST must include (data) Integrity.

WSASecReq006 D-AR6006 The security framework MUST must include Non-repudiation between transacting parties.

Note that there is a close relationship among WSASecReq002.1, WSASecReq002.2, WSASecReq005, D-AR6002.1, D-AR6002.2, D-AR6005, and WSASecReq006, D-AR6006, a la digital signature.

WSASecReq007 D-AR6007 The security framework MUST must include Key Management, pertaining to Public Key Encryption (PKE) and Key Distribution Center (KDC).

WSASecReq008 D-AR6008 The security framework document SHOULD provide some guidelines for securing private keys, though the methods for securing private keys is outside the scope of the architecture.

WSASecReq009 D-AR6009 The security framework document SHOULD recommend a baseline for trust models.

D-AG0007 D-AC0007

is reliable, and stable, and whose evolution is predictable over time

Nomenclature: reference architecture components are referred to as "standards" "standards" below.

Reliability of Architecture

<p> CSF RA1. All standards are versioned. </p> <p> CSF RA2. Non-circular standards: Each standard is specified without the use of another standard within the reference architecture except when a standard is an extension of another standard. </p> <p> CSF RA3. A standard may depend only on non-proprietary standards - standards developed within open standards bodies (W3C, IETF, ISO, OASIS,...). </p> <p> CSF RA4. When a standard uses other standards outside of the reference architecture, the exact versions of other standards will be specified. If the other standards do not have version numbers, WSA will create and assign version numbers and map to a particular instance of the external standard. </p> <p> D-CSF RA4 Each release of the WS-A also should be versioned with the versions of the standards that go in the WS-A. Such a consistent set of versions will be called a "C-set" - for consistent set. </p> <p> D-CSF RA5. Each such combination, as in R2 must be tested with a set of conformance tests. </p> <p> D-CSF RA6. Extension to a standard by anybody must be submitted to WS-A with a C-set and a set of conformance tests. </p>

Stability of Architecture

Stability of Architecture is defined under the "force field" "force field" of the reference architecture, i.e., when a standard changes, then the change will be clear and consistent with the rest of the reference architecture components.

CSF SA1. D-AC0701. A new version of a standard will clearly describe its "backward compatibility" "backward compatibility" status with its earlier version in text.

CSF SA2. D-AC0702. A new version of a standard will not conflict with other standards in the reference architecture that do not conflict with the old version of the standard.

CSF SA3. D-AC0703. Evolvability in identified technologies/standards should be considered up front as much as possible from the point of view of interoperability with other standards [to prevent hasty change of standards]

Predictable Evolution of Architecture

CSF PE0. D-AC0704. The reference architecture must define a framework for growth of the architecture.

CSF PE1. D-AC0705. The reference architecture should identify its axes for evolution. [e.g., independent specification of WS interaction with WS selection of WS measure WS]

CSF PE2. D-AC0706. The standards should be mapped to these axes. [e.g., independent specification, - WSDL interaction - XMLP selection - ? measure - ?]

CSF PE3. D-AC0707. Non-normative extension guidelines to be specified for each standard

CSF PE4. D-AC0708. Stagger "features" "features" in a standard so that even software that implemented only the minimal features in the standard can interoperate with another software that implemented more features

CSF PE5. The version number is available for verification from the software that implements the standard to support CSF PE4

D-AG0008 D-AC0008

is consistent and coherent. This applies to both the reference architecture itself and the document that contains its definition.

D-AC8001 Simple visualization of architecture in the form of a two-dimensional diagram

D-AC8002 Architecture supports the concepts used in commonly accepted design patterns.

D-AC8003 Architectural components work together to form a logical whole.

D-AC8004 Architecture does not do the same or similar things in mutually incompatible ways; it is not self-contradictory.

D-AC8005 There shall not be wildly different means to achieve the same ends in the architecture.

D-AG0009 D-AC0009

is aligned with the semantic web initiative at W3C and the overall existing web architecture

D-AR9001 Any meta data about any aspect of the Web services Services reference architecture should be expressible with an RDF based language (such as RDF itself, RDF Schema, DAML+OIL)

D-AR9002 All recommendations produced by the working group include a normative mapping between all XML technologies and RDF/XML.

D-AR9003 All conceptual elements should be addressable directly via a URI reference.

D-AG0010 D-AC0010

uses W3C XML technologies in the development of the web services Web Services architecture to the extent that this is compatible with the overall goals listed here.

D-AC0010,1 Each new architectural area is representable in a syntactic schema language like XML Schema. deleted text: I stress the "syntactic" adjective to schema language because the TAG has occasionally ratholed into HTML and RDF documents being "schema" languages.

D-AG0011 D-AC0011

is consistent with the existing web to the greatest extent possible. web.

CF1) The

D-AG1101The Web Services reference architecture complies with the architectural principals and design goals of the existing web.

Derived sub-goals:

CF1-A) D-AC1101 universal identifiers

CF1-B) D-AC1102 simplicity

CF1-C) D-AC1103 opaqueness

CF1-D) D-AC1104 decentralization

CF1-E) D-AC1105 statelessness

CF1-F) D-AC1106 scalability of component interactions

CF1-G) D-AC1107 generality of interfaces

CF1-H) D-AC1108 immediate deployment of components

CF1-I) D-AC1109 intermediary components to reduce interaction latency

CF1-J) D-AC1110 enforces security

CF1-K) D-AC1112 encapsulate legacy systems

CF1-L) D-AC1113 caching semantics

CF1-M) D-AR0002 platform independence

CF2) D-AG1102 The Web Services reference architecture recommends the use of existing web technologies which adhere to the above principals and which provide clear functional coverage of the responsibilities and constraints for a component identified in the reference architecure.

Derived sub-goals:

CF2-A) D-AC1114 Use of a standard identifier technology (URI)

CF2-B) D-AC1115 Use of a standard transport technology (HTTP/S over TCP/UPD/IP)

CF3-C) D-AC1116 Use of a standard data encoding technology (XML)

In addition, the Working Group will also act to:

D-AG0012 D-AC0012

identify or create deleted text: the use cases that validate support/illustrate the requirements and deleted text: the web services architecture deleted text: and illustrate the benefits of web services

The goal for the WSAWG and the architecture document should

• D-AR1201 - terms must be deleted text: to address a broad set of applications reflecting the diversity of the W3C membership as well as the organizations that we have identified as important liaisons (OMG, OASIS, etc.) defined and used consistently

• There should be a mapping between D-AR1202 - use cases organized around usage scenarios, usage scenarios and requirements should reflect common usage patterns for deleted text: the web service architecture deleted text: document. I'm not sure we want a usage scenario to actually be the requirement. I think there is a difference between a requirement and a usage scenario.

• The benefit of web services should D-AR1203 - target audience for architectural deliverables must be obvious from the usage scenarios. The architecture document introduction will probably talk about the benefits of web services. I would rather keep the defined

• D-AR1204 - usage scenarios deleted text: short and not add the text that would use cases must be needed to explicitly state the benefits of each scenario. referencable via URI(reference)

• In what way does a usage scenario validate a requirement? The form of a requirement will be "The web services D-AR1205 - architecture shall ..." should support use casesat all levels of WS activity

• For example, "... shall define a way to describe web services". A related D-AR1206 - usage scenario might be "a web service provider publishes a description of its web service, scenarios and a web service user reads the description to determine how to invoke the web service." This requirement is derived from the usage scenario, so in a sense the requirement is valid because it relates to a usage scenario. If a requirement cannot use cases shall be traced back to a usage scenario, then we can consider it invalid (or perhaps we would need to figure out a usage scenario used as justification for it). So, it would be a requirement of the requirement document to include a matrix showing the traceability between requirements and usage scenarios. We would then need to have traceability between the architecture document and each requirement in recommending the requirements document. formation of new WSA WGs

D-AG0013 D-AC0013

co-ordinate with other W3C Working Groups, the Technical Architecture Groups and other groups doing Web services Services related work in order to maintain a coherent architecture for Web services Services

D-AR0013.1 Go through the W3C review process, and satisfy dependencies as listed in the charter.

D-AR0013.2 The documents produced are used as input to charter new Web Services Working Groups.

D-AR0013.3 Maintain liaisons with relevant external groups, such as the ones listed in the charter and possibly others.

D-AG0014 D-AC0014

Closed because it was merged with D-AG0013

D-AG0015 D-AC0015

organize its efforts in such a way as to address vital time-to-market issues for its products, including iterating over successive refinements of the overall requirements for the standard reference architecture.

1. D-AC1501 Is the Web Services Activity a center for web services Web Services standards specification, that is is the community able to start new working groups in a manner that is usable by the community?

2. D-AC1502 Is the WSA perceived as a reliable forum for architectural guidance? Do other working groups ask for advice from the WSA, or do they not bother?

3. D-AC1503 Is the WSA document perceived as usable and referenceable in time for products? New/revised products would be able to reference this WSArch doc if it was delivered in time for their products.

4. D-AC1504 Does the WSA demonstrate a reasonable number of re-use decisions rather than re-inventing?

5. D-AC1505 Is the architecture document regularly revised?

6. D-AC1506 Is the architecture document regularly referenced by other specifications, including but not limited to W3C specifications?

7. D-AC1507 Is there a lack of press/developer commentary that refers to time-to-market problems with WSA? To paraphrase, no press is good press on this issue.

D-AG0016 D-AC0016

identify architectural and technology gaps that prevent interoperability, recommend existing standards and technologies where available, and formation of working groups to formulate new, or to standardize existing, specifications or technologies for filling the gaps.

The Web Services Architecture WG should:

1. D-AR1601. Identify what constitutes interoperability

1.1 D-AR1601.1 in architectural realm.

1.2 D-AR1601.2 in technological realm.

2. D-AR1602. Identify existing

2.1 D-AR1602.1 architecture that supports interoperability

2.2 D-AR1602.2 technologies that support interoperability

3. D-AR1603. Identify gaps

3.1 D-AR1603.1 in architectural realm.

3.2 D-AR1603.2 in technological realm.

4. D-AR1604. Formation of WGs to address gaps

4.1 D-AR1604.1 in architectural realm.

4.2 D-AR1604.2 in technological realm.

D-AG0017 D-AC0017

provides guidance for the development of the web services Web Services infrastructure needed to implement common business functions in a standards-based environment

Measurements: </p> <p> Is there a frameword within the web services architecture that will D-AR0017.1 The Web Services Architecture must support at least an 80-20 of the functions currently offered by proprietary VAN's (Value Added Networks) common business functions, to deleted text: support EDI functions? In particular, will the web services architecture extent that those funtions are defined in similar methodologies such as EDI.

D-AR0017.2 The Web Services Architecture must support reliable messaging, routing messaging and intermediaries, routing.

D-AR0017.3 The Web Services Architecture must support unique ID and sequencing of messages message IDs and message sequencing.

D-AR0017.4 The Web Services Architecture must support reliable transaction processing? processing.

D-AG0018 D-AC0018

provide a standard set of metrics for measuring aspects of Web Services such as reliability, quality of service, and performance, and to define a standard means of measurement of these metrics and instrumentation for management of Web Services.

1. D-AC1801. Develop a standard convention of measuring Web Services metrics so different service providers, implementors and consumers can reach service level agreements.

1.1 D-AC1801.1 The standard should include definitions of metrics such as Quality of Service, Reliability of Service and other metrics.

1.2 D-AC1801.2 The reference architecture should provide guidelines on measuring those metrics.

1.3 D-AC1801.3 Metrics can be independently verified.

2. D-AC1802. Define standard management instrumentations to Web Services.

2.1 D-AC1802.1 The standard should define but not limited to instrumentations such as starting, suspending, and retiring services.

2.2 D-AC1802.2 The instrumentations should confirm to other goals of this working group.

2.3 D-AC1802.3 The definition of management framework is out of scope. There are a number of such technologies available: www.dmtf.org.

2.4 D-AC1802.4 The instrumentations may be exposed as Web Services.

3. D-AC1803. Clearly define and publish reference architecture for implementors.

3.1 D-AC1803.1 Clearly define and publish reference Web Services management model.

D-AC1804 security policies, handling various QoS aspects, negotiation of service level agreements (SLAs) must be facilitated by technologies conforming to this architecture.

D-AG0019 D-AC0019

ensure reliable, stable, and predictably evolvable web services. Web Services.

D-AC1901 Web Services created using WSA can be reliably selected, discovered, accessed, and executed.

D-AC1902 Web Services created using WSA can be implemented such that they are stable with respect to their definitions.

D-AC1903 Web Services created using WSA may be evolved/extended while maintaining their reliability and stability.

D-AG0020 D-AC0020

To develop a standard reference architecture for web services Web Services that enables privacy protection for the consumer of a Web service across multiple domains and services.

D-AC2001 Is it possible for a service consumer to know the privacy policies of the service provider(s) that it is going to deal with? (a.k.a. (eg. hooks for P3P)

D-AC2001 Private data provision during a Web service transaction should not SHOULD NOT exceed the consumer's consent, where the consumer must be provided with reasonable means for opt-out.

D-AR2001 It must be possible to advertise privacy policies for Web Services