Most of the protocol flows of TAS3 use industry standard Web Services bindings and Web Services payload protocols. It is an explicit design goal that existing services are enabled with minor disruption.
A pertinent problem with existing payload service protocols is how to express the sticky policies that generally have to be bound to the data with a digital signature. Following approaches have been identified
Treat all data in one request-response pair as having the same Sticky Policies. In this cases relatively nonintrusive methods
like SOAP headers and LDAP controls can be used to indicate
the sticky policies. We call this Security Header (SH) approach.
This approach is already available as
Use the extension points of the payload protocol to express the Sticky Policies. We call this approach Application Protocol Enhancement (APE), see [TAS3D71IdMAnAz] section 8.2. This approach gives granular Sticky Policies that are naturally associated with the data and does not alter top levels of protocol processing. If client and server are updated to understand this scheme then it works well. Eventually new payload protocols should be specified with TAS3 APE feature built in. A danger of this approach is that if the client is not updated, it may just silently ignore the Sticky Policies.
Expand the data model to carry sticky policies. This is really a special case of APE with similar merits and problems. One benefit is that it is sometimes easier to extend a datamodel than a protocol.
Encapsulating Security Layer (ESL), see [TAS3D71IdMAnAz] section 8.2. Wrap the payload protocol in a TAS3 defined encapsulating protocol that contains all the TAS3 specifics and in particular the sticky policies. Advantages of this approach include
The encapsulated protocol does not need to be modified at all
Possibility to add sticky policies to protocols that do not offer extension points and that are not under control of the implementer.
Disadvantages of this approach are
More invasive on outer layers of the protocol stack. This may make it difficult to integrate to existing protocol stack.
If the payload protocol is not SOAP, or otherwise has poor impedance match to the TAS3 ESL protocol, then integration may be impossible.
Association of the sticky policies to the data will require awkward correlation of data items to the policies. In particular, if the data does not have item specific IDs, it may be necessary to resort to use of techniques such as [XPATH99].
Given the multiplicity of approaches, each with its merits, the problem arises as to which one should be used. Luckily all can coexist in the same Trust Network. This is made possible by expressing different approaches as different Service Types so that it is possible to discover services that make the approach supported by the client possible. Another approach is to use autodetection, observing the namespaces and elements passed in the SOAP payload to determine which one is being used.
Which of the approaches works best and difficulty of supporting several in parallel are topics of active research in TAS3. A future version of this document will give better guidance for selection of the approach. Currently (May 2009) the APE approach has been successfully used in situations where payload protocol was under our control. The ESL approach has been prototyped, but the specifics of this protocol are still to be determined.