Web Services Policy Working Group Charter

The mission of the Web Services Policy Working Group, part of the Web Services Activity, is to produce W3C Recommendations for Web Services Policy by refining the “WS-Policy” Member Submission, addressing implementation experience and interoperability feedback from the specifications, maximizing compatibility with existing policy assertions (as defined in the Scope section), and considering composition with other components in the Web services architecture.

Web Services Policy defines a flexible policy data model and an extensible grammar for expressing the capabilities, requirements and general characteristics of a Web service, and defines mechanisms for associating policies with Web service constructs. Web Services Policy is used to convey the conditions for an interaction between a Web service requester and a Web service provider.

Existing policy assertions are broadly deployed, and many more are under development. Web Services Policy enables Web services to recognize and act on the conditions for an interaction, and is required by other standardization efforts. To meet these critical needs, Web Services Policy should be provided in a timely fashion. Therefore, this Working Group shall be schedule-driven and Web Services Policy shall remain compatible with and to the extent possible accommodate the use of these existing policy assertions. This charter features an aggressive schedule and a tightly constrained scope designed to ensure that the Web Services Policy Working Group will meet its schedule. This charter is intended to carry Web Services Policy consensus and interoperability forward, as outlined in Tips for Getting to Recommendation Faster.

Join the Web Services Policy Working Group.

End date	31 December 2007
Confidentiality	Proceedings are public
Initial Chairs	Paul Cotton (Microsoft), Chris Ferris (IBM)
Initial Team Contacts (FTE %: 35)	Felix Sasaki, Philippe Le Hégaret
Usual Meeting Schedule	See Meetings

Scope

The Web Services Policy Working Group is chartered to standardize a general policy framework for expressing Web service capabilities and requirements. The framework consists of a policy data model for expressing capabilities and requirements of a Web Service, a processing model for combining and comparing Web service capabilities and requirements and an XML Information Set representation for the policy data model. The parts of the framework are described as follows:

A policy data model to allow the expression of consistent combinations of capabilities and requirements of a Web service. The policy data model defines a policy comprised of zero or more policy alternatives. Each policy alternative is comprised of zero or more policy assertions. Each policy assertion has a type and is comprised of nested policy, and parameters. A policy with zero policy alternatives has no admissible capabilities or requirements. A policy alternative with zero policy assertions has no capabilities or requirements.
A processing model for combining and comparing Web service capabilities and requirements. The processing model operates on the policy data model and defines merging and intersecting policies, policy alternatives, and policy assertion types and nested policies. The processing model does not define combining or comparing of policy assertion parameters.
An XML Information Set representation (also known as policy expression) of the policy data model defining:
1. A representation for operators (All and ExactlyOne) to denote consistent combinations of policy assertions, a normal form that maps directly to the policy data model, arbitrary nesting of the operators, and an algorithm to convert arbitrary nesting into the normal form.
2. A mechanism to denote that a policy assertion is optional and an algorithm to convert this into the normal form.
3. A representation for policy assertion type and nested policy; there should be no constraints on the Information Set for policy assertion parameters.
4. A means to identify policy expressions.
5. A means to include one policy expression within another policy expression.
The policy data model, processing model and policy expression shall be designed to be independent of any attachment mechanism.

The Web Services Policy Working Group is also chartered to standardize mechanisms for associating policy expressions with Web Service constructs. These mechanisms consist of items 5-9 below. The Web Services Policy Working Group may choose to vary the number of specification documents and their titles for these mechanisms for associating policy expressions with Web service constructs.

A model for attaching policies to WSDL 1.1 and WSDL 2.0 constructs. The model defines:
1. A partitioning of WSDL constructs into message, operation, endpoint, and service policy subjects.
2. The semantics of attaching a policy to each policy subject.
3. How to combine policies attached to more than one WSDL component within a single policy subject.
An XML representation of policy expressions attached to WSDL 1.1 and WSDL 2.0 constructs and annotating those policy expressions as required extensions using the WSDL-defined extensibility flag @wsdl:required.
A model for attaching policies to UDDI v2 and UDDI v3 entities. The model defines:
1. A partitioning of UDDI constructs into service provider, service, and endpoint policy subjects.
2. The semantics of attaching a policy to each policy subject.
3. How to combine policies attached to more than one UDDI entity within a policy subject.
A set of tModels for referencing and registering policy expressions in UDDI v2 and UDDI v3.
A general-purpose mechanism for external policy attachment.

Web Services Policy should remain compatible with existing policy assertions and offer a smooth migration path for these assertions (where applicable). Existing policy assertions (in specifications that have been submitted to other standards groups) are Web Services Reliable Messaging Policy, Web Services Security Policy, Web Services Atomic Transaction, and Web Services Business Activity Framework.

The Web Services Policy Working Group will use the latest versions of Web Services Policy Framework and Web Services Policy Attachment as the basis for its deliverables.

Success Criteria

The Web Services Policy Working Group is expected to demonstrate interoperable implementations during the Call for Implementations step.

Out of Scope

The area of Web Services policy is very broad as it could be imagined to contain everything from a simple policy assertion to application semantics used for processing policies. To be successful, it is very important to clearly define the scope of the Web Services Policy Working Group.

The following is intended to more tightly constrain the in-scope features, to prevent feature bloat and assure timely delivery. If some function, mechanism or feature is not mentioned here, and it is not mentioned in the Scope of Work section either, then it will be deemed to be out of scope.

Policy Assertions

Web Services Policy assertions indicate domain-specific capabilities and requirements and are defined in domain-specific specifications (these specifications include domain-level intersection of policy assertion parameters, cardinality of policy assertions and attachment subjects). Example specifications include Web Services Reliable Messaging Policy, Web Services Security Policy, Web Services Atomic Transaction, and Web Services Business Activity Framework. Other W3C working groups may define policy assertions to indicate capabilities and requirements, such as for the use of MTOM or Web Services Addressing. The Web Services Policy Working Group will not define policy assertions, or define any mechanisms or patterns or languages for defining policy assertions. The syntax and semantics of policy assertions are delegated to experts in their respective domains.

Application Infrastructure

The Working Group will not engage in defining application or higher-level infrastructure related to Web Services Policy including storage, negotiation, management, lifecycle, visibility, distribution, verification, enforcement, translation, etc for Web Services Policy. These specific aspects of the infrastructure are orthogonal to expressing consistent combinations of capabilities and requirements of a Web service.

Policy Exchange

An important feature of communicating in a distributed environment is the ability to exchange information that describes how the interaction between a Web service requestor and a Web Service provider can occur. The Web Services Policy Working Group will not define any mechanisms for policy exchange.

Mapping Policy to Programming Model or Language

Web Services Policy implies configuration for interactions with a Web service, which can be written in different Web services programming models in different programming languages. Web Services Policy is not geared towards any programming model or language. Therefore, the Web Services Policy Working Group will not define mappings to any programming model or language.

Alternate Representations of Policy

The Web Services Policy Working Group will focus on providing an XML Information Set representation of policy, and will not focus on mapping to or reconciling with other approaches for policy. Alternate representations of policy or alternate approaches for policy may be important for External Groups, other W3C Working Groups and Activities, and are delegated to those groups.

Deliverables

New publications and Milestones

A W3C Recommendation for the Web Services Policy 1.5 - Framework.
A W3C Recommendation for the Web Services Policy 1.5 - Attachment. As described in the Scope section, the Working Group may organize attachment mechanisms into one or more specifications.

List of deliverables and their milestones
Specification	FPWD	LC	CR	PR	Rec
Note: The group will document significant changes from this initial schedule on the group home page. The Advisory Committee MUST be notified of any significant schedule changes.
Web Services Policy 1.5 - Framework	July 2006	November 2006	March 2007	July 2007	August 2007
Web Services Policy 1.5 - Attachment	July 2006	November 2006	March 2007	July 2007	August 2007

Other Deliverables

The Working Group will produce a test suite intended to promote implementation of the Candidate Recommendation, and to assess interoperability between these implementations. To the extent possible, this test suite will use the existing policy assertions.

The Working Group may also:

Author a primer that includes guidance on the use of policy expressions to facilitate Web services interoperability and guidelines for authoring policy assertions, and
Propose a new charter for follow on work on these specifications per the World Wide Web Consortium Process Document.

Timeline View Summary

June 2006: Working Group created.
July 2006: The first face-to-face meeting will be hosted by IBM, in Austin, TX, USA, on July 11, 12 and 13, 2006. First public drafts for Web Services Policy 1.5 - Framework and Web Services Policy 1.5 - Attachment.
September 2006: The second face-to-face meeting is targeted for September 12, 13 and 14, 2006.
November 2006: The third face-to-face meeting occurs in the first week of the month. Last call drafts for Web Services Policy 1.5 - Framework and Web Services Policy 1.5 - Attachment.
January 2007: Fourth face-to-face meeting.
March 2007: Fifth face-to-face meeting. Candidate Recommendation drafts for Web Services Policy 1.5 - Framework and Web Services Policy 1.5 - Attachment.
May 2007: Sixth face-to-face meeting.
July 2007: Seventh face-to-face meeting. Proposed Recommendation drafts for Web Services Policy 1.5 - Framework and Web Services Policy 1.5 - Attachment.
August 2007: W3C Recommendations for Web Services Policy 1.5 - Framework and Web Services Policy 1.5 - Attachment.
September 2007 – December 2007: Post Recommendation work, next steps considerations

Dependencies

W3C Groups

The Web Services Policy Working Group should coordinate its efforts with other Working Groups involved in the Web Services Activity, especially:

XML Protocol Working Group: The Web Services Policy must be able to express capabilities, requirements and general characteristics of a Web service accessible via SOAP 1.2. For example, the XML Protocol Working Group may define policy assertions such as for expressing the use of MTOM.
Web Services Description Working Group: WSDL 2.0 provides a description component for a Web service. The Web Services Policy Working Group will partition WSDL constructs into policy subjects and define a mechanism to attach policy to each of these policy subjects.
Web Services Addressing Working Group: Web Services Addressing provides transport-neutral mechanisms (endpoint references) to address Web services and messages. For example, the Web Services Addressing Working Group may define policy assertions for expressing the use of addressing.

As part of the Web Services Activity, the Web Services Policy Working Group Chair and Team Contact will be represented in the Web Services Coordination Group.

External Groups

The following organizations have groups that may utilize Web Services Policy:

Organization for the Advancement of Structured Information Standards: OASIS is a not-for-profit, international consortium that drives the development, convergence and adoption of e-business standards. Relevant Technical Committees include UDDI, WS-RX, WS-TX, and WS-SX.

Participation

Effective participation is expected to consume one or two workdays per week for each Working Group participant; two or more days per week for editors. The Chair shall ensure that the criteria for Good Standing are understood and followed.

To be successful, we expect the Web Services Policy Working Group to have 10 or more active participants for its duration.

Participants are expected to carry out their assignments in a timely fashion, attend most meetings, and to remain familiar with group documents and mailing list discussion (W3C Process Document, section 6.2.1.7). Active participation will help ensure rapid progress.

The Chair is expected to use the means provided by the W3C Process to help the Web Services Policy Working Group remain on schedule and avoid scope creep (see the list of expected milestones). The Chair will:

Ensure that, when setting the agenda, discussion items are within the scope of the chartered deliverables.
Ensure issues are decided in a timely fashion, after due consideration of all opinions and positions.
Reconsider a decision only when presented with new information. (W3C Process Document, section 3.3.4).
Ensure frequent publication of Recommendation Track documents (W3C Process Document, section 6.2.7).

Meetings

The Web Services Policy Working Group will have distributed and face-to-face meetings.

At least up until the Last Call period ends a two-hour Working Group distributed meeting will be held every week. Thereafter, a one and half hour Working Group distributed meeting will be held every week. When necessary to meet agreed-upon deadlines, distributed meetings may be held twice a week. Face-to-face meetings are expected to occur every 2 months.

The Web Services Policy Working Group may adjust the timing and duration of meetings to address the workload and assure that the goals and schedule of this charter are achieved.

Communication

This group primarily conducts its work on the public mailing list [email protected]. A Member-only mailing list [email protected] is also available for administrative purposes.

Information about the group (deliverables, participants, face-to-face meetings, teleconferences, etc.) is available from the Web Services Policy Working Group home page.

Decision Policy

As explained in the Process Document (section 3.3), this group will seek to make decisions when there is consensus. When the Chair puts a question and observes dissent, after due consideration of different opinions, the Chair should record a decision (possibly after a formal vote) and any objections, and move on.

When deciding a substantive technical issue, the Chair may put a question before the group. The Chair must only do so during a group meeting, and at least 50% of participants in Good Standing must be in attendance. When the Chair conducts a formal vote to reach a decision on a substantive technical issue, eligible voters may vote on a proposal one of three ways: for a proposal, against a proposal, or abstain. For the proposal to pass there must be more votes for the proposal than against. In case of a tie, the Chair will decide the outcome of the proposal.

Patent Policy

This Working Group operates under the W3C Patent Policy (5 February 2004 Version). To promote the widest adoption of Web standards, W3C seeks to issue Recommendations that can be implemented, according to this policy, on a Royalty-Free basis.

For more information about disclosure obligations for this group, please see the W3C Patent Policy Implementation.

About this Charter

This charter for the Web Services Policy Working Group has been created according to section 6.2 of the Process Document. In the event of a conflict between this document or the provisions of any charter and the W3C Process, the W3C Process shall take precedence.

Philippe Le Hégaret

$Date: 2006/06/01 21:39:56 $