Message Exchange Pattern:
Authentication

[Author's note: throughout this document, proposed URIs are supplied in the domain for which the author's employer is authoritative. It is expected that if this document achieves a more formal status, these URIs will be replaced by URIs in domains under the authority of the XMLP or WSD or WSA working groups at W3C. The URIs in question may be searched for using the pattern: "http://www.tibco.com/xmlns/". The remainder of the path for each URI is modeled on similar URIs in the existing request-response MEP in part 2 of the specification.

Status

This is a proposed description of the authentication message exchange pattern, based on the format developed for the request-response pattern and informal discussions with those working on SOAP-related specifications, and informed by the collected experience in messaging of the author's workplace. The document has no formal status whatsoever, within W3C and its working groups, or within Tibco Software Inc., although it has been circulated and edited within Tibco.

Motivation

The authentication message exchange pattern describes a common pattern used when an action involving a response requires some form of in-context confirmation in order to be approved. A classic case is login; authenticated commands are another. It is argued here that the pattern is inadequately described as the combination of two request/response operations. That is, this message exchange pattern description proposes, by example, that the current set of exchange patterns is not only not in need of truncation, it is too small to adequately describe common and useful operations that should be amenable to description for a web service.

The pattern is composed of four messages, which are informally referred to as command (an input message), challenge (an output message), confirmation (an input message), and response (an output message that ends the exchange, changing state on the client, the server, or both).

Table of Contents

Status

Motivation

Table of Contents

Definitions

Informal Description

Formal Description

Fault Handling

Interactions with Other Features and MEPs

Notes

References

Definitions

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119.

Message Exchange Pattern Name

Required Features

Prefix Mappings

Property Definitions

conf:Role
RequestingSOAPNode/RespondingSOAPNode.

Informal Description

Basic Operation

Operation through Intermediaries

Formal Description

Basic Operation

Operation through Intermediaries

Fault Handling

Interactions with Other Features and MEPs

Notes

References


Amelia A Lewis
Last modified: Fri Oct 11 16:14:04 EDT 2002