[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.
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.
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).
Interactions with Other Features and MEPs
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.