Understanding Windows CardSpace: Hints Toward a Solution

This chapter is from the book 

WS-* Web Services Specifications: The Reification of the Identity Metasystem

The Identity Metasystem looks very much like the solution we were searching for. However, what we have defined so far is still far from an implementation. We could devise systems in which negotiations and exchanges are made by throwing paper airplanes or swapping carrier pigeons and design those systems in a way that (given adequate bridging technology) satisfies the requirements we have described so far. From a more pragmatic point of view, giving the Internet an identity layer requires supplying a concrete, interoperable implementation of the components we encountered in the preceding section: a claim-based identity representation, a negotiation protocol, an encapsulation protocol, and so on. Those components must guarantee state-of-the-art security at every stage, but they must be technology and platform-agnostic; they must enjoy as wide a consensus as possible from the key players in the IT space and be accessible from the widest variety of platforms, contexts, and connectivity types. Sounds like a very challenging endeavor, borderline impossible.

Didn't you hear this story before? Another technology in recent years exhibited a similar value proposition, trying to break free from platform or transport dependencies. That technology is loosely referred to by the name web services.

Web services constituted a new way of exposing software to a distributed environment. The key idea behind web services is that, if the entire industry can agree on a set of common standards defining the key aspects of messaging, direct cross-platform interoperability is achievable. That vision gathered an unprecedented number of leaders in the IT industry. In an impressive collaborative effort, historical competitors set aside their differences and began a process of specification definition and standardization that is going on still today.

Web services solved many of the challenges related to the attempt to put into practice the principles behind the Identity Metasystem. They are platform-agnostic by design, they pay special attention to security, and they are a technology widely available in the product offerings of the main IT vendors and in the Open Source world. For this reason, the portion of the Identity Metasystem already in place today is largely based on web services.

In this section, we take a short break from identity and dedicate some time to understanding web services as a phenomenon and as a technology. We position them in the IT landscape and revisit basic principles, terminology, and the aspects more relevant to identity. After we cover the essentials, you will see how the various components of the Identity Metasystem are concretely implemented via advanced web services.

The WS-* Specifications

Developing distributed systems has always been one of the difficult problems of the IT industry. A piece of software that tries to communicate with another software entity across networks or other boundaries needs to address a number of problems. How do we route information to the destination? Which technique should be used for pumping data across the network? Which data format should be used? How do we ensure that the communication is secure and reliable? How do we guarantee that the communication happens in transactional fashion?

The standard way of dealing with those problems was represented by imposing on the designers the need to have complete knowledge of every node of the architecture. That meant knowing in detail which technology was used for developing all the software entities; which technology was used for exposing those entities on the network; and finally, all the painstaking details about the specific functions performed, the exact parameters exchanged, and their expected formats. The task was usually eased by using one single platform because doing so greatly reduced the number of variables coming into play. Component hosting systems such as COM+ and Java EJB emerged, and network middleware such as CORBA and again COM+ offered services for handling software communications. However, the results were often brittle. The tight coupling between software components (i.e., between who provided a function and who consumed it) made the systems extremely susceptible to changes and difficult to maintain. Cross-platform communication was also challenging and painstakingly achieved by ad hoc integration components and expensive bridges.

As the IT world grew in importance and ubiquity, it became clear that those systems could not cope with the strain of increasingly diverse software environments coming from mergers and acquisitions, the need for integrating different software packages, and the dissolution of the boundaries between company information silos. Enterprise application integration knew a short period of popularity, but it was soon clear that there was the need for a strategic, long-term solution that would embrace different technologies. Again, you might have heard this story before!

While all those forces were building up pressure, part of the industry was trying to exploit the emerging ubiquity of the markup languages, such as HTML and XML, to devise a way to easily communicate across platform boundaries. Studying the universal success of HTML as the language of the Web, people realized that a large part of that success was due to its minimal requirements and resilience to errors and interpretations. As a result, in 1998 the first version of the Simple Object Access Protocol (SOAP) specification emerged. It was a very rough cut of what we know today; however, it defined the core of many key concepts still valid in the current vision. The specification defined how to project in-memory data types to XML format, a platform-neutral representation that can be understood without knowing anything about the technology that originated the data. It also defined a rough protocol for message exchange, again abstracting away the need to rely on a specific network transport protocol.

The initiative gained wide consensus among the main industry players and the analyst firms, with more and more important vendors joining the ranks of the specification proponents and backers as subsequent versions were released.

With the problem of sheer data transfer interoperability on its way to being solved, the market moved to consider the next stage: advanced communication capabilities. SOAP and its associated specifications (see the section "Basics" later in the chapter) didn't provide any way to secure messages from tampering in transit, nor was there a mechanism to provide confidentiality to communications; there were no means for a message sender to know whether a message actually reached its destination (and so on). Because the main purpose of web services was to connect loosely associated parties, shortcomings such as the absence of security were especially painful. There was still the chance of leveraging features of the actual transport—for example, sending SOAP messages through HTTPS would have guaranteed confidentiality; relying on that, however, would have partially eliminated the benefits of SOAP's platform-emancipation efforts.

Extending the SOAP specification with security features was a risky path. After having observed the issues with comprehensive but bloated solutions such as CORBA, SOAP was intentionally kept simple so as to keep its size and scope to a manageable level.

The industry broke the impasse by creating additional web services specifications, each designed to solve a single aspect of the advanced communication problem. All those specifications built their new functionalities on top of SOAP and sometimes on top of other web services specifications. The idea was that implementers were not forced to deal with the full range of possible capabilities, but they could have chosen which specifications to implement according to the requirements of their systems. The specifications were all designed to work with each other gracefully, without imposing any unnecessary dependency.

The specifications were named according to a consistent pattern: WS-Security describes how to add security capabilities to SOAP messages, WS-ReliableMessaging establishes a protocol for adding reliability assurances to web services communications, and so on. That earned them the collective name of the WS-* specifications.

Today the WS-* specifications cover most of the key aspects of cross-platform software communication. Many of them already enjoy the status of industry standards ratified by entities such as OASIS or the W3C. Many products on the market, from the most diverse vendors or Open Source projects, leverage those standards for interoperating out of the box across different platforms.

Such ubiquity, coupled with advanced security capabilities, constitutes the ideal foundation for implementing a truly inclusive Identity Metasystem. In the next several sections, we familiarize you with some of the most important WS-* specifications, to the extent to which we can later understand what their roles are in the Identity Metasystem architecture.

Basics

The main idea behind web services is simple: Use a universally understandable format for describing your data and define a way to describe how you want to communicate with your software. That is achieved through a number of specifications that build on one another.

XML

The Extensible Markup Language (XML) is an immensely popular markup language, which has the advantage of being readable cross-platform and, when the complexity and size permits it, by humans as well.

To trivialize things a bit, XML is like a generic-purpose HTML. Where in HTML markups represent hints to the browser about how to render a page, in XML, markups just represent data. Figure 2-3 shows an example of an XML document.

XML is at the center of many important satellite specifications, such as XML schemas and XML namespaces, which we do not cover here.

SOAP

The SOAP specification, currently at version 1.2, defines what a web service message should look like and how it can be sent between two endpoints. SOAP represents everything using XML.

Imagine having a piece of software that performs the sum of two integer numbers A and B. A SOAP message requesting your software to perform the sum may look like that shown in Figure 2-4. It is an XML document that has a root element called envelope.

The area between <env:Body> and </env:Body> is called the body of the message, and it contains the data for your software. The area between <env:Header> and </env:Header> is called the SOAP header element, and it's the key to SOAP extensibility. That is one area of the message where the infrastructure can weave additional information, enriching the communication with further capabilities. All the nonbasic WS-* specifications leverage this mechanism.

WSDL

Once a caller knows that it can use SOAP for communicating, it needs to know which kind of data the software can handle. The Web Services Description Language (WSDL) absolves that function. Documents written in WSDL describe the operations exposed by a web service and the message format required (and returned) for every function provided. The idea of an explicit contract is very important in software development and in web services and service orientation is possibly even more important. However, further discussion of such is beyond the scope of this book. For a comprehensive coverage of the topic, consult Understanding Web Services (Newcomer, 2002).

WS-Addressing

In Chapter 1, in the section "HTTP," we saw how web page addresses work. The address http://www.bob.com/bob/homepage.htm tells the browser to use the HTTP protocol for retrieving the HTML document homepage.htm residing at the path /bob/ on the web server www.bob.com. The address is both a unique identifier and a way to retrieve the page. The same mechanism could be used for web services, and in fact this is common practice in many applications. However, this does not play very well with web services' attempts to be independent from the underlying technology. HTTP mandates the use of one specific protocol, whereas the web service should be able to be moved on some other transport without dependencies. WS-Addressing provides a richer way of referring to web services, helping to overcome the previously mentioned limitations and supplying the more expressive model that is required by the other advanced WS-* specifications.

WS-Policy

WSDL describes the operations offered and the message formats required by a web service, but it does not give further details about any other requirements associated with the web service invocation. For example, a web service implementing a wire transfer may be invoked with the correct message format, but the software will not execute the operation unless the caller identifies itself using a certain authentication technique. WS-Policy provides a generic purpose for describing such requirements, which are said to be the policy of the web service. WS-Policy (and its sister specification, WS-PolicyAttachment) does not define any domain-specific policy assertion such as the one about authentication in the preceding sample. It is a generic mechanism for associating requirements ("policy assertions") to a web service, and as such it does not mandate any particular format. Other specifications, such as WS-SecurityPolicy described later, leverage this general-purpose mechanism for codifying requirements of a specific domain.

WS-Security

WS-Security was the first specification building on the extensibility capabilities of SOAP. Although the specification itself and its derivatives are fairly complex, the purpose of WS-Security is straightforward. It defines ways of protecting SOAP message exchanges and provides a means of transporting security-related information.

Given the enormous success of XML, the industry soon felt the need to provide some security mechanism that could guarantee confidentiality and integrity to the new format, without giving up its cross-platform reach. As a result, the W3C devised two standards, XML Signature and XML Encryption, which describe ways of applying cryptography to XML documents (see the section "Cryptography: A Minimal Introduction" in Chapter 1). Such standards described extremely flexible operations, in which different parts of the document could be encrypted or signed using different algorithms or even different keys. WS-Security describes how to apply XML Signature and XML Encryption to a special kind of XML document, the SOAP message. Without going into the fine details, the peculiar structure of a SOAP message offers a natural way to apply the model. The message can be modified according to the intended operation—for example, by substituting the body with encrypted data—while the SOAP header can carry a description of the cryptographic transformation that took place. The receiving end of such a message analyzes the content of a special WS-Security SOAP header, discovering that the body was encrypted using a certain algorithm and a certain key; if the receiver owns the corresponding key, he can now reverse the process and decrypt the body. The signature case is analogous.

Figure 2-5 illustrates such a SOAP message.

WS-Security does not introduce any new cryptographic algorithm, nor does it define any new source of keys. SOAP is a trade language, designed for bridging different platforms and technologies. To effectively support the SOAP mission, WS-Security needs to be able to accommodate existing security technologies and promote interoperability among those. If it sounds quite similar to what we have seen for the Identity Metasystem and existing authentication technologies, that's because it is.

WS-Security needs to be able to encrypt and sign SOAP messages by using the technologies available to its users: X.509, Kerberos, SAML, username and passwords, plus every present and future source of cryptographic material are candidates. However, there cannot be any explicit dependency in the specification; otherwise, the good cross-technology properties would be lost. The WS-Security authors devised a clever trick for solving the impasse. The specification assumes that the cryptographic material travels in a WS-Security security token, a generic data construct, and refers to it for defining the various encryption and signing operations on the message. Then they separately provided satellite specifications, named token profiles. Each token profile describes how to derive a WS-Security token from an existing security technology, mapping the peculiarities of the particular system to generic WS-Security features. For example, a web service may mandate that the body of the message be signed without specifying the kind of key used. A certain caller may sign using a security token derived from an X.509 certificate, whereas another may use a security token derived from a Kerberos ticket. As long as the receiving end can verify the validity of the signature—for example, by choosing by a pool of well-known certificates or by being part of the same Kerberos domain—everything goes as expected. If at some point in the future a new authentication technology is released, and a suitable token profile is defined, the new technology can be seamlessly integrated into the system without requiring any major change. This arrangement effectively decouples the security capabilities of the protocol from the technologies actually available, allowing users of different technologies to speak a common tongue while still having a return on their investment on the platform of choice. Those are exactly the good properties we indicated as key requirements for the Identity Metasystem, at a lower abstraction level. As discussed in the following sections, the WS-Security token occupies a pivotal role in realizing an architecture coherent with the vision of the Identity Metasystem described thus far.

WS-Trust

The section "The Babel" in Chapter 1 subdivided the authentication schemes into two big families: the ones based on certificates and the ones based on issued tokens. WS-Security can handle security tokens derived from both schemes, as long as the requirements expressed by the relevant token profile are applied. Every authentication technology based on issued tokens describes in its own way how a client can obtain a token. The two examples we have seen, Kerberos and SAML, perform that operation in very different ways. WS-Trust generalizes the token-issuance operation to WS-Security tokens. In other words, WS-Trust extends WS-Security with methods for issuing, renewing, and validating security tokens in a platform-agnostic manner. The advantage is evident. Whereas WS-Security assumes that you managed to create your token outside of your web service architecture, using some unspecified security technology, WS-Trust allows you to also model, in technology-agnostic fashion, the operations necessary to obtain tokens. Thanks to WS-Trust, web services–based systems can now enjoy the flexibility of issued token–based technologies with the added bonus of not being tied to any specific stack.

How does that all work? With its 75 pages of dense security considerations, the WS-Trust 1.3 OASIS Standard specification is a fairly complex document. A comprehensive description of the standard is beyond the scope of this book. However, it is of paramount importance to understand very well the main scenario and the associated terminology because it is the cornerstone of today's Identity Metasystem implementation.

WS-Trust introduces a special kind of web service, called Security Token Service (STS). To put it simply, the job of an STS is "transforming" WS-Security tokens. One token enters; another token exits.

Let's assume that a certain client C wants to invoke a certain web service S. Let's also assume that S specifies in its policies that for security reasons it will accept requests only if secured by a certain WS-Security token, say a SAML-based WS-Security token containing a certain claim about C. C can ask an STS to issue the SAML token it needs for calling S. The request is performed by sending a special kind of message, whose format is described in WS-Trust, called a Request for Security Token (RST). The RST contains, among other things, the description of the kind of token that C is asking the STS to issue. The STS, however, will not issue tokens to just anybody. Because the SAML token required must contain a claim about C, the STS must make sure that is actually C who is requesting the issuance (read, the RST message is actually coming from C). Hence, C must secure the RST message in a way that will convince STS of the correct provenance of the message. In WS-Security terms, this means that C must secure the RST using some security token. For example, C may secure its request to the STS using a Kerberos-derived security token.

When the STS receives the RST, it examines the incoming token and checks that it was properly secured. If everything is as expected, the STS considers C's identity as verified and proceeds to generate the requested SAML token. The newly generated token is sent back to C inside another WS-Trust-defined message called a Request for Security Token Response (RSTR). When C receives the RSTR, it can extract the requested SAML token and use it for invoking S. Upon receipt of the invocation, S can extract the SAML token and verify whether the claim about C satisfies its requirements. Figure 2-6 shows the exchange just described. The end result is straightforward. The STS received a Kerberos token and issued a SAML token in return.

At this point, you might be asking yourself where the "trust" aspect in all of this is. The answer to that is simple: The scenario just described was just a fairly elaborate dance for allowing C to benefit from the trust relationship between S and STS.

In the generic case, the reason for which C has to go to the STS goes beyond the sheer need of changing token format. Usually S does not trust C, so C needs to be endorsed by somebody who S trusts. Remember our ever-present wine seller example. In this case, the web service S is the wine seller, and the client C is the buyer. The claim requested by S is the age, and the picture ID that the buyer shows to the wine seller is the security token. Just as the wine seller trusts the age written on the picture ID because it is government issued, S trusts the content of the claim in the SAML token because the latter is coming from the STS. The analogy is not a perfect match. If it were, in the offline world it would mean that your driver's license (or any other ID document) would always be expired, and you'd have to get one freshly issued every time you need to show it to somebody. In that case, you would need to contact your department of motor vehicles on-the-fly, and they would want to verify your identity (maybe checking your passport) before issuing you a new license. As you probably have already discerned, the department of motor vehicles plays the role of the STS, and your passport has the same function as the Kerberos token in our diagram. It is okay that the analogy is not 100 percent accurate. Tokens and picture IDs have many similarities, but the former can be used in many more ways and enables scenarios that do not have a counterpart in the offline world. Besides, we dare the bureaucracy of any administration to issue IDs as fast as an STS can issue tokens! That said, there are still some instructional aspects of the analogy that would be useful to spell out. The wine seller knows that the picture ID shown by the client is true because it recognizes the government manufacturing (e.g., holographic serigraphy or special paper) and implicitly assumes that it is extremely difficult to forge. How can S be sure that the SAML token presented by C was actually issued by the STS that S trusts? The system is much more secure than the offline counterpart. The STS signs with its private key all the tokens it issues, so anybody knowing the STS public key can verify their source. Furthermore, the wine merchant compares the facial features of the client in front of him with the picture in the ID document, thus verifying that the document was actually issued to the buyer. In the web service world, C demonstrates that the SAML token was actually issued to it by being able to use the token for securing its request to S. In doing to, C is showing off that it knows a certain key that could have been acquired only from the RSTR that contained the token. There is no need to understand the details of that exchange. The bottom line is that S has cryptographic proof that C is the legitimate holder of the token, so the token cannot be fraudulently repurposed by others.

In summary, WS-Trust defines entities and messages for issuing WS-Security tokens via web services. The preceding example explored the scenario in which a client requests that an STS issue a token. However, the specification covers many other cases, such as issuance requests coming from services and token management beyond pure issuance (token renewal and validation being two examples). We concentrated on that scenario because, as we observed, it exhibits striking similarities with identity-related transactions we encountered elsewhere in the text. In the section "WS-* Implementation of the Identity Metasystem," we further clarify the parallel. The capability of WS-Trust of expressing trust relationships between parties will play a key role in the realization of an identity layer for the Internet.

WS-MetadataExchange

WSDL and WS-Policy provide means to describe the web service to the world, or better, they help define the ways in which external callers are supposed to interact with the service itself. In the first years of web service existence, those documents were acquired by potential callers out of band or leveraging features of the specific web service stack implementation. For example, the Microsoft stack made the WSDL of a service available at one special address, obtained by attaching the string "?WSDL" to the address of the service itself. As the web service–based transactions grew in complexity, it became clear that there was the need to define how to acquire service metadata in a standard and programmatic fashion. WS-MetadataExchange is a protocol that fulfills exactly that purpose. It allows one caller to query one web service and obtain its metadata information, typically WSDL/policies.

WS-SecurityPolicy

WS-SecurityPolicy defines an assertion framework (that is, a collection of assertions and assertion operators) aimed at expressing security requirements for the invocation of web services. It builds upon the more generic WS-Policy, standardizing how to express requirements such as how to mandate in a message the presence of a security token of a certain shape, which parts of a message should be signed or encrypted and with which keys, and so on. Although WS-Policy is generic enough to express any policy, it is good to have, for security, a set of standard assertions with a well-known semantic to which every platform and product can refer without further negotiations.

WS-Federation

We already encountered the concept of federation. However, it is worth revisiting the concept. A federation is a set of two or more entities, where resources of one entity can be accessed by identities belonging to another entity. If that sounds confusing, just think of the example offered in the sections "User Control and Consent," "Minimal Disclosure for a Constrained Use," and "Claim Transformers." In that instance, the two entities were a company and its hardware supplier. The hardware supplier was offering access to its web store (the "resource") to the employees of the first company. The two formed a federation.

WS-Federation builds on top of WS-Trust and WS-Security, organizing the primitives offered by those specifications in a higher-level language suitable for modeling systems such as the example just mentioned. In practical terms, given a certain topology of clients, services, and STSs, WS-Federation establishes the sequences of messages that must be exchanged among the various parties for obtaining a certain result. In our simple example, the result is an employee of the first company accessing the web store offered by the hardware vendor, but WS-Federation is expressive enough to solve much more complex scenarios such as multicompany single sign-on. WS-Federation describes how to deal with those scenarios in synergy with other WS-* specifications. The case in which the actors are web services is described as the active requestor case. A requestor is active because, being web service capable, you can expect it to be able to use cryptography on the messages emitted and show off the ownership of keys.

A comprehensive solution, however, cannot ignore that many transactions are driven through the use of a web browser. A web browser cannot apply cryptography to messages in the same way as a web service can. Hence, this situation must be accommodated by opportunely devising message exchanges protected by transport security. WS-Federation devotes a comprehensive portion of its text for addressing the web browser case, which is referred to as the passive requestor case.

WS-Federation is a specification of key importance. The explanation we gave here does not even begin to scratch its surface. It is advisable to everybody interested in enterprise identity management to become intimately familiar with this specification.

The Identity Metasystem and the practices it enables are often defined as "user-centered federation." Whereas WS-Federation relies on automatic sequences driven by metadata and by inter-company partnerships, the Identity Metasystem can leverage the newfound user control for driving decisions with much looser relationships between entities. The two models are complementary, and they have ample areas of collaboration and synergy. Chapter 4, "CardSpace Implementation," discusses how Windows CardSpace handles federation in more detail.

WS-* Implementation of the Identity Metasystem

In the previous section "The WS-* Specifications," we devoted some time to better understanding the phenomenon of web services. Web services emerged in independence from the identity-related considerations we presented in this chapter, but they are the best tool at the industry's disposal for putting into practice the requirements discovered while formulating the seven laws and envisioning the Identity Metasystem.

Identity Metasystem Components as WS-* Features

Let's put the idea to test. Imagine that the three roles defined by the Identity Metasystem (subject, relying party, and identity provider) are implemented as web services. To be exact, we should say that every role will communicate with the other entities via web services. Holding on to that assumption, let's recall what the components of the Identity Metasystem were, as follows:

• A way to represent identities using claims
• A means for IPs, RPs, and Ss to negotiate
• An encapsulating protocol to obtain claims and requirements
• A means to bridge technology and organizational boundaries using claims transformation
• A consistent user experience across multiple contexts, technologies, and operators

The component-consistent user experience across contexts cannot be addressed directly by a protocol (even if it is the existence of a common metaprotocol that makes consistency possible to begin with). Therefore, we defer consideration about it until after the discussion on WS-*. All the other components find perfect fits in the entities and capabilities provided by the WS-* specifications.

A Way to Represent Identities Using Claims

The obvious candidate for representing an identity in data exchanges is the WS-Security token. A token is self-contained and claim-based by design, so it owns the necessary expressive power for describing a digital identity as we defined it. The definition of token in WS-Security and the token-profiles mechanism avoids dependencies from existing and future authentication technologies, maintaining the potential to embrace them all. Finally, a token issued by an STS can be tracked with cryptographic certainty to its source. That makes the RST-RSTR transaction described in the section "WS-Trust" the perfect implementation of the process, followed by the S for acquiring an identity from the IP.

A Means for Identity Providers, Relying Parties, and Subjects to Negotiate

Web services architectures try to keep out of band communication to a minimum, aiming to expose all the information relevant to invocation via standard means. WSDL and WS-Policy, with its specializations such as WS-SecurityPolicy, make explicit to everyone the requirements that must be satisfied for being able to use a certain web service. The requirements can cover the most diverse areas, and they can certainly address things especially relevant to the metasystem such as expressing which authentication technology should be used. WS-MetadataExchange makes it possible to acquire such requirements directly online, keeping the need for coupling between parties as low as possible. RPs can easily use the tools above for expressing what it takes for engaging in business with them.

WS-Policy and WS-Metadata exchange can easily tell the subject that the web service of an online wine merchant requires a SAML token from the STS of the department of motor vehicles (driver's licenses), and that such a token must contain a claim with the age of the S. An S can acquire the relevant policies via WS-MetadataExchange and make a match between requirements and capabilities. An IP that would expose its identity-issuing capabilities by mean of an STS could specify its requirements using exactly the same specifications.

An Encapsulating Protocol to Obtain Claims and Requirements

Because we implemented digital identities using security tokens, it follows pretty naturally that the encapsulating protocol is WS-Security itself. WS-Security defines how to attach and use security tokens to messages. Such a definition does not change regardless of the source from which the WS-Security token was derived, being it SAML, X.509, Kerberos, or any other technology. WS-Security serves the purpose of the encapsulating protocol very well.

A Means to Bridge Technology and Organizational Boundaries Using Claims Transformation

Claims transformation can be easily performed by an STS. Security tokens are flexible enough to provide the technology and claim types transformations for bridging differences in requirements such as the ones described in the section "Claim Transformers."

The Dance of Identity—Implemented by WS-*

Now that we have defined a mapping between the Identity Metasystem and web services elements, we can give concrete indications about how the sequences presented in the section "The Dance of Identity" can be implemented with technologies available today. We will revisit the two sequences, specifying how every step is realized with WS-*.

The Canonical Scenario

Again we have one subject, S, one relying party, RP, and an identity provider, IP. The RP is implemented as a web service; the IP offers its functions by mean of an STS. (An STS that offers IP functions is often referred to as an IP-STS.) S was and remains a person, a human user of the system. For the purpose of this walkthrough, we will assume that S uses some sort of agent that hides the complexities of the web services interactions. We will get back to that agent in greater detail in the section "Presenting Windows CardSpace."

With this web services mapping in mind, let's revisit the original sequence under a new light (see Figure 2-7):

1. S wants to call RP. The S's agent reaches out to the RP via WS-MetadataExchange, to acquire the RP's policy and requirements. The WS-MetadataExchange returns a WS-Policy document containing some WS-SecurityPolicy assertions. The RP states that it will consider for authentication only the users presenting an identity issued by IP's STS, in SAML1.1 format and containing Claim1 and Claim2.
2. The S's agent checks if S has a relationship with IP that would allow it to ask for a token of the right format and with the requested claims in it. It then presents to S its options (that is, all the courses of actions that will end with the acquisition of a token satisfying RP's policy).
3. Assuming that S does have a suitable relationship with IP and that S chooses to pursue that option among the ones offered by the agent, S's agent uses WS-MetadataExchange for acquiring IP's invocation policy.
4. The S agent uses the information acquired in the former step for requesting an identity from IP's STS, by sending an appropriate RST. The agent will also take care of finding the token that the IP-STS requested for securing the RST.
5. The S's agent receives the RSTR from IP, and with it the required token. The S's agent returns the token to S. S goes through the experience of examining the details of the identity, such as the content of Claim1 and Claim2, and decides whether it consents to the disclosure of that information to RP.
6. If S decides to disclose, it uses WS-Security for securing the token obtained from IP the invocation to RP.

The preceding sequence uses only technologies in wide availability already today, yet all the requirements imposed by the Identity Metasystem are preserved. If all parties understand WS-*, a requirement that does not mandate any particular platform per se, the negotiation capabilities of WS-Policy and WS-MetadataExchange guarantee that if there is a match among the parties, it will be found. WS-Security ensures that the specific technologies are properly tunneled while maintaining a common abstract protocol, whereas WS-Trust guarantees that if there is a trust path between parties, the system will be able to exploit it for flowing identity information.

Brokered Trust

The case of brokered trust is analogous to the one described in the section "The Dance of Identity." The rules of mapping to WS-* elements are the same ones demonstrated in the previous section. There is one thing that is worth highlighting: IP2 is still implemented as an STS; however, in the brokered trust scenario it performs pure claim transformation rather than sheer identity provisioning. An STS that performs that kind of function is called a Resource STS, or R-STS, because it takes care of mapping claims for a resource as opposed to providing identities for generic utilization. RSTSs are discussed more in depth in Chapter 4, in the section about federation, and in Chapter 6.