Windows CardSpace and Internet Explorer
The next release of Microsoft's Web browser, Internet Explorer 7, will let users rely on CardSpace for their digital identities. Since it's today's most widely-used tool for accessing the Internet, IE is an important application for this new identity technology. In the most general case, CardSpace communicates entirely using SOAP-based protocols. As described earlier, however, websites can also interact with IE 7 (and potentially other Web browsers) by using HTML and HTTP.
Figure 7 shows one approach to doing this.
Figure 7. Windows CardSpace and Internet Explorer 7
1. The process begins when a browser user accesses a protected page at a website, such as the page to purchase products at an online merchant. At this point, the website requires that the user log in to the site, and therefore the site redirects the browser to its login page.
2. This redirect results in the site sending a login form to the browser.
This form might allow the user to log in to the site by providing his or her username and password, as usual, but if the site supports CardSpace logins, the page that conveys the form will also contain a specific OBJECT tag or XHTML syntax. This information contains the site's policy, and it will cause the browser to display an Windows CardSpace login option to the user.
3. If the user selects this option, IE 7 will execute code identified by the OBJECT tag or XHTML syntax that requests CardSpace's involvement in the login process.
4. The CardSpace screen will appear, and the user can select an identity.
5. So far, all communication with this site has used HTTP. Once the user selects an identity, however, CardSpace contacts the associated identity provider using WS-Trust, as usual, and gets a security token.
6. This token is then sent to the website using HTTP POST as part of the login process.
The web application can use the token to authenticate the user or for any other purpose.
In this scenario, the identity provider might be the self-issued identity provider that is running locally on the user's system, or it might be some external provider. The website itself can also provide its own security token service that generates custom tokens used by this site. This option can make sense for sites that wish to provide application-specific tokens or for high-traffic sites, since it allows most of the authentication work to occur on dedicated servers.
One more important point to make about this process is that there's nothing IE-specific about it. Any browser on, any operating system, can use the identity metasystem in the same way. On Windows, the stated goal of Microsoft is to allow any application, including other vendors' Web browsers, to manage and use digital identities with CardSpace.
Windows CardSpace and Windows Communication Foundation
Windows Communication Foundation is the forthcoming Microsoft platform for building service-oriented applications. WCF implements all of the interoperable protocols used by CardSpace and the identity metasystem, including WS-Security, WS-SecurityPolicy, WS-Trust, and WS-MetadataExchange, and much of CardSpace itself is built on WCF. Unsurprisingly, using WCF to create an application that acts as a relying party, an identity provider, or an CardSpace client is straightforward.
Understanding how this is done requires knowing a few things about WCF services (which implement operations) and WCF clients (which invoke those operations). Every WCF service exposes one or more endpoints through which that service's operations can be accessed. Every WCF client indicates the endpoint it wishes to communicate with. Both service and client specify a binding for an endpoint; the binding defines what protocol will be used to convey SOAP messages, how security will be accomplished, and more. For example, the binding called WsHttpBinding indicates that SOAP messages should be sent over HTTP, that WS-Security is supported, and more. WCF also automatically creates an accessible description of an application's policy, expressed using WS-SecurityPolicy.
Although it's certainly not required, most people implementing identity providers and relying parties on Windows systems that support version 3.0 of the .NET Framework will likely build them using WCF. To create an identity provider or relying party, all that's needed is to build a WCF service that conforms to the requirements listed in the previous section. As long as the application conforms to these requirements and chooses an appropriate WCF binding, such as WsHttpBinding, it can participate in CardSpace.
However, creating a WCF client application that lets its user rely on CardSpace to specify a digital identity does require directly using the CardSpace software. A special binding is provided to indicate that a WCF application should use CardSpace for authentication. If a WCF client specifies this binding for the endpoint it's communicating with (an endpoint implemented by a relying party that may or may not be built on WCF), CardSpace will automatically be invoked when a security token is required. As usual, the CardSpace selection screen will appear, letting the user choose which digital identity to send. CardSpace will automatically contact the appropriate identity provider in order to acquire a security token, and then insert it in the WCF application's outgoing request. The developer just specifies that the right binding should be used, and CardSpace takes care of everything else.
Windows CardSpace and Active Directory
Active Directory is an obvious and important candidate for an identity provider. CardSpace is scheduled for release in early 2007, however, while no new release of Active Directory is scheduled until some time after that. Microsoft has said that Active Directory will eventually be able to act in the role of an identity provider, but no dates have been announced for when this functionality will be available.
A more immediate question is how CardSpace relates to Active Directory Federation Services (ADFS). ADFS is available today, and it can initially seem similar to CardSpace. In fact, however, these two technologies are quite different. CardSpace provides an identity selector and a self-issued identity provider, both of which run on a client machine. ADFS is server-based software that allows an organization using Active Directory to federate its identities with other organizations by using WS-Federation. Another important distinction is that, while a browser using CardSpace plays an active role, as described in the previous section, browsers are oblivious to ADFS—their role is entirely passive. While both are concerned with identity, CardSpace and ADFS perform very different functions.
Windows CardSpace and Windows Live ID
The Microsoft Windows Live ID system (formerly known as Passport) was originally intended to provide a standard authentication system that could be used by any site on the Internet. Today, the network that has evolved from this initial effort consists largely of sites run by Microsoft itself. Even though Windows Live ID now handles close to one billion logins a day, the lesson was clear: no single organization, not even one as big as Microsoft, could act as the sole identity provider for everything on the Internet.
CardSpace and the identity metasystem, with their much more general view of identity and identity providers, represent a fundamentally different approach. Microsoft has said that Windows Live ID will be modified to act as an identity provider, and that users will be able to sign in to their Windows Live ID accounts by using CardSpace. Yet CardSpace has no dependency on Windows Live ID, and the identity provider that Windows Live ID one day provides will not play any special role in the identity metasystem.
Conclusion
The problems addressed by the identity metasystem are undeniably important, as are the solutions it offers. Providing a standard way to work with diverse digital identities can make the networked world as convenient and as safe as the physical world. Giving users control over what identity is used in each situation puts people squarely in charge of how their digital identities are used. Using digital identities, including self-issued identities, can reduce the need for password-based Web logins, and together with improved user confidence in the identity of a website, it can also reduce the phishing attacks that bedevil many users.
Windows CardSpace is a key part of these solutions. Yet until people who create software for other operating systems, build identity providers, and provide relying parties also implement the standard Web services protocols that allow this metasystem to exist and interoperate, the effort will not yet have achieved its goals. Microsoft is doing its part by providing software for Windows, but it can't unilaterally make the identity metasystem vision successful. Others must also understand the benefits they will derive from more effective use of digital identities, and they must choose to participate.
Still, CardSpace is likely to be widely available. Because the identity metasystem underlying CardSpace is based on open protocols, CardSpace-compatible software for identity providers, relying parties, and other identity selectors can be built on any platform or device. And because CardSpace exposes a singular, intuitive interface, it can be predictably and consistently used by any Windows software. Given all of these realities, Windows CardSpace is guaranteed to be important for anyone who's interested in digital identity.
|
|
| A First Look at InfoCard |
| |
| |
The Web can be annoying at times. I'm certain that I'm not alone in my frustration with filling out the same old forms on every Web site I visit. Like most other techies, I've acquired many tools over the years to help combat this repetition, and I even wrote my own password manager for my hundreds of different identities on the Web. To me this constant repetition is simply an annoyance, but to someone like my mom, it can be very confusing, and often confusion can lead to security vulnerabilities, such as using the same password everywhere.
Not only is this forced fragmentation of identity on the Web annoying, it's also really limiting the Web's potential. In this column, I'll introduce you to a system that I truly hope will be a uniting force for identity on the Web. It's called InfoCard, and it's planned to be available with Windows Vista™.
I am going to talk about InfoCard purely in the domain of Web services, because that's the only place you can use the prerelease bits as I write this column (see Microsoft Federated Identity and Access Resource Kit for Sept 2005 Community Technology Preview). But in the future it will also work with browser-centric Web apps. I've used Thawte and eBay as concrete examples because they're familiar. These examples are entirely fictitious—whether or not Thawte or eBay decides to implement InfoCard is entirely up to them.
What is identity, anyway? The technical implications of this question are vast (never mind the philosophical implications). How should people be identified on the Web? How should entities such as services, companies, organizations, and the like be identified?
Take me, for example. My name is Keith Brown. I live in a suburb of
On eBay, I have a stellar reputation as a buyer and a seller. On Slashdot, my posts have been ranked "insightful," and I'm an upstanding member of a number of other communities. These reputations have value, but today they are stuck in silos. When I join a new community, there's no way to prove to people that I'll be an honest, intelligent, easygoing member. I have to start from scratch at every site, because there's no common way to share my eBay or Slashdot identity (with all the reputation I've worked hard to build). Sure, I can say, "I'm Keith over on eBay," but who is going to believe me?
I've made a bunch of statements about who I am. Do you believe them? Are they assertions of fact or merely claims? That really depends on who is making the statements and how much you trust that person or organization. For example, if you wanted to trade with me on eBay, you could easily discover that eBay says I have an excellent record for paying quickly. If you regularly trade on eBay, you probably have a reasonable degree of trust in their feedback system, so this is a claim you'll accept.
One approach that InfoCard takes is that it doesn't make any assumptions about the veracity of statements made about a given identity. It's up to you to decide whether you believe the claims I've made about myself, or the claims eBay makes about me. Thus the use of the word, "claim" as opposed to something stronger, like "assertion."
In fact, this leads directly to a definition of identity from the InfoCard perspective: A digital identity is a set of claims made by one digital subject about itself or another digital subject. This definition was proposed by Kim Cameron on his identity blog (www.identityblog.com). Kim is an architect at Microsoft working on InfoCard, and he's made many important contributions to the current thinking on identity.
Oh, and one more thing, in case you think you know where I'm going. The problem of having hundreds of identities today is not solved by merging them into a single identity that's used everywhere. That would introduce more problems than it solves. InfoCard allows you to have as many identities as you need. Looking into the future, you might have one identity that's issued by your government, one that's issued by your bank, and one issued by a Web community of which you're a long-standing member with a good reputation. You will likely have several self-issued identities, a few of which contain false information! I don't know about you, but I usually lie when a Web site asks me for personal information that I don't want them to have. I really don't live at
im Cameron has postulated that there must be a set of objective laws that govern whether any given identity system will succeed or fail in a given context. No matter how an organization positions an identity system, if it breaks these laws, it will very likely fail in some way. Perhaps the failure will be a breach of security, allowing such mischief as identity theft. Or maybe people will simply reject the system because they don't feel comfortable with it. Regardless of the reasons, the InfoCard architects don't think they will succeed without adhering closely to these laws.
Seven Laws of Successful Identity Systems
So to get a feel for the environment in which InfoCard has been incubating, let me take you on a brief tour of the seven laws. I have abbreviated them in my own words in the sidebar "Seven Laws of Successful Identity Systems," but you can take a look at the complete text at The Laws of Identity.
InfoCard: An Identity Metasystem
InfoCard encompasses a lot of different tasks. It orchestrates a few of the WS-* protocols to make the secure interchange of identity information feasible. It also presents a GUI that allows a user to choose among several digital identities, each of which is represented visually as a card. Figure 1 shows a very early "wire frame" UI. I'll talk a bit more about some of the other things it does later on, but first let me introduce the three players that are always involved in any InfoCard transaction.
Figure 1 Digital Identity Made Concrete for Users
First is the subject. An example of a subject is a user who wants to represent herself digitally on the Internet. Second is the identity provider (IP), an organization that issues digital identities. A close analogy is a company like Thawte, the issuer of the secure sockets layer (SSL) certificate that I use to identify my company's Web site. Finally, there's the relying party (RP), which relies on digital identity for its operation. Most Web sites and Web services today allow users to submit some form of identity, anything from a simple e-mail address to a digital certificate or something more exotic.
In accordance with the fifth law of successful identity systems, InfoCard is a metasystem that establishes a few guidelines and protocols to make it possible for many different identity systems to play nicely together. Lots of people have been thinking about digital identity for quite some time, and lots of different techniques have emerged. LID, SXIP, Liberty Alliance, and Microsoft® Passport are just a few examples.
Establishing Digital Identity with InfoCard
At this point I'm going to introduce a concrete example that I can build on throughout the column. Imagine that Thawte has decided to become an identity provider for InfoCard. I visit the Web site at Thawte and use a Web Form over HTTPS to set up a digital identity that they will manage for me. I might provide an e-mail address, home phone number, snail mail address, and so on. In fact, I might even set up a few different identities that I could use in different contexts.
Depending on the type of identity I want to establish and the amount of money I'm willing to pay for their service, Thawte may authenticate me before issuing an identity. Authentication could be as simple as verifying my e-mail address, or as sophisticated as calling around to verify every detail of my identity.
For each of these identities, Thawte will send me an InfoCard, an XML document that acts as a reference to the particular digital identity I just established. How they send it to me isn't dictated by InfoCard; they could e-mail it or I could download it from their Web site. Once I receive the InfoCard, I import it onto any computers from which I want to use it. Note that the InfoCard itself doesn't actually contain any of my identity details. That phone number I gave to Thawte isn't in the InfoCard.
What the InfoCard does carry is metadata that describes the shape of the identity. This information includes what claims it has inside it, such as an e-mail address, a home phone, and so forth, and what identity technology it uses such as Security Assertion Markup Language 1.1 (SAML). It also includes who issued it (Thawte), and a unique identifier that Thawte can use to look up my identity and get the values of each of the claims. So while my actual digital identities are safely tucked away on a highly secure server at Thawte, the InfoCards I've imported onto my computer are really just a way to remember that I have those identities. An InfoCard gives you the means to use and manage a digital identity.
My corporate Web site uses Active Directory® Federation Services (ADFS) to act as an identity provider. I can sign up for another identity there. The Web site authenticates me using Kerberos and issues an InfoCard that I can use to access my corporate identity for use with partners on the Internet. I import this card onto my computer. Once I've got some cards, I can use them as long as they are valid. The Thawte identity might be valid for a year (or however long I want to pay to maintain it), and my corporate identity is valid as long as I'm employed there.
Message Flow
In order to get a feel for how an InfoCard transaction works, I'm going to walk through an example to show the flow of messages between the players. For now, I'm going to ignore an awful lot of details such as how messages are secured, which protocols are used, and so on, to make sure the basic flow is clear.
Imagine that eBay has a Web service that supports InfoCard (the relying party). I launch my eBay auction manager application, a rich client app that helps me manage the multitude of items I'm auctioning on any given day. My app knows that it needs to present a digital identity to eBay in order to manage my auction items, but it has no idea which identity I want to use. So it first asks eBay what shape of credential it supports, what identity providers it trusts, and what types of claims it needs. eBay responds:
Credential type: SAML 1.1 or 2.0 Identity Providers: Entrust, Thawte, Verisign Requested Claims: email address
My app then takes this information from eBay and hands it off to the InfoCard system on my laptop. Up pops up a dialog that displays a list of cards that could satisfy eBay's needs. This includes all identities I've registered with Thawte that include e-mail addresses. It does not include my work identity because eBay didn't list my company as an identity provider that it trusts. In this dialog, eBay's logo is prominently displayed. Along with other countermeasures, this helps me verify that I'm not sending personal information to an imposter. Figure 1 should give you an idea of what this looks like. I click on the card that I use to sell items on eBay, and the InfoCard system makes a request to Thawte to get the one claim that eBay cares about: the e-mail address. Thawte returns a SAML token with this information.
InfoCard now pops up a view that shows me exactly what information I'm about to disclose to eBay, which is the e-mail address in the SAML token. I consent by pressing Submit, which allows InfoCard to pass the token to my application so it can fire it off to eBay and get started managing my auction items.
A lot happened here, but from my perspective as a user, I found that the interaction was straightforward. When my application connected to eBay, I was prompted to choose an identity to present, asked to confirm the personal information I was about to disclose, and then I was able to immediately start working with my auction items. And I didn't have to bother with a password. Under the covers, the strong crypto specified by InfoCard was at work ensuring the authenticity of the transaction.
The Laws Revisited
Consider this interaction in light of the laws of identity. The first law was satisfied: as the user, I was asked for consent, and shown exactly the information to be disclosed. I was also shown the logo of the relying party, so I could make an informed decision.
The second law was also satisfied. My home phone number and snail mail address were not sent to eBay, even though they were part of my digital identity maintained at Thawte. Only the information needed for that particular interaction was sent: the e-mail address. And really even that wasn't necessary; InfoCard is happy to craft a unique, opaque identifier that a relying party can use to identify you without having to know any personal information about you at all. This is called a Personal Private Identifier (PPID), and is computed as a function of the relying party's public key, the InfoCard id, and a random salt value. As a relying party, you can request a PPID if you want to track requests for someone without tying your tracking data to their personal information. This is a great way to protect the privacy of your users.
What about the third law? When I use a Web service at work, I use my corporate-issued identity. But I don't trust the sysadmins with my eBay identity. So I choose to use Thawte to manage my external identities. They have a lot more to lose if they misuse my identity and get caught doing it! There is a little circle of trust that comes together here: me, Thawte, and eBay. All parties to the transaction are justified in being there.
The fourth law also came into play. Anyone who uses InfoCard to talk to eBay sees eBay's logo. That's an omnidirectional identity, a beacon. But my relationship with eBay is private. The InfoCard system on my laptop isn't broadcasting my e-mail address via Bluetooth. Even if it wanted to reveal my e-mail address, it doesn't store that information, remember?
Because I was able to choose my own identity provider and identity technology, the fifth law was satisfied. Granted, the identity provider and relying party must support at least one technology in common for this to work, but InfoCard in no way limited which type of credential (SAML or otherwise) I used. The fifth law is really all about freedom of choice, and I'm happy to say that InfoCard buys into it.
The sixth law talks about securing the channel between the user interface and the user's brain. By using certificates with logotypes (RFC 3709), InfoCard avoids confusing the user by forcing them to look at certificates, and instead uses images that the user can recognize to identify the entities involved. There are other countermeasures that happen behind the scenes as well. For example, the entire InfoCard UI is actually hosted on a separate, more tightly secured desktop (similar to the one that WinLogon uses when you press Ctrl+Alt+Delete). Note that it's up to the identity provider to ensure that a bad guy doesn't register a certificate with a logo that looks like another company's logo. But that's exactly the sort of service that an identity provider supplies, and companies that participate will pay for that service.
Finally, the seventh law is satisfied by presenting the user with something that appears concrete: the cards themselves. And no matter what type of credential is used with the card, the user experience is the same. The user is shown a text representation of every claim that's going to be sent to the relying party, no matter what type of token or what type of claim it is. How can this be possible? InfoCard can't possibly predict all the types of credential formats that might spring up in the future. To solve this problem, the identity provider can include an optional "display token" that accompanies the real token. The display token contains a simple name-value collection that can be used to display the contents of the token to the user in text, even if InfoCard can't parse the actual token itself.
Sharing My Reputation
I hinted earlier that it would be really neat to have the choice of sharing my reputation from one community to another. If I could prove that I have a great reputation on eBay and Slashdot, I could use that as currency for other communities that I might want to join so I wouldn't have to start from scratch. And I might want to be known by the same handle at a few different online communities, so my friends know who I am in all those places. It would be up to me to make these linkages, but having that flexibility would be incredibly powerful.
This can happen under InfoCard. Say eBay decided to become not only a relying party, but an identity provider as well. In this case, I could get an InfoCard from eBay stating that I'm a reliable buyer and seller with 99.8 percent positive feedback. That's simply a claim that eBay is making about me, but remember the definition of identity: a digital identity is a set of claims made by one digital subject about itself or another digital subject.
Web communities that care about reputation might support eBay and Slashdot as trusted identity providers for these types of claims. I could now sign up for an account at one of these communities using my Thawte card, and then immediately bump up my reputation with my eBay card. I can show as many cards as I want to a community.
The downside to this is that the relying party can now correlate any identity information I give it, but it's ultimately my choice. If I trust the community and want to share more information with it, I can choose to do so. And a well-designed relying party will ask for the smallest possible amount of identifying information. I'd feel perfectly comfortable disclosing a PPID for my Thawte identity along with my eBay reputation. Even someone malicious couldn't do much with that!
Self-Issued Cards
A lot of the infrastructure I alluded to in my examples simply doesn't exist today. There aren't many identity providers out there that support InfoCard. The current version of ADFS doesn't yet support it either. So the InfoCard team has supplied a built-in provider that allows you to issue your own InfoCards to yourself to bootstrap things. In fact, the example cards shown in Figure 1 are actually self-issued cards.
To understand how this works, consider a traditional Web site that allows you to register with a user name and password. If that Web site accepted self-issued InfoCards, you could use a self-issued InfoCard to register. There would be no password; just select a card when prompted, and the Web site would record your PPID and make a note of the long-term key sent in the token. That key would replace the traditional password, and would be unique for every site you visit. Under the covers this key would be computed as a function of a master key, which would be generated randomly for each self-issued InfoCard, and the public key of the relying party. It would be as if you'd chosen a unique password for each Web site you visit, without actually going through the hassle of managing all those passwords yourself.
Self-issued cards are a great way to get started with InfoCard. If you have a Web service and want to make it a relying party, you can get a quick start by simply testing with self-issued cards. But in the long term, using a third-party identity provider will be much more powerful, because it enables user-constrained sharing of personal information between different systems on the Web.
InfoCard is right around the corner, and it has incredible potential. On the social Web, it will pave the way for all kinds of new innovations by individuals and companies. For corporations, InfoCard will make it much simpler to connect with partners online. But InfoCard will only succeed if there are innovative people like you who are willing to take the time to build interesting relying parties and identity providers.
Subscribe to Andy Harjanto's blog (blogs.msdn.com/andyhar) if you're interested in experimenting with InfoCard today. Andy, a member of the InfoCard team, has provided links to specs and downloads (blogs.msdn.com/495649.aspx), as well as code samples for building relying parties and identity providers using Windows® Communication Foundation (WCF).
I hope this has whetted your appetite for InfoCard. In my next column, I'll open the hood and show you what makes InfoCard tick. Stay tuned!
|
|
| Step-by-Step Guide to InfoCard |
| |
| |
In my April 2006 column I began a discussion of InfoCard, the upcoming identity metasystem, which is being prepared for release in the Windows Vista™ timeframe. If you haven’t read that column, you should definitely start there because I’m going to assume you’re familiar with the basics I covered. This time around, I’ll go deeper into how the identity metasystem works, and write a service that relies on InfoCard for authentication.
A number of you sent me questions after reading the April column, so I’d like to clarify some things before drilling deeper. Technically, InfoCard is only one part of the identity metasystem: it’s the identity selector—the front-end GUI that’s displayed to the user. I tend to use the term InfoCard to refer to the metasystem as a whole simply because it’s a heck of a lot easier to say, and I think it sounds more concrete.
The identity selector being implemented by Microsoft will first surface in the Windows Vista operating system. If you saw any PDC 2005 talks, you most likely saw the identity selector in action. But InfoCard will be available on earlier versions of Windows® as well, including Windows XP. And Microsoft has made it clear that it wants to work with other operating system vendors to provide tips on designing secure identity selectors for their platforms as well. If InfoCard is to be successful, it needs to be very widely deployed, and not just on Microsoft® operating systems.
Some of you also asked for clarification about Security Assertion Markup Language (SAML), which is a standard that specifies the shape of a credential (or token, in WS-* terminology), as well as a protocol for passing these credentials around. InfoCard can use many types of tokens, including SAML tokens; self-issued cards happen to use SAML 1.1 tokens, for example. While SAML tokens are fairly common in InfoCard, WS-Trust is the protocol that is used to obtain and exchange tokens. The SAML protocol is not used by InfoCard.
What about folks using the Java language to build Web services? Back in August 2005, Ping Identity, a major player in the SAML space, released a Java toolkit for writing server-side applications that interact with InfoCard. It was released as a work in progress, but when it is finished, according to the toolkit documentation, it should be possible to build Web services (on top of Axis) and servlet-based Web applications that can request and handle all kinds of InfoCards from InfoCard-enabled clients.
And finally, InfoCard is not the "Son of Passport" that some in the media seem to fear. Passport is a single identity system and, as such, naturally fits into the metasystem as one of many technologies available to InfoCard users. But unlike the old days when Passport was being positioned as the only identity system you’d ever need on the Internet, today Microsoft is proposing a metasystem that allows the user to choose the identity technologies that make sense for her. Passport works well for accessing Microsoft properties like MSN®, but as an InfoCard user, that’s the only context in which I’ll be using Passport. My friends will tell you that I was never a big fan of Passport, but I am really excited about InfoCard, and you should be too!
InfoCard Interactions and Protocols
In the April column I talked about three InfoCard players—the subject, relying party, and identity provider. Most Web developers who need to add support for InfoCard to their Web services and applications will be acting as a relying party, so I’ll focus on that role here.
Figure 1 is an interaction diagram from "A Guide to Integrating with InfoCard," which you can get from the Microsoft download center. It illustrates how a user can authenticate with a service using InfoCard. In the diagram, you can see the identity provider (the relying party), which is a Web service, and the subject, which is the user. The client app the user is running is also shown for clarity.
Figure 1 InfoCard Interaction
The first thing to notice is that in order to use InfoCard the user must first enroll with an identity provider. That’s the out-of-band step shown by a dashed line in the figure. It could be as simple as creating a self-issued card on her own machine using the InfoCard GUI, in which case the identity provider is right on the user’s machine. Alternatively, the user might obtain an InfoCard from a standalone identity provider. A newly issued InfoCard is an XML document that can be transmitted to the user via e-mail, Web download, and so forth. There is no required protocol for how the identity provider authenticates the user or issues the InfoCard.
Once the user has one or more cards, the required protocols move into action. When the user runs an InfoCard-enabled application that makes a request of an InfoCard-enabled Web service, the first step is for the app to determine what type of identity and channel security the service requires. This is shown as the first round-trip to the service (Steps 2 and 3 in Figure 1). The protocol used here is WS-MetadataExchange, often referred to as WS-MEX, or just MEX.
The application now invokes the identity selector (Step 4), passing in the policy retrieved from the service. The identity selector pops up a secure GUI showing the user a collection of cards that would work for the given policy (Step 5). This is primarily governed by the type of token and the type of claims required by the service.
If the user has never used this service before, InfoCard will display the service’s and issuer’s certificate logos, giving the user a chance to visually verify that he’s talking to the right Web service so he doesn’t give away identity details to an imposter.
Once the user selects a card to send (Step 6), the identity selector initiates a behind-the-scenes conversation with the identity provider that issued the card. First there’s a MEX exchange (Steps 7 and 8), where the provider’s security policy is discovered so that the exchange can be properly secured. This also tells InfoCard how the user is supposed to prove his identity to the identity provider. For example, if the provider requires a password, the identity selector will prompt the user for his password. Now a WS-Trust request is sent to the identity provider (Step 9). This request includes the user’s proof, such as the password as in the example. It also includes the ID of the card, which allows the provider to figure out which account is being accessed. Also included is a list of requested claims—the identity details that the Web service wants.
Assuming the identity provider can validate the user’s password that was sent, it will now construct a security token for the user to send to the service. This token will contain all the claims the service requested. If the service requested the user’s street address, that address will be included in the token. Remember that the original list of cards shown to the user included only those that support the claims being requested. Note that a password is just one of several ways an identity provider can authenticate the user. Other techniques include using a certificate, Kerberos credentials, or a self-issued InfoCard.
WS-Trust is the core protocol around which InfoCard is built. It is basically a credential exchange (or more technically, a security token exchange) protocol, and is implemented by what is called a security token service (STS). The most common type of STS is an identity provider like the one shown in Figure 1. In Steps 9 and 10, the user’s password is being exchanged for a signed set of claims from the identity provider’s STS.
Now the identity provider signs and encrypts the token and sends it back to the InfoCard identity selector (Step 10) along with some key material that can be used by the client application to prove that it obtained a legitimate token from the identity provider. This key material is known as proof of possession.
When the identity selector receives the token and proof of possession, it decrypts the token and shows the user one final GUI. This allows the user to see exactly what identity data is going to be sent to the service. If the service requested the user’s street address, the actual street address will be displayed to the user. Figure 1 doesn’t show this particular interaction, but it’s an important one for the user. Once the user gives his final blessing by pressing Send, the identity selector returns to the application (finally!) giving it the token and proof of possession it needs to authenticate with the target service. As you can see, there’s a lot going on under the hood when you select an InfoCard. Fortunately, if you’re a client or service developer, you don’t have to worry about building any of this infrastructure.
At this point the application makes its request to the target service using WS-Security to send the token along with a signature formed via the proof-of-possession key material (Step 11). The user has now been authenticated and the service has the claims it requested and can use those claims to make authorization decisions and carry out the user’s requests.
It’s possible and even likely that WS-SecureConversation might be used at this point to set up an efficient secure channel for an ongoing conversation between the application and the service, but that’s beyond the scope of the InfoCard specification.
Considerations for Relying Parties
As a relying party, the first thing you’re going to need is a certificate to identify your organization. This is the beacon type identity that I discussed in my previous column. A large percentage of secure Web services today already use certificates to enable secure sockets layer (SSL), so this shouldn’t be a significant barrier to adoption of the technology.
What is a bit new is that this certificate needs a name that represents your organization, not your URL (as in an SSL certificate). It also should include logo images for both the issuer and subject, following the guidelines in RFC 3709. Each image isn’t physically embedded in the certificate; rather, it’s linked to avoid making certificates even bigger than they already are. The logotype extension includes a URL that points to an image on the Web. It also includes a cryptographic hash of that image. The hash is embedded in the certificate to allow the program displaying the logo to ensure that the image hasn’t been modified since the certificate was issued.
Another major consideration is the type of identity information (claims) you’ll request of your users. InfoCard has already defined several claim types that will cover the needs of most applications, but this list can be extended by third-party identity providers that serve other types of claims. The current list is shown in Figure 2. To form the full Uniform Resource Identifier (URI) for each claim, append its suffix to schemas.microsoft.com/ws/2005/05/identity/claims. You’ll see these URIs in policies exposed by InfoCard-enabled services. This is the way you specify the identity expectations your service places on its users.
Many Web services don’t need any personally identifiable information at all, and you shouldn’t ask for anything you don’t absolutely need. With InfoCard, a great way to start is by simply identifying the user with a Private Personal Identifier (PPID). This is communicated as a base64-encoded byte array. In my own tests this value has been 32 bytes long, but its definition doesn’t include a length, so don’t rely on this. As an example, a self-issued InfoCard will generate a unique PPID for each target service based on the card’s unique ID, the service’s public key, and a random salt value. The PPID alone is not considered personally identifiable information, so it’s a great way to associate your own data with a user while preserving her anonymity. I’ll show an example shortly.
The Notepad Service
Microsoft support for InfoCard rests entirely within Windows Communication Foundation today. It is surprisingly easy to add InfoCard support to a Web service, making that service into a relying party. It’s really just about selecting the appropriate binding, and you can do it all with a configuration file if you want.
Figure 3 shows a Windows Communication Foundation Web service with a contract called INotepad. This allows a user to leave herself a note by sending the SetNote message, and lets her retrieve that note later via the GetNote message.
Figure 4 shows the corresponding Windows Communication Foundation client code. Because the client dynamically discovers the service’s binding requirements via WS-MEX, there’s no need for a client-side configuration file in this app. If you build and run this code, you’ll quickly see a flaw in the design. It works fine as a scratchpad for a single user, but as soon as two or more users invoke the service, they begin stepping on each other’s notes. By adding InfoCard support, I’ll ensure that each user gets a personal storage area for notes that no other user can see. I’ll do this without requiring user registration or any personal information.
The majority of typing you’ll do will be in the service configuration file. You’ll need to tell Windows Communication Foundation where to find its certificate. You’ll also need to advertise what sort of security token you want from your clients and what claims you expect to see in that token. For this application, I allow my clients to remain anonymous, choosing to rely on a PPID claim. I let clients use the self-issued identity provider, which issues SAML tokens.
It may seem odd to authenticate clients that will remain anonymous, but it’s really no different than the way a typical bulletin board works today. When you create an account, you supply a user name and password. The user name is pretty meaningless; keith3425 doesn’t give the board a clue as to how to get in touch with me. But the password allows the site to ensure that it’s the same person logging in each time.
InfoCard makes this type of service very easy for users. There’s zero registration required; because PPIDs are unique for each site, the user can simply create a single card that she uses at all anonymous sites like this. She doesn’t have to go into that familiar loop of attempting user names until she finds one that hasn’t been used already. You can think of her user name as being replaced by a PPID, which is generated automatically by InfoCard. She also doesn’t have to generate and manage yet another password. A strong key will be generated dynamically to use with the service.
The biggest drawback to using self-issued tokens is that they can be a hassle if the user works on multiple machines. Eventually, a third-party identity provider will be able to centralize the user’s identity so that it can be used from any machine. In the future there may even be portable STS hardware devices that you can carry around and plug into your computer’s USB port. This would make self-issued cards more portable and secure.
InfoCard-Enabling the Notepad Service
Enough talk; let’s do it. The first step in InfoCard-enabling the service is to obtain and install a certificate. I’m going to use the one that came with the InfoCard Resource Kit that shipped back in September 2005. The logos in it are configured to point to GIF files in a virtual directory at localhost/ServiceModelSamples. I’ll supply a batch file to get the certificates and logos set up for you if you’re following along with the code sample.
Figure 5 shows the updated service configuration file. Note that the references to the Fabrikam certificate are required because it’s used to authenticate the service to the client application, allowing the client app and service to negotiate security for their communication channel. Also, it’s used to authenticate the service to the identity provider.
Also note the binding’s security mode. I’m now specifying message-level security, which indicates the need for the WS-Security suite of protocols. The clientCredentialType is specified as InfoCard, which is really just shorthand for a self-issued SAML token that has no personally identifiable information in it, only a PPID. If you want to specify other claims, use the wsFederationBinding instead of wsHttpBinding; this allows you to specify the exact claim types you’re looking for.
Figure 6 shows the updated service code, with only the guts of the Notepad class that changed. You’ll see here that I’m now using a dictionary instead of a single string to store notes. The dictionary is keyed off the base64-encoded PPID. There’s really no reason to bother decoding the PPID into a byte array if a unique string is good enough to identify the user, so my dictionary uses a string PPID as its key.
Besides the synchronization code, the major new addition is the getCallerPPID function, which shows you how to use the new claims-based authorization feature in Windows Communication Foundation to discover the claims that were sent in the token. This code simply searches for a PPID claim. If there are other claims you requested, such as a user name or e-mail address, you can look for those as well using the URI for the claim types you are interested in.
The client code that looks up the service via WS-MEX also changed a bit. The MEX code doesn’t change, but once the channel factory is created, a behavior is dynamically added that tells the client-side Windows Communication Foundation plumbing to use InfoCard credentials with the service, as well as what certificate to expect for the service. This extra piece of code is here:
ChannelFactory
If you build and run the new service, you’ll notice that on the very first call to the Web service, the identity selector pops up! Once you select a card and submit it, you’ll see the second GUI that shows the actual information that’s going to be sent; click the Information tab to see the personal information that will be sent. In this case, you will see an empty list since none of your personal information is requested. The PPID isn’t really personal information; it’s just an anonymous identifier that doesn’t mean anything to the user anyway, so it’s not shown here. After pressing the Send button, the rest of the client code runs, making a couple more calls to the Web service. You shouldn’t be prompted again while the client application is running though since the Windows Communication Foundation proxy is caching your credentials and doesn’t need to bug you anymore.
It’s pretty amazing to realize what you’re getting for about 10 lines of configuration code and maybe 20 lines of C#. You now have a login system that works over the Web with state-of-the-art authentication protocols. Windows Communication Foundation handles the heavy crypto required for authenticating the user’s credentials. There’s no worry about weak passwords, because you’re not relying on them! The user can create a single InfoCard that works at your site and at other sites; each site no longer needs to ask for a user name and password.
Exploring InfoCard Without WCF
You can play with InfoCard without using Windows Communication Foundation. Earlier I explained how the client application must invoke the InfoCard identity selector, handing it the server’s policy so the selector can display appropriate cards to the user. Well, if you’re using Windows Communication Foundation, the client-side plumbing handles this for you transparently. You don’t have to call InfoCard yourself, but you can if you want to.
If you look in the %WINDIR%\system32 directory, you’ll find a file called infocardapi.dll. A quick dump of its exports shows a function called GetToken. There’s also the managed assembly, Microsoft.Infocards.dll, which has a class called InfoCardClient with a static GetToken function that wraps the unmanaged version. You can build an array of policy elements and call this method directly if you want to pop up the identity selector and let the user choose a card. When the function returns, you’ll have the dereferenced InfoCard in your hands in the form of a security token, which is a great idea if you want to learn more about how the identity selector works.
If you want to simply pop the identity selector so the user can manage his cards, you can do this via the ManageInfoCard method. And if you want to import an InfoCard, you can do so by calling ImportInfoCard. There are no APIs for enumerating or otherwise programmatically manipulating InfoCards; you need to remember that this is something that the user must manage, since it’s his own personal information.
Oh, and one final note. If you’re wondering where the InfoCard identity selector itself lives, you can find it in a service called Microsoft Digital Identity Service. The code behind this service lives in a file called, appropriately enough, infocard.exe.
In this issue, I drilled deeper into InfoCard and showed the code for a relying party and a client. If it’s not already apparent, I’m really excited about the possibilities that InfoCard and the underlying identity metasystem present. Kim Cameron (the chief identity architect at Microsoft I told you about last time) has often said that if we can succeed in building an identity metasystem that respects the laws of identity, we will reach what he calls the "identity big bang," a new era of software which is identity-aware. I’m hopeful that InfoCard will help lead us there.
The Laws of Identity
Kim Cameron
Identity and Access Architect
Microsoft Corporation
May 2005
Applies to:
Security
Web development
Web services
Summary: Understand the dynamics causing digital identity systems to succeed or fail in various contexts, expressed as the Laws of Identity. Together these laws define a unifying identity metasystem that can offer the Internet the identity layer it needs. (14 printed pages)
Contents
Problem Statement
Words That Allow Dialogue
The Laws of Identity
Conclusion
For More Information
The Internet was built without a way to know who and what you are connecting to. This limits what we can do with it and exposes us to growing dangers. If we do nothing, we will face rapidly proliferating episodes of theft and deception that will cumulatively erode public trust in the Internet.
This paper is about how we can prevent the loss of trust and go forward to give Internet users a deep sense of safety, privacy, and certainty about whom they are relating to in cyberspace. Nothing could be more essential if Web-based services and applications are to continue to move beyond "cyber publication" and encompass all kinds of interaction and services. Our approach has been to develop a formal understanding of the dynamics causing digital identity systems to succeed or fail in various contexts, expressed as the Laws of Identity. Taken together, these laws define a unifying identity metasystem that can offer the Internet the identity layer it so obviously requires.
The ideas presented here were extensively refined through the Blogosphere in a wide-ranging conversation documented at www.identityblog.com that crossed many of the conventional fault lines of the computer industry, and in various private communications. In particular I would like to thank Arun Nanda, Andre Durand, Bill Barnes, Carl Ellison, Caspar Bowden, Craig Burton, Dan Blum, Dave Kearns, Dave Winer, Dick Hardt, Doc Searls, Drummond Reed, Ellen McDermott, Eric Norlin, Esther Dyson, Fen Labalme, Identity Woman Kaliya, JC Cannon, James Kobielus, James Governor, Jamie Lewis, John Shewchuk, Luke Razzell, Marc Canter, Mark Wahl, Martin Taylor, Mike Jones, Phil Becker, Radovan Janocek, Ravi Pandya, Robert Scoble, Scott C. Lemon, Simon Davies, Stefan Brands, Stuart Kwan and William Heath.
Problem Statement
The Internet was built without a way to know who and what you are connecting to.
A Patchwork of Identity "One-Offs"
Since this essential capability is missing, everyone offering an Internet service has had to come up with a workaround. It is fair to say that today's Internet, absent a native identity layer, is based on a patchwork of identity one-offs.
As use of the Web increases, so does users' exposure to these workarounds. Though no one is to blame, the result is pernicious. Hundreds of millions of people have been trained to accept anything any site wants to throw at them as being the "normal way" to conduct business online. They have been taught to type their names, secret passwords, and personal identifying information into almost any input form that appears on their screen.
There is no consistent and comprehensible framework allowing them to evaluate the authenticity of the sites they visit, and they don't have a reliable way of knowing when they are disclosing private information to illegitimate parties. At the same time they lack a framework for controlling or even remembering the many different aspects of their digital existence.
Criminalization of the Internet
People have begun to use the Internet to manage and exchange things of progressively greater real-world value. This has not gone unnoticed by a criminal fringe that understands the ad hoc and vulnerable nature of the identity patchwork—and how to subvert it. These criminal forces have increasingly professionalized and organized themselves internationally.
Individual consumers are tricked into releasing banking and other information through "phishing" schemes that take advantage of their inability to tell who they are dealing with. They are also induced to inadvertently install "spyware" which resides on their computers and harvests information in long term "pharming" attacks. Other schemes successfully target corporate, government, and educational databases with vast identity holdings, and succeed in stealing hundreds of thousands of identities in a single blow. Criminal organizations exist to acquire these identities and resell them to a new breed of innovators expert in using them to steal as much as possible in the shortest amount of time. The international character of these networks makes them increasingly difficult to penetrate and dismantle.
Phishing and pharming are now thought to be one of the fastest growing segments of the computer industry, with an annual compound growth rate (CAGR) of 1000%. (For example, the Anti-Phishing Working Group "Phishing Activity Trends Report" of February 2005 cites an annual monthly growth rate in phishing sites between July through February of 26% per month, which represents a compound annual growth rate of 1600%.) Without a significant change in how we do things, this trend will continue.
It is essential to look beyond the current situation, and understand that if the current dynamics continue unchecked, we are headed toward a deep crisis: the ad hoc nature of Internet identity cannot withstand the growing assault of professionalized attackers.
A deepening public crisis of this sort would mean the Internet would begin to lose credibility and acceptance for economic transactions when it should be gaining that acceptance. But in addition to the danger of slipping backwards, we need to understand the costs of not going forward. The absence of an identity layer is one of the key factors limiting the further settlement of cyberspace.
Further, the absence of a unifying and rational identity fabric will prevent us from reaping the benefits of Web services.
Web services have been designed to let us build robust, flexible, distributed systems that can deliver important new capabilities, and evolve in response to their environment. Such living services need to be loosely coupled and organic, breaking from the paradigm of rigid premeditation and hard wiring. But as long as digital identity remains a patchwork of ad hoc one-offs that must still be hard-wired, all the negotiation and composability we have achieved in other aspects of Web services will enable nothing new. Knowing who is connecting with what is a must for the next generation of cyber services to break out of the starting gate.
It's Hard to Add an Identity Layer
There have been attempts to add more standardized digital identity services to the Internet. And there have been partial successes in specific domains—like the use of SSL to protect connections to public sites; or of Kerberos within enterprises. And recently, we have seen successful examples of federation in business-to-business identity sharing.
But these successes have done little to transform the identity patchwork into a rational fabric extending across the Internet.
Why is it so hard to create an identity layer for the Internet? Mainly because there is little agreement on what it should be and how it should be run. This lack of agreement arises because digital identity is related to context, and the Internet, while being a single technical framework, is experienced through a thousand kinds of content in at least as many different contexts—all of which flourish on top of that underlying framework. The players involved in any one of these contexts want to control digital identity as it impacts them, in many cases wanting to prevent spillover from their context to any other.
Enterprises, for example, see their relationships with customers and employees as key assets, and are fiercely protective of them. It is unreasonable to expect them to restrict their own choices or give up control over how they create and represent their relationships digitally. Nor has any single approach arisen which might serve as an obvious motivation to do so. The differing contexts of discreet enterprises lead to a requirement that they be free to adopt different kinds of solutions. Even ad hoc identity one-offs are better than an identity framework that would be out of their control.
Governments too have found they have needs that distinguish them from other kinds of organization. And specific industry clusters—"verticals" like the financial industry—have come to see they have unique difficulties and aspirations when it comes to maintaining digital relationships with their customers.
As important as these institutions are, the individual—as consumer—gets the final say about any proposed cyber identity system. Anything they don't like and won't—or can't—use will inevitably fail. Someone else will come along with an alternative.
Consumer fears about the safety of the Internet prevent many from using credit cards to make online purchases. Increasingly, malware and identity theft have made privacy issues of paramount concern to every Internet user. This has resulted in increased awareness and readiness to respond to larger privacy issues.
As the virtual world has evolved, privacy specialists have developed nuanced and well-reasoned analyses of identity from the point of view of the consumer and citizen. In response to their intervention, legal thinkers, government policy makers, and elected representatives have become increasingly aware of the many difficult privacy issues facing society as we settle cyberspace. This has already led to vendor sensitivity and government intervention, and more is to be expected.
In summary, as grave as the dangers of the current situation may be, the emergence of a single simplistic digital identity solution as a universal panacea is not realistic.
Even if a miracle occurred and the various players could work out some kind of broad cross-sector agreement about what constitutes perfection in one country, the probability of extending that universally across international borders would be zero.
An Identity Metasystem
In the case of digital identity, the diverse needs of many players demand that we weave a single identity fabric out of multiple constituent technologies. Although this might initially seem daunting, similar things have been done many times before as computing has evolved.
For instance, in the early days of personal computing, application builders had to be aware of what type of video display was in use, and of the specific characteristics of the storage devices that were installed. Over time, a layer of software emerged that was able to provide a set of services abstracted from the specificities of any given hardware. The technology of "device drivers" enabled interchangeable hardware to be plugged in as required. Hardware became "loosely coupled" to the computer, allowing it to evolve quickly since applications did not need to be rewritten to take advantage of new features.
The same can be said about the evolution of networking. At one time applications had to be aware of the specific network devices in use. Eventually the unifying technologies of sockets and TCP/IP emerged, able to work with many specific underlying systems (Token Ring, Ethernet, X.25 and Frame Relay)—and even with systems, like wireless, that were not yet invented.
Digital identity requires a similar approach. We need a unifying identity metasystem that can protect applications from the internal complexities of specific implementations and allow digital identity to become loosely coupled. This metasystem is in effect a system of systems that exposes a unified interface much like a device driver or network socket does. That allows one-offs to evolve towards standardized technologies that work within a metasystem framework without requiring the whole world to agree a priori.
Understanding the Obstacles
To restate our initial problem, the role of an identity metasystem is to provide a reliable way to establish who is connecting with what—anywhere on the Internet.
We have observed that various types of systems have successfully provided identification in specific contexts. Yet despite their success they have failed to attract usage in other scenarios. What factors explain these successes and failures? Moreover, what would be the characteristics of a solution that would work at Internet scale? In answering these questions, there is much to be learned from the successes and failures of various approaches since the 1970s.
This investigation has led to a set of ideas called the Laws of Identity. We chose the word "laws" in the scientific sense of hypotheses about the world—resulting from observation—which can be tested and are thus disprovable. (We consciously avoided the words "proposition," meaning something proven through logic rather than experiment, and "axiom," meaning something self-evident.) The reader should bear in mind that we specifically did not want to denote legal or moral precepts, nor embark on a discussion of the "philosophy of identity." (All three areas are of compelling interest, but it is necessary to tightly focus the current discussion on matters that are directly testable and applicable to solving the imminent crisis of the identity infrastructure.)
These laws enumerate the set of objective dynamics defining a digital identity metasystem capable of being widely enough accepted that it can serve as a backplane for distributed computing on an Internet scale. As such, each law ends up giving rise to an architectural principle guiding the construction of such a system.
Our goals are pragmatic. When we postulate the Law of User Control and Consent, for example, it is because experience tells us: a system that does not put users in control will—immediately or over time—be rejected by enough of them that it cannot become and remain a unifying technology. How this law meshes with values is not the relevant issue.
Like the other laws, this one represents a contour limiting what an identity metasystem must look like—and must not look like—given the many social formations and cultures in which it must be able to operate. Understanding the laws can help eliminate a lot of doomed proposals before we waste too much time on them.
The laws are testable. They allow us to predict outcomes, and we have done so consistently since proposing them. They are also objective, i.e., they existed and operated before they were formulated. That is how the Law of Justifiable Parties, for example, can account for the successes and failures of the Microsoft Passport identity system.
The Laws of Identity, taken together, define the architecture of the Internet's missing identity layer.
Words That Allow Dialogue
Many people have thought about identity, digital identities, personas, and representations. In proposing the laws we do not expect to close this discussion. However, in keeping with the pragmatic goals of this exercise we define a vocabulary that will allow the laws themselves to be understood.
What is a Digital Identity?
We will begin by defining a digital identity as a set of claims made by one digital subject about itself or another digital subject. We ask the reader to let us define what we mean by a digital subject and a set of claims before examining this further.
What Is a Digital Subject?
The Oxford English Dictionary (OED) defines a subject as:
"A person or thing that is being discussed, described or dealt with."
So we define a digital subject as:
"A person or thing represented or existing in the digital realm which is being described or dealt with."
Much of the decision-making involved in distributed computing is the result of "dealing with" an initiator or requester. And it is worth pointing out that the digital world includes many subjects that need to be "dealt with" other than humans, including:
Devices and computers (which allow us to penetrate the digital realm in the first place)
Digital resources (which attract us to it)
Policies and relationships between other digital subjects (e.g., between humans and devices or documents or services)
The OED goes on to define subject, in a philosophical sense, as the "central substance or core of a thing as opposed to its attributes." As we shall see, "attributes" are the things expressed in claims, and the subject is the central substance thereby described.
(We have selected the word subject in preference to alternatives such as "entity," which means "a thing with distinct and independent existence." The independent existence of a thing is a moot point here—it may well be an aspect of something else. What matters is that a relying party is dealing with the thing and that claims are being made about it.)
What Is a Claim?
A claim is:
"An assertion of the truth of something, typically one which is disputed or in doubt."
Some examples of claims in the digital realm will likely help:
A claim could just convey an identifier—for example, that the subject's student number is 490-525, or that the subject's Windows name is REDMOND\kcameron. This is the way many existing identity systems work.
Another claim might assert that a subject knows a given key—and should be able to demonstrate this fact.
A set of claims might convey personally identifying information—name, address, date of birth and citizenship, for example.
A claim might simply propose that a subject is part of a certain group—for example, that she has an age less than 16.
And a claim might state that a subject has a certain capability—for example, to place orders up to a certain limit, or modify a given file.
The concept of "being in doubt" grasps the subtleties of a distributed world like the Internet. Claims need to be subject to evaluation by the party depending on them. The more our networks are federated and open to participation by many different subjects, the more obvious this becomes.
The use of the word claim is therefore more appropriate in a distributed and federated environment than alternate words such as "assertion," which means "a confident and forceful statement of fact or belief." (OED) In evolving from a closed domain model to an open, federated model, the situation is transformed into one where the party making an assertion and the party evaluating it may have a complex and even ambivalent relationship. In this context, assertions need always be subject to doubt—not only doubt that they have been transmitted from the sender to the recipient intact, but also doubt that they are true, and doubt that they are even of relevance to the recipient.
Advantages of a Claims-Based Definition
The definition of digital identity employed here encompasses all the known digital identity systems and therefore allows us to begin to unify the rational elements of our patchwork conceptually. It allows us to define digital identity for a metasystem embracing multiple implementations and ways of doing things.
In proffering this definition, we recognize it does not jibe with some widely held beliefs—for example, that within a given context, identities have to be unique. Many early systems were built with this assumption, and it is a critically useful assumption in many contexts. The only error is in thinking it is mandatory for all contexts.
By way of example, consider the relationship between a company like Microsoft and an analyst service that we will call Contoso Analytics. Let's suppose Microsoft contracts with Contoso Analytics so anyone from Microsoft can read its reports on industry trends. Let's suppose also that Microsoft doesn't want Contoso Analytics to know exactly who at Microsoft has what interests or reads what reports.
In this scenario we actually do not want to employ unique individual identifiers as digital identities. Contoso Analytics still needs a way to ensure that only valid customers get to its reports. But in this example, digital identity would best be expressed by a very limited claim—the claim that the digital subject currently accessing the site is a Microsoft employee. Our claims-based approach succeeds in this regard. It permits one digital subject (Microsoft Corporation) to assert things about another digital subject without using any unique identifier.
This definition of digital identity calls upon us to separate cleanly the presentation of claims from the provability of the link to a real world object.
Our definition leaves the evaluation of the usefulness (or the truthfulness or the trustworthiness) of the claim to the relying party. The truth and possible linkage is not in the claim, but results from the evaluation. If the evaluating party decides it should accept the claim being made, then this decision just represents a further claim about the subject, this time made by the evaluating party (it may or may not be conveyed further).
Evaluation of a digital identity thus results in a simple transform of what it starts with—again producing in a set of claims made by one digital subject about another. Matters of trust, attribution, and usefulness can then be factored out and addressed at a higher layer in the system than the mechanism for expressing digital identity itself.
The Laws of Identity
We can now look at the seven essential laws that explain the successes and failures of digital identity systems.
1. User Control and Consent
Technical identity systems must only reveal information identifying a user with the user's consent. (Blogosphere discussion starts here...)
No one is as pivotal to the success of the identity metasystem as the individual who uses it. The system must first of all appeal by means of convenience and simplicity. But to endure, it must earn the user's trust above all.
Earning this trust requires a holistic commitment. The system must be designed to put the user in control—of what digital identities are used, and what information is released.
The system must also protect the user against deception, verifying the identity of any parties who ask for information. Should the user decide to supply identity information, there must be no doubt that it goes to the right place. And the system needs mechanisms to make the user aware of the purposes for which any information is being collected.
The system must inform the user when he or she has selected an identity provider able to track Internet behavior.
Further, it must reinforce the sense that the user is in control regardless of context, rather than arbitrarily altering its contract with the user. This means being able to support user consent in enterprise as well as consumer environments. It is essential to retain the paradigm of consent even when refusal might break a company's conditions of employment. This serves both to inform the employee and indemnify the employer.
The Law of User Control and Consent allows for the use of mechanisms whereby the metasystem remembers user decisions, and users may opt to have them applied automatically on subsequent occasions.
2. Minimal Disclosure for a Constrained Use
The solution that discloses the least amount of identifying information and best limits its use is the most stable long-term solution. (Starts here...)
We should build systems that employ identifying information on the basis that a breach is always possible. Such a breach represents a risk. To mitigate risk, it is best to acquire information only on a "need to know" basis, and to retain it only on a "need to retain" basis. By following these practices, we can ensure the least possible damage in the event of a breach.
At the same time, the value of identifying information decreases as the amount decreases. A system built with the principles of information minimalism is therefore a less attractive target for identity theft, reducing risk even further.
By limiting use to an explicit scenario (in conjunction with the use policy described in the Law of Control), the effectiveness of the "need to know" principle in reducing risk is further magnified. There is no longer the possibility of collecting and keeping information "just in case" it might one day be required.
The concept of "least identifying information" should be taken as meaning not only the fewest number of claims, but the information least likely to identify a given individual across multiple contexts. For example, if a scenario requires proof of being a certain age, then it is better to acquire and store the age category rather than the birth date. Date of birth is more likely, in association with other claims, to uniquely identify a subject, and so represents "more identifying information" which should be avoided if it is not needed.
In the same way, unique identifiers that can be reused in other contexts (for example, drivers' license numbers, Social Security Numbers, and the like) represent "more identifying information" than unique special-purpose identifiers that do not cross context. In this sense, acquiring and storing a Social Security Number represents a much greater risk than assigning a randomly generated student or employee number.
Numerous identity catastrophes have occurred where this law has been broken.
We can also express the Law of Minimal Disclosure this way: aggregation of identifying information also aggregates risk. To minimize risk, minimize aggregation.
3. Justifiable Parties
Digital identity systems must be designed so the disclosure of identifying information is limited to parties having a necessary and justifiable place in a given identity relationship. (Starts here...)
The identity system must make its user aware of the party or parties with whom she is interacting while sharing information.
The justification requirements apply both to the subject who is disclosing information and the relying party who depends on it. Our experience with Microsoft Passport is instructive in this regard. Internet users saw Passport as a convenient way to gain access to MSN sites, and those sites were happily using Passport—to the tune of over a billion interactions per day. However, it did not make sense to most non-MSN sites for Microsoft to be involved in their customer relationships. Nor were users clamoring for a single Microsoft identity service to be aware of all their Internet activities. As a result, Passport failed in its mission of being an identity system for the Internet.
We will see many more examples of this law going forward. Today some governments are thinking of operating digital identity services. It makes sense (and is clearly justifiable) for people to use government-issued identities when doing business with the government. But it will be a cultural matter as to whether, for example, citizens agree it is "necessary and justifiable" for government identities to be used in controlling access to a family wiki—or connecting a consumer to her hobby or vice.
The same issues will confront intermediaries building a trust fabric. The law is not intended to suggest limitations of what is possible, but rather to outline the dynamics of which we must be aware.
We know from the Law of Control and Consent that the system must be predictable and "translucent" in order to earn trust. But the user needs to understand whom she is dealing with for other reasons, as we will see in the Law of Human Integration. In the physical world we are able to judge a situation and decide what we want to disclose about ourselves. This has its analogy in digital justifiable parties.
Every party to disclosure must provide the disclosing party with a policy statement about information use. This policy should govern what happens to disclosed information. One can view this policy as defining "delegated rights" issued by the disclosing party.
Any use policy would allow all parties to cooperate with authorities in the case of criminal investigations. But this does not mean the state is party to the identity relationship. Of course, this should be made explicit in the policy under which information is shared.
4. Directed Identity
A universal identity system must support both "omni-directional" identifiers for use by public entities and "unidirectional" identifiers for use by private entities, thus facilitating discovery while preventing unnecessary release of correlation handles. (Starts here...)
Technical identity is always asserted with respect to some other identity or set of identities. To make an analogy with the physical world, we can say identity has direction, not just magnitude. One special "set of identities" is that of all other identities (the public). Other important sets exist (for example, the identities in an enterprise, an arbitrary domain, or a peer group).
Entities that are public can have identifiers that are invariant and well known. These public identifiers can be thought of as beacons—emitting identity to anyone who shows up. And beacons are "omni-directional" (they are willing to reveal their existence to the set of all other identities).
A corporate Web site with a well-known URL and public key certificate is a good example of such a public entity. There is no advantage—in fact there is a great disadvantage—in changing a public URL. It is fine for every visitor to the site to examine the public key certificate. It is equally acceptable for everyone to know the site is there: its existence is public.
A second example of such a public entity is a publicly visible device like a video projector. The device sits in a conference room in an enterprise. Visitors to the conference room can see the projector and it offers digital services by advertising itself to those who come near it. In the thinking outlined here, it has an omni-directional identity.
On the other hand, a consumer visiting a corporate Web site is able to use the identity beacon of that site to decide whether she wants to establish a relationship with it. Her system can then set up a "unidirectional" identity relation with the site by selecting an identifier for use with that site and no other. A unidirectional identity relation with a different site would involve fabricating a completely unrelated identifier. Because of this, there is no correlation handle emitted that can be shared between sites to assemble profile activities and preferences into super-dossiers.
When a computer user enters a conference room equipped with the projector described above, its omni-directional identity beacon could be utilized to decide (as per the Law of Control) whether she wants to interact with it. If she does, a short-lived unidirectional identity relation could be established between the computer and the projector—providing a secure connection while divulging the least possible identifying information in accordance with the law of minimal disclosure.
Bluetooth and other wireless technologies have not so far conformed to the Law of Directed Identity. They use public beacons for private entities. This explains the consumer backlash innovators in these areas are currently wrestling with.
Public key certificates have the same problem when used to identify individuals in contexts where privacy is an issue. It may be more than coincidental that certificates have so far been widely used when in conformance with this law (i.e., in identifying public Web sites) and generally ignored when it comes to identifying private individuals.
Another example involves the proposed usage of RFID technology in passports and student tracking applications. RFID devices currently emit an omni-directional public beacon. This is not appropriate for use by private individuals.
Passport readers are public devices and therefore should employ an omni-directional beacon. But passports should only respond to trusted readers. They should not be emitting signals to any eavesdropper that identify their bearers and peg them as nationals of a given country. Examples have been given of unmanned devices that could be detonated by these beacons. In
5. Pluralism of Operators and Technologies
A universal identity system must channel and enable the inter-working of multiple identity technologies run by multiple identity providers. (Starts here...)
It would be nice if there were one way to express identity. But the numerous contexts in which identity is required won't allow it.
One reason there will never be a single, centralized monolithic system (the opposite of a metasystem) is because the characteristics that would make any system ideal in one context will disqualify it in another.
It makes sense to employ a government issued digital identity when interacting with government services (a single overall identity neither implies nor prevents correlation of identifiers between individual government departments).
But in many cultures, employers and employees would not feel comfortable using government identifiers to log in at work. A government identifier might be used to convey taxation information; it might even be required when a person is first offered employment. But the context of employment is sufficiently autonomous that it warrants its own identity, free from daily observation via a government-run technology.
Customers and individuals browsing the Web meanwhile will in many cases want higher levels of privacy than is likely to be provided by any employer.
So when it comes to digital identity, it is not only a matter of having identity providers run by different parties (including individuals themselves), but of having identity systems that offer different (and potentially contradictory) features.
A universal system must embrace differentiation, while recognizing that each of us is simultaneously—and in different contexts—a citizen, an employee, a customer, and a virtual persona.
This demonstrates, from yet another angle, that different identity systems must exist in a metasystem. It implies we need a simple encapsulating protocol (a way of agreeing on and transporting things). We also need a way to surface information through a unified user experience that allows individuals and organizations to select appropriate identity providers and features as they go about their daily activities.
The universal identity metasystem must not be another monolith. It must be polycentric (federation implies this) and also polymorphic (existing in different forms). This will allow the identity ecology to emerge, evolve, and self-organize.
Systems like RSS and HTML are powerful because they carry any content. We need to see that identity itself will have several—perhaps many—contexts, and yet can be expressed in a metasystem.
6. Human Integration
The universal identity metasystem must define the human user to be a component of the distributed system integrated through unambiguous human-machine communication mechanisms offering protection against identity attacks. (Starts here...)
We have done a pretty good job of securing the channel between Web servers and browsers through the use of cryptography—a channel that might extend for thousands of miles. But we have failed to adequately protect the two or three foot channel between the browser's display and the brain of the human who uses it. This immeasurably shorter channel is the one under attack from phishers and pharmers.
No wonder. What identities is the user dealing with as she navigates the Web? How understandably is identity information conveyed to her? Do our digital identity systems interface with users in ways that objective studies have shown to work? Identity information currently takes the form of certificates. Do studies show certificates are meaningful to users?
What exactly are we doing? Whatever it is, we've got to do it better: the identity system must extend to and integrate the human user.
Carl Ellison and his colleagues have coined the term 'ceremony' to describe interactions that span a mixed network of human and cybernetic system components—the full channel from Web server to human brain. A ceremony goes beyond cyber protocols to ensure the integrity of communication with the user.
This concept calls for profoundly changing the user's experience so it becomes predictable and unambiguous enough to allow for informed decisions.
Since the identity system has to work on all platforms, it must be safe on all platforms. The properties that lead to its safety can't be based on obscurity or the fact that the underlying platform or software is unknown or has a small adoption.
One example is United Airlines' Channel 9. It carries a live conversation between the cockpit of one's plane and air traffic control. The conversation on this channel is very important, technical, and focused. Participants don't "chat"—all parties know precisely what to expect from the tower and the airplane. As a result, even though there is a lot of radio noise and static, it is easy for the pilot and controller to pick out the exact content of the communication. When things go wrong, the broken predictability of the channel marks the urgency of the situation and draws upon every human faculty to understand and respond to the danger. The limited semiotics of the channel mean there is very high reliability in communications.
We require the same kind of bounded and highly predictable ceremony for the exchange of identity information. A ceremony is not a "whatever feels good" sort of thing. It is predetermined.
But isn't this limitation of possibilities at odds with our ideas about computing? Haven't many advances in computing come about through ambiguity and unintended consequences that would be ruled out in the austere light of ceremony?
These are valid questions. But we definitely don't want unintended consequences when figuring out who we are talking to or what personal identification information to reveal.
The question is how to achieve very high levels of reliability in the communication between the system and its human users. In large part, this can be measured objectively through user testing.
7. Consistent Experience Across Contexts
The unifying identity metasystem must guarantee its users a simple, consistent experience while enabling separation of contexts through multiple operators and technologies.
Let's project ourselves into a future where we have a number of contextual identity choices. For example:
Browsing: a self-asserted identity for exploring the Web (giving away no real data)
Personal: a self-asserted identity for sites with which I want an ongoing but private relationship (including my name and a long-term e-mail address)
Community: a public identity for collaborating with others
Professional: a public identity for collaborating issued by my employer
Credit card: an identity issued by my financial institution
Citizen: an identity issued by my government
We can expect that different individuals will have different combinations of these digital identities, as well as others.
To make this possible, we must "thingify" digital identities—make them into "things" the user can see on the desktop, add and delete, select and share. (We have chosen to "localize" the more venerable word "reify".) How usable would today's computers be had we not invented icons and lists that consistently represent folders and documents? We must do the same with digital identities.
What type of digital identity is acceptable in a given context? The properties of potential candidates will be specified by the Web service from which a user wants to obtain a service. Matching thingified digital identities can then be displayed to the user, who can select between them and use them to understand what information is being requested. This allows the user to control what is released.
Different relying parties will require different kinds of digital identities. And two things are clear:
A single relying party will often want to accept more than one kind of identity, and
A user will want to understand his or her options and select the best identity for the context
Putting all the laws together, we can see that the request, selection, and proffering of identity information must be done such that the channel between the parties is safe. The user experience must also prevent ambiguity in the user's consent, and understanding of the parties involved and their proposed uses. These options need to be consistent and clear. Consistency across contexts is required for this to be done in a way that communicates unambiguously with the human system components.
As users, we need to see our various identities as part of an integrated world that nonetheless respects our need for independent contexts.
Conclusion
Those of us who work on or with identity systems need to obey the Laws of Identity. Otherwise, we create a wake of reinforcing side effects that eventually undermine all resulting technology. The result is similar to what would happen if civil engineers were to flaunt the law of gravity. By following them we can build a unifying identity metasystem that is universally accepted and enduring.
Microsoft's Vision for an Identity Metasystem
Microsoft Corporation
May 2005
Applies to:
Security
Web development
Web services
Summary: The Identity Metasystem is an interoperable architecture for digital identity that assumes people will have several digital identities based on multiple underlying technologies, implementations, and providers. Using this approach, customers will be able to continue to use their existing identity infrastructure investments, choose the identity technology that works best for them, and more easily migrate from old technologies to new technologies without sacrificing interoperability with others. This paper introduces the principles behind this approach in "The Laws of Identity"; it presents an open and interoperable architecture for building the metasystem, and it describes Microsoft's plans to participate in the identity metasystem. (12 printed pages)
Contents
Digital Identity: The Challenge
What is the Identity Metasystem?
Identities Function in Contexts
The Laws of Identity
Roles within the Identity Metasystem
Components of the Identity Metasystem
Benefits of the Identity Metasystem
An Architecture for the Identity Metasystem: WS-* Web Services
Microsoft's Implementation Plans
What We Learned from Passport
Conclusion
For More Information
Digital Identity: The Challenge
For users and businesses alike, the Internet continues to be increasingly valuable. More people are using the Web for everyday tasks, from shopping, banking, and paying bills to consuming media and entertainment. E-commerce is growing, with businesses delivering more services and content across the Internet, communicating and collaborating online, and inventing new ways to connect with each other.
But as the value of what people do online has increased, the Internet itself has become more complex, criminalized, and dangerous. Online identity theft, fraud, and privacy concerns are on the rise, stemming from increasingly sophisticated practices such as "phishing". The multiplicity of accounts and passwords users must keep track of and the variety of methods of authenticating to sites result not only in user frustration, known as "password fatigue", but also insecure practices such as reusing the same account names and passwords at many sites.
The root of these problems is that the Internet was designed without a system of digital identity in mind. In efforts to address this deficiency, numerous digital identity systems have been introduced, each with its own strengths and weaknesses. But no one single system meets the needs of every digital identity scenario. And even if it were possible to create one system that did, the reality is that many different identity systems are in use today, with still more being invented. As a result, the current state of digital identity on the Internet is an inconsistent patchwork of ad hoc solutions that burdens people with different user experiences at every Web site, renders the system as a whole fragile, and constrains the fuller realization of the promise of e-commerce.
What is the Identity Metasystem?
Given that universal adoption of a single digital identity system or technology is unlikely ever to occur, a successful and widely employed identity solution for the Internet requires a different approach—one with the capability to connect existing and future identity systems into an identity metasystem. This metasystem, or system of systems, would leverage the strengths of its constituent identity systems, provide interoperability between them, and enable creation of a consistent and straightforward user interface to them all. The resulting improvements in cyberspace would benefit everyone, making the Internet a safer place with the potential to boost e-commerce, combat phishing, and solve other digital identity challenges.
In the offline world, people carry multiple forms of identification in their wallets, such as driver's licenses or other government-issued identity cards, credit cards, and affinity cards such as frequent flyer cards. People control which card to use and how much information to reveal in any given situation.
Similarly, the identity metasystem makes it easier for users to stay safe and in control when accessing resources on the Internet. It lets users select from among a portfolio of their digital identities and use them at Internet services of their choice where they are accepted. The metasystem enables identities provided by one identity system technology to be used within systems based on different technologies, provided an intermediary exists that understands both technologies and is willing and trusted to do the needed translations.
It's important to note that the identity metasystem does not compete with or replace the identity systems it connects. Rather, it plays a role analogous to that of the Internet Protocol (IP) in the realm of networking. In the 1970s and early 1980s, before the invention of IP, distributed applications were forced to have direct knowledge of the network link, be it Ethernet, Token Ring, ArcNet, X.25, or Frame Relay. But IP changed the landscape by offering a technology-independent metasystem that insulated applications from the intricacies of individual network technologies, providing seamless interconnectivity and a platform for including not-yet-invented networks (such as 802.11 wireless) into the network metasystem.
In the same way, the goals of the identity metasystem are to connect individual identity systems, allowing seamless interoperation between them, to provide applications with a technology-independent representation of identities, and to provide a better, more consistent user experience with all of them. Far from competing with or replacing the identity systems it connects, the metasystem relies on the individual systems to do its work!
Identities Function in Contexts
The identities held by a person in the offline world can range from the significant, such as birth certificates, passports, and drivers' licenses, to the trivial, such as business cards or frequent coffee buyer's cards. People use their different forms of identification in different contexts where they are accepted.
Identities can be in or out of context. Identities used out of context generally do not bring the desired result. For example, trying to use a coffee card to cross a border is clearly out of context. On the other hand, using a bank card at an ATM, a government-issued ID at a border, a coffee card at a coffee stand, and a Passport Network (formerly .NET Passport) account at MSN Hotmail are all clearly in context.
In some cases, the distinction is less clear. You could conceivably use a government-issued ID at your ATM instead of a bank-issued card, but if this resulted in the government having knowledge of each financial transaction, some people would be uncomfortable. You could use a Social Security Number as a student ID number, but that has significant privacy implications, even facilitating identity theft. And you can use Passport accounts at some non-Microsoft sites, but few sites chose to enable this; even where it was enabled, few users did so because they felt that Microsoft's participation in these interactions was out of context.
Studying the Passport experience and other digital identity initiatives throughout the industry led us to work with a wide range of industry experts to codify a set of principles that we believe are fundamental to a successful, broadly adopted, and enduring digital identity system on the Internet. We call these principles "The Laws of Identity".
The Laws of Identity
The "Laws of Identity" are intended to codify a set of fundamental principles to which any universally adopted, sustainable identity architecture must conform. The Laws were proposed, debated, and refined through a long-running, open, and continuing dialogue on the Internet. Taken together, the Laws define the architecture of the identity metasystem.
They are:
1. User Control and Consent: Identity systems must only reveal information identifying a user with the user's consent.
2. Minimal Disclosure for a Constrained Use: The identity system must disclose the least identifying information possible, as this is the most stable, long-term solution.
3. Justifiable Parties: Identity systems must be designed so the disclosure of identifying information is limited to parties having a necessary and justifiable place in a given identity relationship.
4. Directed Identity: A universal identity system must support both "omni-directional" identifiers for use by public entities and "uni-directional" identifiers for use by private entities, thus facilitating discovery while preventing unnecessary release of correlation handles.
5. Pluralism of Operators and Technologies: A universal identity solution must utilize and enable the interoperation of multiple identity technologies run by multiple identity providers.
6. Human Integration: Identity systems must define the human user to be a component of the distributed system, integrated through unambiguous human-machine communication mechanisms offering protection against identity attacks.
7. Consistent Experience Across Contexts: The unifying identity metasystem must guarantee its users a simple, consistent experience while enabling separation of contexts through multiple operators and technologies.
For more information, see the Laws of Identity whitepaper. To join in the discussion of the Laws of Identity, visit www.identityblog.com.
Roles within the Identity Metasystem
Different parties participate in the metasystem in different ways. The three roles within the metasystem are:
Identity Providers, which issue digital identities. For example, credit card providers might issue identities enabling payment, businesses might issue identities to their customers, governments might issue identities to citizens, and individuals might use self-issued identities in contexts like signing on to Web sites.
Relying Parties, which require identities. For example, a Web site or online service that utilizes identities offered by other parties.
Subjects, which are the individuals and other entities about whom claims are made. Examples of subjects include end users, companies, and organizations.
In many cases, the participants in the metasystem play more than one role, and often all three.
Components of the Identity Metasystem
To build an identity metasystem, five key components are needed:
1. A way to represent identities using claims
2. A means for identity providers, relying parties, and subjects to negotiate
3. An encapsulating protocol to obtain claims and requirements
4. A means to bridge technology and organizational boundaries using claims transformation
5. A consistent user experience across multiple contexts, technologies, and operators
Claims-Based Identities
Digital identities consist of sets of claims made about the subject of the identity, where "claims" are pieces of information about the subject that the issuer asserts are valid. This parallels identities used in the real world. For example, the claims on a driver's license might include the issuing state, the driver's license number, name, address, sex, birth date, organ donor status, signature, and photograph, the types of vehicles the subject is eligible to drive, and restrictions on driving rights. The issuing state asserts that these claims are valid. The claims on a credit card might include the issuer's identity, the subject's name, the account number, the expiration date, the validation code, and a signature. The card issuer asserts that these claims are valid. The claims on a self-issued identity, where the identity provider and subject are one and the same entity, might include the subject's name, address, telephone number, and e-mail address, or perhaps just the knowledge of a secret. For self-issued identities, the subject asserts that these claims are valid.
Negotiation
Negotiation enables participants in the metasystem to make agreements needed for them to connect with one another within the metasystem. Negotiation is used to determine mutually acceptable technologies, claims, and requirements. For instance, if one party understands SAML and X.509 claims, and another understands Kerberos and X.509 claims, the parties would negotiate and decide to use X.509 claims with one another. Another type of negotiation determines whether the claims needed by a relying party can be supplied by a particular identity. Both kinds of negotiation are simple matching exercises; they compare what one party can provide with what the other one needs to determine whether there's a fit.
Encapsulating Protocol
The encapsulating protocol provides a technology-neutral way to exchange claims and requirements between subjects, identity providers, and relying parties. The participants determine the content and meaning of what is exchanged, not the metasystem. For example, the encapsulating protocol would allow an application to retrieve SAML-encoded claims without having to understand or implement the SAML protocol.
Claims Transformers
Claims transformers bridge organizational and technical boundaries by translating claims understood in one system into claims understood and trusted by another system, thereby insulating the mass of clients and servers from the intricacies of claim evaluation. Claims transformers may also transform or refine the semantics of claims. For example, a claim asserting, "Is an employee" might be transformed into the new claim, "OK to purchase book". The claim "Born on
Consistent User Experience
Many identity attacks succeed because the user was fooled by something presented on the screen, not because of insecure communication technologies. For example, phishing attacks occur not in the secured channel between Web servers and browsers—a channel that might extend thousands of miles—but in the two or three feet between the browser and the human who uses it. The identity metasystem, therefore, seeks to empower users to make informed and reasonable identity decisions by enabling the development of a consistent, comprehensible, and integrated user interface for making those choices.
One key to securing the whole system is presenting an easy-to-learn, predictable user interface that looks and works the same no matter which underlying identity technologies are employed. Another key is making important information obvious—for instance, displaying the identity of the site you're authenticating to in a way that makes spoofing attempts apparent. The user must be informed which items of personal information relying parties are requesting, and for what purposes. This allows users to make informed choices about whether or not to disclose this information. Finally, the user interface provides a means for the user to actively consent to the disclosure, if they agree to the conditions.
Benefits of the Identity Metasystem
Microsoft recognizes that the identity metasystem will only gain widespread adoption if participants filling all roles in the metasystem stand to benefit from their participation. Fortunately, this is the case. Key benefits of the identity metasystem include:
Greater user control and flexibility. Users decide how much information they disclose, to whom, and under what circumstances, thereby enabling them to better protect their privacy. Strong two-way authentication of identity providers and relying parties helps address phishing and other fraud. Identities and accompanying personal information can be securely stored and managed in a variety of ways, including via the online identity provider service of the user's choice, or on the user's PC, or in other devices such as secure USB keychain storage devices, smartcards, PDAs, and mobile phones
Safer, more comprehensible user experience. The identity metasystem enables a predictable, uniform user experience across multiple identity systems. It extends to and integrates the human user, thereby helping to secure the machine-human channel.
Increases the reach of existing identity systems. The identity metasystem does not compete with or replace the identity systems it connects, but rather preserves and builds upon customers' investments in their existing identity solutions. It affords the opportunity to use existing identities, such as corporate-issued identities and identities issued by online businesses, in new contexts where they could not have been previously employed.
Fosters identity system innovation. The identity metasystem should make it easier for newly developed identity technologies and systems to quickly gain widespread use and adoption. Claims transformers can allow new systems to participate even when most participants don't understand their native claims formats and protocols.
Enables adaptation in the face of attacks. New technologies are needed to stay ahead of criminals who attack existing identity technologies. The metasystem enables new identity technologies to be quickly deployed and utilized within it, as they are needed.
Creates new market opportunities. The identity metasystem enables interoperable, independent implementations of all metasystem components, meaning that the market opportunities are only limited by innovators' imaginations. Some parties will choose to go into the identity provider business. Others will provide certification services for identities. Some will implement server software. Others will implement client software. Device manufacturers and mobile telephone players can host identities on their platforms. New business opportunities are created for identity brokers, where trusted intermediaries transform claims from one system to another. New business opportunities abound.
A benefit we will all share as the identity metasystem becomes widely deployed is a safer, more trustworthy Internet. The metasystem will supply the widely adopted identity solution that the Net so desperately needs.
Participants in the identity metasystem can include anyone or anything that uses, participates in, or relies upon identities in any way, including, but not limited to existing identity systems, corporate identities, government identities,
An Architecture for the Identity Metasystem: WS-* Web Services
Microsoft has worked for the past several years with industry partners on a composable, end-to-end architecture for Web services. The set of specifications that make up this architecture have been named the WS-* Web Services architecture by the industry. This architecture supports the requirements of the identity metasystem.
The encapsulating protocol used for claims transformation is WS-Trust. Negotiations are conducted using WS-MetadataExchange and WS-SecurityPolicy. These protocols enable building a technology-neutral identity metasystem and form the "backplane" of the identity metasystem. Like other Web services protocols, they also allow new kinds of identities and technologies to be incorporated and utilized as they are developed and adopted by the industry.
To foster the interoperability necessary for broad adoption, the specifications for WS-* are published and are freely available, have been or will be submitted to open standards bodies, and allows implementations to be developed royalty-free.
Deployments of existing identity technologies can be leveraged in the metasystem by implementing support for the three WS-* protocols above. Examples of technologies that could be utilized via the metasystem include LDAP claims schemas, X.509, which is used in Smartcards; Kerberos, which is used in Active Directory and some UNIX environments; and SAML, a standard used in inter-corporate federation scenarios.
Identity Metasystem Architectural Diagram
This figure depicts sample relationships between a subject, identity providers, and relying parties, showing some of the technologies used by the metasystem and by specific systems utilized through the metasystem.
The Security Token Server implements the WS-Trust protocol and provides support for claims transformation.
Relying parties provide statements of requirements, expressed in terms of the WS-SecurityPolicy specification, and made available through the WS-MetadataExchange protocol.
The Identity Selector implements the consistent user experience. After being invoked by an application, it performs the negotiation between relying party and identity provider(s); displays the identities of "matched" identity providers and relying parties to the subject (e.g., the end user); obtains claims; and releases them to the application under the supervision of the subject.
Microsoft's Implementation Plans
Microsoft plans to build software filling all roles within the identity metasystem (while encouraging others to also build software filling these roles, including on non-Windows platforms). Microsoft is implementing the following software components for participation in the metasystem:
"InfoCard" identity selector: "InfoCard" is the code name for a WinFX component that provides the consistent user experience required by the identity metasystem. It is specifically hardened against tampering and spoofing to protect the end user's digital identities and maintain end-user control. A visual "Information Card" in the client user interface represents each digital identity managed by "InfoCard". The user selects identities represented by "InfoCards" to authenticate to participating services.
"InfoCard" simple self-issued identity provider: "InfoCard" also includes a simple identity provider that enables individual PC users to create and utilize self-issued identities, enabling password-free strong authentication to relying parties. A self-issued identity is one where the user vouches for the information they are providing, much like users do today when registering with a Web site. We are implementing the simple self-issued identity provider to help bootstrap the identity metasystem; we believe self-issued identities will continue to be accepted for certain classes of services. Identities hosted in the simple self-issued identity provider will not include or store sensitive personal information, such as Social Security numbers (or other national ID numbers if these are developed) or credit card numbers. Self-issued identities are not intended to provide the full range of features that a managed identity provider can offer - the market is wide open for companies to provide managed identity solutions to consumers.
Active Directory identity provider: This is a managed identity provider integrated with Active Directory. It includes a full set of policy controls to manage the use of Active Directory identities in the identity metasystem. Active Directory Federation Services, a new Active Directory feature shipping in Windows Server 2003 R2, is the first step to integrating identities in Active Directory with the identity metasystem.
"Indigo": The code-named "Indigo" Web services run time provides developers a way to rapidly build and deploy distributed applications, including relying party services in the identity metasystem.
The identity metasystem preserves and builds upon customers' investments in their existing identity solutions, including Active Directory and other identity solutions. Microsoft's implementation will be fully interoperable via WS-* protocols with other identity selector implementations, with other relying party implementations, and with other identity provider implementations.
Non-Microsoft applications will have the same ability to use "InfoCard" to manage their identities as Microsoft applications will. Non-Windows operating systems will be able to be full participants of the identity metasystem we are building in cooperation with the industry. Others can build an entire end-to-end implementation of the metasystem without any Microsoft software, payments to Microsoft, or usage of any Microsoft online identity service.
What We Learned from Passport
Microsoft's best-known identity effort is almost certainly the Passport Network (formerly .NET Passport). Microsoft has learned a great deal from building one of the largest Internet scale authentication services in the world, and applied these hard-won lessons in developing the Laws of Identity, the identity metasystem, and several of our products.
Passport was originally intended to solve two problems: to be an identity provider for the MSN and Microsoft properties, and to be an identity provider for the Internet. It succeeded at the first, with over 250 million active Passport accounts and over 1 billion authentications per day. As for the second original goal, it became clear to us through continued engagement with partners, consumers, and the industry that in many cases it didn't make sense for Microsoft to play a role in transactions between, for instance, a company and its customers.
Apart from its input to our thinking on the Laws of Identity, it is worth mentioning that operating the Passport service has helped Microsoft gain a deep understanding of the operational and technical challenges that large-scale identity providers face. These experiences have helped us ensure that our identity products meet the needs of large-scale deployments.
The identity metasystem is different from the original version of Passport in several fundamental ways. The metasystem stores no personal information, leaving it up to individual identity providers to decide how and where to store that information. The identity metasystem is not an online identity provider for the Internet; indeed, it provides a means for all identity providers to coexist with and compete with one another, with all having equal standing within the metasystem. Finally, while Microsoft charged services to use the original version of Passport, no one will be charged to participate in the identity metasystem.
The Passport system itself has evolved in response to these experiences as well. It no longer stores personal information other than username/password credentials. Passport is now an authentication system targeted at Microsoft sites and those of close partners – a role that is clearly in context and with which our users and partners are very comfortable. Passport and MSN plan to implement support for the identity metasystem as an online identity provider for MSN and its partners. Passport users will get improved security and ease of use, and MSN Online partners will be able to interoperate with Passport through the identity metasystem.
Conclusion
Many of the problems on the Internet today, from phishing attacks to inconsistent user experiences, stem from the patchwork nature of digital identity solutions that software makers have built in the absence of a unifying and architected system of digital identity. An identity metasystem, as defined by the Laws of Identity, would supply a unifying fabric of digital identity, utilizing existing and future identity systems, providing interoperability between them, and enabling the creation of a consistent and straightforward user interface to them all. Basing our efforts on the Laws of Identity, Microsoft is working with others in the industry to build the identity metasystem using published WS-* protocols that render Microsoft's implementations fully interoperable with those produced by others.
We believe that many of the dangers, complications, annoyances, and uncertainties of today's online experiences can be a thing of the past. Widespread deployment of the identity metasystem has the potential to solve many of these problems, benefiting everyone and accelerating the long-term growth of connectivity by making the online world safer, more trustworthy, and easier to use. Microsoft is working with others in the industry to define and deploy the identity metasystem. We hope that you will join us!
For More Information
The Laws of Identity whitepaper
Join the identity discussion at http://www.identityblog.com/
Read more about Web services on the MSDN Web Services Developer Center
Read about the Microsoft InfoCard software that implements components of the Identity Metasystem.
A Guide to Supporting InfoCard v1.0 Within Web Applications and Browsers
March 2006
Author
Michael B. Jones
Microsoft Corporation
Copyright Notice
© 2006 Microsoft Corporation. All rights reserved.
Abstract
The Identity Metasystem allows users to manage their digital identities from various identity providers and employ them in different contexts where they are accepted to access online services. In the Identity Metasystem, identities are represented to users as "Information Cards" (a.k.a. "InfoCards"). One important class of applications where InfoCard-based authentication can be used is applications hosted on Web sites and accessed through Web browsers.
This paper documents the Web interfaces utilized by browsers and Web applications that support the Identity Metasystem. The information in this document is not specific to any one browser or platform.
This document supplements the information provided in two other "InfoCard" references: the [InfoCard-Guide] which provides a non-normative description of the overall InfoCard model, and the InfoCard Technical Reference [InfoCard-TechRef], which provides the normative schema definitions and behaviors referenced by the InfoCard Guide.
Status
This draft corresponds to the "InfoCard" support that Microsoft is implementing in WinFX [WinFX] and Internet Explorer 7. Other implementations following these specifications should be able to interoperate with the Microsoft implementation. The behaviors described in this document are subject to change.
Table of Contents
1. Introduction
2. Design Goals
3. Browser Behavior with InfoCards
3.1 Basic Protocol Flow When Using an InfoCard at a Web Site
3.2 Protocol Flow with Relying Party STS
3.3 User Perspective and Examples
3.4 Browser Perspective
3.5 Web Site Perspective
4. Invoking InfoCard from a Web Page
4.1 Syntax Alternatives: OBJECT and XHTML tags
4.1.1 OBJECT Syntax Examples
4.1.2 XHTML Syntax Example
4.2 InfoCard Invocation Parameters
4.2.1 issuer (optional)
4.2.2 issuerPolicy (optional)
4.2.3 tokenType (optional)
4.2.4 requiredClaims (optional)
4.2.5 optionalClaims (optional)
4.3 Data Types for Use with Scripting
4.4 Detecting and Utilizing an InfoCard-enabled Browser
5. References
Appendix A – HTTP POST Sample Contents
Appendix B – Detecting InfoCard Browser Support by Internet Explorer
Appendix C – Corrigenda
C.1. Self-Issued Card Issuer Syntax
C.2. Claim Separator Syntax
The Identity Metasystem allows users to manage their digital identities, whether they are self-issued or issued by third-party identity providers, and employ them in contexts where they are accepted to access online services. In the Identity Metasystem, identities are represented to users as "Information Cards" (a.k.a. "InfoCards"). One important class of applications where InfoCard-based authentication can be used is applications hosted on Web sites and accessed through Web browsers.
This paper documents the Web interfaces utilized by browsers and Web applications supporting the Identity Metasystem. The information in this document applies to all platforms and browsers. These mechanisms are documented here to enable Web sites and browsers on all platforms to implement and use these mechanisms so they can utilize InfoCards for authentication.
Two other documents should be considered prerequisites for understanding this document: the InfoCard Guide [InfoCard-Guide] which provides a non-normative description of the overall InfoCard model, and the InfoCard Technical Reference [InfoCard-TechRef], which provides the normative schema definitions and behaviors referenced by the InfoCard Guide.
Numerous alternatives were considered for ways of bringing InfoCard-based authentication to Web sites. The design goals that led to the eventual decisions described in this document are:
Browser independent: A goal was to ensure that the protocols developed for InfoCard-based authentication to Web sites could be implemented by a broad range of Web browsers on the platforms of their choice.
Web server independent: A closely related goal was to ensure that the protocols developed for InfoCard-based authentication to Web sites could be used by Web-based applications running on a broad range of Web servers on the platforms of their choice.
Minimal impact on Web sites: A goal was to facilitate the adoption of InfoCard-based authentication for existing Web sites by requiring as few changes to them as possible.
Seamless browser integration: A goal was that InfoCard-based authentication should be viewed as a seamless security feature that is a natural extension of the browser(s) being used.
Seamless user experience: A goal was that the InfoCard Web integration design should permit graceful fallback when a browser or platform does not have InfoCard support available.
Work with browser high security settings: A goal was that the mechanisms chosen should remain enabled even when browser security settings are set to "high".
The choices described in this document are an attempt to balance among all these sometimes competing goals and to achieve all of them as well as possible, given the realities of how the Web is used today.
3. Browser Behavior with InfoCards
This section explains the steps that a Web browser takes when using an InfoCard to authenticate to a Web site. Two cases are described. The basic case is where the Web site provides all the relying party functionality via HTML extensions transported over HTTP and HTTPS. The second case is where the relying party employs a relying party Security Token Server (STS), which it references via HTML extensions transported over HTTP and HTTPS.
3.1 Basic Protocol Flow When Using an InfoCard at a Web Site
This section explains the protocol flow when using an InfoCard to authenticate at a Web site where no relying party STS is employed.
Figure 1: Basic protocol flow when using an InfoCard to authenticate at a Web site
Figure 1 gives an example of the basic protocol flow when an InfoCard is used to authenticate at a Web site that employs no relying party STS. Steps 1, 2, and 5 are essentially the same as a typical forms-based login today: (1) The user navigates to a protected page that requires authentication. (2) The site redirects the browser to a login page, which presents a Web form. (5) The browser posts the Web form that includes the login credentials supplied by the user back to the login page. The site then validates the contents of the form including the user credentials, typically writes a cookie to the client for the protected page domain, and redirects the browser back to the protected page.
The key difference between this scenario and today's site login scenarios is that the login page returned to the browser in step (2) contains an HTML tag that allows the user to choose to use an InfoCard to authenticate to the site. When the user selects this tag, the browser's InfoCard support code invokes the InfoCard protocols and user experience, and triggers steps (3) through (5).
In Step (3), the browser InfoCard support code invokes the InfoCard identity selector, passing it parameter values supplied by the InfoCard HTML tag supplied by the site in Step (2). The user then uses the identity selector to choose an InfoCard, which represents a digital identity that can be used to authenticate at that site. Step (4) uses the standard Identity Metasystem protocols [InfoCard-Guide] to retrieve a security token that represents the digital identity selected by the user from the STS at the identity provider for that identity.
In Step (5), the browser posts the token obtained back to the Web site using a HTTP(S)/POST. The Web site validates the token, completing the user's InfoCard-based authentication to the Web site. Following authentication, the Web site typically then writes a client-side browser cookie and redirects the browser back to the protected page.
It is worth noting that this cookie is likely to be exactly the same cookie as the site would have written back had the user authenticated via other means, such as a forms-based login using username/password. This is one of the ways that the goal of "minimal impact on Web sites" is achieved. Other than its authentication subsystem, the bulk of a Web site's code can remain completely unaware that InfoCard-based authentication is even utilized. It just uses the same kinds of cookies as always.
3.2 Protocol Flow with Relying Party STS
In the previous scenario, the Web site communicated with the client Identity selector using only the HTML extensions enabling InfoCard use, transported over the normal browser HTTP or HTTPS channel. In this scenario, the Web site also employs a relying party STS to do part of the work of authenticating the user, passing the result of that authentication on to the login page via HTTP(S) POST.
There are several reasons that a site might factor its solution this way. One is that the same relying party STS can be used to do the authentication work for both browser-based applications and smart client applications that are using Web services. Second, it allows the bulk of the authentication work to be done on servers dedicated to this purpose, rather than on the Web site front-end servers. Finally, this means that the front-end servers can accept site-specific tokens, rather than the potentially more general or more complicated authentication tokens issued by the identity providers.
Figure 2: Protocol flow when using an InfoCard to authenticate at a Web site, where the Web site employs a relying party STS
This scenario is similar to the previous one, with the addition of steps (3) and (6). The differences start with the InfoCard information supplied to the browser by the Web site in Step (2). In the previous scenario, the site encoded its WS-SecurityPolicy information using InfoCard HTML extensions and supplied them to the InfoCard-extended browser directly. In this scenario, the site uses different InfoCard HTML extensions in the Step (2) reply to specify which relying party STS should be contacted to obtain the WS-SecurityPolicy information.
In Step (3), the client InfoCard code contacts the relying party STS specified by the Web site and obtains its WS-SecurityPolicy information via WS-MetadataExchange. In Step (4) the identity selector is shown and the user selects an InfoCard, which represents a digital identity to use at the site. In Step (5), the identity provider is contacted to obtain a security token for the selected digital identity. In Step (6), the security token is sent to the Web site's relying party STS to authenticate the user and a site-specific authentication token is returned to the InfoCard client. Finally, in Step (7), the browser posts the token obtained in Step (6) back to the Web site using HTTP(S)/POST. The Web site validates the token, completing the user's InfoCard-based authentication to the Web site. Following authentication, the Web site typically then writes a client-side browser cookie and redirects the browser back to the protected page.
3.3 User Perspective and Examples
The InfoCard user experience at Web sites is intended to be intuitive and natural enough that users' perspective on it will simply be "That's how you log in". Today, Web sites that require authentication typically ask the user to supply a username and password at login time. With InfoCard, they instead ask users to supply an InfoCard. Some sites will choose to accept only InfoCards whereas others will give users the choice of InfoCards or other forms of authentication.
A site that accepts InfoCards typically has a login screen that contains button with a label such as "Sign in with an InfoCard" or "Login in using an InfoCard". Upon clicking this button, the user is presented with a choice of his InfoCards that are accepted at the site, and is asked to choose one. Once a card is selected and submitted to the site, the user is logged in and continues using the site, just as they would after submitting a username and password to a site.
Sites that accept both InfoCards and other forms of authentication present users with both an InfoCard login choice and whatever other choices the site supports. For instance, a site login screen might display both "Sign in with your username and password" and "Sign in with an InfoCard" buttons.
Very little additional support is required from today's Web browsers to also support InfoCard-based authentication. The main addition is that they must recognize special HTML and/or XHTML tags for invoking the InfoCard user experience, pass encoded parameters on to the Identity selector on the platform, and POST back the token resulting from the user's choice of a digital identity for the authentication.
Web sites that employ InfoCard-based authentication must support two new pieces of functionality: adding HTML or XHTML tags to their login page to request an InfoCard-based login and code to log the user into the site using the POSTed credentials. In response to the InfoCard-based login, the Web site typically writes the same client-side browser cookie that it would have if the login had occurred via username/password authentication or other mechanisms, and issue the same browser redirects. Thus, other than the code directly involved with user authentication, the bulk of a Web site can remain unchanged and oblivious to the site's acceptance of InfoCards as a means of authentication.
4. Invoking InfoCard from a Web Page
4.1 Syntax Alternatives: OBJECT and XHTML tags
HTML extensions are used to signal to the browser when to invoke the identity selector. However, not all HTML extensions are supported by all browsers, and some commonly supported HTML extensions are disabled in browser high security configurations. For example, while the OBJECT tag is widely supported, it is also disabled by high security settings on some browsers, including Internet Explorer.
An alternative is to use an XHTML syntax that is not disabled by changing browser security settings. However, not all browsers provide full support for XHTML.
To address this situation, two HTML extension formats are specified. Browsers may support one or both of the extension formats.
An example of the OBJECT syntax is as follows:
This is an example of a page that requests that the user log in using an InfoCard. The key portion of this page is the OBJECT of type "application/x-informationCard". Once a user selects a card, the resulting security token is included in the resulting POST as the xmlToken value of the form. Appendix A shows a sample POST resulting from using a login page similar to the preceding one. If the user cancels the authentication request, the resulting POST contains an empty xmlToken value.
Parameters of the InfoCard OBJECT are used to encode the required WS-SecurityPolicy information in HTML. In this example, the relying party is requesting a SAML 1.0 token from a self-issued identity provider, supplying the required claims "emailaddress", "givenname", and "surname". This example uses the basic protocol described in Section 3.1 (without employing a relying party STS).
A second example of the OBJECT syntax is as follows:
This example uses the enhanced protocol described in Section 3.2, which employs a relying party STS. Note that in this case, the "issuer" points to a relying party STS. The "issuerPolicy" points to an endpoint where the security policy of the STS (expressed via WS-SecurityPolicy) is to be obtained using WS-MetadataExchange. Also, note that the "tokenType" parameter requests a custom token type defined by the site for its own purposes. The "tokenType" parameter could have been omitted as well, provided that the Web site is capable of understanding all token types issued by the specified STS or if the STS has prior knowledge about the token type to issue for the Web site.
The object parameters can be set in normal script code. This is equivalent to setting them using the "PARAM" declarations in the previous example.
An example of the XHTML syntax is as follows:
4.2 InfoCard Invocation Parameters
The parameters to the OBJECT and XHTML InfoCard objects are used to encode information in HTML that is otherwise supplied as WS-SecurityPolicy information via WS-MetadataExchange when InfoCard is used in a Web services context.
This parameter specifies the URL of the STS from which to obtain a token. If omitted, no specific STS is requested. The special value "urn:schemas-microsoft-com:ws:2005:05:identity:issuer:self" specifies that the token should come from a self-issued identity provider.
This parameter specifies the URL of an endpoint from which the STS's policy can be retrieved. If omitted, the value "
This parameter specifies the type of the token to be requested from the STS as a URI. This parameter can be omitted if the STS and the Web site front-end have a mutual understanding about what token type will be provided, or if the Web site is willing to accept any token type.
4.2.4 requiredClaims (optional)
This parameter specifies the types of claims that must be supplied by the identity. If omitted, there are no required claims. The value of requiredClaims is a space-separated list of URIs, each specifying a required claim type.
4.2.5 optionalClaims (optional)
This parameter specifies the types of optional claims that may be supplied by the identity. If omitted, there are no optional claims. The value of optionalClaims is a space-separated list of URIs each specifying a claim type that can be optionally submitted.
4.3 Data Types for Use with Scripting
The object used in the InfoCard HTML extensions has the following type signature, allowing it to be used by normal scripting code:
interface IInformationCardSigninHelper { string issuer; // URI specifying token issuer string issuerPolicy; // MetadataExchange endpoint of issuer string tokenType; // URI specifiying type of token to be requested string requiredClaims; // Set of required claims string optionalClaims; // Set of optional claims boolean isInstalled; // True when InfoCard implementation is available // in the browser }
4.4 Detecting and Utilizing an InfoCard-enabled Browser
Web sites may choose to detect browser support for InfoCards and modify their login page contents depending upon whether InfoCard support is present, and which of the OBJECT and/or XHTML syntaxes are supported by the browser and supported by the Web site. This allows InfoCard capabilities to be shown when available to the user, and to be not displayed otherwise.
Detecting an InfoCard-enabled browser may require detecting specific browser versions and being aware of the nature of their InfoCard support. A method of accomplishing this for Internet Explorer is described in Appendix B.
"A Guide to Integrating with InfoCard v1.0," August 2005.
"A Technical Reference for InfoCard v1.0 in Windows," August 2005.
"WinFX Developer Center," January 2006.
[WS-MetadataExchange]
"Web Services Metadata Exchange (WS-MetadataExchange)," September 2004.
[WS-SecurityPolicy]
"Web Services Security Policy Language (WS-SecurityPolicy)," July 2005.
[WS-Trust]
"Web Services Trust Language (WS-Trust)," February 2005.
Appendix A – HTTP POST Sample Contents
The contents of an HTTP POST generated by a page like the first example in Section 4.1.1 follows:
POST /test/s/TokenPage.aspx HTTP/1.1 Cache-Control: no-cache Connection: Keep-Alive Content-Length: 6478 Content-Type: application/x-www-form-urlencoded Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-sh ockwave-flash, */* Accept-Encoding: gzip, deflate Accept-Language: en-us Host: calebb-tst Referer: https://localhost/test/s/ User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727) UA-CPU: x86 InfoCardSignin=Log+in&xmlToken=%3Cenc%3AEncryptedData+Type%3D%22http%3A%2F%2F www.w3.org%2F2001%2F04%2Fxmlenc%23Element%22+xmlns%3Aenc%3D%22http%3A%2F%2Fww w.w3.org%2F2001%2F04%2Fxmlenc%23%22%3E%3Cenc%3AEncryptionMethod+Algorithm%3D% 22http%3A%2F%2Fwww.w3.org%2F2001%2F04%2Fxmlenc%23aes256-cbc%22+%2F%3E%3CKeyIn fo+xmlns%3D%22http%3A%2F%2Fwww.w3.org%2F2000%2F09%2Fxmldsig%23%22%3E%3Ce%3AEn cryptedKey+xmlns%3Ae%3D%22http%3A%2F%2Fwww.w3.org%2F2001%2F04%2Fxmlenc%23%22% 3E%3Ce%3AEncryptionMethod+Algorithm%3D%22http%3A%2F%2Fwww.w3.org%2F2001%2F04% 2Fxmlenc%23rsa-oaep-mgf1p%22%3E%3CDigestMethod+Algorithm%3D%22http%3A%2F%2Fww w.w3.org%2F2000%2F09%2Fxmldsig%23sha1%22+%2F%3E%3C%2Fe%3AEncryptionMethod%3E% 3CKeyInfo%3E%3Co%3ASecurityTokenReference+xmlns%3Ao%3D%22http%3A%2F%2Fdocs.oa sis-open.org%2Fwss%2F2004%2F01%2Foasis-200401-wss-wssecurity-secext-1.0.xsd%2 2%3E%3Co%3AKeyIdentifier+ValueType%3D%22http%3A%2F%2Fdocs.oasis-open.org%2Fws s%2Foasis-wss-soap-message-security-1.1%23ThumbprintSHA1%22+EncodingType%3D%2 2http%3A%2F%2Fdocs.oasis-open.org%2Fwss%2F2004%2F01%2Foasis-200401-wss-soap-m essage-security-1.0%23Base64Binary%22%3E%2BPYbznDaB%2FdlhjIfqCQ458E72wA%3D%3C %2Fo%3AKeyIdentifier%3E%3C%2Fo%3ASecurityTokenReference%3E%3C%2FKeyInfo%3E%3C e%3ACipherData%3E%3Ce%3ACipherValue%3EEq9UhAJ8C9K5l4Mr3qmgX0XnyL1ChKs2PqMj0Sk 6snw%2FIRNtXqLzmgbj2Vd3vFA4Vx1hileSTyqc1kAsskqpqBc4bMHT61w1f0NxU10HDor0DlNVcV Dm%2FAfLcyLqEP%2Boh05B%2B5ntVIJzL8Ro3typF0eoSm3S6UnINOHIjHaVWyg%3D%3C%2Fe%3AC ipherValue%3E%3C%2Fe%3ACipherData%3E%3C%2Fe%3AEncryptedKey%3E%3C%2FKeyInfo%3E %3Cenc%3ACipherData%3E%3Cenc%3ACipherValue%3ErBvpZydiyDzJtzl1%2FjUFX9XAzO1mOR q0ypPLjh%2FBagXcfZeYwWD57v4Jvn1QwGajadcDASCisazswn1skdkwgmd4IUWJpPMRH7es9zY0U vnS4ccsakgDcmscq3pDYTrxbSBfhdvrzjDiHC2XCtowOveoHeB51C5N8UAbff18IxCNtkWO8y3wLH VGdvwaDOSakK%2FK%2Fv1UgXIc51%2FtYvjeFGeGbbSNxo8DTqeDnAMQ%2B4Y%2B1aUGhI%2FtbSr EyJECkDgtztcxhrumbupKO%2BogWKUTTpSt851xjOFxAMiVaPZ%2FAm8V8H3ZLsR087sX%2FJ%2Bn bRqze%2BfbdUwimN5pNoJDdMnF%2BEDLass1dPsvhL4EXzuIp5deGBaqAIoaOMEUW7ssuh1PtwkEM eqwlOzOhu%2FHtwP1qh3D02U59MtyQnJMD5UwIwO7sZJl6%2BPg6Zp9HHtKKUMnkguvFmhyXS4BFS ZVxPl18i%2B0MLO1um5dejEFd4nwGO%2FmNw6yEI8DdGVjXcYOT6JhPz9rHNh9%2F%2FOj5snJfL6 j2sg0EvIYoRs%2BhT4sdHZ95tGAiwMwT6cFOXbAQZUbYTr1ZOC6XPsfL2CFwiTM3mI%2Blco4Hc%2 F7IakIA8jwAJdtnd2mGuV67ZbY1mzibM1LUApixZj59El83ixctSQbV7iyywQ4IYN2CAq%2BCLMdl R%2BDHfgEe8O3IVaGBDUEcd2MYimEiA7Yw3NIDrC14SbLzNvU702HpVJMeYv9q6S9xIVGApSrARsw RFXyMbkMDp5WIQaJEXon7qLcsZONpdlX9bCcmaiikdpxmCeyS638te%2FhGBLmYJSQ0stf7BhA6E0 kwDRgdwsAa88bODiWHek0vDhAN4HlXFZ%2BCxp53L9Mmvy%2FCAOI%2B9OkPL2yxS22yjWQxom%2F yZuawsK98JHVShsIVmmbKvRM6xJwvHDSzuBAOlQKS%2FMHcFZn8vHZR4lMhm5nL3F%2B%2BumMKh0 vMuKk6JiCqG9OEj996bVIIkLzESU5Z5vT6I1Kr9Brdx8ckDElipdH3x54WVfaItHJTYU%2BsxIR1T 25fi9k%2FOc%2FMX7Q%2B6NSDs4nGqkn4rzqpez9BUWNZw7caVOrDeao85f%2FiDCGymtl0A3JaSZ dTKfzHLGmUfSkCAlVeisdvB6R7uBw8tR%2BZlgLIGS28wppFlnUYvSK7DnPrzId%2BGfHwLfL6WA% 2FEzBMMgppb5Vi%2BauHq%2BHxpCamlkrcUkzagbwNkGV8TfafkqUvRwJbxRwNVPI%2F%2Fxs%2Fp Lcu1dh6eKcmU00%2FNx0zNOScd9XoeEU3zsV78PgvPIBT4EDugdv4bMR6dExXvZBl%2F84b1gOMhK ZRplF8t6EAc4LCct01ht7VOVNz25NtP27ct9QPrDJc%2FoxihT4Df6NV3l4vlTnu%2B%2BzVB%2BH JAxNkiO9gx3uLUJM9XEZCDzZKihaBk2y%2F3RhsJpABVneUd%2B3sCRbQXhgKYNBHZyRAUGpMDLhL qpjoF9x%2FNvUujQ5DBLJafxxzNVshG52jRz%2BikhCNhJDDbeA5MQ8Q7QsYcKDC0DBFsewtWaA%2 FsKxl3JU6hyTotnFS%2FoS2EzbOSvn25qZuBERsZ3w%2B5WMkRzfQadyIYOSv2Df1YoljubDKy1l9 St%2FbCIBgXbVIZKYtQ%2BLyepxxFjrN7cWo2aYFnB6YLurg4USJwhXzcGcvA3%2BR5dRT6Fr37U6 OcHc%2Fz2MaZmn1cQWiDGNxHtRVxEvirBc1x47hWfSRjrKzf3orL5LzgMlYc7Iwclw2rbeWljCqOb oV3d71ez%2FvNz1pxEMi4w8yUAQL8p%2FRCZ%2BpzvsgORu4RWKWiSwbl7AN0J3jiWShyZgDmxd2O DDYffXjNiuH1mQWnDTkJX1ig88mqjhOYJEal0W6L0ErwrRIy29tOiAvXZANC8kA1HexulH0e38x8E IOaVaJtNz9mqrnmnp4GdZ38txV%2BCUeWHOZaHLF4xkdtRxMAu%2FbzQ03YmUOhgxqkTfNzV6Ymne v2nv5VsyQGJaQsNjb0M4yOe6kX2qNTwKBN2%2Bp%2Fz3f15i8KuGCgBcfP%2BP9xBizBeo7FbFtyo 2pfFhzBPmZeSOJ6kEbF1yQKHYQAT5iZ4SyTIfqqmwGxsQpWMstx3qJF8aW8WFzU1qXcC1LmgClg19 rx9NYFaQshX4f729B9Ue5MX7gTrMgwAnlXty9BsoP7nzGbr3HSXy8pR%2BimuAFW3c2NaQSbjSH5Z FOr7PZdLHsNVJzFIsaufAwr0CAEtvlPJUt7%2B%2FE5MQsMsVqMoXFmefgdxbvY1Ue6MX1wtuJYY1 PAX7MHTyRUR3RfJDO054EoflVTwNE1fmocUXUh5rtFFuzy2T%2F2Y6pLAARXzo8uslAuH67VkuXv% 2BEMc7e3ogbf5%2BROsgJirZS6qkcYpfEUwqHiQYLnSIP4bt%2BWI5j1bxs7yzcSCkNZ2rd%2FHWr A41AyGMfYzqxfGcrOaxHsds3JUcByB5Zw17W58GBC32Iusqa69BFTPagEapM0Fb5CbTqXnWTNNB5J t40BVZvLv3u5oy%2BBRaMKXZhwnbT2WUTp0Ebsn17xvte52B%2BLMlSWJn96Nl5thd%2Ft1D7PlWA sUvpJAd0UHPizCkY8VIhcXTrsSyEwer2J2I9TQTUosmssFjoP8Lx9qMfXo0eGVmneV8kVBtu4J7N1 QmWfV%2B%2FK8vGbCwW3Gm%2FEUlOO4ZbbK39y0JgNQ7fshxHr5Hdtd%2F6S%2FQkb6NPVDwn7Srh Y0diWujXz5QlIYBSN7vDfMun3yF%2BGbmMExZ8MkOthuYkgMS9qiFoJGUXGyELsJfxbzdcRE9iyJn p88L4%2BCtcO3l2JxIhMAgxOZx42RfAiDV1Gbpa4f%2F0urmWQ2VK7uZ%2FlViVrGAJ2kpH0EfwYE Mb2YYT8FFjogqEpDSJX48BLIh1TE4nMbqQVG1cksCGDc0XyGKaF5Z7Ikw493Xz0JQ0BZvaf2Kceb7 MUZlsU1DSHcQQ9X%2Bxu9RcgUePJEe9BgCMpZ5Kr6r43qyk79noBSgrsSkDhT5sg%2Fc20RHQB8OX %2BC4r3XGQFWF2m2j0xTc%2Boy14xqUmSB2qJtuWGOXDJspejDRP1GIfFnqDFdqSO3%2FkV9AC5Ee 39iJGv8I%2B5nErtQao645bCytn4B2bJah8R2fXLs8Dd4%2BC2ykxVrLxTUmJaGqd2RK%2F6t1E47 l%2B90Vp4WEzC0CFXXt9XNqdVjo2bZsXbfKQgO2zT2q2qCsgwbxVzIF5y39R%2BrkSkX16uuz3q6w n3I5RI9M8Hn3DCzzv6Ms4rYxYuiqxaIcb7DgjI2fk1bdyiiRjSxzpCHpK6CWjBD8DPQYdkqGr%2Bs oWeSvHvPLMSDxEPzwlnaxysRXzKphHUeUa2CCqcpagux2mbKkwHSXemX9I3V3AhPePp5XI5eCRiy3 D4%2BcBXOydie94Nz9DIhW749hPiVD9CioAgyqgAzFwCxEEUCXKTzu9xXX4DXg9b3CUfGzwERtY7x TGT2y%2F9i7r5Xs0lrKi9ftws4JO5v%2Be3WuAEtWv0w%2FVKCl1WwTbV9xtx%2B4RZQ3%2Fewvv% 2F0GqiiSrhiVBGuCDaQs7stwqfkF3vFgGXmmODGTIkIxvYm2fzcEfq4A6LRp5RkYyJyUTF87c56tn Qa%2Bo3xeiX5WRJybpabrRou09vyWLdlkhcUaBElGWB7iYUJ9bCltByEdNZnuDV%2FXlfnmDARKp8 RVN028czIk57wQMuizgWrM6S9Ku20noDmLgbT554UBf7FnjRWOb%2FF9OJuPpUcARBPrfuqTcOsBq tZr7AJl3zz%2F53mpyn9rgzw5gBLgkvrdbciabJOAacccTDEB5kEzCLuprC3SlVedhgY%2BMQ5%2F xgN%2Faf3TtJiBKFvb1V37BlbXXGosnPFcoH8I0XbqW5FSsxmcnpg48poJcB7j5eHq7Y%2F01RLb4 iMmzNap4%2BFg2F3LrwOI0Wk7ueIjgFd5KJ1iTda1ivGU%2Fchr9aTNpM5HiLb2fDW0pZ%2FFBJcI XxpT9eNY%2FpVj5pnTW2ubpPnBulPOQTLCi1EOxbl33wnhUIfnGiVWJdrls2j3GWgqOnrYUbP%2FX tNJqIucnMYGqPbcGIF2QRuiwD%2FiTRMvCRCmdCsYE%2FaXjOMhskX7KYC%2B9iG%2FT1wQRbfHSK WD%2Fpv450OVDsfc1Adq6FCr1LesDNTew%2FF8Z3SiHnWS76OVsNM2SB%2FhMP67iu5UWVkb3%2FQ qCN0aosOPs2QX0XBCZFmN6p3FhFnXPbAbaGz9y6KzUiUxC03U0fZcToKl4y%2Bw0P4IvxpjVt4t8b 84Q9hiBxd5xu1%2BRE973a%2FyIWO%2Fit1MdUSmxWakxWuGxDnQxwkNCN7ekL%2FQ%2B6FItm86b w9cc%2FMiI7q2fK7y7YAzM3tmamhF1%2FWJNj1lH0vh%2BhNehJlLlb4Z%2F9ZtxMWV4LVTyrFaF1 zyCEqcKUTk0jc%2FXDwyKZc%2FSV9EOoPk2fVnmzs3WkA74GB%2BWtjdvQjSmnJYtPkMNsikHw%2B RyB1hTkYbn3iQ6BUiJ0v97j7MVZHxCa1KS3t2gx8H7ts6Tfy5il89xVUdiZwfj0w06g199qlAqUMZ EWxh0%3D%3C%2Fenc%3ACipherValue%3E%3C%2Fenc%3ACipherData%3E%3C%2Fenc%3AEncryp tedData%3E
An un-escaped and reformatted version of the preceding xmlToken value, with the encrypted value elided, is as follows:
Appendix B – Detecting InfoCard Browser Support by Internet Explorer
Script code can detect browser support for InfoCard within Internet Explorer by testing the userAgent string to determine whether the browser version is greater than or equal to MSIE 7.0. A second issue with Internet Explorer 7 is that the InfoCard support might not be installed (because WinFX is not installed on the machine). This can be detected by using the "isInstalled" property on the InfoCard OBJECT from scripting code.
This appendix describes the known differences between the preceding specifications and the early implementation included in the build of Windows Vista distributed to MIX 2006 attendees.
C.1. Self-Issued Card Issuer Syntax
The syntax for indicating self-issued cards in the MIX 2006 build is "http://schemas.microsoft.com/ws/2005/05/identity/issuer/self"—not the URN syntax "urn:schemas-microsoft-com:ws:2005:05:identity:issuer:self" documented previously.
Windows Communication Foundation Architecture Overview
Microsoft Corporation
March 2006
Summary: Get a high-level view of the Windows Communication Foundation (WCF) architecture and its key concepts. Code examples demonstrate WCF contracts, endpoints, and behaviors. (17 printed pages)
Contents
Introduction
WCF Fundamentals
Code Examples
Summary
This document provides a high-level view of the Windows Communication Foundation (WCF) architecture. It is intended to explain key concepts in WCF and how they fit together. There are a few code examples to further illustrate the concepts, but code is not the emphasis of this document.
The rest of this document is organized in two main sections:
WCF Fundamentals: Covers key concepts in WCF, terms, and architectural components.
Code Examples: Provides a few short code examples intended to illustrate and reify the concepts covered in WCF Fundamentals.
A WCF Service is a program that exposes a collection of Endpoints. Each Endpoint is a portal for communicating with the world.
A Client is a program that exchanges messages with one or more Endpoints. A Client may also expose an Endpoint to receive Messages from a Service in a duplex message exchange pattern.
The following sections describe these fundamentals in more detail.
Endpoints
A Service Endpoint has an Address, a Binding, and a Contract.
The Endpoint's Address is a network address where the Endpoint resides. The EndpointAddress class represents a WCF Endpoint Address.
The Endpoint's Binding specifies how the Endpoint communicates with the world including things like transport protocol (e.g., TCP, HTTP), encoding (e.g., text, binary), and security requirements (e.g., SSL, SOAP message security). The Binding class represents a WCF Binding.
The Endpoint's Contract specifies what the Endpoint communicates and is essentially a collection of messages organized in operations that have basic Message Exchange Patterns (MEPs) such as one-way, duplex, and request/reply. The ContractDescription class represents a WCF Contract.
The ServiceEndpoint class represents an Endpoint and has an EndpointAddress, a Binding, and a ContractDescription corresponding to the Endpoint's Address, Binding, and Contract, respectively (see Figure 1).
Figure 1. Each Service's Endpoint contains an EndpointAddress, a Binding and a Contract represented by ContractDescription.
EndpointAddress
An EndpointAddress is basically a URI, an Identity, and a collection of optional headers as shown in Figure 2.
An Endpoint's security identity is normally its URI; however, in advanced scenarios the identity can be explicitly set independent of the URI using the Identity address property.
The optional headers are used to provide additional addressing information beyond the Endpoint's URI. For example, address headers are useful for differentiating between multiple Endpoints that share the same address URI.
Figure 2. EndpointAddress contains a URI and AddressProperties contains an Identity and a collection of AddressHeaders.
Bindings
A Binding has a name, a namespace, and a collection of composable binding elements (Figure 3). The Binding's name and namespace uniquely identify it in the service's metadata. Each binding element describes an aspect of how the Endpoint communicates with the world.
Figure 3. Binding class and its members
For example, Figure 4 shows a binding element collection containing three binding elements. The presence of each binding element describes part of the how of communicating with the Endpoint. The TcpTransportBindingElement indicates that the Endpoint will communicate with the world using TCP as the transport protocol. ReliableSessionBindingElement indicates that the Endpoint uses reliable messaging to provide message delivery assurances. SecurityBindingElement indicates that the Endpoint uses SOAP message security. Each binding element usually has properties that further describe the specifics of the how of communicating with the Endpoint. For example, the ReliableSessionBindingElement has an Assurances property that specifies the required message delivery assurances, such as none, at least once, at most once, or exactly once.
Figure 4. An example Binding with three binding elements
The order and types of binding elements in Bindings are significant: The collection of binding elements is used to build a communications stack ordered according to the order of binding elements in the binding elements collection. The last binding element to be added to the collection corresponds to the bottom component of the communications stack, while the first one corresponds to the top component. Incoming messages flow through the stack from the bottom upwards, while outgoing messages flow from the top downwards. Therefore the order of binding elements in the collection directly affects the order in which communications stack components process messages. Note that WCF provides a set of pre-defined bindings that can be used in the majority of scenarios instead of defining custom bindings.
Contracts
A WCF Contract is a collection of Operations that specifies what the Endpoint communicates to the outside world. Each operation is a simple message exchange, for example one-way or request/reply message exchange.
The ContractDescription class is used to describe WCF Contracts and their operations. Within a ContractDescription, each Contract operation has a corresponding OperationDescription that describes aspects of the operation such as whether the operation is one-way or request/reply. Each OperationDescription also describes the messages that make up the operation using a collection of MessageDescriptions.
A ContractDescription is usually created from an interface or class that defines the Contract using the WCF programming model. This type is annotated with ServiceContractAttribute and its methods that correspond to Endpoint Operations are annotated with OperationContractAttribute. You can also build a ContractDescription by hand without starting with a CLR type annotated with attributes.
A duplex Contract defines two logical sets of operations: A set that the Service exposes for the Client to call and a set that the Client exposes for the Service to call. The programming model for defining a duplex Contract is to split each set in a separate type (each type must be a class or an interface) and annotate the contract that represents the service's operations with ServiceContractAttribute, referencing the contract that defines the client (or callback) operations. In addition, ContractDescription contains a reference to each of the types thereby grouping them into one duplex Contract.
Similar to Bindings, each Contract has a Name and Namespace that uniquely identify it in the Service's metadata.
Each Contract also has a collection of ContractBehaviors that are modules that modify or extend the contract's behavior. The next section covers behaviors in more detail.
Figure 5. ContractDescription class describes a WCF contract
Behaviors
Behaviors are types that modify or extend Service or Client functionality. For example, the metadata behavior that ServiceMetadataBehavior implemented controls whether the Service publishes metadata. Similarly, the security behavior controls impersonation and authorization, while the transactions behavior controls enlisting in and auto-completing transactions.
Behaviors also participate in the process of building the channel and can modify that channel based on user-specified settings and/or other aspects of the Service or Channel.
A Service Behavior is a type that implements IServiceBehavior and applies to Services. Similarly, a Channel Behavior is a type that implements IChannelBehavior and applies to Client Channels.
Service and Channel Descriptions
The ServiceDescription class is an in-memory structure that describes a WCF Service including the Endpoints exposed by the Service, the Behaviors applied to the Service, and the type (a class) that implements the Service (see Figure 6). ServiceDescription is used to create metadata, code/config, and channels.
You can build this ServiceDescription object by hand. You can also create it from a type annotated with certain WCF attributes, which is the more common scenario. The code for this type can be written by hand or generated from a WSDL document using a WCF tool called svcutil.exe.
Although ServiceDescription objects can be created and populated explicitly, they are often created behind the scenes as part of running the Service.
Figure 6. ServiceDescription object model
Similarly on the client side, a ChannelDescription describes a WCF Client's Channel to a specific Endpoint (Figure 7). The ChannelDescription class has a collection of IchannelBehaviors, which are Behaviors applied to the Channel. It also has a ServiceEndpoint that describes the Endpoint with which the Channel will communicate.
Note that, unlike ServiceDescription, ChannelDescription contains only one ServiceEndpoint that represents the target Endpoint with which the Channel will communicate.
Figure 7. ChannelDescription object model
WCF Runtime
The WCF Runtime is the set of objects responsible for sending and receiving messages. For example, things like formatting messages, applying security, and transmitting and receiving messages using various transport protocols, as well as dispatching received messages to the appropriate operation, all fall within the WCF runtime. The following sections explain the key concepts of the WCF runtime.
Message
The WCF Message is the unit of data exchange between a Client and an Endpoint. A Message is essentially an in-memory representation of a SOAP message InfoSet. Note that Message is not tied to text XML. Rather, depending on which encoding mechanism is used, a Message can be serialized using the WCF binary format, text XML, or any other custom format.
Channels
Channels are the core abstraction for sending Messages to and receiving Messages from an Endpoint. Broadly speaking, there are two categories of Channels: Transport Channels handle sending or receiving opaque octet streams using some form of transport protocol such as TCP, UDP, or MSMQ. Protocol Channels, on the other hand, implement a SOAP-based protocol by processing and possibly modifying messages. For example, the security Channel adds and processes SOAP message headers and may modify the body of the message by encrypting it. Channels are composable such that a Channel may be layered on top of another Channel that is in turn layered on top of a third Channel.
EndpointListener
An EndpointListener is the runtime equivalent of a ServiceEndpoint. The EndpointAddress, Contract, and Binding of ServiceEndpoint (representing where, what and how), correspond to the EndpointListener's listening address, message filtering and dispatch, and channel stack, respectively. The EndpointListener contains the Channel stack that is responsible for sending and receiving messages.
ServiceHost and ChannelFactory
The WCF Service runtime is usually created behind the scenes by calling ServiceHost.Open. ServiceHost (Figure 6) drives the creation of a ServiceDescription from on the Service type and populates the ServiceDescription's ServiceEndpoint collection with Endpoints defined in config or code, or both. ServiceHost then uses the ServiceDescription to create the channel stack in the form of an EndpointListener object for each ServiceEndpoint in the ServiceDescription.
Figure 8. ServiceHost object model
Similarly, on the client side, the Client runtime is created by a ChannelFactory, which is the Client's equivalent of ServiceHost.
ChannelFactory drives the creation of a ChannelDescription based on a Contract type, a Binding, and an EndpointAddress. It then uses this ChannelDescription to create the Client's channel stack.
Unlike the Service runtime, the Client runtime does not contain EndpointListeners because a Client always initiates connection to the Service, so there is no need to "listen" for incoming connections.
This section provides code examples that show how Services and Clients are built. These examples are intended to reify the above concepts and not to teach WCF programming.
Defining and Implementing a Contract
As mentioned above, the easiest way to define a contract is creating an interface or a class and annotating it with ServiceContractAttribute, allowing the system to easily create from it a ContractDescription.
When using interfaces or classes to define contracts, each interface or class method that is a member of the contract must be annotated with OperationContractAttribute. For example:
using System.ServiceModel; //a WCF contract defined using an interface [ServiceContract] public interface IMath { [OperationContract] int Add(int x, int y); }
Implementing the contract in this case is simply a matter of creating a class that implements IMath. That class becomes the WCF Service class. For example:
//the service class implements the interface public class MathService : IMath { public int Add(int x, int y) { return x + y; } }
Defining Endpoints and Starting the Service
Endpoints can be defined in code or in config. In the example below, the DefineEndpointImperatively method shows the easiest way to define Endpoints in code and start the service.
DefineEndpointInConfig method shows the equivalent endpoint defined in config (config example follows the code below).
public class WCFServiceApp { public void DefineEndpointImperatively() { //create a service host for MathService ServiceHost sh = new ServiceHost(typeof(MathService)); //use the AddEndpoint helper method to //create the ServiceEndpoint and add it //to the ServiceDescription sh.AddServiceEndpoint( typeof(IMath), //contract type new WSHttpBinding(), //one of the built-in bindings "http://localhost/MathService/Ep1"); //the endpoint's address //create and open the service runtime sh.Open(); } public void DefineEndpointInConfig() { //create a service host for MathService ServiceHost sh = new ServiceHost (typeof(MathService)); //create and open the service runtime sh.Open(); } }
Sending Messages to an Endpoint
The code below shows two ways to send a message to the IMath endpoint. SendMessageToEndpoint hides the Channel creation, which happens behind the scenes while the SendMessageToEndpointUsingChannel example does it explicitly.
The first example in SendMessageToEndpoint uses a tool named svcutil.exe and the Service's metadata to generate a Contract (IMath in this example), a proxy class (MathProxy in this example) that implements the Contract, and associated config (not shown here). Again, the Contract defined by IMath specifies the what (i.e., the operations that can be performed), while the generated config contains a Binding (the how) and an address (the where).
Using this proxy class is simply a matter of instantiating it and calling the Add method. Behind the scenes, the proxy class will create a Channel and use that to communicate with the Endpoint.
The second example in SendMessageToEndpointsUsingChannel below shows communicating with an Endpoint using ChannelFactory directly. In this example, instead of using a proxy class and config, a Channel is created directly using ChannelFactory
using System.ServiceModel; //this contract is generated by svcutil.exe //from the service's metadata public interface IMath { [OperationContract] public int Add(int x, int y) { return x + y; } } //this class is generated by svcutil.exe //from the service's metadata //generated config is not shown here public class MathProxy : IMath { ... } public class WCFClientApp { public void SendMessageToEndpoint() { //this uses a proxy class that was //created by svcutil.exe from the service's metadata MathProxy proxy = new MathProxy(); int result = proxy.Add(35, 7); } public void SendMessageToEndpointUsingChannel() { //this uses ChannelFactory to create the channel //you must specify the address, the binding and //the contract type (IMath) ChannelFactory
Defining a Custom Behavior
Defining a custom Behavior is a matter of implementing IServiceBehavior (or IChannelBehavior for client-side behaviors). The code below shows an example behavior that implements IServiceBehavior. In IServiceBehavior.ApplyBehavior, the code inspects the ServiceDescription and writes out the Address, Binding, and Contract of each ServiceEndpoint, as well as the name of each Behavior in the ServiceDescription.
This particular behavior is also an attribute (inherits from System.Attribute), making it possible to apply declaratively as will be shown below. However, behaviors are not required to be attributes.
[AttributeUsageAttribute( AttributeTargets.Class, AllowMultiple=false, Inherited=false)] public class InspectorBehavior : System.Attribute, System.ServiceModel.IServiceBehavior { public void ApplyBehavior( ServiceDescription description, Collection
Applying a Custom Behavior
All behaviors can be applied imperatively by adding an instance of the behavior to the ServiceDescription (or the ChannelDescription on the client side). For example, to apply the InspectorBehavior imperatively you would write:
ServiceHost sh = new ServiceHost(typeof(MathService)); sh.AddServiceEndpoint( typeof(IMath), new WSHttpBinding(), "http://localhost/MathService/Ep1"); //Add the behavior imperatively InspectorBehavior behavior = new InspectorBehavior(); sh.Description.Behaviors.Add(behavior); sh.Open();
Additionally, behaviors that inherit from System.Attribute may be applied declaratively to the service. For example, because InspectorBehavior inherits from System.Attribute, it can be applied declaratively like this:
[InspectorBehavior] public class MathService : IMath { public int Add(int x, int y) { return x + y; } }
WCF Services expose a collection of Endpoints where each Endpoint is a portal for communicating with the world. Each Endpoint has an Address, a Binding, and a Contract (ABC). The Address is where the Endpoint resides, the Binding is how the Endpoint communicates, and the Contract is what the Endpoint communicates.
On the Service, a ServiceDescription holds the collection of ServiceEndpoints each describing an Endpoint that the Service exposes. From this description, ServiceHost creates a runtime that contains an EndpointListener for each ServiceEndpoint in the ServiceDescription. The Endpoint's address, Binding, and Contract (representing the where, what, and how) correspond to the EndpointListener's listening address, message filtering and dispatch, and channel stack, respectively.
Similarly, on the Client, a ChannelDescription holds the one ServiceEndpoint with which the Client communicates. From this ChannelDescription, ChannelFactory creates the channel stack that can communicate with the Service's Endpoint.
No comments:
Post a Comment