D2.4 TAS3 Protocols, API, and Concrete Architecture

December 2009 version (v1.48) of deliverable D2.4 (TAS3 Protocols, API, and Concrete Architecture) is open to public comments, feedback and review !

All feedback welcome ! 

You could download it and publish comment from here:

http://www.tas3.eu/project/publications/download/wp2-framework-architecture-semantics/TAS3_D2p4_Protocols_API_Concrete_Arch_v10.pdf/view

(you need to login first to put a comment)

---

Executive Summary

This document specifies a set of protocol level interoperability profiles, usually leveraging open standards, deployment scenarios, APIs, and other considerations that constitute the official way to deploy version 1 of TAS3 architecture, see [TAS3ARCH]. The purpose of defining these specifics is to enable multiple independent implementations of TAS3 to be wire protocol interoperable (and to limited extent also API interoperable). TAS3 reference implementation and reference deployment will behave essentially as described in this document.
The TAS3 architecture is designed to be standards, protocol, data and application agnostic so that any protocol capable of implementing the flows and satisfying the service requirements can potentially be used by any application. However, to build practical systems, different components, possibly from different sources, must speak the same protocols, hence TAS3 provides this profile that allows interoperability at the level of Single Sign-On, Web Service Discovery, Web Service Call, and Authorization. The standardized profile provides the scaffolding where plurality of trust and privacy negotiation mechanisms, policy languages, obligations and other value added features can exist.
The TAS3 API is designed to allow an application programmer to understand how simple it is to "TAS3 enable" his application. It is noteworthy that using the API does not require any in-depth knowledge of the underlying standards, protocols, and profiles, or indeed even of the TAS3 Architecture itself. All these details are taken care of by the API implementation, supplied commercially or in open source. The TAS3 Reference Implementation will be one such API implementation. The APIs will be available in all popular programming languages and platforms.
The simplicity of the API is due to a coherent integration model that shows how the steps from SSO and Authorization all the way to the web service calls work together and are able to pass necessary credentials and tokens "behind the scenes" by the use of session and other state information. Many design parameters that could have been handled by yet another argument to the API functions, are in fact handled by configuration file, with sensible default values, and automated discovery, trust negotiation, and trust network business processes.
The split between explicit arguments, configurability, and automated processes has been guided by division of concerns between the application programmer and the systems administrator. When automatic mechanisms are used, appropriate manual control point exists elsewhere in the architecture, e.g. automated discovery is kept in check with explicit authorization.
We provide guidance regarding possible integration and deployment scenarios and illustrate how TAS3 Architecture can be deployed in a resilient and redundant way.
Neither this document nor the TAS3 Architecture [TAS3ARCH] mandate use of a particular deployment or software architecture (although the integration scenarios suggest a recommended one), implementers are free to organize their software and deployment in other ways as long as the wire protocol compatibility is maintained and all signature generation and validation steps, as well as trust determinations, and authorizations are implemented.
The Annex gives some example protocol messages.