Computer Security Alert has done a nice frontpage feature on “What InfoCard is and isn't” in its May 2006 issue.  The Alert is normally only available to members, but Robert Richardson has given me permission to let you download and reprint the PDF version, complete with sidebars – or you can read the main part of the story here: 

There’s little doubt that the Microsoft marketing engine will get itself geared up to tell the public at large what InfoCard “is,” but in the meanwhile, getting a handle on the next major security-related software introduction is remarkably difficult. It’s a slippery topic.

The place to start, however, is with the diagram below from an overview of the “Identity Metaverse” by Microsoft’s identity guru Kim Cameron.

The box at the very bottom of the diagram is you, the subject. If you go to a Web site or an application that requires you to establish that you’re authorized to use its services (where in the past you’d have been challenged for a username and password), you’ll instead be shown an interface where you can choose from what appear to be traditional “ID cards.” Simply put, that interface is InfoCard. That’s it.

Or, at least, that’s how to draw a line around it that differentiates it from everything else. Obviously, there’s more to it than that. For one thing, it’s running in a different security context than the rest of your applications on whatever operating system you happen to be running. It’s supposed to be completely cordoned off in terms of memory access and the like. Other applications (and, say, viruses that have installed themselves unbeknownst to you) can’t see memory that’s being used by the InfoCard interface.

Cameron does note that “if you get a rootkit, you’re in trouble. But Vista makes it much less likely that you’ll get one, because you almost always run in your own context (e.g. not at ‘root’ privilege). A virus caught in your user context cannot see your InfoCard screen or memory.” There are other security gains as well, Cameron notes: “InfoCard protects against keyloggers because typing of shared secrets becomes obsolete. And social engineering attacks are mitigated because Web sites no longer control the user experience. Finally, sensitive information like a credit card number is never stored on the PC, or visible to a virus running there.”

InfoCard presents your various credential possibilities to you in the form of “cards,” so not too surprisingly there’s also a mechanism for generating your own self-signed InfoCard and then issuing encrypted tokens when the card is used (in other words, there’s a tool for making yourself into an ID Provider, which Microsoft’s documents often refer to as an IP, but which we’ll call an IDP in the hopes of not creating confusion around the already overloaded “IP” acronym)—this too is part of InfoCard.

Finally, there’s a strong sense that this is what Microsoft thinks every operating system’s authentication interface should look like: an isolated page where you pick from your various ID cards. This really isn’t about Redmond wanting everything to look like a version of Windows—in fact InfoCard is trying to look a bit different than the rest of the Windows Vista operating system. Rather, it’s supposed to look different from everything else altogether, so that you the user realize you’ve entered one of those transitional moments where you may be handing over some of your personal information.

But other than these pieces, everything else in the identity management universe is something other than InfoCard. The part where the InfoCard interface talks across the network and exchanges information isn’t InfoCard, but the WS-Trust standard. The server that creates a token that attests that you’ve got authorization to use a certain service isn’t InfoCard either, but something like a certificate authority (CA) or perhaps something a little more old-fashioned like a Kerberos server. The primary thing that InfoCard does is allow you to choose which of several identities you want to use in a given situation where you’ve been challenged for ID.

The “cards” represent your various identities. The “cards,” it’s vital to note, don’t contain information about you, per se. You won’t find your name and address or your social security number stored in one of your cards. Instead, enough metadata is stored that when the appropriate moment arrives, InfoCard can communicate to the IDP to say who you’re supposed to be. The IDP will confirm this by challenging you in one way or another (doesn’t matter to InfoCard what that way is—it’s completely agnostic in this important respect—but it may very well matter to the Web site that is requesting the information).

So the IDP plays an important role in this, but as we mentioned above, may in some cases actually be you, as self-provider of a card (this is the situation you’ll find yourself in at a Web site that asks for a login name or e-mail address but otherwise doesn’t care who you are). The other player (besides you, the user of all this splendor) is the Web site that wants to know who you are in the first place. In today’s pre-InfoCard world, this site would normally challenge you for a username and password and check up on your assertion that you are in fact you on its own steam. With InfoCard, this site becomes a Relying Party (RP) and actually gets its assurance that you are you by way of the IDP.

There are early releases of InfoCard in the hands of developers, and blog reports so far make it clear that it’s pretty fragile just yet—it takes just the right combination of operating system release, Explorer browser preview and InfoCard code to make the thing work. It does work if you get it all right, but would seem that there are only a handful of non-Microsoft people in the world who’ve managed to InfoCard their way into a site (such as Cameron’s identityblog.com). As Cameron puts it, “it’s new, it’s evolving quickly, and it hasn’t stabilized yet.”

What happens bat game time

So with the various pieces in place, we can walk through the mechanics of an InfoCard transaction. We’ll talk here about going to a Web site, but clearly there are other use cases, such as internal applications that directly invoke the InfoCard interface to authenticate the user with an intranet application, perhaps built on a service-oriented architecture.

Arriving at the site

I’m an InfoCard-enabled user and I arrive at my bank, which has now implemented support for this interface. My arrival causes a page to be sent to my browser, as would always be the case. Indeed, the page my still contain all the usual paraphernalia for a traditional login.

Triggering the InfoCard process

What’s also in the HTML page that is sent to my browser, however, is an HTML OBJECT tag. The browser, which also has to be up-to-date, recognizes that this object has a “type” parameter that identifies it as an InfoCard request. It therefore triggers the InfoCard dynamic link library (DLL) module. The stage is set and the screen dims (I’m not kidding, it really does dim—another way of differentiating this process from normal computing activities as well as a way of making the process harder to spoof).

InfoCard gears up

Among the parameters passed to the DLL from the OBJECT tag are the claims about the user that need to be proven. These might be things like the user’s name, but on the other hand, the Web site may only need to know some anonymous piece of information, such as that the user is older than 21. Generally, the site should only have requested what it needs to know. The DLL compares the claim requests to the user’s InfoCards to see what claims can be met by which cards, and then displays those that can meet the request (others are visible but grayed out).

The user picks a card and is challenged

This is an important moment if you think about it. The user may use any card that meets the requirements of the Web site’s request. A user might maintain different personas with different sets of proofs for different contexts. With the selection made, the DLL contacts the IDP via WS-Trust. The IDP then does whatever it needs to do to authenticate the user. Possibly it asks for a username and password; possibly a one-time password must be used or some biometric proof supplied.

A secure token is issued and reviewed

Assuming the user successfully authenticates with the IDP (not the Web site, which is the RP in this scenario, it’s important to keep in mind), the IDP places the appropriate claims into an XML document and then uses the RP’s public key to encrypt them. This is sent not to the RP but back to the user’s InfoCard process, which displays the claims that are about to be sent so that the user can review them.

The approved claims are forwarded

If the user is comfortable with passing the information in the claims along to the Web site, they press a Submit button and the encrypted token is forwarded to the RP, which will now grant access to the user. The Web object in more detail Jumping back a step, notice that the mechanism for invoking the InfoCard interface really is pretty much as simple as it sounds. A snippet of HTML code is added to the rest of the material in the Web page, as in this example from Andy Harjanto’s Infocard Weblog.

Notice that this example shows a Web site that requires a SAML assertion for authentication. The RP may not get to dictate that I’ll provide my credentials or that I’ll provide a specific credential if there are several that meet the need, but it does get to dictate what kind of credential must be provided if it’s to be considered sufficient. Specifically, the RP can make requests concerning:  

  • The issuer;
  • The type of token that will be returned;
  • What claims must be vouched for by the token;
  • Requirements regarding the kind of proof used (symmetric, public key, etc), the size of the key used in authentication and other such details as might be required for high-security scenarios.

It’s worth underscoring that the RP only receives proofs of the specific claims it requests, not access to any kind of full profile of data about the individual. The user (or, at any rate, not the RP) gets to choose where data used for this particular user’s authentications are stored. This ability to separate authenticated claims from specific identities is potentially a huge gain for Internet privacy. This would be true even in relatively small ways: one can imagine being able to post comments at a blog site anonymously, but only after proving that one had the reputation (from actions at other sites) of never posting spam. Anonymity is preserved while the social good of keeping out bad actors is upheld.

On the other hand, we shouldn’t overstate how much may be gained in the real world—RP’s may still very well want a full complement of information, including name, address and credit card numbers, before selling you their products. And once they’ve got the information, they may well decide to store it, even insecurely.

As an aside, Microsoft has taken the interesting step of essentially not providing any kind of normal application/programming access to InfoCards. They are stored in their own little world; there is no API to access them. The effect of this is that cards don’t get deleted or modified or added without the user’s direct involvement, because these steps must be taken through the InfoCard interface.

For the InfoCard interface to be invoked, of course, there has to be some software resident on the user’s system. At present, it gets there by way of a purpose-built software file (a DLL file) that has to be expressly loaded along with Internet Explorer 7. These things will be part and parcel of Microsoft Vista, when it’s released next year, but users who stick with XP will have to download these pieces in order to use InfoCard.

Given that migration to Vista is bound to take place at a measured—perhaps even downright reluctant, depending on the vicissitudes of the market—pace, one question is whether the requirement for additional specialized software will make Web site developers reluctant to get involved. Obviously, they can use pre-existing login routines for users who don’t have InfoCard capability on their machines, but having two systems will just complicate life. Cameron says it’s not all that much more complicated, however: “We’ve taken this into account so the changes to a Web site are absolutely minimal.”

Organizations may or may not decide that dealing with InfoCard is worth the trouble—it will have to move beyond its current proof-of-concept stage before anyone can decide—but one thing organizations don’t have to do, should they opt to use InfoCard, is run Windows servers. From the “Microsoft’s Vision for an Identity Metasystem” white paper:

    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.

Just to prove that this is so, Cameron, who’s in charge of the InfoCard project, moved his identityblog.com over to non-Microsoft software (completely so: he’s running the classic, open-source LAMP stack). The blog is running on WordPress (also open source) and he’s written his own PHP scripts to handle the InfoCard login process. By Cameron’s own admission, it’s still a bit buggy and it lacks a certain degree of polish:

    Some of the user experience is still pretty “basic”. Like what happens if you click on InfoCard login and don’t have InfoCards installed. When I have some time I’ll make that take you to a page that tells you what InfoCards are, how they work, how to install them, and that sort of thing. But for now, the behavior should appeal to lovers of cryptic error messages.

So at least in theory, the Linux and Macintosh systems of the world could implement compatible identity selectors, RPs and IDPs that were all compatible with InfoCard. And, really, it’s only that it’s Microsoft doing the developing that makes it seem like InfoCard is the driving force here. In point of fact, InfoCard’s mission is to work with WS-Trust, an open standard (we could quibble about how open it is, but at least there’s nothing preventing anyone from using it). So the open standards for identity, such as WS-Trust, are really the driving force behind InfoCard. In any case, identity management seems to be entering something of a 2.0 phase, and there’s no question that InfoCard will play a significant role in whatever that turns out to be. — R.R.


This sounds like the best thing since sliced bread:

Ever feel like Chicken Little? Wonder if letter grades, color codes, and/or duct tape are even a tiny bit useful? Cringe at the subjectivity applied to security in every manner?

If so, MetriCon 1.0 may be your antidote to change security from an artistic “matter of opinion” into an objective, quantifiable science. The time for adjectives and adverbs has gone; the time for numbers has come.

MetriCon 1.0 is intended as a forum for lively, practical discussion in the area of security metrics. It is a forum for quantifiable approaches and results to problems afflicting information security today, with a bias towards practical, specific implementations. Topics and presentations will be selected for their potential to stimulate discussion in the Workshop.

Workshop Format

MetriCon 1.0 will be a one-day event, Tuesday, August 1, 2006, co-located with the 15th USENIX Security Symposium in Vancouver, B.C., Canada. Beginning first thing in the morning, with meals taken in the meeting room, and extending into the evening.

Attendance will be by invitation and limited to 50 participants. All participants will be expected to “come with opinions” and be willing to address the group in some fashion, formally or not. Preference giventothe authors of position papers/presentations who have actual work in progress.

Each presenter will have 10-15 minutes to present his or her idea, followed by 15-20 minutes of discussion with the workshop participants. Panels may be convened to present different approaches to related topics, and will be steered by what sorts of proposals come in in response to this Call.

Goals and Topics

The goal of the workshop is to stimulate discussion of and thinking about security metrics and to do so in ways that lead to realistic, early results of lasting value. Potential attendees are invited to submit position papers to be shared with all. Such position papers are expected to address security metrics in one of the following categories:

– Benchmarking
– Empirical Studies
– Metrics Definitions
– Financial Planning
– Security/Risk Modeling
– Visualization

Practical implementations, real world case studies, and detailed models will be preferred over broader models or general ideas.

How to Participate

Submit a short position paper or description of work done/ongoing. Your submission must be no longer than five(5) paragraphs or presentation slides. Author names and affiliations should appear first in/on the submission. Submissions may be in PDF, PowerPoint, HTML, or plaintext email and must be submitted to MetriCon AT securitymetrics.org.

Presenters will be notified of acceptance by June 15, 2006 and expected to provide materials for distribution by July 15, 2006. All slides and position papers will be made available to participants at the workshop. No formal proceedings are intended.


MetriCon 1.0 will be co-located with the 15th USENIX Security Symposium (Security ’06).

$200 all-inclusive ofmeeting space, materials preparation, and meals for the day.

Important Dates

Requests to participate: by May 15, 2006
Notification of acceptance: by June 15, 2006
Materials for distribution: by July 15, 2006

Workship Organizers

Andrew Jaquith, Yankee Group, Chair
Adam Shostack, emergentchaos.org
Gunnar Peterson, Arctec Group
Elizabeth Nichols, ClearPoint Metrics
Pete Lindstrom, Spire Security
Dan Geer,Verdasys

Funny, I was just at a conference today arguing that the truth is in the quantitative studies.  There are some wonderful people putting this together – it seems full of promise.


Identity people should think about attending the grass roots identity conference called Internet Identity Workshop 2006 organized by Kaliya Hamlin, Doc Searls and Phil Windley.  The other conferences in this series have been been great informal venues for exchanging ideas and meeting people, and this one is sure to to be as well.  I'll be there, as will Mike Jones.

If you don't know Kaliya, she is the mild-mannered unconference organizer who, whenever identity is threatened, emerges as the intrepid Identity Woman.  Doc is the editor of Linux Journal and author of the Cluetrain Manifesto who has revolutionized everyone's understanding of what a market is and what the Blogosphere can be – he got me to start my blog.  Phil Windley is a professor specializing in identity, with deep experience as the CIO of the state of Utah, giving him a unique perspective.  He's also the author of Digital Identity.

Here's what it's all about:

The Internet Identity Workshop focuses on user-centric identity and identity in the large. Providing identity services between people, websites, and organizations that don't necessarily have a formalized relationship is a different problem than providing authentication and authorization services within a single organization.

The goal of the Internet Identity Workshop is to support the continued development of several open efforts in the user-centric identity community. These include the following:

  • Technical systems and proposal like Yadis (LID, OpenID, i-Names), SXIP, Identity metasystem, InfoCards, and the Higgins Project
  • Legal and social movements and issues like Identity Commons, identity rights agreements, and service providers reputation.
  • Use cases for emerging markets such as user generated video (e.g. dabble.com), innovative economic networks (e.g. interraproject.org), attention brokering and lead generation (e.g. root.net), consumer preferences (e.g. permission based marketing), and civil society networking

The workshop will take place May 2 and 3, 2006 at the Computer History Museum. We will also have a 1/2 day on the first of May for newbies who want to get oriented to the protocols and issues before diving into the community. If you are new to the discussion, we encourage your attendance on May 1st because of the open format we'll be using to organize the conference.

Format and Process

At the last identity workshop we did open space for a day. It was so successful and energizing that we will be using this format for both days. If you have a presentation that you would like to make or a topic that you know needs discussion in the community you can propose it here on the wiki. We will make the schedule when we are face to face at 9AM on May 2nd. We do this in part because the ‘field’ is moving so rapidly that we your organizing team are in no position to ‘know’ what needs to be talked about. We do know great people who will be there and it is the attendees who have a passion to learn and contribute to the event that will make it.

Part of the reason for moving to the Computer History Museum is to have better space for running this kind of effort with an expanding community. We expect a large and energized community to attend and are counting on plenty of participation. Don't be put off by that, however, if you're just getting into this. Come and learn. You won't be disappointed.


We are committed to keeping this conference open and accessible. Having a venue that will support our doubling in size also means that it costs a bit more. We decided to have a tiered cost structure to support accessibility as well as inviting those who are more able to pay to contribute. If you want to come we want you there. If cost is an issue please contact us and we can discuss how to make it work.

  • Students – $75
  • Independents – $150
  • Corporate – $250

The fees are used to cover the cost of the venue, organization, snacks and lunch both days. We encourage you to pre-register since we will limit attendance at the event to 200 people. The IIW workshop in October sold out and we expect strong interest in this one as well.


Our goal is to keep the workshop vendor neutral, but we will be accepting limited sponsorships for the following:

  • Morning Break, May 2, and 3 ($800 each)
  • Afternoon Break, May 1, 2, and 3 ($800 each)
  • Lunch on May 2 and 3 ($2400 each)
  • Conference Dinner, May 2 ($4000)

If you or your company would like to sponsor one of these workshop activities, or have ideas about other activities contact me. You will not get any extra speaking time for sponsoring but you will get thank-yous and community ‘love.’


The Brigham Young University Enterprise Computing Laboratory is providing logistical support and backing for this workshop.

Registration is here. The wiki is here. And pick up the hotel information and map



Here is a must-watch MSNBC interview with Blakely Smith, a bride who was duped while buying a wedding dress during her first eBay shopping experience. 

Her attacker convinced her to use Western Union due to “a security breach at Paypal”.  In a bizarre twist, Ebay's PR spokesman took this as license to say that Smith “let her greed get the best of her” in falling for the scam. “What she did is the online equivalent of walking out of a store and buying something in a back alley.”

Watching the MSNBC interview with the very likeable and reasonable Ms. Smith, it's hard to believe that eBay has really adopted this PR strategy.  I don't auction, so I have no first-hand experience with which to judge the situation, but I came away from this convinced that Blakely Smith deserves better technology.  If we don't come up with it, sales of wedding dresses on the Internet are going to falter.

Here is the story as told by the South Bend Tribune:

PHILADELPHIA — Blakely Smith dreamed of getting married in a Monique Lhuillier wedding gown — the kind she'd always loved when she saw them on pop stars such as Pink in People magazine. She's out $2,400 to an eBay scammer and thinks maybe she should be married in a courthouse.

She called to tell her tale of wedding-dress-lust, clouded judgment, and wedding-dream-lost. Yes, it's a bit embarrassing. But she hopes to help others avoid the pain she feels.

EBay says Smith made at least two textbook mistakes en route to being scammed. What may make her case most remarkable, though, is how it ended — in a bizarre e-mail exchange with her anonymous scammer.

It came after Smith had paid her money and got nothing back. She e-mailed “Kate,” the supposed seller, told of a coworker's eBay horror story, and outlined why she was was suspicious. “I am sorry to be this way, but in today's world, it is not totally off base to be wary,” she said.

To which “Kate” replied:

“That's true, indeed. I just scammed you, sorry for that, it's nothing personal. … It's what I do, and it pays well.”

How did Smith get into this mess? The way any confidence-game victim does — by letting an overabundance of trust overwhelm ordinary caution.

Smith, 29, works in advertising at Philadelphia Style magazine. Her fiancé, Michael Minton, teaches high school science. She turned to eBay because, dreams or not, a new Monique Lhuillier gown was out of reach.

She was the top bidder for the gown, which sold new for $5,500 and features Alencon lace, “decadent silk chartreuse lining.” But she fell short of the reserve, the seller's hidden minimum price.

She couldn't tell how short. Neither, presumably, could the scammer. But the fake “Kate” knew when to pounce.

Soon after the auction closed, Smith got a message via her eBay account. The seller had decided to accept her final bid, it said, and directed her to reply to an outside e-mail address.

Looking back, Smith realizes that was a red flag — one that was even warned against in a “Marketplace Safety Tip” on the same screen: “If you receive a response inviting you to transact outside of eBay, you should decline — such transactions may be unsafe and are against eBay policy.”

Another red flag was the wire-transfer “Kate” requested, saying her account on PayPal, eBay's own payment system, had been frozen because of — what else? — a scammer's intrusion.

But Smith, new to eBay, didn't notice either warning until the deed was done. Last week, after a brief e-mail exchange with “Kate,” she sent her money — more than $2,400, including fees — to a Western Union office in Mount Clemens, Mich.

Police there are investigating and may catch the scammer or a confederate. But there are broader lessons in Smith's story for anyone new to eBay.

One is that eBay says it can only warn against scams, not prevent them. “Ultimately, this is between the buyer and seller. This is just a venue,” spokesman Hani Durzy told me.

Don't expect much sympathy, either. Durzy even suggested that Smith “let her greed get the best of her” in falling for the scam. “What she did is the online equivalent of walking out of a store and buying something in a back alley,” he says.

For that matter, eBay doesn't even count such “back alley” crimes as frauds when it boasts that only a small fraction of total listings — just one-hundredth of 1 percent — “lead to a confirmed case of fraud.”

Sure, it's a small fraction. But eBay reported 1.9 billion listings in 2005, so it translates into 190,000 confirmed frauds in one year. (To report an online scam, go to www.ic3.gov/complaint.)

Smith is understandably angered by the suggestion she fell victim to her own greed. She turned to eBay for a used wedding dress, and lost eight months of savings. The truth is, eBay can be a risky place for newbies.

Don't take my word. Consider how “Kate” put it when I e-mailed her at the address the scammer gave Smith: “It's like the food chain, you know — I was the predator, she was the prey.”

A chilling reminder of an online truism: On the Internet, anybody might be a shark.


A Guide to Supporting InfoCard v1.0 Within Web Applications and Browsers

March 2006


Michael B. Jones
Microsoft Corporation

Copyright Notice

© 2006 Microsoft Corporation. All rights reserved.


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.


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

1. Introduction

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.

2. Design Goals

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.

3.4 Browser Perspective

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.

3.5 Web Site Perspective

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.

4.1.1 OBJECT Syntax Examples

An example of the OBJECT syntax is as follows:

    <title>Welcome to Fabrikam</title>
    <img src='fabrikam.jpg'/>
    <form name="ctl00" id="ctl00" method="post"
        <img src='infocard.bmp' onClick='ctl00.submit()'/>
        <input type="submit" name="InfoCardSignin" value="Log in"
          id="InfoCardSignin" />
      <OBJECT type="application/x-informationCard" name="xmlToken">
        <PARAM Name="tokenType" Value="urn:oasis:names:tc:SAML:1.0:assertion">
        <PARAM Name="issuer" Value=
        <PARAM Name="requiredClaims" Value=

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:

    <form name="ctl01" method="post"
        id="ctl01" onSubmit="fnGetCard();">
      <img src='infocard.bmp' onClick='ctl01.submit()'/>
      <input type="submit" name="InfoCardSignin" value="Log in"
          id="InfoCardSignin" />
      <OBJECT type="application/x-informationCard" name="xmlToken"
          ID="oCard" />
    <script type="text/javascript">
      function fnGetCard(){
         Card.issuer = "http://www.fabrikam.com/sts";
         Card.issuerPolicy = "http://www.fabrikam.com/sts/mex";
         Card.tokenType = "urn:fabricam:custom-token-type";

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.

4.1.2 XHTML Syntax Example

An example of the XHTML syntax is as follows:

<html XMLNS:ic="http://www.identityselectors.org/2006/10">
    <title>Welcome to Fabrikam</title>
    <img src='fabrikam.jpg'/>
    <form name="ctl00" id="ctl00" method="post"
      <ic:informationCard name='xmlToken'
        <ic:add claimType=
            optional="false" />
        <ic:add claimType=
            optional="false" />
        <ic:add claimType=
            optional="false" />
        <input type="submit" name="InfoCardSignin" value="Log in"
            id="InfoCardSignin" />

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.

4.2.1 issuer (optional)

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.

4.2.2 issuerPolicy (optional)

This parameter specifies the URL of an endpoint from which the STS's policy can be retrieved. If omitted, the value “<issuer>/mex” is used.

4.2.3 tokenType (optional)

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.

5. References

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.
Web Services Metadata Exchange (WS-MetadataExchange),” September 2004.
Web Services Security Policy Language (WS-SecurityPolicy),” July 2005.
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
UA-CPU: x86


An un-escaped and reformatted version of the preceding xmlToken value, with the encrypted value elided, is as follows:

<enc:EncryptedData Type="http://www.w3.org/2001/04/xmlenc#Element" xmlns:enc=
<enc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc"
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<e:EncryptedKey xmlns:e="http://www.w3.org/2001/04/xmlenc#">
<e:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
<o:SecurityTokenReference xmlns:o="http://docs.oasis-open.org/wss/2004/01/oas
<o:KeyIdentifier ValueType="http://docs.oasis-open.org/wss/oasis-wss-soap-mes
sage-security-1.1#ThumbprintSHA1" EncodingType="http://docs.oasis-open.org/ws

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.

Appendix C – Corrigenda

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.

C.2. Claim Separator Syntax

Claims in the “requiredClaims” and “optionalClaims” list are separated by commas in the MIX 2006 build—as opposed to using spaces for separation as documented previously.


Scobleizer has just hit me with “Kim turns Microsoft toward open source?

Kim Cameron, what are you doing (he just announced that he got Microsoft’s InfoCards working on WordPress and PHP and is having a conversation with lots of people in the community)? You trying to ruin Microsoft’s reputation? By listening to folks like Marc Canter? “I came away incredibly excited and anxious to meet those folks at Mix06.”

What’s going on here?

Of course Microsoft isn’t quite hip yet. How do we know that? We don’t have a sticker. Or is that a stickr. Heheh. Check out Cory Doctorow’s laptop. All the cool kids have stickrs.

Yeah. This stickr thing is really a big deal.


Kim Cameron
Identity and Access Architect
Microsoft Corporation

May 2005

Applies to:
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)


Problem Statement
Words That Allow Dialogue
The Laws of Identity
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 California we are already seeing the first legislative measures being taken to correct abuse of identity directionality. It shows a failure of vision among technologists that legislators understand these issues before we do.

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.


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 flout the law of gravity. By following them we can build a unifying identity metasystem that is universally accepted and enduring.

For More Information

Microsoft's Vision for an Identity Metasystem whitepaper

This whitepaper as it appears on MSDN

Join the identity discussion at https://www.identityblog.com/

Scott C. Lemon on the Third Law

I just came across this – shows how swamped I was in December. What a fascinating post. I know my “fascination” must appear simply narcissitic to someone just popping their head in to the discussion. But Scott thought through so many issues when he was working on Digital Me (and since). It is significant that in the light of such a different set of experiences he comes to many of the same conclusions.

I agree completely with Kim's Third Law.

The Fewest Parties Law of Identity

Technical 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.

This is, IMHO, the same thing that caused the failure of Novell's digitalMe project … after it was taken over by others in the company. It's funny how some people at Novell really thought that Novell was somehow going to become the de facto source of identity information in the world.

I kept hearing these funny internal pitches about “billion user directories” … and silly me I just kept thinking “I would rather sell hundreds of millions of personal directories, then a couple of ‘billion user’ directories!” How many “billion user” communities are there on earth?

I think of a different theory on why these grand schemes fail. Kim touches on this also. If you try to build the “one big thing in the sky”, and there is a second group of people that don't like you or trust you, then they'll build their own version. Which means there will be two. If there are two, then there will be three or more … and then things start to go in all directions. It's funny to see this even occurring in the Open Source world. People have disagreements and fork a project … and then it get's forked again. I'm not saying this is bad at all … it's the natural progression. So build to embrace this!

The original digitalMe team was after building community platforms, and then providing methods to federate … however much of what we were pursuing was “client-side federation” … allowing the user to be the federation point, since they exist at the intersection of all of the communities that they belong to. We figured that we would allow anyone to create a community … and allow people to choose the communities that they wanted to belong to, and which ones they would trust.

Part of the reason that I strongly believe in the Third Law is that this is how the “philosophical” views fall also. When I participate in an identity transaction, I can choose to limit the parties involved if I trust the other party or if the information being exchanged is not too valuable. On the other hand, I might have to bring in a third or fourth party if we both want to feel secure about who the other party is, or I want to authenticate the identity information being exchanged.

In the end … I like Kim's thoughts …

Totally asleep at the wheel

I just received mail asking why I hadn&#39t answered the marvelous post by Marc Canter, father of Macromedia. I have to admit I was totally asleep at the wheel – could it be my day job?

Marc opines in his lovable blend of angel and baseball bat:

Here&#39s where Kim tells us about how ‘Passport is dead’ – while simultaneously being used by 200M people. MSN Spaces sure uses it. ]

I&#39d bet that his new InfoCards technology super-sets Passport – making it just one of many identity systems – which all have to work together. So Sxip, Liberty and Passport/WS-* all using i-names, FOAF and XFN. To be exact.

So what I&#39d say to Kim is: “Hey Kim? Where&#39s that all expense paid, guru fees junket, PR suck-up strategy session where Microsoft pays us to go up there, eat Oyster stew and learn about InfoCards?”

And we reply with even more open source ideas – for free.

Well, I&#39ve been trying to animate a discussion about the objective factors constraining what an identity system must be in order to be successful. And a bunch of the people you mention are looking at this deeply and thinking about the fundamental issues in identity that will make a universal system possible.

I don&#39t personally think that Microsoft should operate an identity provider other than for its own properties – and I don&#39t think that&#39s in our plans. I do think we should provide great identity software – that interoperates with great identity software from others. I also think MSN properties should be able to use other identity providers if that&#39s what people want – so Passport needs to be able to federate in that sense.

Further, I&#39m convinced no one will get out of this without reving what they&#39ve done so far. We all need to move forward. And I think this discussion shows many people are willing to move forward.

So yes, we need an open, inclusive system, but the constituent technologies all need to come into alignment with the laws of identity in order to succeed.

By the way, I want to organize some meetings. And I&#39ll bet I can get Microsoft to spring for the oyster stew. But if I don&#39t want the meetings to be PR junkets – and I don&#39t – I&#39m worried we&#39ll have to dispense with the all-expense paid guru fees part.

Interview with Mike Foley on Bluetooth

To help me frame the Laws of Identity in a practical way, I took on a scenario presented to me by Eric Norlin and began to drill into it to expose the technology issues it presented in terms of identity. Part of this scenario involved using a bluetooth connection between a Polycomm and a Bluetooth phone.

I knew virtually nothing about Bluetooth at that point, and so had to learn. I studied the Bluetooth web site, and then approached Noel Anderson, a Program Manager in Networking at Microsoft. He was kind enough to give me an introductory tutorial about Bluetooth identity issues which I recorded as an Identity Interview with Noel Anderson. I found Noel fascinating, and Craig Burton thought our discussion was interesting enough to transcribe some of it: In particular, I thought Noel&#39s example of an “identity bomb” taught us a lot about the underlying technology issues:

When we were writing the paper we wanted to catch attention so we came up with the idea of the Bluetooth bomb. Every Bluetooth device has a 48—bit unique ID number, which is possible to either query for directly or in a broadcast mode. So we came up with the concept of a low power Bluetooth device which was attached to a weapon that was querying for a particular device ID so that when the target cell phone or PDA or another Bluetooth device came into range it would activate the [bomb] device.

Noel told me that things were being done to fix the protocols. But I was initially more interested in Bluetooth as an example of how privacy issues affect identity, and didn&#39t immediately tune into the details of the fixes.

Then Mike Foley, who is the organizer of the special interest group that is fixing these problems, contacted me. I offered to interview him so everyone could learn about what his organization was doing. As he began to tell me about the work that is going on to fix the identity problems, I was not only relieved, but amazed at how the fixes themselves demonstrated the dynamics of the Laws of Identity hard at work. Bluetooth having been out of conformance with the Laws, concerns about the marketplace motivated its technologists to fix the technology.

When Mike talks about the water that has flowed under the bridge of privacy since Bluetooth was first envisaged in the late 1990s, you really get a feeling for how there are objective factors shaping the emergence of identity technology. And his discussion of how identifiers work (in conjunction with what we learned from Noel) teaches us a lot about the relationship between identifiers and privacy.

So here&#39s the Identity Interview with Mike Foley as an mp3 (22 minutes). It&#39s really fun when we are talking about the Fourth Law of Identity… Mike also invites those of us who are serious about identity to join the SIG.

By the way, I plan to publish a series of Identity Interviews to accompany the blog, so this will become a regular feature.