WS-I (Web Services Interoperability Organization) has released a working group draft specification for WS-I Basic Profile Version 1.0. Produced by the WS-I's Basic Profile Working Group, the document defines the WS-I Basic Profile, consisting of a set of non-proprietary Web services specifications, along with clarifications to those specifications which promote interoperability. The Basic Profile "dictates how a selected set of specified Web services technologies should be used together in an interoperable manner. They are: (1) Messaging -- the exchange of protocol elements, usually over a network, to effect a Web service; (2) Description -- the enumeration of the messages associated with a Web service, along with implementation details; (3) Discovery -- metadata that enables the advertisement of a Web service's capabilities; (4) Security -- mechanisms that provide integrity, privacy, authentication and authorization functions. The profile mandates the use of a particular technology (or technologies), when appropriate, for each of these components."

Bibliographic information: Basic Profile Version 1.0. Working Group Draft. Date: 2002-10-08. 31 pages. Copyright (c) 2002 by The Web Services Interoperability Organization (WS-I) and Certain of its Members. Edited by Keith Ballinger (Microsoft), David Ehnebuske (IBM), Martin Gudgin (Microsoft), Mark Nottingham (BEA Systems), and Prasad Yendluri (webMethods). Version URL: http://www.ws-i.org/Profiles/Basic/2002-10/BasicProfile-1.0-WGD.htm. Latest version URL: http://www.ws-i.org/Profiles/Basic/2002-10/BasicProfile-1.0-WGD.htm.

Excerpted from the Basic Profile Version 1.0 working group draft:

Messaging The Messaging portion of the profile incorporates by reference:

• Simple Object Access Protocol (SOAP) 1.1
• Extensible Markup Language (XML) 1.0 (Second Edition)
• RFC2616: Hypertext Transfer Protocol -- HTTP/1.1
• RFC2965: HTTP State Management Mechanism

Service Description The Basic Profile uses Web Services Description Language (WSDL) to enable the description of services as a set of endpoints operating on messages. This portion of the profile incorporates by reference:

• Web Services Description Language (WSDL) 1.1
• XML Schema Part 1: Structures
• XML Schema Part 2: Datatypes

Service Discovery When discovery is required, UDDI is the mechanism the Basic Profile has adopted to describe Web service providers and the Web services they provide. Business, intended use, and Web service type descriptions are made in UDDI terms; detailed technical descriptions are made in WSDL terms. Where the two specifications define overlapping descriptive data and both forms of description are used, the Basic Profile specifies that the descriptions must not conflict. UDDI description is optional for Web service instances. By no means do all usage scenarios require the kind of metadata and discovery UDDI provides, but where such capability is needed, UDDI is the sanctioned mechanism. This portion of the profile incorporates by reference:

• The UDDI Version 2.04 API Published Specification, Dated 19 July 2002
• UDDI Version 2.03 Data Structure Reference, Published Specification, Dated 19 July 2002
• Version 2.0 UDDI XML Schema 2001
• UDDI Version 2.03 Replication Specification, Published Specification, Dated 19 July 2002
• Version 2.03 Replication XML Schema 2001
• UDDI Version 2.03 XML Custody Schema
• UDDI Version 2.01 Operator's Specification, Published Specification, Dated 19 July 2002

Security "... For Web services, as for other information technologies, security consists of understanding the potential threats an attacker may mount and applying operational, physical, and technological countermeasures to reduce the risk of a successful attack to an acceptable level. Because an "acceptable level of risk" varies hugely depending on the application, and because costs of implementing countermeasures is also highly variable, there can be no universal "right answer" for securing Web services. Choosing the absolutely correct balance of countermeasures and acceptable risk can only be done on a case by case basis. That said, there are common patterns of countermeasures that experience shows reduce the risks to acceptable levels for many Web services. The Basic Profile adopts, but does not mandate use of, the most widely used of these: HTTP secured with either TLS 1.0 or SSL 3.0 (HTTPS). That is, conformant Web services may use HTTPS; they may also use other countermeasure technologies or none at all... This portion of the profile incorporates by reference:

• RFC2818: HTTP Over TLS
• RFC2246: The TLS Protocol Version 1.0
• The SSL Protocol Version 3.0
• RFC2459: Internet X.509 Public Key Infrastructure Certificate and CRL Profile

From the overview article by Chris Ferris (IBM):

"... This publication represents an important milestone for WS-I and the Basic Profile Working Group, one of the three initial WS-I technical Working Groups chartered with deliverables associated with the WS-I Basic Profile version 1.0. This draft document, while not complete, does represent the consensus of the members of the WS-I Basic Profile Working Group. It is expected that the document will undergo further change to incorporate more examples and more detailed rationalization for the constraints and requirements imposed by the profile."

The profile provides constraints and clarifications to those base specifications with the intent to promote interoperability. Where the profile is silent, the base specifications are normative. If the profile prescribes a requirement or constraint, it supersedes the underlying base specification. Some of the constraints imposed by the profile are intended to restrict, or require, optional behavior and functionality, so as to reduce the potential for interoperability problems. Some of the constraints or requirements are provided to clarify language in the base specification that may be the source of frequent misinterpretation, that have been a frequent source of interoperability problems.

"The following highlights of the key constraints imposed by the profile:

• precludes the use of SOAP encoding
• requires the use of HTTP binding for SOAP
• requires the use of HTTP 500 status response for SOAP Fault messages
• requires the use of HTTP POST method
• requires the use of WSDL1.1 to describe the interface of a Web service
• requires the use of rpc/literal or document/literal forms of the WSDL SOAP binding
• precludes the use of solicit-response and notification style operations
• requires the use of WSDL SOAP binding extension with HTTP as the required transport
• requires the use of WSDL1.1 descriptions for UDDI tModel elements representing a Web service

"The WS-I Basic Profile 1.0 is, of course, just the tip of the iceberg. WS-I plans to begin work on a number of profiles for Web services specifications, moving further up the stack. Possible future profiles include the likes of security, choreography, reliable messaging, etc. Work will begin on these future profiles as the various specifications upon which they are to be founded mature and stabilize. WS-I intends that composed profiles may be created from these base profiles in order to combine features, such basic communications (as found in the Basic Profile), security, and reliable messaging to address business needs."

From the published Table of Contents:

1. Introduction
1.1. Notational Conventions
2. Scope of the Profile
3. Profile Conformance
3.1. Conformance of Artifacts
3.2. Conformance of Services
4. Messaging
4.1. XML Representation of SOAP Messages
4.2. The SOAP Processing Model
4.3. Using SOAP in HTTP
5. Service Description
5.1. Document Structure
5.2. Types
5.3. Messages
5.4. Port Types
5.5. Bindings
5.6. Ports
5.7. Services
5.8. SOAP Binding
5.9. XML Schema
6. Service Discovery
6.1. businessService Substructure Breakdown
6.2. tModel Substructure Breakdown
7. Security
7.1. The Use of HTTPS
7.2. Certificate Authority
7.3. Permitted HTTPS Encryption Algorithms