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., innovative economic networks (e.g., attention brokering and lead generation (e.g., 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



The British web site The Register has a new developer section, and journalist Mary Branscombe has written a piece in it on InfoCard and the Identity Metasystem.  She gets many deep points about the system across in very few words, again amazing me.   

InfoCard is more than the replacement for Microsoft's Passport; in some ways it’s the antidote.

Identity architect Kim Cameron (read his paper on The Laws of Identity here) joined Microsoft when it bought the metadirectory he developed at Zoomit to turn into Active Directory, and stayed because he thought Microsoft was the best place to be to try to solve the internet’s identity problem.

He’s very clear on what Passport got wrong: “It did not make sense to most non-MSN sites for Microsoft to be involved in their customer relationships,” he says. “Nor were users clamouring for a single Microsoft identity service to be aware of all their internet activities. Passport was positioned as a candidate for or something ready to be the identity system for the internet. Nobody used it as that identity system; it doesn't take a rocket scientist to see that doesn't fly.”

InfoCard isn’t trying to be the identity system for the internet, and it isn’t just a password management system like Opera’s Magic Wand or the Password Manager in Firefox. It’s intended to be a consistent and secure way to choose the identity you want to use for a website or an application – like picking a card from your wallet – and to find out who you’re dealing with and what they’re asking for.

Users will have multiple InfoCards, each of them an XML description of the information about you that each identity supplies. But the information –name, age, email address, credit card number, membership number or whatever else is on the card – isn’t in the InfoCard or even on your PC (unless it’s a card you’ve issued yourself).

Instead, when you use an InfoCard it retrieves that information from the identity provider – VeriSign, your bank, the airline you have a frequent flyer card with and so on – and passes it to the site you want to access. This is done using a new class of “higher-value” X.509 site certificates that Microsoft is developing with VeriSign and other certificate authorities, which include digitally-signed company logos to show who you’re giving your details to.

InfoCard works with an identity metasystem that allows different identity systems to interact. Each identity provider runs a Security Token Server (STS) using WS-Trust to securely exchange claims with other identity systems (negotiations between systems use WS-MetadataExchange and WS-SecurityPolicy and messages are secured with WS-Security). It doesn’t have to be a Microsoft STS; Ping Identity’s PingTrust is the first third-party STS for the identity metasystem but several identity providers support WS-Trust and the other WS-* web services.

Authentication is based on unique keys generated each time you use an InfoCard. You get a new key pair even if you use the same card on the same site. And the information sent doesn’t have to be everything in that InfoCard; a site asking you to prove you’re over 18 won’t get your birth date, just the confirmation you’re a legal adult. Your credit card company can supply a one-time transaction authorisation rather than your card number.

What is on your PC is configuration information telling InfoCard how to contact the identity provider. That’s encrypted in a Metadata Store with no programmatic interface so nothing but InfoCard can access it. In version 1, this stays on your PC, unless you export it by hand to copy to another computer. In the future it could be on your phone, on a smartcard or a USB stick – or even supplied by a web service.

InfoCard works with smartcards and security fobs; you could use biometric sensors to protect especially confidential information. VeriSign’s Identity Protection Network will use InfoCard and one-time passwords generated by security fobs, USB keys, or certain mobile phones to login to sites like eBay, PayPal and Yahoo!.

InfoCard runs on a separate secure desktop under a different user account. Malware will have to run with administrative privileges to see the InfoCard process; something Windows Vista aims to make less common.

Supporting InfoCard

On a website InfoCard uses the same HTTP/HTTPS GET and POST, and writes the same client-side browser cookie as a username and password login. The login link is either an OBJECT tag or XHTML, to support multiple browsers (although Microsoft is talking to other browser developers about adding InfoCard support, at this stage only IE 7 has it).

This link details the information the site wants from the user (such as name, email address or age8). If you’re using an STS of your own (or specifying a third-party STS) to authenticate users, the details of that go in the link. You also need the code to log the user in once the credentials have been supplied; the rest of your website works as before.

To add InfoCard support to Windows applications, you need to use the Windows Communication Foundation (that’s in WinFX so it will be available on Windows XP and Vista), but you can develop in any programming language that supports web services.

Anyone can issue their own InfoCard – and Passport will accept self-issued InfoCards once Vista comes out. Other identity providers will be able to issue InfoCards. Microsoft is going to be pushing Active Directory as a source of InfoCards. In Windows Server R2, Active Directory Federation Services uses WS–Trust although it isn’t until we finally see Longhorn Server that Active Directory will be able to issue and manage InfoCards for a company, as well as acting as an STS.

That emphasis on Active Directory may be why IBM is backing Higgins, the open source implementation of WS-Trust in Eclipse.

Paul Trevithick from The SocialPhysics Project emphasises that it isn’t meant to compete with InfoCard or the identity metasystem. “We are following what Microsoft is doing; to us it looks like a very inspired move. Higgins is a software framework that relies on service adapters that connect to external systems using that system’s native protocols or APIs. We expect that in the next few months a WS-* service will be created for Higgins. Higgins – when configured with this service and running on Linux, Mac OS and so on – will fully interoperate with InfoCard running on Windows.”

The more systems that work like this, the better, Kim Cameron says. “There's a visual metaphor we call InfoCards and then there's the identity metasystem. That is not something that we're building. All we can do is build a contribution to it.”

Celeste Biever has also done a nice piece in New Scientist but since it's a pay-per-view, I'll leave each of you to fend for yourself.



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

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.


I've received many comments like this one from Shigeya Tanabe:

mmm.. This InfoCard auth looks like it's not working with March 20th version of IE7.  It says “IE has blocked this website from displaying non-secure content”.  instead of prompting to download ‘Microsoft Information Card IE Helper’. 

So please hold off on further testing until I resolve the state of this.  I've had a really busy week what with the MIX06 conference and everything else.  I'll post again over the weekend.



In my recent post on Hardy Infocard Pioneers, I refered to the fact that the first “attack” had been made on the site. Apparently, I wasn't clear enough about the fact that I saw this as a good thing – something I appreciated. That led to this comment from Rohan.

Hi Kim,

An Attacker. thats a nice title, when the intention was not to “attack” but try to look at infocards from the other side. From another perspective altogether. Everybody seems to just nod heads when workflows and use case examples are explained. I have not seen many who have tried to disagree in the “open”.

Well, I am trying to do just that. Not disagree, but to look at it from another angle, and talk to you about my discoveries.

I’m sure that youd’ acknowledge, that I “did” inform you as soon as I logged into your site with FAKE info. Well, thats not called an “attack”.

As far as the “” link goes, thats just a joke…

Like you said : All of us will be attacked and all of us have to work hard – and together – to create a safe internet. I AGREE with you. 100%. But lets be open to ideas that may be contradictory to our own….. My efforts are to create a SAFE internet. To point out issues and errors, so that one may work on fixing them.

So let me set the record straight. I think Rohan is making a positive contribution to thinking about InfoCards. I appreciate what he is doing for the very reasons he expresses. And if you go to his site, you'll see how creative he is.

I didn’t mean “attacker” in the “normal” sense of the word – I was talking about THE ATTACKER ROLE we refer to as identity and security people, when we attempt, as he did, to think things through from the viewpoint of an attacker.

I am delighted to have others in the community thinking through the possible attacks with me. More about that in a minute.

In terms of the thing, it was obvious that Rohan was poking fun – and that's fine. I just appreciated the opportunity to rail, en passant, against a couple of the site's more dubious claims.

This said, I'd like to be very clear about the status of the work I'm doing here to InfoCard-enable my site.

There are two parts to this project.

The first is pretty much complete, and involved developing a way to consume and verify InfoCard SAML tokens using a typical LAMP server without installing binaries.

The second is the part I'm working on now. It involves experimentatng with how to use InfoCards concretely from a web site – in this case my blog. I'm learning as I go. After all, InfoCards are a relatively recent arrival on the scene…

I'll publish various elements of code as it evolves – but I'm writing this stuff personally as an exploration – it isn't a product, doesn't yet have a formal threat analysis, hasn't gone through security reviews, and hasn't even been seen by anyone other than me before appearing here. What you see is what you get.

My thinking is that the security threat model and reviews will be done here as part of the blogoshere process. And no doubt we'll find things to fix, working as a team.


InfoCard's Mike Jones has just finished a new technical paper that explains how a web designer gets web browsers to invoke the infocard experience. Here's the 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

I thought the paper was clear – but I'm obviously way too close to know for sure. Mike ran several versions of it past a number of people from across the industry and “known to be interested” in browser matters. Many suggestions were incorporated.

If you have further comments, now is the time to get them in to us, and if you have questions or comments about things that are unclear, please don't be shy.


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 = "";
         Card.issuerPolicy = "";
         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="">
    <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="" xmlns:enc=
<enc:EncryptionMethod Algorithm=""
<KeyInfo xmlns="">
<e:EncryptedKey xmlns:e="">
<e:EncryptionMethod Algorithm="
<DigestMethod Algorithm="" />
<o:SecurityTokenReference xmlns:o="
<o:KeyIdentifier ValueType="
sage-security-1.1#ThumbprintSHA1" EncodingType="

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 ““—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.


It's currently hard to locate and install the right software to try out InfoCard on the identityblog but a bunch of intrepid explorers have now actually done it, making me feel a deep wave of geek comraderie.

In fact, the subscription list has doubled since yesterday (doubling once every twenty-four hours may not be sustainable!) And we've had our first identity attack! Things are poppin’ – so to speak – techies bumping into a new technology and a lot of fun.

You can see a sanitized list of subscribers here – the uncategorized entry at the bottom is the attacker (more later).

So let me start with Ashish Jain. Looks like he is starting an identity blog called He calls this posting Welcome InfoCard:

As a core Java / ex-BEA guy (if I only got a penny every time I told customers to stay away from .NET), I never thought I would say this: it's been fun playing with Infocards for the past couple of days. Sure, it takes a lifetime to figure out what you need and what's the right place to download (MS overusage of ‘setup.exe’ doesn't really help)… but once you have that figured out, it's all ‘click’ and ‘play’. Managed to log into Kim Cameron's Identity Blog using my self-issued Infocard. This is what I did:

  1. Harass my IT guy to get a vanilla m/c with WinXP2 (I wasn't going to risk my own).
  2. Downloaded (here) and installed WinFX Runtime Component.
  3. Updated some COM+ Hotfix (the installation process guides you there).
  4. In my control panel, verified that I have the extra icon ‘Digital Identities’.Digital Identities
  5. Clicked ‘Digital Identities’ icon and created some dummy infocards (the interface is pretty intuitive).
  6. Downloaded IE7 from here.
  7. Accessed and clicked on login.
  8. Selected Infocard as the option to login.
  9. Installed the ActiveX control (it's a test machine so I was little more liberal in clicking ‘Yes’ to every download).

Screen started greying out… (very theatrical… they should add some sound effects too). Picked one of my self-issued inforcard and I'm in.

Some of the screen shots here.

Identity Selector Login PagePick a card

Plan to put together a SP application and hopefully use some managed Infocards in the coming days. Stay tuned.

So cool. Before we go further, let me say that Ashish is totally on the money here in making sure he rounded up a test PC. Please follow his example.

I've actually installed this stuff on my production laptop, which is insane, but this is only because I am prepared to sacrifice deeply to get a feeling for what it's really like to live in an infocard world. (Someone just called me the “Madame Curie of Identity”). I need to understand the experience issues as well as I can.

Be prepared for minor changes with breaking periods before InfoCard goes to release. In case of doubt follow the implementor's guide when it comes to futures.

If you think installing the software is hard, upgrading it is just not supported. So use a dedicated or virtual machine.

I like Ashish's comment that the InfoCard desktop is, well, “…theatrical… they should add some sound effects too”. The goal is to draw the user into a ceremony where he or she will be on the lookout for abnormal behavior – in accordance with the sixth law. And yet, not to do something that would grate on your nerves as you get used to it. It's pretty clean.

OK. Now let's move on to the next new visitor. I'm talking about Caleb Baker. I haven't said enough about my team, and I want everyone to know how much I like and appreciate these foks. They have worked relentlessly to get this stuff out.

Caleb is one of the guys who is most critical to our InfoCard team. He works in the test organization, building automation for the Identity Selector and other components. If anyone knows what components work with what others, it's Caleb!

Testing this kind of project is unbelievably complex given the security issues. Imagine doing UI testing on a product when your test programs can't even see the InfoCard screen (because they are running on a private desktop)! It boggles the mind! But Caleb always seems to be in a positive mood.

One of the great things about Caleb – and his buddies – is how deeply committed he is to the privacy and security aspects of InfoCard. Few architects are fortunate enough to work with people who go so far to make sure theory and high level design principles are being applied in every nook and cranny of a project – with no shortcuts. I'm very grateful.

Finally, last but not least, there is the inimitable Rohan Pinto.

Rohan is from Sun, and blogs about infocards here. He is working on this stuff as a personal initiative at this point, and he's right out there in trying to understand it. In fact, he was visiting my site and using infocard on it even before I had finished porting it. He actually stunned me – I thought there was some kind of an error since it never occured to me that someone would be using the system before I had even announced it was working!

Rohan tells it as he sees it, and this posting is no exception. First he shows a graphic that proves he has logged in, which is great. Then he notes that the current incarnation takes you to a dashboard where you see a link to He points out:

The first page of has text that reads as : “Internet Explorer can make your computer unsafe. Why not switch to a browser that's more secure?”.
I read that and thought…. {{{nothing}}} I Know, I Know, and wordpress are interlinked…

I have to smile. All of us will be attacked and all of us have to work hard – and together – to create a safe internet. So the kind of stuff on browsehappy doesn't even register with me – or, I suspect, with my long-tail subscribers.

Back on the subject at hand, Rohan continues:

I sent an infocard with Kim's own FirstName, LastName and email address (because from Kim's infocard invoker code, I saw that the only info he requested from an infocard was just the firstname, lastname and email address) and was able to login with that infocard too. However either with my own infocard or with a FAKE infocard with Kim's own info, I could not do much on the site. But the point is that regardless of the authenticity of the user, a “user” was provisioned on his blog.

Actually, the way the system works, you start off as a “subscription requestor”. You aren't recognized as a subscriber until you respond to an email sent to your email address.

When Rohan made his FAKE card and posed as me, I was the one who got the invitation to validate my email address. Clearly I didn't – it was obvious to me that someone was pulling my leg. When I've finished the implementation, it will also be impossible to socially engineer anyone into inadvertantly confirming an email. More about this later.

The email verification stage explains why, in the screen shot above, the bottom “cameron” subscription requestor is not shown as a subscriber. Over time, the fake registration attempt will time out and be deleted.

The net result is that the people who are promoted to subscriber can use their infocard to post comments on the site, wheras the fakes cannot.

None of this is yet implemented as well as it should be. I'm still experimenting.
But for people interested in trying things out, after you've logged in using an infocard and been approved through the mail validation, click on the “view site” portion of the dashboard. That takes you to the public identity blog. Then click on a “comment” link and leave a comment. It bypasses the moderation queue and gets posted immediately.

Using my subscriber InfoCard, for example, this is what I saw when I went to type in a comment:

I pressed “Add my comment” and it was immediately posted.


Here are the first three InfoCard based autoregistrations at Identityblog. Email addresses have been doctored to protect the innocent (and even the not-so-innocent). I'm still thinking about the data minimalization issues.

Pete Rowley blogs here and Pamela Dingle blogs here.

As I said, all this is still very much a work in progress only for the strong-hearted.

I'm going to be posting a video of the user experience this weekend so everyone can see what it's like.


Pete Rowley, identity guru from RedHat, is one of the first to have logged into my site using an infocard. His report:

Kim Cameron blogs INFOCARDS ON IDENTITYBLOG which is good news for open source because Kim recently converted his blog to WordPress on the LAMP stack. It is also good news for InfoCards and the identity meta-system since according to Kim’s own laws of identity the meta-system is required to be platform agnostic in order to ensure success.

If you are itching to try out InfoCards be advised that it appears that only the combination of Windows XP SP2, WinFX, and IE7.0 Beta 2 will work. Vista appears to have issues. Registration to the site is painless, present your InfoCard as you would to log in and you are sent an email with a link to confirm. That is it.

Since this is an ongoing effort to integrate InfoCards with WordPress you should expect to see missing functionality, for example, having logged in you are still required to enter your name and email address in order to leave a comment.

I look forward to seeing the code.

Pete is right. At this point in time you still have to diddle and twiddle a bit to get the “right combination” of software for all the alpha and beta pieces to work together properly. I'll be posting something about how to download the magical bits combination.

He's also right that there are problems with InfoCard in the current version of the Vista beta – you are better off running it on XP for the time being. We have Vista bits where most of these issues are fixed, but not in a form we can release.

It's also true this is a work in progress – I appreciate Pete's support in helping set expectations.