INTERNET IDENTITY WORKSHOP 2006

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&#39ll be there, as will Mike Jones.

If you don&#39t 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&#39s 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&#39s also the author of Digital Identity.

Here&#39s what it&#39s 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&#39t necessarily have a formalized relationship is a different problem than providing authentication and authorization services within a single organization.

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

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

The workshop will take place May 2 and 3, 2006 at the Computer History Museum. We will also have a 1/2 day on the first of May for newbies who want to get oriented to the protocols and issues before diving into the community. If you are new to the discussion, we encourage your attendance on May 1st because of the open format we&#39ll 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&#39t be put off by that, however, if you&#39re just getting into this. Come and learn. You won&#39t be disappointed.

Cost

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.

Sponsorships

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

Sponsors

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 REGISTER&#39S NEW DEVELOPER SECTION DOES INFOCARDS

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&#39s 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&#39t take a rocket scientist to see that doesn&#39t 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&#39s a visual metaphor we call InfoCards and then there&#39s the identity metasystem. That is not something that we&#39re 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&#39s a pay-per-view, I&#39ll leave each of you to fend for yourself.

 

DUPED BRIDE GETS NO SYMPATHY

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&#39s 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&#39s hard to believe that eBay has really adopted this PR strategy.  I don&#39t 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&#39t 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&#39d always loved when she saw them on pop stars such as Pink in People magazine. She&#39s 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&#39s 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&#39s eBay horror story, and outlined why she was was suspicious. “I am sorry to be this way, but in today&#39s world, it is not totally off base to be wary,” she said.

To which “Kate” replied:

“That&#39s true, indeed. I just scammed you, sorry for that, it&#39s nothing personal. … It&#39s 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&#39s hidden minimum price.

She couldn&#39t 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&#39s own payment system, had been frozen because of — what else? — a scammer&#39s intrusion.

But Smith, new to eBay, didn&#39t 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&#39s 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&#39t 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&#39t 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&#39s a small fraction. But eBay reported 1.9 billion listings in 2005, so it translates into 190,000 confirmed frauds in one year. (To report an online scam, go to www.ic3.gov/complaint.)

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

Don&#39t take my word. Consider how “Kate” put it when I e-mailed her at the address the scammer gave Smith: “It&#39s 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.

PLEASE HOLD INFOCARD TESTING WHILE I LOOK INTO IE 7 CHANGES

I&#39ve received many comments like this one from Shigeya Tanabe:

mmm.. This InfoCard auth looks like it&#39s 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&#39ve had a really busy week what with the MIX06 conference and everything else.  I&#39ll post again over the weekend.
 

 

MY FRIEND THE ATTACKER

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&#39t 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 “browsehappy.com” 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&#39ll 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 browsehappy.com thing, it was obvious that Rohan was poking fun – and that&#39s fine. I just appreciated the opportunity to rail, en passant, against a couple of the site&#39s more dubious claims.

This said, I&#39d like to be very clear about the status of the work I&#39m 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&#39m working on now. It involves experimentatng with how to use InfoCards concretely from a web site – in this case my blog. I&#39m learning as I go. After all, InfoCards are a relatively recent arrival on the scene…

I&#39ll publish various elements of code as it evolves – but I&#39m writing this stuff personally as an exploration – it isn&#39t a product, doesn&#39t yet have a formal threat analysis, hasn&#39t gone through security reviews, and hasn&#39t 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&#39ll find things to fix, working as a team.

A NEW TECHNICAL PAPER BY MIKE JONES

InfoCard&#39s Mike Jones has just finished a new technical paper that explains how a web designer gets web browsers to invoke the infocard experience. Here&#39s the Table of Contents:

Mike

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&#39m 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&#39t be shy.

SUPPORTING INFOCARD v1.0 WITHIN WEB APPS AND BROWSERS

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

March 2006

Author

Michael B. Jones
Microsoft Corporation

Copyright Notice

© 2006 Microsoft Corporation. All rights reserved.

Abstract

The Identity Metasystem allows users to manage their digital identities from various identity providers and employ them in different contexts where they are accepted to access online services. In the Identity Metasystem, identities are represented to users as “Information Cards” (a.k.a. “InfoCards”). One important class of applications where InfoCard-based authentication can be used is applications hosted on Web sites and accessed through Web browsers.

This paper documents the Web interfaces utilized by browsers and Web applications that support the Identity Metasystem. The information in this document is not specific to any one browser or platform.

This document supplements the information provided in two other “InfoCard” references: the [InfoCard-Guide] which provides a non-normative description of the overall InfoCard model, and the InfoCard Technical Reference [InfoCard-TechRef], which provides the normative schema definitions and behaviors referenced by the InfoCard Guide.

Status

This draft corresponds to the “InfoCard” support that Microsoft is implementing in WinFX [WinFX] and Internet Explorer 7. Other implementations following these specifications should be able to interoperate with the Microsoft implementation. The behaviors described in this document are subject to change.

Table of Contents

1. Introduction
2. Design Goals
3. Browser Behavior with InfoCards
   3.1 Basic Protocol Flow When Using an InfoCard at a Web Site
   3.2 Protocol Flow with Relying Party STS
   3.3 User Perspective and Examples
   3.4 Browser Perspective
   3.5 Web Site Perspective
4. Invoking InfoCard from a Web Page
   4.1 Syntax Alternatives: OBJECT and XHTML tags
      4.1.1 OBJECT Syntax Examples
      4.1.2 XHTML Syntax Example
   4.2 InfoCard Invocation Parameters
      4.2.1 issuer (optional)
      4.2.2 issuerPolicy (optional)
      4.2.3 tokenType (optional)
      4.2.4 requiredClaims (optional)
      4.2.5 optionalClaims (optional)
   4.3 Data Types for Use with Scripting
   4.4 Detecting and Utilizing an InfoCard-enabled Browser
5. References
Appendix A – HTTP POST Sample Contents
Appendix B – Detecting InfoCard Browser Support by Internet Explorer
Appendix C – Corrigenda
   C.1. Self-Issued Card Issuer Syntax
   C.2. Claim Separator Syntax

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&#39s 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&#39s 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&#39s 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&#39s 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&#39s 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&#39s 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&#39s 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&#39s 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&#39s 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&#39s 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:

<html>
  <head>
    <title>Welcome to Fabrikam</title>
  </head>
  <body>
    <img src='fabrikam.jpg'/>
    <form name="ctl00" id="ctl00" method="post"
        action="https://www.fabrikam.com/InfoCard-Browser/Main.aspx">
      <center>
        <img src='infocard.bmp' onClick='ctl00.submit()'/>
        <input type="submit" name="InfoCardSignin" value="Log in"
          id="InfoCardSignin" />
      </center>
      <OBJECT type="application/x-informationCard" name="xmlToken">
        <PARAM Name="tokenType" Value="urn:oasis:names:tc:SAML:1.0:assertion">
        <PARAM Name="issuer" Value=
            "urn:schemas-microsoft-com:ws:2005:05:identity:issuer:self">
        <PARAM Name="requiredClaims" Value=
"http://schemas.microsoft.com/ws/2005/05/identity/claims/emailaddress

http://schemas.microsoft.com/ws/2005/05/identity/claims/givenname

http://schemas.microsoft.com/ws/2005/05/identity/claims/surname">
      </OBJECT>
    </form>
  </body>
</html>

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:

<html>
  <body>
    <form name="ctl01" method="post"
        action="https://www.fabrikam.com/InfoCard-Browser-STS/login.aspx"
        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" />
    </form>
    <script type="text/javascript">
    <!--
      function fnGetCard(){
         Card.issuer = "http://www.fabrikam.com/sts";
         Card.issuerPolicy = "http://www.fabrikam.com/sts/mex";
         Card.tokenType = "urn:fabricam:custom-token-type";
      }
    //-->
    </script>
  </body>
</html>

This example uses the enhanced protocol described in Section 3.2, which employs a relying party STS. Note that in this case, the “issuer” points to a relying party STS. The “issuerPolicy” points to an endpoint where the security policy of the STS (expressed via WS-SecurityPolicy) is to be obtained using WS-MetadataExchange. Also, note that the “tokenType” parameter requests a custom token type defined by the site for its own purposes. The “tokenType” parameter could have been omitted as well, provided that the Web site is capable of understanding all token types issued by the specified STS or if the STS has prior knowledge about the token type to issue for the Web site.

The object parameters can be set in normal script code. This is equivalent to setting them using the “PARAM” declarations in the previous example.

4.1.2 XHTML Syntax Example

An example of the XHTML syntax is as follows:

<html XMLNS:ic="http://www.identityselectors.org/2006/10">
  <head>
    <title>Welcome to Fabrikam</title>
  </head>
  <body>
    <img src='fabrikam.jpg'/>
    <form name="ctl00" id="ctl00" method="post"
        action="https://www.fabrikam.com/InfoCard-Browser/Main.aspx">
      <ic:informationCard name='xmlToken'
          style='behavior:url(#default#informationCard)'
          issuer="urn:schemas-microsoft-com:ws:2005:05:identity:issuer:self"
          tokenType="urn:oasis:names:tc:SAML:1.0:assertion">
        <ic:add claimType=
       "http://schemas.microsoft.com/ws/2005/05/identity/claims/emailaddress"
            optional="false" />
        <ic:add claimType=
         "http://schemas.microsoft.com/ws/2005/05/identity/claims/givenname"
            optional="false" />
        <ic:add claimType=
         "http://schemas.microsoft.com/ws/2005/05/identity/claims/surname"
            optional="false" />
      </ic:informationCard>
      <center>
        <input type="submit" name="InfoCardSignin" value="Log in"
            id="InfoCardSignin" />
      </center>
    </form>
  </body>
</html>

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&#39s 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

[InfoCard-Guide]
A Guide to Integrating with InfoCard v1.0,” August 2005.
[InfoCard-TechRef]
A Technical Reference for InfoCard v1.0 in Windows,” August 2005.
[WinFX]
WinFX Developer Center,” January 2006.
[WS-MetadataExchange]
Web Services Metadata Exchange (WS-MetadataExchange),” September 2004.
[WS-SecurityPolicy]
Web Services Security Policy Language (WS-SecurityPolicy),” July 2005.
[WS-Trust]
Web Services Trust Language (WS-Trust),” February 2005.

Appendix A – HTTP POST Sample Contents

The contents of an HTTP POST generated by a page like the first example in Section 4.1.1 follows:

POST /test/s/TokenPage.aspx HTTP/1.1
Cache-Control: no-cache
Connection: Keep-Alive
Content-Length: 6478
Content-Type: application/x-www-form-urlencoded
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-sh
ockwave-flash, */*
Accept-Encoding: gzip, deflate
Accept-Language: en-us
Host: calebb-tst
Referer: https://localhost/test/s/
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; SV1; .NET CLR
2.0.50727)
UA-CPU: x86

InfoCardSignin=Log+in&xmlToken=%3Cenc%3AEncryptedData+Type%3D%22http%3A%2F%2F
www.w3.org%2F2001%2F04%2Fxmlenc%23Element%22+xmlns%3Aenc%3D%22http%3A%2F%2Fww
w.w3.org%2F2001%2F04%2Fxmlenc%23%22%3E%3Cenc%3AEncryptionMethod+Algorithm%3D%
22http%3A%2F%2Fwww.w3.org%2F2001%2F04%2Fxmlenc%23aes256-cbc%22+%2F%3E%3CKeyIn
fo+xmlns%3D%22http%3A%2F%2Fwww.w3.org%2F2000%2F09%2Fxmldsig%23%22%3E%3Ce%3AEn
cryptedKey+xmlns%3Ae%3D%22http%3A%2F%2Fwww.w3.org%2F2001%2F04%2Fxmlenc%23%22%
3E%3Ce%3AEncryptionMethod+Algorithm%3D%22http%3A%2F%2Fwww.w3.org%2F2001%2F04%
2Fxmlenc%23rsa-oaep-mgf1p%22%3E%3CDigestMethod+Algorithm%3D%22http%3A%2F%2Fww
w.w3.org%2F2000%2F09%2Fxmldsig%23sha1%22+%2F%3E%3C%2Fe%3AEncryptionMethod%3E%
3CKeyInfo%3E%3Co%3ASecurityTokenReference+xmlns%3Ao%3D%22http%3A%2F%2Fdocs.oa
sis-open.org%2Fwss%2F2004%2F01%2Foasis-200401-wss-wssecurity-secext-1.0.xsd%2
2%3E%3Co%3AKeyIdentifier+ValueType%3D%22http%3A%2F%2Fdocs.oasis-open.org%2Fws
s%2Foasis-wss-soap-message-security-1.1%23ThumbprintSHA1%22+EncodingType%3D%2
2http%3A%2F%2Fdocs.oasis-open.org%2Fwss%2F2004%2F01%2Foasis-200401-wss-soap-m
essage-security-1.0%23Base64Binary%22%3E%2BPYbznDaB%2FdlhjIfqCQ458E72wA%3D%3C
%2Fo%3AKeyIdentifier%3E%3C%2Fo%3ASecurityTokenReference%3E%3C%2FKeyInfo%3E%3C
e%3ACipherData%3E%3Ce%3ACipherValue%3EEq9UhAJ8C9K5l4Mr3qmgX0XnyL1ChKs2PqMj0Sk
6snw%2FIRNtXqLzmgbj2Vd3vFA4Vx1hileSTyqc1kAsskqpqBc4bMHT61w1f0NxU10HDor0DlNVcV
Dm%2FAfLcyLqEP%2Boh05B%2B5ntVIJzL8Ro3typF0eoSm3S6UnINOHIjHaVWyg%3D%3C%2Fe%3AC
ipherValue%3E%3C%2Fe%3ACipherData%3E%3C%2Fe%3AEncryptedKey%3E%3C%2FKeyInfo%3E
%3Cenc%3ACipherData%3E%3Cenc%3ACipherValue%3ErBvpZydiyDzJtzl1%2FjUFX9XAzO1mOR
q0ypPLjh%2FBagXcfZeYwWD57v4Jvn1QwGajadcDASCisazswn1skdkwgmd4IUWJpPMRH7es9zY0U
vnS4ccsakgDcmscq3pDYTrxbSBfhdvrzjDiHC2XCtowOveoHeB51C5N8UAbff18IxCNtkWO8y3wLH
VGdvwaDOSakK%2FK%2Fv1UgXIc51%2FtYvjeFGeGbbSNxo8DTqeDnAMQ%2B4Y%2B1aUGhI%2FtbSr
EyJECkDgtztcxhrumbupKO%2BogWKUTTpSt851xjOFxAMiVaPZ%2FAm8V8H3ZLsR087sX%2FJ%2Bn
bRqze%2BfbdUwimN5pNoJDdMnF%2BEDLass1dPsvhL4EXzuIp5deGBaqAIoaOMEUW7ssuh1PtwkEM
eqwlOzOhu%2FHtwP1qh3D02U59MtyQnJMD5UwIwO7sZJl6%2BPg6Zp9HHtKKUMnkguvFmhyXS4BFS
ZVxPl18i%2B0MLO1um5dejEFd4nwGO%2FmNw6yEI8DdGVjXcYOT6JhPz9rHNh9%2F%2FOj5snJfL6
j2sg0EvIYoRs%2BhT4sdHZ95tGAiwMwT6cFOXbAQZUbYTr1ZOC6XPsfL2CFwiTM3mI%2Blco4Hc%2
F7IakIA8jwAJdtnd2mGuV67ZbY1mzibM1LUApixZj59El83ixctSQbV7iyywQ4IYN2CAq%2BCLMdl
R%2BDHfgEe8O3IVaGBDUEcd2MYimEiA7Yw3NIDrC14SbLzNvU702HpVJMeYv9q6S9xIVGApSrARsw
RFXyMbkMDp5WIQaJEXon7qLcsZONpdlX9bCcmaiikdpxmCeyS638te%2FhGBLmYJSQ0stf7BhA6E0
kwDRgdwsAa88bODiWHek0vDhAN4HlXFZ%2BCxp53L9Mmvy%2FCAOI%2B9OkPL2yxS22yjWQxom%2F
yZuawsK98JHVShsIVmmbKvRM6xJwvHDSzuBAOlQKS%2FMHcFZn8vHZR4lMhm5nL3F%2B%2BumMKh0
vMuKk6JiCqG9OEj996bVIIkLzESU5Z5vT6I1Kr9Brdx8ckDElipdH3x54WVfaItHJTYU%2BsxIR1T
25fi9k%2FOc%2FMX7Q%2B6NSDs4nGqkn4rzqpez9BUWNZw7caVOrDeao85f%2FiDCGymtl0A3JaSZ
dTKfzHLGmUfSkCAlVeisdvB6R7uBw8tR%2BZlgLIGS28wppFlnUYvSK7DnPrzId%2BGfHwLfL6WA%
2FEzBMMgppb5Vi%2BauHq%2BHxpCamlkrcUkzagbwNkGV8TfafkqUvRwJbxRwNVPI%2F%2Fxs%2Fp
Lcu1dh6eKcmU00%2FNx0zNOScd9XoeEU3zsV78PgvPIBT4EDugdv4bMR6dExXvZBl%2F84b1gOMhK
ZRplF8t6EAc4LCct01ht7VOVNz25NtP27ct9QPrDJc%2FoxihT4Df6NV3l4vlTnu%2B%2BzVB%2BH
JAxNkiO9gx3uLUJM9XEZCDzZKihaBk2y%2F3RhsJpABVneUd%2B3sCRbQXhgKYNBHZyRAUGpMDLhL
qpjoF9x%2FNvUujQ5DBLJafxxzNVshG52jRz%2BikhCNhJDDbeA5MQ8Q7QsYcKDC0DBFsewtWaA%2
FsKxl3JU6hyTotnFS%2FoS2EzbOSvn25qZuBERsZ3w%2B5WMkRzfQadyIYOSv2Df1YoljubDKy1l9
St%2FbCIBgXbVIZKYtQ%2BLyepxxFjrN7cWo2aYFnB6YLurg4USJwhXzcGcvA3%2BR5dRT6Fr37U6
OcHc%2Fz2MaZmn1cQWiDGNxHtRVxEvirBc1x47hWfSRjrKzf3orL5LzgMlYc7Iwclw2rbeWljCqOb
oV3d71ez%2FvNz1pxEMi4w8yUAQL8p%2FRCZ%2BpzvsgORu4RWKWiSwbl7AN0J3jiWShyZgDmxd2O
DDYffXjNiuH1mQWnDTkJX1ig88mqjhOYJEal0W6L0ErwrRIy29tOiAvXZANC8kA1HexulH0e38x8E
IOaVaJtNz9mqrnmnp4GdZ38txV%2BCUeWHOZaHLF4xkdtRxMAu%2FbzQ03YmUOhgxqkTfNzV6Ymne
v2nv5VsyQGJaQsNjb0M4yOe6kX2qNTwKBN2%2Bp%2Fz3f15i8KuGCgBcfP%2BP9xBizBeo7FbFtyo
2pfFhzBPmZeSOJ6kEbF1yQKHYQAT5iZ4SyTIfqqmwGxsQpWMstx3qJF8aW8WFzU1qXcC1LmgClg19
rx9NYFaQshX4f729B9Ue5MX7gTrMgwAnlXty9BsoP7nzGbr3HSXy8pR%2BimuAFW3c2NaQSbjSH5Z
FOr7PZdLHsNVJzFIsaufAwr0CAEtvlPJUt7%2B%2FE5MQsMsVqMoXFmefgdxbvY1Ue6MX1wtuJYY1
PAX7MHTyRUR3RfJDO054EoflVTwNE1fmocUXUh5rtFFuzy2T%2F2Y6pLAARXzo8uslAuH67VkuXv%
2BEMc7e3ogbf5%2BROsgJirZS6qkcYpfEUwqHiQYLnSIP4bt%2BWI5j1bxs7yzcSCkNZ2rd%2FHWr
A41AyGMfYzqxfGcrOaxHsds3JUcByB5Zw17W58GBC32Iusqa69BFTPagEapM0Fb5CbTqXnWTNNB5J
t40BVZvLv3u5oy%2BBRaMKXZhwnbT2WUTp0Ebsn17xvte52B%2BLMlSWJn96Nl5thd%2Ft1D7PlWA
sUvpJAd0UHPizCkY8VIhcXTrsSyEwer2J2I9TQTUosmssFjoP8Lx9qMfXo0eGVmneV8kVBtu4J7N1
QmWfV%2B%2FK8vGbCwW3Gm%2FEUlOO4ZbbK39y0JgNQ7fshxHr5Hdtd%2F6S%2FQkb6NPVDwn7Srh
Y0diWujXz5QlIYBSN7vDfMun3yF%2BGbmMExZ8MkOthuYkgMS9qiFoJGUXGyELsJfxbzdcRE9iyJn
p88L4%2BCtcO3l2JxIhMAgxOZx42RfAiDV1Gbpa4f%2F0urmWQ2VK7uZ%2FlViVrGAJ2kpH0EfwYE
Mb2YYT8FFjogqEpDSJX48BLIh1TE4nMbqQVG1cksCGDc0XyGKaF5Z7Ikw493Xz0JQ0BZvaf2Kceb7
MUZlsU1DSHcQQ9X%2Bxu9RcgUePJEe9BgCMpZ5Kr6r43qyk79noBSgrsSkDhT5sg%2Fc20RHQB8OX
%2BC4r3XGQFWF2m2j0xTc%2Boy14xqUmSB2qJtuWGOXDJspejDRP1GIfFnqDFdqSO3%2FkV9AC5Ee
39iJGv8I%2B5nErtQao645bCytn4B2bJah8R2fXLs8Dd4%2BC2ykxVrLxTUmJaGqd2RK%2F6t1E47
l%2B90Vp4WEzC0CFXXt9XNqdVjo2bZsXbfKQgO2zT2q2qCsgwbxVzIF5y39R%2BrkSkX16uuz3q6w
n3I5RI9M8Hn3DCzzv6Ms4rYxYuiqxaIcb7DgjI2fk1bdyiiRjSxzpCHpK6CWjBD8DPQYdkqGr%2Bs
oWeSvHvPLMSDxEPzwlnaxysRXzKphHUeUa2CCqcpagux2mbKkwHSXemX9I3V3AhPePp5XI5eCRiy3
D4%2BcBXOydie94Nz9DIhW749hPiVD9CioAgyqgAzFwCxEEUCXKTzu9xXX4DXg9b3CUfGzwERtY7x
TGT2y%2F9i7r5Xs0lrKi9ftws4JO5v%2Be3WuAEtWv0w%2FVKCl1WwTbV9xtx%2B4RZQ3%2Fewvv%
2F0GqiiSrhiVBGuCDaQs7stwqfkF3vFgGXmmODGTIkIxvYm2fzcEfq4A6LRp5RkYyJyUTF87c56tn
Qa%2Bo3xeiX5WRJybpabrRou09vyWLdlkhcUaBElGWB7iYUJ9bCltByEdNZnuDV%2FXlfnmDARKp8
RVN028czIk57wQMuizgWrM6S9Ku20noDmLgbT554UBf7FnjRWOb%2FF9OJuPpUcARBPrfuqTcOsBq
tZr7AJl3zz%2F53mpyn9rgzw5gBLgkvrdbciabJOAacccTDEB5kEzCLuprC3SlVedhgY%2BMQ5%2F
xgN%2Faf3TtJiBKFvb1V37BlbXXGosnPFcoH8I0XbqW5FSsxmcnpg48poJcB7j5eHq7Y%2F01RLb4
iMmzNap4%2BFg2F3LrwOI0Wk7ueIjgFd5KJ1iTda1ivGU%2Fchr9aTNpM5HiLb2fDW0pZ%2FFBJcI
XxpT9eNY%2FpVj5pnTW2ubpPnBulPOQTLCi1EOxbl33wnhUIfnGiVWJdrls2j3GWgqOnrYUbP%2FX
tNJqIucnMYGqPbcGIF2QRuiwD%2FiTRMvCRCmdCsYE%2FaXjOMhskX7KYC%2B9iG%2FT1wQRbfHSK
WD%2Fpv450OVDsfc1Adq6FCr1LesDNTew%2FF8Z3SiHnWS76OVsNM2SB%2FhMP67iu5UWVkb3%2FQ
qCN0aosOPs2QX0XBCZFmN6p3FhFnXPbAbaGz9y6KzUiUxC03U0fZcToKl4y%2Bw0P4IvxpjVt4t8b
84Q9hiBxd5xu1%2BRE973a%2FyIWO%2Fit1MdUSmxWakxWuGxDnQxwkNCN7ekL%2FQ%2B6FItm86b
w9cc%2FMiI7q2fK7y7YAzM3tmamhF1%2FWJNj1lH0vh%2BhNehJlLlb4Z%2F9ZtxMWV4LVTyrFaF1
zyCEqcKUTk0jc%2FXDwyKZc%2FSV9EOoPk2fVnmzs3WkA74GB%2BWtjdvQjSmnJYtPkMNsikHw%2B
RyB1hTkYbn3iQ6BUiJ0v97j7MVZHxCa1KS3t2gx8H7ts6Tfy5il89xVUdiZwfj0w06g199qlAqUMZ
EWxh0%3D%3C%2Fenc%3ACipherValue%3E%3C%2Fenc%3ACipherData%3E%3C%2Fenc%3AEncryp
tedData%3E

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

<enc:EncryptedData Type="http://www.w3.org/2001/04/xmlenc#Element" xmlns:enc=
"http://www.w3.org/2001/04/xmlenc#">
<enc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc"
/>
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<e:EncryptedKey xmlns:e="http://www.w3.org/2001/04/xmlenc#">
<e:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1
p">
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
</e:EncryptionMethod>
<KeyInfo>
<o:SecurityTokenReference xmlns:o="http://docs.oasis-open.org/wss/2004/01/oas
is-200401-wss-wssecurity-secext-1.0.xsd">
<o:KeyIdentifier ValueType="http://docs.oasis-open.org/wss/oasis-wss-soap-mes
sage-security-1.1#ThumbprintSHA1" EncodingType="http://docs.oasis-open.org/ws
s/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary">
+PYbznDaB/dlhjIfqCQ458E72wA=
</o:KeyIdentifier>
</o:SecurityTokenReference>
</KeyInfo>
<e:CipherData>
<e:CipherValue>
Eq9UhAJ8C9K5l4Mr3qmgX0XnyL1ChKs2PqMj0Sk6snw/IRNtXqLzmgbj2Vd3vFA4Vx1hileSTyqc1
kAsskqpqBc4bMHT61w1f0NxU10HDor0DlNVcVDm/AfLcyLqEP+oh05B+5ntVIJzL8Ro3typF0eoSm
3S6UnINOHIjHaVWyg=
</e:CipherValue>
</e:CipherData>
</e:EncryptedKey>
</KeyInfo>
<enc:CipherData>
<enc:CipherValue>
...=
</enc:CipherValue>
</enc:CipherData>
</enc:EncryptedData>

Appendix B – Detecting InfoCard Browser Support by Internet Explorer

Script code can detect browser support for InfoCard within Internet Explorer by testing the userAgent string to determine whether the browser version is greater than or equal to MSIE 7.0. A second issue with Internet Explorer 7 is that the InfoCard support might not be installed (because WinFX is not installed on the machine). This can be detected by using the “isInstalled” property on the InfoCard OBJECT from scripting code.

Appendix C – Corrigenda

This appendix describes the known differences between the preceding specifications and the early implementation included in the build of Windows Vista distributed to MIX 2006 attendees.

C.1. Self-Issued Card Issuer Syntax

The syntax for indicating self-issued cards in the MIX 2006 build is “http://schemas.microsoft.com/ws/2005/05/identity/issuer/self“—not the URN syntax “urn:schemas-microsoft-com:ws:2005:05:identity:issuer:self” documented previously.

C.2. Claim Separator Syntax

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

MORE HARDY PIONEERS TRY OUT INFOCARD

It&#39s 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&#39ve 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 iTickr.com. 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&#39s been fun playing with Infocards for the past couple of days. Sure, it takes a lifetime to figure out what you need and what&#39s the right place to download (MS overusage of ‘setup.exe’ doesn&#39t really help)… but once you have that figured out, it&#39s all ‘click’ and ‘play’. Managed to log into Kim Cameron&#39s 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&#39t 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 identityBlog.com and clicked on login.
  8. Selected Infocard as the option to login.
  9. Installed the ActiveX control (it&#39s 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&#39m 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&#39ve 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&#39s 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&#39s 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&#39s 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&#39s pretty clean.

OK. Now let&#39s move on to the next new visitor. I&#39m talking about Caleb Baker. I haven&#39t 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&#39s 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&#39t 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&#39m 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&#39s 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 browsehappy.com. He points out:

The first page of browsehappy.com has text that reads as : “Internet Explorer can make your computer unsafe. Why not switch to a browser that&#39s more secure?”.
I read that and thought…. {{{nothing}}} I Know, I Know, browsehappy.com 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&#39t 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&#39s own FirstName, LastName and email address (because from Kim&#39s 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&#39s 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&#39t 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&#39t – it was obvious to me that someone was pulling my leg. When I&#39ve 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&#39m still experimenting.
But for people interested in trying things out, after you&#39ve 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.

INFOCARD SUBSCRIBERS AT IDENTITYBLOG

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&#39m 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&#39m going to be posting a video of the user experience this weekend so everyone can see what it&#39s like.

INFOCARDS LIVE ON LAMP

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&#39ll be posting something about how to download the magical bits combination.

He&#39s 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&#39s also true this is a work in progress – I appreciate Pete&#39s support in helping set expectations.