Notes from IIW 2007a

Over at self-issued, Mike Jones picked up on the OSIS Wiki Page reporting on the recent Information Card Connect-a-thon.  Maybe the most encouraging thing was to see new players show up with working bits:

The OSIS group sponsored an Information Card interoperability connect-a-thon on May 15, 2007 as part of the Internet Identity Workshop 2007 A in Mountain View California. Participants collaborated to work through combinations of Identity Provider, Identity Agent, and Relying Party scenarios, in order to identify and workshop problems with interoperability. The following representatives were present and participated:

5 Information Card Selectors

  • Ian Brown’s Safari Plugin
  • Windows Cardspace
  • Higgins IdA Native
  • Higgins IdA Java

11 Relying Parties

  • Bandit (basic wiki authentcation)
  • Bandit (elevated privileges)
  • PamelaWare
  • CA
  • Windows Live RP (used to obtain a managed card)
  • Windows Live/single-issuer (where you can use the managed card)
  • Oracle RP
  • Identityblog RP (based on Rob Richards’ library)
  • Identityblog helloworld token RP
  • UW/Shibboleth

7 Identity Providers

  • Higgins
  • Bandit
  • UW/Shibboleth
  • LiveLabs
  • HumanPresent
  • Identityblog HelloWorld IdP

4 Token Types

  • SAML 1.0
  • SAML 1.1
  • helloworld
  • username token

2 Authentication Mechanisms

  • username/password
  • self-issued (personal) card

Many combinations interoperated as expected; several issues were identified and are being fixed in preparation for the coming Information Card Interop event to be held at the Burton Group Catalyst Conference in San Francisco (June 25-29).

Socket and Ecosystem Days

David Coder comments on my recent reflection on “novel auth” technology:

Kim, I very much agree with everything you wrote.

But there is another thing I don't understand lately. CardSpace is shipping now for almost half a year in its RTM version. And yet, I have never come across a production site (except this one) that uses it. You post all these fantastic anouncements of new groups that will support this, but out there on the web, very little adoption seems to take place. And in particular, there seems to be not a single Microsoft site that uses it. Why? Contrary, the one huge MS group where I would have thought they might use it (Windows Live ID and all the sites that use it) seems to be even implementing their own identity selector.

Quite frankly, right now my impression is that what is needed most is some highly visible commitment from MS itself to this idea and to implement it widespread on its platform. I am just quite sceptical that anyone else will use this widespread, unless you do the first step.

Make no mistake:  you will see deep Microsoft support. But you need to give us time to roll it out, just as we need to give others in the industry time to do the same. 

Using your example of Windows Live ID, it is a huge production system handling a billion authentications a day.  There are strict requirements for introducing new software.  In fact, some of them arose through input from policy makers.  Much more is involved than “wanting to do something” and coming up with “bits” suitable for use on such an enormous site.  There is Process.

The same is true in terms of integrating the new technology into our federation product, Active Directory Federation Service (ADFS).  There is a whole team working on CardSpace support, so administrators will be able to give their Active Directory (AD) users Information Cards at the flick of a switch.  But we want to do it as well as we can, and in the most secure way possible, and we can't do that over night.

My colleagues and I wanted to see CardSpace bits get into circulation as early as possible – even if service offerings weren't ready yet.  Why?

Socket and Ecosystem Days

The problem with identity is getting the infrastructure in place. Some great talent – I don't know who – pointed this out when he said, “The Public Key Infrastructure (PKI) is great except for one thing: the public has no keys”…

CardSpace eliminates the need to “give the people keys”. But the bits still have to “get out there” before it will work. We are still in “Socket and Ecosystem Days”, when sockets start to appear on desktops and people running web sites can move past “but nobody has information cards” and get to “hey, everyone is going to have them”. 

Our first job was to ship CardSpace V1.0 so Information Cards became “real”.  Now we need to distribute bits.  And finally we need to lead in adoption, just as you say. 

CardSpace can't succeed without its sister implementations on other platforms. It also needs relying party software in a dozen languages to run on all platforms.  And identity provider software.  

These are just starting to emerge.  But all this is happening in a methodical and persistant way.  I think of it as “ecosystem time”.  

I'll post the report that appeared on the OSIS wiki describing the Connect-a-thon held at a recent IIW.  You will see the degree to which the ecosystem is growing.

Meanwhile, Windows Live ID plans to introduce Information Card support this summer.  At that point, all the Microsoft properties will be enabled.  The integration will grow progressively stronger over time.

Bandits strike at BrainShare

Incredible news from Dale Olds’ VirtualSoul at Novell:

This week was Novell’s Brainshare conference. It’s a big deal for Novell folks and it’s a great event. It gives us a place to show off new technologies like the emerging Internet identity systems and some of the recent work that we have done on the Bandit team.

Our most significant demo this year was shown during the technology preview keynote on Friday. The whole series of demos is interesting — I especially liked some of the Linux desktop stuff — but if you want to just skip to the infocard stuff, it starts at about 40 minutes into the video.

For those who may want to know more detailed information about what the demo actually does, let me give some background information here:

There were 3 new open source components written by Bandits and made available this week:

  • A fully open source, cross platform identity selector service was contributed to Higgins. Written in C++, this Higgins ISS runs as a daemon (no UI) and provides core infocard selector service: it accesses multiple card stores, enumerates available cards, matches cards based on requested claims, and interacts with the appropriate STS to get a token. It is almost complete on support for personal cards, with an internal STS, etc. The real deal.
  • A UI process for the Higgins ISS. It is currently written in C#, runs on Mono, and leverages much of the management UI of the CASA component of Bandit.
  • A new OpenID context provider was contributed to Higgins. This context provider plugs into the Higgins IdAS and allows identity data to be accessed from any OpenID Provider. What this means is that, with no change to the Higgins STS code (since the STS uses IdAS), we could set up a demo such that infocards can be generated from any OpenID identity. In other words, using the Higgins STS and the new OpenID context provider, I can access any site that accepts infocards with my openID account.

So what Baber showed in the demo:

  1. A fully functional, native infocard selector running on the Mac.
  2. He accessed a shopping site with an infocard generated from an OpenID account. Put some things in the cart and logged out.
  3. Baber switched to a SUSE Linux Desktop machine. Fully functional infocard selector there as well. Accessed the same site with an OpenID infocard and see stuff in his cart from the Mac session.
  4. Goes to check out. The site asks for a card with different claims, needs a payment card.
  5. The Higgins Infocard selector supports multiple card stores. In this case Baber selects a credit card from a card store on his mobile phone via bluetooth.
  6. He authorizes a (hypothetical) payment and the online shopping site (the relying party) only gets his shipping address and an authorization code from the credit card.

It’s a simple demo, and easy to miss the number of technologies and interactions involved, but this is the kind progress that we have been working towards for a long time.

The Bandits are happy and tired.

Comment problem seems due to Firefox bug

As Pamela explains, it was neither the upgrade to WordPress 2.0.2 (made necessary by a security vulnerability discovered in WordPress 2.0.1), nor the nifty Pamela Project code, that has been causing problems when using non-Windows Card Selectors with Firefox on my blog.  Instead, it is the latest rev of Firefox itself (bugs are being filed).

For anyone who is using the “xmldap Identity Selector” Firefox plugin on the Mac and has suddenly found that they are unable to log into the PamelaWare Test Blog or Product Blog or Pat’s or Kim’s blogs, the problem is not with the blogs themselves. The problem appears to be buggy nastiness in the Mac version of Firefox, which wreaks havoc with Chuck’s plugin (xmldap Identity Selector v0.8.6) . If you uninstall Firefox and then install Firefox from (get release here), you will again be able to authenticate to everyone’s blogs once again. The Safari plugin works as well, so if you want to remain on Firefox, you could satisfy your Information Card needs by using that plugin on your Mac instead.

We now return you to your regularly scheduled blog commenting :)

A number of people also discovered a less severe problem where comments ended up in a manual approval queue rather than being automatically posted even after InfoCard login.  If you have logged in with an InfoCard you should be getting automated instant access.  As far as I can tell, this now works properly.

Please keep me posted about any other issues.  This will help everyone using WordPress with the Pamela Project plugin.

Final note:  automated trackbacks will also be slowed down for a while I strengthen the trackback spam filter (gee – too bad there is no delegated authentication yet…)  If you want me to see a posting quickly please drop an i-names email.

Temporary problems logging in?

A number of people have had problems logging in to my blog from non-CardSpace identity selectors.  Eric Norman writes:

As of the upgrade today, I can't get to Kim's blog any more. The same thing happens with either Firefox or Safari.

When I click on the link to log in with an InfoCard, I get redirected to an error page that says I submitted an invalid one (see attachment).

I suspect that the problem is in on the WordPress side since it happens with two separate browsers, but I suppose it's possible that they both share some bad code.

In any case, I would be glad to help diagnose the problem…

I do come from an academic environment and we here do care a lot about interoperability across platforms. While I understand that all this code is still very experimental, I am faced with the problem that it worked yesterday and doesn't work today.

As long as I'm trying to help debug, I'll mention one other thing.

I don't know if this is still a problem since I can't get far enough any more. Neither of the above identity selectors have the ability to export and import cards, so I just had to install a new card on each. Whenever I would switch browsers, I would have to go through  the email verification bit again. This could get rather noisome.

It appears that the server side just remembers the last card that contains an email address instead of all of them.

So first, let me say I threw my blog into Pamela mode as part of the Pamela beta – hoping people who come here would be willing to put up with any inconvenience.  Maybe I should have asked first!  And I probably should have asked for Project Pamela's permission as well.  What can I say?  I'm an architect and I get excited about things.  I've really wanted to get on to production code. 

Make a note not to hire me as your operations manager…

We'll get it sorted out ASAP.  I'll post when we get things fixed.  In the meantime, if you use the Safari or Firefox Java identity selectors please use my i-name (or my email) to send your comments and I'll post them.

In terms of Eric's comment that it should be possible to register several cards at once, I know Pamela Project wants to work on that.

Finally, we need a cross-vendor automated test suite that includes tokens produced by everyone's implementations.  All of us will want to test with such a resource.

Understanding Bandit

There's so much going on around identity these days, that it's easy to lose track of how the different pieces fit together.  Here's a posting by Novell's Dale Olds that tells us all about Bandit.

There has been a huge flurry of activity in the Internet identity space in recent months mostly around convergence, working code, and actual deployments.

Since I am an unashamed Bandit, I am sometimes asked “where does the Bandit project fit in all this?” I think that it fits in three ways:

First, Bandit supports the above mentioned projects and convergence points.

We participate in the community as much as we can, and we are one of the few projects I have seen that will actively contribute code to other projects. We NEED this stuff to work coherently and we work to accelerate convergence where possible.

In some ways the Bandit project is much like our close ally, the Higgins Project. Both projects write open source code that glues together existing and future systems. Neither project pushes a particular protocol family or identity system. Higgins provides a framework that supports a common interface to multiple identity systems and protocol families. Bandit needs such a framework, so we contribute to Higgins to help it get done faster. We work with Higgins on other shared components as well.

We are also excited to work with the new Pamela Project. It fills a very important need for consistent relying party code that is usable, robust, and handles evolutionary accounts from existing silos to the emerging identity systems. Relying parties need consistent user experience too.

Most projects that we work with are open source. I personally would want my identity information handled by open source software. I also think that open source development is particularly good at interoperable components of distributed systems — like identity systems.

Second, Bandit adds a layer of open source components for consistent authentication, authorization and audit capabilities.

You might say that accelerating convergence, contributing code to other projects, and some authentication code is necessary before we can build effective authorization and audit components. We need a cohesive, distributed identity system. But we also know that when we get such a system, some critical issues involving authentication, authorization, and audit will surface.

Bandit focuses on simple, reusable components for authentication, authorization, and audit. These capabilities are most recognized as needed in enterprise identity systems, but I think they will be needed in other places as well. The recent experiences of the Bandit team and others are confirming this. Once applications or services (web based or otherwise) start to actually be used by more than a few users and sources of identity, they immediately find they need a general, scalable solution for authorization and audit.

Authorization means determining whether a particular user can perform an operation. Most network services really support authorization based on something like a role. For example, a wiki may have a notion of an administrator, an editor, and a reader. The Bandit Role Engine will allow a sysadmin great power and flexibility in how to map security tokens, claims, and other information into the native roles of the system.

Auditing is needed to provide an record of who did what. In the case of most of the emerging Internet identity systems we are particularly interested in providing a record for the user of what a service has agreed to do for them. Think of it (in the insight of Bob Blakley) as the receipt from a Relying Party. Audit records are also needed (like a cash register receipt log) to help a service prove compliance with various accounting regulations.

Bandit is not limited to these components or use cases, but they illustrate the point. From the main project page:

Bandit is a set of loosely-coupled components that provide consistent identity services for Authentication, Authorization, and Auditing.

Third, the Bandit Project is a conduit between developers and those who make these systems work in real deployments.

The Bandit Project works with Novell product teams, other vendors, current and future customers to determine what still needs to be done to make these identity systems work in real deployments. This will be an increasing emphasis of the Bandit Project this year.


New Information Card Profile V1.0 Technical Reference

These new documents are too low-level to be of interest to people working on the practical issues of deploying Information Cards on their Web sites.  

But they may be of interest to students, researchers and the intrepid souls who really want to get their hands dirty and understand the nitty-gritty of the underlying technical elements.

The latest and most accurate version of “A Technical Reference for the Information Card Profile V1.0” is available for download here.  In addition, I've posted a new version of “A Guide To Interoperating with the Information Card Profile V1.0” since it had a few grammatical errors and an inaccuracy in one of the examples – the URI of the self-issued IP claims was incorrect.

Johannes sends “marriage” greetings

Here's more support from another legendary member of the OpenID community, Johannes Ernst of Netmesh.  He's the inventor of LID, and one of the strongest champions for the “URL-based” identity used in OpenID.  He brought ideas his together with Brad Fitzpatrick's quite a while ago now, creating one of the first synergy-lurches for the community.

I should also point out that Johannes has also been one of the first, and most tireless, advocates of the synergy between OpenID and Information Cards.  He has given many cycles to OSIS, the group that has co-ordinated open source work around identity selectors and information card technology.  The beautiful thing here is that convergence with CardSpace MEANS convergence with Information Cards in general, including the Higgins project and work by many others in the community.  I've been concentrating on CardSpace for obvious reasons, but to me it is very important that this goes far beyond CardSpace into another whole community.

Wow! After two years of hard work, we are finally getting real convergence in identity land! Today, Bill Gates is announcing has announced in his keynote at the RSA conference that Microsoft will support OpenID. Here are some posts covering the news:

At NetMesh, we've held for a long time that URL-based identity (OpenID, with its roots LID, i-names and Sxip), and other technologies such as CardSpace have to come together so we can really get to an interoperable, multi-vendor, user-centric identity layer for the open internet. That's why we helped put together OSIS, and lots of activities of that nature.

Now even Bill Gates supports the same vision! Yippie!! (apologies for being too excited, but this is exciting!)

Just pointed out to my wife — who wrote the first line of code, ever, about three years ago, implementing URL-based identity — that in some way, she should now be famous!

So, congratulations Tammy!

Integrating OpenID and Infocard – Part 1

Let's start by taking a step-by-step look at the basic OpenID protocol to see how the phishing attack works.  (Click on the diagrams to see them on a more readable scale.)

The system consists of three parties – the relying party (or RP) which wants an ID in order to provide services to the user;  the user – running a browser;  and the Identity Provider (OpenID affectionados call it an OP – presumably because the phrase Open Identity Identity Provider smacks of the Department of Redundancy Department.   None the less I'll stick with the term IP since I want to discuss this in a broader context).

OpenID can employ a few possible messages and patterns, but I'll just deal with the one which is of concern to me.  An interaction starts with the user telling the RP what her URL is (1).  The RP consults the URL content to determine where the user's IP is located (not shown).  Then it redirects the user to her IP to pick up an authentication token, as shown in (2) and (3).  To do the authentication, the IP has to be sure that it's the user who is making the request.  So it presents her with an authentication screen, typically asking for a username and password in (4).  If they are entered correctly, the IP mints a token to send to the RP as shown in (5) and (6).  If the IP and RP already know each other, this is the end of the authentication part of the protocol.  If not, the back channel is used as well.

The attack works as shown in the next diagram.  The user unwittingly goes to an evil site (through conventional phishing or even by following a search engine).  The user sends the evil RP her URL (1) and it consults the URL's content to determine the location of her IP (not shown).  But instead of redirecting the user to the legitimate IP, it redirects her to the Evil Scooper site as shown in (2) an (3).  The Evil Scooper contacts the legitimate IP and pulls down an exact replica of its login experience (it can even simply become a “man in the middle”) as shown in (4).  Convinced she is talking to her IP, the user posts her credentials (username and password) which can now be used by the Evil Scooper to get tokens from the legitimate IP.  These tokens can then be used to gain access to any legitimate RP (not shown – too gory).

The problem here is that redirection to the home site is under the control of the evil party, and the user gives that party enough information to sink her.  Further, the whole process can be fully automated.

We can eliminate this attack if the user employs Cardspace (or some other identity selector) to log in to the Identity Provider.  One way to do this is through use of a self-issued card.  Let's look at what this does to the attacker.

Everything looks the same until step (4), where the user would normally enter her username and password.  With self-issued cards, username and password aren't used and can't be revealed no matter how much the user is tricked.  There is nothing to steal.  The central “honeypot credentials” cannot be pried out of the user. The system employs public key cryptography and generates different keys for every site the user visits.  So an Evil Scooper can scoop as much as it wants but nothing of value will be revealed to it.

I'll point out that this is a lot stronger as a solution than just configuring a web browser to know the IP's address.  I won't go into the many potential attacks on the web browser, although I wish people would start thinking about those, too.  What I am saying is the solution I am proposing benefits from cryptogrphy, and that is a good thing, not a bad thing. 

There are other advantages as well.  Not the least of these is that the user comes to see authentication as being a consistent experience whether going to an OpenID identity provider or to an identity provider using some other technology. 

So is this just like saying, “you can fix OpenID if you replace it with Cardspace”?  Absolutely not.  In this proposal, the relying parties continue to use OpenID in its current form, so we have a very nice lightweight solution.  Meanwhile Cardspace is used at the identity provider to keep credentials from being stolen.  So the best aspects of OpenID are retained.

How hard would it be for OpenID producers to go in this direction? 

Trivial.  OpenID software providers would just have to hook support for self-issued cards into their “OP” authentication.  More and more software is coming out that will make this easy, and if anyone has trouble just let me know.

Clearly not everyone will use Infocards on day one.  But if OpenID embraces the  alternative I am proposing, people who want to use selectors will have the option to protect themselves.  It will give those of us really concerned about phishing and security the opportunity to work with people so they can understand the benefits of Information Cards – especially when they want, as they inevitably will, to start protecting things of greater value.

So my ask is simple.  Build Infocard compatibility into OpenID identity providers.  This would help promote Infocards on the one hand, and result in enhanced safety for OpenID on the other.  How can that be anything other than a WIN/WIN?  I know there are already a number of people in the milieux who want to do this.

I think it would really help and is eminently doable.

This said, I have another proposal as well.  I'll get to it over then next few days.

Ping unveils Managed Card IP written in Java

Ashish Jain of Ping Identity seems to have broken another barrier by demonstrating a “managed card” identity provider written in Java.

In the world of InfoCards, we talk about two kinds of “identity provider”.  One is a “self-issued” card provider, through which individuals can make claims about themselves.  The other is a “managed” card provider, which supports claims made by one party about another party. 

Examples of managed card providers could include claims made by an employer about its employees; a financial institution about its customers; an enterprise about its customers; or a reputation service making claims about its users.  While the technology for posting tokens from an identity selector like Cardspace to a web site can be very light weight (RESTful), that for building managed card providers is more challenging.

Here's how Ashish puts it:

The Managed Card IdP as well as the RP server that we demonstrated at DIDW is now available for a test run. It’s still early access…so expect some issues. But if you do want to try early, give it a go. It should give you an idea of the things to come.


Please do the following (you need to have RC1 client installed on your machine).

  • Access the IdP Demo here.
  • Enter your information and click ‘Get Card’.
  • When the popup happens, click “open” to save it to the CardSpace Client. Alternatively, you can save it to the disk and double-click to install it. (You can change the extension from .crd to .xml if you are interested in looking at the contents).
  • Close the CardSpace Client.
  • Next go to the RP site here.
  • Click on the Managed Infocard Image.
  • Your CardSpace client should pop-up at this time and only the relevant card should be available for selection.
  • Select the card and it will challenge you to enter your IdP credentials. The server doesn’t perform any password validation at this time (as long as the username is correct).

And you should be logged in to the Relying party. The relying party page also displays the IdP as well as the RP message flow.

I tried it and it definitely worked for me.  I'll do a screen capture.

I don't know if the picture in Ashish's piece shows something he drank as a baby, but if so, a lot of other programmers may want to try some.