Seems like Gunnar Peterson of 1 raindrop finds the intersection of InfoCard and Federation as interesting as I do.  And in resonance with my recent post on enterprise identity management, his taxonomy includes the fascinating “deperimeterization” – I see that while I wasn't working he's done a whole much of good work on this.

Ping is set to demo its new Infocard authentication + federated SSO at Catalyst.

A user authenticates to a healthcare portal leveraging a self-asserted InfoCard. The user’s credentials are validated by a Java InfoCard Server built by Ping Identity. PingFederate is then used to enable federated single sign-on to a remote Web site without a redundant user authentication.



There are a number of interesting aspects here including proving out Identity Law 5, which is, of course, Pluralism of Technologies and Operators, jacking InfoCards assertion into the federation network through the WS-Trust backplane, and the ability of InfoCards to help to strengthen the authentication process, for example through a smart card and then have that assertion carried through the system, Brian Snow:

Consider the use of smartcards, smart badges, or other critical functions. Although more costly than software, when properly implemented the assurance gain is great. The form factor is not as important as the existence of an isolated processor and address space for assured operations – an “Island of Security” if you will.

An island of security in a networked world, now there is a future worth inventing.

Is it really an island?


O.K.  I've hit a gold mine.  It's called  Who or what is Tiara?  “A PhD student in the Department of Culture and Communication at NYU, studying social technology from a feminist perspective.”  Go to her “About me” page and it has everything except… a name – at least in a form straightforward enough to come up in a search engine.  So for me she's just Tiara.

Tiara has assembled a spectacular identity bibliography.  I'm going to ask if she'll let me put it up on identityblog – with credit to her, of course.

It turns out Tiara had blogged about the Times’ Facebook story over the weekend.  Somehow through the miracles of ping-backs this floated past my desktop:

Kim Cameron, the architect of MS’ Infocard Identity Metasystem, which I’m not at all a fan of, writes a great post on Facebook and the globalization of identity, based on the NYT article I blogged over the weekend.

Wow.  Such a smart person is not a fan of the identity metasystem.  I need to find out more about this.  None the less, we seem to agree when it comes to some of the issues raised in the Facebook article.  After quoting my piece, she continues:

Beautiful point: Facebook (& MySpace) are extremely performative communities, where the values being espoused– being cool, being “hard”, being sexy, being transgressive, being resistant– are those of mythical teenage worlds. There’s not just a generation gap between teens/young adults and their future possible bosses, there’s a culture gap between the “professional world”, where we’re not really supposed to have any sort of interesting personal lives (witness the furor over academic blogging), and the “online world”, where we’re supposed to be larger-than-life (microcelebrity again!).

I also like Cameron’s point about companies not being “invited” into these worlds. I definitely feel that Facebook is a private community, and I don’t go poke around looking for my undergraduate students, because it’s none of my business what they do in their private lives. But, again, as I said the other day, there are no regulations about searching social networking sites (or even just Google) , and there aren’t likely to be. The justification that it’s public information trumps the contextualization argument.

I talked to someone else recently who said that their local sheriff’s office uses MySpace as a first resource whenever they are looking for something or bringing someone in — of course it’s a young receptionist who does the searching. And universities like UC Santa Barbara are formulating specific policies to discipline students based on their Facebook information. So although I agree with Cameron, it’s really irrelevant. As long as sites like MySpace and Facebook are viewed as public information, they will not enjoy any type of protection from authorities or employers.

It's not really irrelevant.  There are a lot of issues buried here, and I'm not about to give up the ghost on them. 

One question I have is whether it is possible for an operator to provide access to a site for specific reasons – and prevent it for others.  In other words, is it possible to require those entering a site to sign a binding statement of use?  Can liability be associated with breaking such an agreement? 

Let's go further.  Is it possible to prevent usage of a site for commercial purposes, or purposes of employment, or in the interests of an employer? 

I'm going to be at the identity mashup hosted by Berkman Center for Internet and Society at the Harvard Law School next week.  I'll should probably be able to find a few (hundred) lawyers there.  I'll try to find out more about these issues. 

But as Tiara says in her own interesting post on the matter:

So what’s “the solution”? I’ve heard three:
1. Young people should stop putting content online.
2. Recruiters and employers shouldn’t use Google or Facebook to research potential candidates (don’t hear this one very often, although you’d think in a country where it’s illegal to ask people to include a snapshot with their resume, there might be potential room for legislation here).
3. We just have to wait until there’s no longer a divide between your “work” persona and your “life” persona. I know this sounds stupid, but I heard it from the CEO of Facebook.  (Tiara heard it from the CEO of Facebook??? – Kim)

And here’s what’s actually happening: People are obfuscating personal data by using pseudonyms that can only be identified within situated, contextual networks, or by using services which allow them to restrict who can view their personal information. This is really the only one of these solutions which makes any sense.

O.K.  So we totally agree.  Contextual separation is one of the main concepts behind the identity metasystem.  I suspect she has impressions of what we are trying to do that just aren't accurate.

In truth, InfoCards and the metasystem have been designed to enable privacy while still being able to make provable assumptions.  For example, the system can be used to allow you to limit access to your site to full-time students – and recognize them when they return – without actually knowing their names or exposing their identities to the digital grim reaper.  The very problems Tiara worries are not solvable, are actually some of those addressed by this system.

And in truth, they have to be addressed if the resulting infrastructure is to be consistent with the “third law of identity”.  Identity information should only be available to relevant parties.  As an industry we need to think about how the virtual fabric will work and offer people separation of context – or there will be a further and terrible erosion of confidence in cyberspace by those who constitute its future inhabitants.


James McGovern over at Enterprise Architecture: Thought Leadership has a nice post where he poses questions for a bunch of his blogrollers.

It's not that the questions are wicked.  He asks Dan Blum:

Would it be possible for you to figure out creative ways for others to observe the client/analyst dialog in a more public fashion? What would it take for you to start blogging more frequently?

Pat Patterson gets this one:

What would it take for you to get Liberty Alliance to embrace the WS-Federation specification? Having federation capabilities built directly into an operating system is liberating…

And for me:

I would love it if you could start talking about identity from a corporate perspective and not stay exclusively focused on consumer-centric identity. You can leave the consumer stuff to Dick Hardt…

It's true I've been dealing a lot with user-centric identity.  But James, the future of the corporation will unfold largely in the virtual world.  What will then be more important to a corporation that its relationships with its “consumers”?  The lack of a reliable grid for dealing with the individual in the digital world is, in the big picture, the most urgent corporate identity issue of our time. That's one of the reasons I was led into the problem area.

The most important thing about the identity metasystem the way it creates a unified infrastructure reaching between the corporation (or organization) and the individual (aka consumer).

What are we going to have?  One set of precepts that faces towards the inside of the corporation, and another completely different set that faces the outside?  That doesn't compute, and my work on this blog applies to both sides of this boundary.

The whole evolution of business is towards a more open mesh of interconnecting organizations in which individual relationships are key.  So empowering the individual within the organization will increasingly become the most important aspect of empowering the corporation.  The dichotomy you propose is a false one.

One of the most interesting trends I've seen is that of enterprises “kicking their employees out of the firewall”.  This isn't a good strategy in all cases, for sure, but I've seen a bunch of studies of companies that have slashed IT expenditures by treating their own employees as external individuals (factors of 10)!  More than one of these just tell their employees to buy their own PCs outfitted with various programs “off the street” and expense them back to the company – and still get order of magnitude savings.  They only keep there line of business apps remain behind the firewall.

I'm not proposing this as a direction forward – simply reporting on trends I see.

Reliable identity-based collaboration between individual users which also integrates with organizational identity will empower them both the users and the organizations.  Making progress on this front is the most important single thing we can do right now to help the corporations we work for benefit from technology.  That is the big picture.

One key takeaway from your request is that I should explain where I'm coming from a lot better.  On a related theme, I'm getting ready to spend more time on the challenges of being “the relying party” in identity transactions, so I'll try to build these notions into what I'm writing.

You probably know that metadirectory, self-management and provisioning of identities all form an interconnected cluster of passionate interests for me.  Note to self:  start writing about these issues too.


I got a note recently from federation master Mike Beach – a man with a great deal of experience in terms of how users react to security:

Is it just me or does your site have an invalid cert.  When I attempt to
login using my new Infocard in IE7 I get the infamous “warning, go back, do
not enter, danger ahead” and things go all red (really more pink).

Given the primary drivers of Infocard are to save us from all the web evils
of today it would seem this is contrary reinforcement when I must ignore all
the security warnings to log in.

I thought, “That's weird.  I don't get that problem.”  – you know, the ancestral “That's funny.  It doesn't happen on MY box.”  But of course it really was happening to Mike, so I wrote back and asked if he could send some screenshots.  It turned out this wasn't necessary – he had already figured out the problem.

He had been visiting identityblog using this URL:  

When he clicked on Login he was redirected to  

But my certificate is limited to  Therefore IE (correctly) saw Mike's and the certificate's as being different – resulting in the redish bar.  It looked like this:


That's enough to confuse anyone.  So clearly, redirecting to something that isn't consistent with your certificate is a no-no.  I was setting up an experience that would undermine my user's understanding of what was happening to her, breaking law six.  I should have been checking and redirecting to even if the user didn't supply the “www”.  Strangely, I had done the Dashboard link correctly – it was only the Login link that had the error.

All of which goes to show there are a set of gotchas that we have to nail down in terms of establishing prescriptive guidance for how a site should deal with these issues in order to be consistent.  We need a checklist – or better still, a test plan.  A wiki would be a good way to elaborate this.

Another big takeaway is that an identity 2.0 relying party has an obligation to make sure it doesn't do things that send mixed signals (in my case, nice InfoCard experience but big red warning bar in IE).  Everyone has to co-operate with the goal of not confusing the user.

It's worth pointing out that none of this is primarily an InfoCard problem.  The same considerations apply to any use of https.  But in the InfCard case we want to make sure we have the deployment practices nailed down to a higher level than has previously been the case.


Somehow I tumbled into Personal InfoCloud today.  It's a thought provoking site by Thomas Vander Wal, with all kinds of nooks and crannies that lurch off into explorations, from many points of view, of how information and technology could be restructured from the vantage point of the individual.  You should poke around yourself to get a sense for how these ideas hold together;  but here's part of a post on the Come To Me Web:

The improved understanding of the digital realm and its possibilities beyond our metaphors of the physical environment allows us to focus on a “Come to Me” web. What many people are doing today with current technologies is quite different than was done four or five years ago. This is today for some and will be the future for many.

When you talk to people about information and media today they frame it is terms of, “my information”, “my media”, and “my collection”. This label is applied to not only information they created, but information they have found and read/used. The information is with them in their mind and more often than not it is on one or more of their devices drives, either explicitly saved or in cache.

Many of us as designers and developers have embraced “user-centered” or “user experience” design as part of our practice. These mantras place the focus on the people using our tools and information as we have moved to making what we produce “usable”. The “use” in “usable” goes beyond the person just reading the information and to meeting peoples desires and needs for reusing information. Microformats and Structured Blogging are two recent projects (among many) that focus on and provide for reuse of information. People can not only read the information, but can easily drop the information into their appropriate application (date related information gets put in the person's calendar, names and contact information are easily dropped into the address book, etc.). These tools also ease the finding and aggregating of the content types.

As people get more accustomed to reusing information and media as they want and need, they find they are not focussed on just one device (the desktop/laptop), but many devices across their life. They have devices at work, at home, mobile, in their living space and they want to have the information that they desire to remain attracted to them no matter where they are. We see the proliferation of web-based bookmarking sites providing people access their bookmarks/favorites from any web browser on any capable device. We see people working to sync their address books and calendars between devices and using web-based tools to help ensure the information is on the devices near them. People send e-mail and other text/media messages to their various devices and services so information and files are near them. We are seeing people using their web-based or web-connected calendars to program settings on their personal digital video recorders in their living room (or wherever it is located).

Keeping information attracted to one's self or within easy reach, not only requires the information and media be available across devices, but to be in common or open formats. We have moved away from a world where all of our information and media distribution required developing for a proprietary format to one where standards and open formats prevail. Even most current proprietary formats have non-proprietary means of accessing the content or creating the content. We can do this because application protocols interfaces (APIs) are made available for developers or tools based on the APIs can be used to quickly and easily create, recreate, or consume the information or media.

People have moved from finding information and media as being their biggest hurdle, to refinding things in “my collection” being the biggest problem. Managing what people come across and have access to (or had access to) again when they want it and need it is a large problem. In the “come to me” web there is a lot of filtering of information, as we have more avenues to receive information and media.

The metaphor and model in the “I go get” web was navigation and wayfinding. In the “come to me” web a model based on attraction. This is not the push and pull metaphor from the late 1990s (as that was mostly focussed on single devices and applications). Today's usage is truly focussed on the person and how they set their personal information workflow for digital information. The focus is slightly different. Push and pull focussed on technology, today the focus is on person and technology is just the conduit, which could (and should) fade into the background. The conduits can be used to filter information that is not desired so what is of interest is more easily identified.

It's exciting that Thomas has already had the identity aha.  I think a framework like the one he proposes – based on attraction – is probably an early harbinger of the identity big bang.



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

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



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.


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.