March 6, 2021
Hot Topics:

Web Services Security and More, Part 2: The Global XML Web Services Architecture (GXA)

  • By Joseph M. Chiusano, Booz Allen Hamilton
  • Send Email »
  • More Articles »

Derived Keys

The use of derived keys in a multi-message exchange allows a different key to be used for each exchange, further enhancing security. Each successive key is derived from a key that was used on a previous exchange within the communications session. While there exist multiple algorithms for key derivation, WS-SecureConversation defines an algorithm that is a subset of the mechanism defined for TLS in RFC 2246. This algorithm uses a pseudorandom function called P_SHA-1 (pseudorandom functions are commonly used for encryption, key generation, message-authentication and challenge-response protocols). Both parties use this function to generate shared keys as needed. This function is of the following format:

    P_SHA1 (secret, label + seed)

where secret is the shared secret, label is the concatenation of the client's and service's labels (as defined in their respective policies), and seed is the concatenation of the initiator's and receiver's exchanged nonce values.

The <DerivedKeyToken> element is used to represent a key that is derived from a shared secret. In creating a derived key, the requestor can specify which generation of the key to use as the basis for the derivation. The following example represents a derived key based on the 5th generation of the shared secret (note that generations start with 0):


If a new key is to be derived based on this derived key, the above <DerivedKeyToken> element would be passed to the P_SHA-1 function as the secret parameter.

Specification Location

The WS-SecureConversation specification can be found at

Web Services Inspection Language: WS-Inspection

Registry specifications such as Universal Description, Discovery, and Integration (UDDI), and OASIS/ebXML Registry enable the registration and discovery of Web service description documents, such as WSDL documents. Once discovered, these description documents can be utilized in a Web services exchange. The WS-Inspection specification enables the aggregation of such description documents on a single site that is not a registry. In doing so, it allows a site to be inspected for service offerings regardless of the format of the description documents for these service offerings. The WS-Inspection specification was released in 2001 by Microsoft and IBM.

WS-Inspection Document

A WS-Inspection document is essentially a set of pointers to service description documents of various formats. For example, the following WS-Inspection document contains a pointer to a single WSDL document:

<inspection xmlns="http://schemas.xmlsoap.org/ws/2001/10/
    <description referencedNamespace="http://schemas.xmlsoap.org/

The following WS-Inspection document references a service description that resides in a UDDI registry:

<inspection xmlns="http://schemas.xmlsoap.org/ws/2001/10/
    <description referencedNamespace="urn:uddi-org:api">
                location="http://www.descriptionlocation.com ">

In the preceding example, the "referencedNamespace" attribute identifies the namespace to which the document belongs. While the above example denotes UDDI, the value would be http://schemas.xmlsoap.org/wsdl for a description that points to a WSDL document. This attribute is provided so that WS-Inspection document consumers can easily retrieve WS-Inspection documents based on this information. Additionally, the "location" attribute provides the actual location of the description document, whereas the value of the <wsiluddi:serviceKey> element is used by a UDDI registry in conjunction with the UDDI "get_serviceDetail" message to retrieve the UDDI service description.

Link Mechanism

WS-Inspection specifies a "link" mechanism by which a WS-Inspection document can reference additional aggregations of service descriptions, such as other WS-Inspection documents. This is shown in the following example (note that the "location" attribute contains the URI of a WS-Inspection document):

<inspection xmlns="http://schemas.xmlsoap.org/ws/2001/10/
  <wsil:link referencedNamespace="http://schemas.xmlsoap.org/wsdl"

This mechanism can be valuable in two ways:

  1. It can allow for WS-Inspection documents to processed in a hierarchical manner
    • WS-Specification does not specify any sort of pattern or algorithm for doing so—it is left up to the consumer of the links.
  2. For UDDI descriptions, the "location" attribute can point to the UDDI registry, thereby alleviating the need to create inspection documents with large numbers of service elements containing only single description elements
    • This is a "best of both worlds" approach in which maintenance is easier, while still allowing the information contained in the UDDI registry to be discovered through the WS-Inspection inspection process.

WS-Inspection Document Usage

WS-Inspection specifies two methods of usage for WS-Inspection documents that describe where the documents should be placed and how they should be found:

  1. Fixed Name
    • A WS-Inspection document named "inspection.wsil" is placed wherever the most common entry points to Web sites and applications deployed on the server may be;
    • Consistent file naming allows for easy inspection of sites for available services;
  2. Linked
    • WS-Inspection documents are "linked" into HTML pages through the use of a META tag whose "name" attribute includes the value "serviceInspection" and whose "content" tag specifies a URI indicating the location of a WS-Inspection document;
    • This approach allows for user-defined naming of WS-Inspection documents;

HTML META tags are used to communicate information that a human visitor may not be concerned with but which is "meta" information for the page, such as a page description that can influence the description of the page in search engines. An example of the linked approach is:

    <META name="serviceInspection"
    <META name="serviceInspection"
    <META name="serviceInspection"

WSDL Binding

WS-Inspection defines a WSDL 1.1 binding that allows for specific information within WSDL documents to be known to WS-Inspection document consumers. More specifically, the following capabilities are provided:

  1. Indication of the types of WSDL bindings that appear in the referenced WSDL document;
  2. For WSDL documents that specify multiple services, specification of which WSDL service is being referenced;
  3. Indication of whether or not a particular referenced WSDL document is providing endpoint information;

The following is an example of the above capabilities expressed within a single WS-Inspection document:

    <description referencedNamespace="http://schemas.xmlsoap.org/
      <silwsdl:reference endpointPresent="true">

Specification Location

The WS-Inspection specification can be found at msdn.microsoft.com/webservices/understanding/gxa/default.aspx?pull=/library/en-us/dnglobspec/html/ws-inspection.asp.

Page 2 of 5

This article was originally published on May 21, 2003

Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Thanks for your registration, follow us on our social networks to keep up-to-date