Understanding Windows CardSpace: Hints Toward a Solution

This chapter is from the book 

Trust

The concept of trust is pivotal in the IT security literature, and it can certainly elicit interesting philosophical digressions. In this context we will be much more prosaic, and we will simply define trust as the willingness of a subject to believe the claims asserted by a certain other subject. If Alice trusts Bob, any claim Bob will make will be considered true by Alice. There's that little matter of making sure that Bob is really who he says he is and verifying that the claims are actually coming from Bob; but after that is taken care of, Alice will believe just about anything. Technically, that is not strictly true because Alice's trust for Bob may be bounded only to certain areas. However, for the purpose of the explanations in this text, we can safely think in terms of unbounded trust.

Verisign says, via a certificate, that this website is "contoso.com"? Your browser is happy. Your government says, via a difficult to fake ID card, that you are over 21. Your bartender smiles and pours Chianti in your high-stem glass. That's trust.

Roles in the Identity Metasystem

The Identity Metasystem abstracts the entities and processes involved in identification operations.

The various actors participating in the transaction are perhaps the first things that need to be modeled, the basic blocks from which we can start to build our Metasystem. Understanding the invariant characteristics of relationships and mutual expectations is a key step toward successfully capturing the essence of the process. Observing the recurrence of such features across many different identity-related transactions leads to the definition of some archetypes, or roles, which successfully describe the behavior and the properties of all the actors involved. Substantially, if an entity participates in an identity-related process, you can always represent such an entity in the Identity Metasystem with one or more of those roles.

The Identity Metasystem distinguishes three possible roles: subject (S), relying party (RP), and identity provider (IP). As the following descriptions will clarify, those roles describe perfectly natural behaviors, in full agreement with the intuition; in fact, they are perfectly suitable for describing identity-related processes happening in the offline world, too. That should not surprise too much. We are rebuilding a system from the ground up, explicitly to get things right, free from the artifacts and aberrations derived from implementation details and historical burdens.

The next three sections introduce the three roles. In the section "The Dance of Identity" later in this chapter, we examine how those three roles contribute to propagate identity information.

Relying Parties

A relying party, often abbreviated RP, is an entity that consumes identities. An RP is typically something or somebody who provides a service that is intended to be enjoyed by a restricted audience. To make sure that the access is granted only to the rightful crowd, the RP requires receiving an identity from the requestor.

The wine seller in the example from the section "Minimal Disclosure for a Constrained Use" is an RP; so is any website that requires you to authenticate yourself before accessing its services. If you examine the section "The Babel," from Chapter 1, you will see that every authentication scheme described includes an entity that plays the role of the RP: intranet services requesting a certificate form a smartcard, HTTPS endpoints asking for a certificate via SSL authentication, the "service B" described in the "Kerberos" subsection. In SAML, the service requesting the caller identity is even called relying party!

The RP is a powerful invariant of identity-related systems. Its requirements are among the main reasons for which we need an identity system in the first place.

Subjects

We have already used the term subject a number of times throughout the book, relying on its common meaning. From a definition standpoint, a subject is just something or somebody who owns a digital identity. From the role definition point of view, however, it is worth considering the definition in more detail.

In the section "Directed Identity," we introduced the differentiation between omnidirectional and unidirectional identities. The former type of identity can often be assigned to every actor in a transaction, or at least to all the ones that exhibit one-to-many relationships. That basically means that the label "subject" can be applied to many entities in an identity system, and therefore its usefulness as a role-differentiating factor seems pretty unlikely. In the context of the Identity Metasystem roles, however, we usually intend the subject as one entity whose unidirectional identity comes into play. That does not mean that the entity cannot also own omnidirectional identities. Instead, it means that for purposes of modeling the behavior of an entity in the subject role in an identity transaction, we will consider only the unidirectional aspect. Translating the example in the section "Directed Identity" into Identity Metasystem terms would result in something like this: If the RP is the actor who consumes identities, the subject is the entity whom the consumed identity is about. If the wine seller plays the role of the RP, the buyer is the subject; it is the buyer's identity, in the sense of the claim defining his age, that the wine seller will want to verify ("consume").

Identity Providers

The concept of IP is extremely natural. It models a role that is practically omnipresent in real-life situations in which people handle identities. Unfortunately, in traditional online authentication schemes, the IP is implicit or is an emergent property of the system, making it difficult to weave into the system the requirements associated with the role.

An identity provider, abbreviated IP, is an entity that issues digital identities. An IP is the entity that asserts the claims constituting a digital identity, typically in virtue of the relationship that associates it to the subject owning that identity. The list of examples from the offline world is endless. Governments can emit claims about their citizens; employers can issue claims about their employees; a department of motor vehicles can claim that a certain individual can lawfully drive particular vehicles; an airline can declare that a given individual is a passenger of a certain flight; a doctor can declare that a specified patient is fit for physical activity; a department store can award a customer with loyalty privileges. A very important example is the one in which an individual makes claims about himself, such as declaring his home address on a feedback form in a restaurant.

Note that in all the previous examples the IP was actually competent in terms of the kind of identity information mentioned. A government is a natural IP for its citizens because it actually owns the information involved (such as the passport number), and it has the appropriate means for managing it (such as demographic archives). Every entity aware of preceding facts will consider the government an authority in the matter of its citizens. In other words, it will trust the government (as trust was defined previously). This simple consideration gives us the last piece for fully translating the wine seller example in Identity Metasystem terms. The wine seller is the RP, the buyer is the subject and the government is the IP that provides the buyer with an identity (for example, in the form of a picture ID document). The RP trusts the IP and therefore accepts the claims on the document as true and acts accordingly, granting or denying the buyer request according to the rules.

Explicitly acknowledging the existence of the IP role is a powerful shift in perspective and helps to reconsider many aspects of identity-related transaction.

One of the concepts that surfaces more clearly thanks to the idea of IP is the identity context. Different RPs will grant their trust to diverse IPs, according to the service they offer or the relationship they themselves have with the IPs. In the offline world, you would never try to board a plane just by showing your driver license, nor would you attempt to get a discount at the local department store by waving your passport. Yet, as mentioned in the section "Consistent Experience Across Contexts," with today's online-authentication system, errors of that magnitude are not uncommon. Expressing identities as collections of claims was the first step toward clarifying the information flow: Explicitly stating the issuer of those claims, and its trust relationship with the RP requesting them, is the step that finally defines the transaction details and helps the subject to make informed decisions.

Another important effect of introducing the concept of IP lies in the reinterpretation of transactions in which the identity information is claimed by the subject itself. In today's online world, many of the low-value services (typically the ones for which you are not charged) do not require the user to be endorsed by any specific IP. The authentication operation will just verify that the current requestor owns the credentials associated with a certain signup profile. That signup profile, created at registration time, is the subject identity. Some portion of the profile will have been entered by the subject itself, and hence it would be considered self-asserted. Name, surname, and email are typical examples of self-asserted claims. Some other portions of the profile (such as the last pages visited on that website in the former session) may contain information that belongs to the RP itself. The Identity Metasystem model allows the self-asserted portion of the user profile to be described as a full-fledged identity, issued by the subject to itself. In other words, the requestor simultaneously plays the role of the subject and the IP. Such an arrangement gives back control and awareness to the user, who can now maintain and disclose information at a finer level of granularity. Above all, however, the use of an IP in the case of self-issued claims provides a level of consistency that can finally satisfy the seventh law, "Consistent Experience Across Contexts." Windows CardSpace expresses self-issued claims via an artifact named Personal Card, which concretely realizes the advantages of the last scenario described here. Parts II and III of this book delve into the details.

The implications of the introduction of an explicit IP role in the system are profound and cannot all be covered here, but you will see more and more of them as the Identity Metasystem is described in further detail throughout this chapter.

In summary, an IP is the first occurrence of the word subject in the definition of digital identity (see the section "(Digital) Identity"). It is the entity that asserts claims about another subject, typically with regard to the relationship between the two. The digital identity is a currency that a subject can spend with a certain RP if the latter trusts the IP that minted it.

Components of the Identity Metasystem

The preceding section introduced the roles that an entity can possibly play in an identity-related transaction. You can verify identities (RP), you can have your identity verified (Subject), and you can provide an identity to somebody (IP). This is a beautiful model that also applies nicely to the offline world. However, we need to lower the abstraction level if we want to give a practical answer to the problem we decided to solve: adding an identity layer to the Internet.

Let's take one step back and gather our thoughts. What do we know so far? We want to solve the problem of propagating identities through the Internet. We said that we want a system of systems that would accommodate existing and future technologies in a single Metasystem (as opposed to yet another technology that would compete with the current and future offering). We have the laws, which warn us that the only constants on the Internet are diversity and change.

The "Microsoft Vision for an Identity Metasystem" white paper, the manifesto of the Identity Metasystem, coalesces the preceding consideration into a need for five key components, as follows:

• A way to represent identities using claims
• A means for IPs, RPs, and subjects 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 list of components could be rearranged in different ways, but we chose to maintain the original criteria for the sake of coherence with the rest of the literature on the S. The following sections explain the components one by one, tying the definitions to the concepts introduced so far.

Claim-Based Identities

At this point in the text, the reader is familiar with the concept of digital identity. In Chapter 1, we observed the shift from blind credentials to authentication in the section "Ascent"; in the section "HTTPS, Authentication, and Digital Identity," we gained an intuitive understanding of the concept of digital identity, where the frequent-flyer example showed a first instance of claims usage; in the section "The Babel," we observed how some technologies incorporate the idea of claim. In this chapter, we gave a formal definition of claims and digital identity in the section "Some Definitions." The reasons why an identity is well modeled by a set of claims have been given throughout the entire text. Now that we have defined the key roles and the relationships among them, it is natural to adopt claim-based identities as the currency exchanged in the Identity Metasystem.

Negotiation

The various participants in the Identity Metasystem support many different identification technologies. How can we achieve interoperability? One important component of the solution lies in the need for a negotiation protocol.

Let's introduce what we mean by negotiation with an example. An Italian person and a Chinese person, perfect strangers, go to an international conference. They meet in the elevator. The Chinese person says to the Italian person "" and the Italian person answers "Non capisco!" As soon as it's clear that they can't understand each other, they shrug and part ways.

Imagine the same scene, but this time the two are wearing the conference badges mentioned in the section "Directed Identity" that identify the languages they speak. The badge of the Italian person says "Italiano, English"; the one of the Chinese person says ", English." This time the Chinese person will know that if he wants to be understood he can speak English. A glance at the two badges is enough to understand each other's capabilities and negotiate a common ground.

The same principle can be applied to accommodating the diverse technological capabilities of the entities involved in an identity-related process. The Identity Metasystem should provide a means through which the various parties can negotiate which technologies among the ones supported will be used for that specific transaction. If a subject can express his identity with SAML or Extensible rights Markup Language (XrML), and the RP he's invoking can accept Kerberos or SAML tokens, the Identity Metasystem will provide a way for the two to agree on using SAML. One frequent question that arises at this point is what happens when there is no match. If the subject supports only X.509, and the RP supports only Kerberos, there's no way for the two to engage in a transaction, at least until one of the two acquires a capability compatible with one of the other party. The negotiation protocol cannot perform miracles and instantly make Italians speak Chinese; however, it is still useful for gaining knowledge of the requisites. It is important that the negotiation phase be embedded in the Metasystem, instead of being left as an explicit integration task to the parties, so that the format in which requirements are expressed is as formal as possible and the stage is completed without imposing burdens on the parties' implementers. In the section "WS-* Implementation of the Identity Metasystem," we describe WS-MetadataExchange, a concrete example of a negotiation protocol that enables querying web services for dynamically discovered policies.

Because the Metasystem does not define an authentication technology of its own, reaching an agreement on that requirement is a necessary condition for any transaction to take place. It is also important, however, to make sure that all parties understand other kinds of requirements less bonded to implementation details. In the wine seller example, the merchant needs to know the age of the subject. This is a requirement that the buyer needs to be aware of and understand if he is to decide whether he wants to disclose the requested information. The fact that the merchant will accept only claims from a government-issued ID is again information that needs to make its way from the RP to the subject. The set of requirements of an RP is said to be its policy. The IP has policies, too, as discussed later in the chapter.

Encapsulating Protocol

As the negotiation takes place, the information must actually flow according to the roles and the rules of the transaction. The subject needs some way to retrieve his identity from the IP, and the RP needs some way to receive it.

The existing technologies already have their own ways of representing identity and moving it from node to node. However, those methods will not interoperate, and therefore they need to be abstracted away. The Identity Metasystem needs to define a protocol that presents a common model to every participant so that no specific technology needs to be understood for establishing a connection; such a protocol, however, should also enable effective transfer of information according to the rules of the particular technologies. The latter is possible in a sustainable and future-proof fashion only if the Identity Metasystem is not required to understand the technicalities of every technology. It should be able to transfer that data without depending on features and peculiarities of the formats.

In the previous section "Negotiation," we saw an example in which two parties agreed to use SAML for their transaction. An encapsulating protocol allows the Identity Metasystem to put in practice that decision by transporting SAML information as it would have done for Kerberos or any other technologies (that is, without really knowing anything about how to interpret the SAML format).

Claim Transformers

In the examples provided so far, we have been pretty loose in our usage of claims. The wine merchant mentioned previously wanted to know the age of the buyer, but we didn't bother to provide more detail about the format in which that information should have been codified. We took for granted that the merchant could, with little effort, extract that information from a driver's license or from a foreign passport without much premeditation.

Well, we have reached one of the limits of the metaphor. Computer systems are much pickier than bartenders (or wine sellers), and the reasons and business models that require online identification are much more complex than our canonical example.

Consider for a moment every home-banking application up and running on the Internet today. Nearly every one of those applications, and the corresponding back end, has a construct that represents the concept of an account number. The semantic of an account number is fairly unambiguous, even if some local shades of meaning are possible. Yet the representations will greatly vary from bank to bank. If you were to make those home-banking applications participate in the Identity Metasystem, their natural role would be an RP. The policy of those RPs may state that the subject's identity should contain an account number; however, because we are talking about computer systems, the way in each bank indicates an account number will make a difference. For the bartender, the DOB (Date of Birth) field on the driver's license is happily equivalent to the "Birth Date" field on the passport; for a computer system, AccountNumber is very different from Account_Number. This is a very easy example because banks and financial institutions already participate in standard definition bodies, and therefore they can come out with canonical claims representing the concepts inherent to their specific domain of knowledge. The point here is that an apparently minor difference can make or break the feasibility of a project when we talk in Internet scale, and the Identity Metasystem must be able to plan for and accommodate those differences. Those are just principles of good service-oriented architecture. Reducing the coupling between parties reduces unnecessary dependencies and leads to a more robust system. Before talking about how the Identity Metasystem copes with the incompatible claims problem, let's examine a slightly more complex example.

In the sections "User Control and Consent" and "Minimal Disclosure for a Constrained Use," we introduced an example in which a company is in partnership with a supplier, a hardware vendor. We mentioned that one of the claims that the subject should present to the hardware vendor RP is "spending limit." Who is the IP in that scenario? The natural choice is the employer. After all, purchases within that application happen in the context of the company-supplier partnership, and it is only natural that the latter will restrict the service to employees only. Hence, the employee's identity must be issued by the employer. The employer, however, might not actually know what the spending limit of the employee is. What if the value fluctuates following some business rules specific to that vendor? The agreements between the two parties may state that there's a monthly buffer, and beyond a certain threshold only managers are allowed to make expensive purchases. Sure, the employer may incorporate those business rules in its IT system; however, that would not scale at all because it would have to do so for every partnership it entertains and differentiate all expenses as they are made as opposed to keeping a single bucket sorted out at invoicing time. It is much easier, and far more natural, to leave that function to the supplier. The hardware vendor knows how much the employer spent so far because it has a good business reason for knowing it. It has yet to invoice it. It also knows the rule. A manager can spend even if the preordained buffer has been depleted, whereas nonmanagers will have variable allowance. In summary, the employer's IP can issue to the subject claims it is competent to emit, such as whether the subject belongs to the category Managers; the supplier's RP needs to know the spending limit of the subject, and the supplier knows how to derive that value just by knowing whether the subject is a manager. The solution is straightforward: We need a construct that performs claim transformations applying the business rule previously described.

Claim transformers are the ultimate decoupling devices. They can help reduce the technical and business differences between identity representations. They can handle naming issues, translating incoming claims corresponding to the same concept in a format understood by the RP; they can apply business rules by examining incoming claims and expressing the implications in terms relevant to the RP business; and they can resolve format incompatibilities, repackaging and transforming claims from one technology to another. Claim transformers are also the element that makes complex trust-chaining scenarios possible. A company that sells houses may only consider candidates who have been certified as eligible by a consulting firm. The consulting firm may trust the statements from a pool of banks for issuing eligibility certificates. The bank where you keep your main account may be part of that pool of banks. A claim transformer is the means through which the trust chain can percolate from you to the house seller. Your identity of bank customer can be sent to the consultancy firm, which in turn will issue an identity that satisfies the house seller.

Claim transformers are one vital component of the Identity Metasystem. There will be quite a few scenarios in which claim transformers will not be necessary. If all parties in a transaction understand the semantic of the claims required, they can all find a common technological ground, and there are only single-hop trust relationships, so the claims can be consumed without further processing. However, those scenarios cover only the simplest and cleanest situations. Even if in the future the semantic Web or a similar movement leads to a very large base of commonly accepted claims, there will always be scenarios in which the trust must be brokered, in which new technologies must be integrated, and in which some organizational gulf must be bridged.

Consistent User Experience

The importance of a consistent user experience cannot be stressed enough. In Chapter 1, in the section "The Babel," we invested some time to understand in depth how cryptography and current authentication protocols address the safety of identity information transfer; however, we also saw that the transfer is only one of the phases in which data is at risk. The section "Malware and Identity Theft" describes attacks in the information-entering phase, which are ignored by all the protocol schemes described so far. Now that we have had a chance to understand how HTTPS works, we can see how nothing in the common practices based on it addresses attacks such as phishing.

The analysis that brought about the formulation of the identity laws had many occasions to uncover problems derived from poor user experience, widespread inconsistencies, and nonexistent planning for integration of the human component. That's the reason why at least two laws, "User Control and Consent" and "Consistence Experience across Contexts," address the issue explicitly.

A successful universal identification mechanism cannot address just the needs of machines, regardless of how clever its metaprotocols may be. Because the Subject role will almost always be played by humans, the peculiarities and modus operandi of human beings deserve at least the same amount of attention we devoted to integrating the software components of the system. The lessons learned, as summarized by the laws, must make their way into any implementation of the Identity Metasystem.

The Dance of Identity

In this section, we describe in Identity Metasystem terms a couple of classical authentication scenarios. By seeing the various components and roles in action, you will gain a deeper understanding of functions and relationships.

Note that the two examples are just the most basic templates. With the three roles and the five components of the Identity Metasystem, we now have at our disposal the intellectual tools for modeling any identity transaction of arbitrary complexity.

The Canonical Scenario

In the most classic scenario, we have one instance of every role represented. We have one subject, S, one relying party, RP, and an identity provider, IP. The situation is completely straightforward: S wants to use RP, which in turn requires its callers to present an identity issued from the IP to authorize access. This is, once again, a generalization of our wine seller example: S is the buyer, RP is the seller, and IP is whatever government institution issued an identification document to the buyer, and Claim1 or Claim2 (see Figure 2-1) is the age claim. In the rest of this section, we explain Figure 2-1, pointing out what part of the Identity Metasystem is involved as the transaction unfolds. Note that because we are still technology-agnostic at this point, we simplify the sequence a bit (especially in Steps 3 and 4).

1. S engages RP in a negotiation to acquire RP's policy and requirements. RP states that it will consider for authentication only the users presenting an identity issued by IP, in SAML1.1 format and containing Claim1 and Claim2.
2. S goes through the experience of mapping RP requirements with S's capabilities. Namely, S checks whether it 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.
3. Assuming that S does have a suitable relationship with IP, S negotiates with IP the details about how the IP wants to be called (for example, with which technology).
4. S uses the information acquired in the preceding step to request an identity from the IP. The encapsulation protocol tunnels the specific technology that the IP requires to be invoked.
5. S receives the required identity from the IP. S examines 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 the RP.
6. If S decides to disclose, it uses the encapsulation protocol for transmitting the identity to the RP in accordance with the policy received in Step 1.

No technology prerequisites are imposed by the preceding sequence. All parties need to understand the Identity Metasystem; beyond that, however, everybody is free to use the technology of choice. Negotiation and encapsulation protocols provide the mechanism necessary to dynamically configure the system for automatic policy exchange and interoperability.

Brokered Trust

The brokered trust scenario generalizes the business partnership example developed in the section "Claim Transformers." The situation depicted in Figure 2-2 includes four actors. A subject, S, a relying party, RP, and two identity providers, IP1 and IP2. Referring to the business relationship example mentioned previously, those elements map as follows: S is the employee that will make the purchase, RP is the web store of the hardware vendor, IP1 is the employer's identity provider, and IP2 is the claim transformer, implemented in the form of an IP. A step-by-step description of the sequence follows.

1. S engages RP in a negotiation to acquire RP's policy and requirements. RP states that it will consider for authentication only the users presenting an identity issued by IP2, in SAML1.1 format and containing the claim SpendingLimit.
2. S goes through the experience of mapping RP requirements with S capabilities. Namely, S checks whether it has a relationship with IP2 that would allow it to ask for a token of the right format and with the requested claims in it.
3. S does not have an existing relationship with IP2; hence, S engages IP2 in a negotiation, to acquire IP2's policy and requirements. IP2 states that it will consider for authentication only the users presenting an identity issued by IP1, in SAML1.0 format and containing the claim Role.
4. S goes through the experience of mapping IP2 requirements with S capabilities. Namely, S checks whether it has a relationship with IP1 that would allow it to ask for a token of the right format and with the requested claims in it.
5. S does have a suitable relationship with IP1. S negotiates with IP1 the details about how IP wants to be called (for example, with which technology).
6. S uses the information acquired in Step 5 to request an identity from IP1. The encapsulation protocol tunnels the specific technology with which IP1 must be invoked.
7. S receives the required identity from IP1. S examines the details of the identity, such as the content of Role, and decides whether it consents to the disclosure of that information to the RP and its trust chain.
8. If S decided to disclose, it uses the encapsulation protocol for transmitting to IP2 the identity it obtained from IP1. IP2 then issues to S an identity complying with the requirements of the RP.
9. S uses the encapsulation protocol for transmitting to the RP the identity obtained in Step 8.

It seems a long sequence, but it is really easier to do than to describe. The presence of the decoupling level provided by the Identity Metasystem enables the existing trust relationships to be leveraged automatically. A traditional identification technology would have required explicit out-of-band coordination, whereas the policy-based negotiation and the dynamic encapsulation protocol can self-organize a system that just works.