LibertyWSFRoadmap

The ID-WSF 2.0 specs have been formally released, so they're stable and publically available from the Liberty web site at http://www.projectliberty.org/resources/specifications.php#box2

Foundational Material

The ID-WSF 2.0 spec set is fairly large, and covers a lot of ground. (See LibertyWSFIntro for a basic introduction.) It's a good idea to have a rough understanding of the primary standards that WSF is based on before trying to digest it all at once.

• SOAP 1.1: WSF is a "web services" framework, and in the commercial sense at least, that means SOAP. WSF 2.0 is designed for SOAP 1.1, the only version that has seen wide deployment. If SOAP 1.2 ever matters, then a future WSF version will migrate to it.
• WS-Addressing 1.0: Currently a W3C Proposed Recommendation, it's rather abstract in presentation, but where WSF is concerned, it plays a key role in providing SOAP message addressing and routing syntax, eliminating some older SOAP headers that earlier WSF versions had to define. It also defines a key structure called an EndpointReference , which is a way of describing where and how to invoke a WSF-compliant web service, including security requirements.
• WS-Security 1.1: Updated OASIS standard, this is the base spec that defines the syntax of various security measures like signatures, encryption, and attachment of security tokens in SOAP headers. WSF security mechanisms are based on this spec, the relevant token profiles (mainly the SAML Token Profile 1.1, which includes SAML 2.0 support), and other common technology like X.509 certificates and SSL/TLS.
• SAML 2.0: Finally, not surprisingly, there's a lot of SAML 2.0 in WSF, for two main reasons. First, WSF is designed to compose with and bootstrap from the original Liberty ID-FF specs, which evolved into SAML 2.0. Secondly, the primary federated security mechanism for WSF 2.0 services is based on SAML 2.0 because it's a standardized security token with enough capability to model the security semantics WSF is designed to capture.

ID-WSF Low-Level Specs

There are a lot of different specs, most of them fairly well isolated from each other, but there are some natural dependencies. The WSF Technical Overview is a good starting point to get an overview (duh) of what's in the framework. Some of it is a little too high-level and some a bit too detailed, but on the whole it's a good place to start skimming.

As an order to approach the technical material, I would suggest:

• LibertyWSFSOAPBinding: Defines the basic message structure and SOAP header blocks (required and optional) that make up a WSF SOAP message, a lot of it derived from WS-Addressing.
• LibertyWSFSecurity: Interoperable profiles for securing LibertyWSFSOAPBinding messages in various ways, including a SAML 2.0 profile supporting services acting on behalf of user identities.
• LibertyWSFAuthentication: Includes a web service for client authentication designed around the SASL framework, and a pair of SAML 2.0 profiles that combine the SAML Authentication Request protocol with the LibertyWSFSOAPBinding. This provides clients and servers with the ability to leverage SAML tokens (or other LibertyWSFSecurity mechanisms) and obtain new SAML tokens for use by other services.

ID-WSF Service Specs

There are a handful of infrastructure services defined on top of the core messaging and security layer:

• LibertyWSFDiscovery: Powerful but somewhat overloaded, combines registering and locating web services with the capability to issue security tokens needed for accessing them. WSPs register their service information and indicate their security requirements so that a query can return everything a WSC needs to access a WSP in a single EndpointReference structure.
• LibertyWSFPeople: A web service enabling users to reference other users across IdPs without requiring the use of global identifiers. The People Service utilizes features exposed by Liberty IdPs to map identifiers between namespaces and can issue invitations on behalf of users to establish new federated identifiers across domains.