InfoCards for Firefox users

From Chuck Mortimore at xmldap.org

It sounds like Craig Burton has been having trouble with the demo Cardspace Selector I put together for Firefox. I'm not sure what trouble he's been having, but I thought I'd toss up some quick instructions, and a screen cast.

Step 1) Make sure you're on Firefox 1.5 or greater.

Step 2) Make sure you've got J2SE 1.4x installed on your machine. The xmldap selector doesn't use any .net or Microsoft code…its a cross platform implementation written from scratch in Java. You can hit http://java.sun.com if you need to download a JDK

Step 3) Go to http://xmldap.org and download the Firefox extension. You may need to allow the popup blocker to trust my site. Restart firefox.

Step 4) Go to a Cardspace enabled site like xmldap, identityblog, or ping

Step 5) Click to login, create a card, and submit.

Note that you'll still get a warning saying: “Additional plugins are required to display all the media on this page” Ignore it…I haven't figured out how to make it go away yet. Please email me or comment if you know!

Craig and others – email me at cmort at xmldap.org if you have questions or issues!

When I tried it I was using an earlier version of Firefox and had no luck – so make sure you get onto Firefox 1.5 or later.

By the way, this is a must-see demo not only for its general coolness, but for the special coolness of its sound track.  It's really a wonderful, no-nonsense piece of work.

WordPress InfoCard integration code

Update:  There are now excellent community-based and commercial implementations of Information Card code for WordPress, php, ruby, “C” and other languages.  I've left this zip here for documentary and pedagogical purposes only.

 I've been wanting to share my experiences adding Information Card support to identityblog for quite a while now.  I just haven't had the time.

I started by publishing my work on building the necessary code for handling secure identity tokens.  But then I got interrupted with the necessities of life – like shipping Cardspace.

Anyway, now I'm ready to present my integration code.  Very little of it is unique to WordPress – it is really code that would in general apply just as much to any other piece of software.  Someone could easily factor my code so the interface is a little cleaner than is currently the case. 

When I had to actually alter wordpress files (only 3 of them), I just show the changes that are necessary.  You'll have to download the original files from wordpress to see what I'm talking about (version 2.0.4) in context (usually not necessary unless you are making the changes in your own version.)

Download my contribution here.  My assumption is that the root of this download is the same as the root of the wordpress directory. 

[WARNING:  DO NOT INSTALL THE WORDPRESS FILES  FROM MY ZIP INTO YOUR OPERATIONAL WORDPRESS DIRECTORY!  IF YOU WANTED TO USE THIS CODE, YOU WOULD NEED TO MANUALLY INTEGRATE THE CHANGES I HAVE MADE TO MY VERSION OF THE WORDPRESS FILES INTO YOUR VERSION OF THE SAME FILES..  THIS NO LONGER MAKES SENSE SINCE THERE ARE EXCELLENT (SUPPORTED!!) VERSIONS AVAILABLE. ]

The files all begin with “infocard” so they're easy to delete if you want to.

I'll be publishing a number of pieces explaining why I took the approaches it did.  I hope this will get some good, concrete conversation going.  The first in this series is uncharacteristically wordpress specific – don't get discouraged if you're looking for something more general.  It talks about how I approached changing the wp-login page.  I'm pretty sure that even people thinking about infocard-enabling other products will find some ideas here that help them out.

Like my previous work, you can use this code in whatever way you want.  My goal is to help as many people as possible understand, use and deploy information cards.

UPDATE:  Thanks to Samuel Rinnetmäki for pointing out the need to warn readers not to install “as is” in an operational directory – it had never occured to me they might do this…  I've edited the  ZIP to make this impossible (09-02-2008).

Upcoming DIDW

I hope everyone's going to Digital ID World (DIDW) next week. We'll start on Monday with an Identity Open Space Unconference (don't worry, Virgos, they're unstructured, but not without shape and self-revealing purpose). Once this gives rise to the main event, there are a number of sessions that look fascinating for identity afficionados – like “What Do the Internet's Largest Sites Think About Identity?”, a panel moderated by Dan Farber and featuring representatives of the large sites and a new presentation by Dick Hardt. There will also be an OSIS meeting – and of course, the endless hallway conversation.

I'm pairing up with Patrick Harding (from Ping Identity) on a Wednesday session called “Understanding InfoCards in an Enterprise Setting“. It will include a demo that I think will really help show the concrete benefits of InfoCards inside the enterprise. What can you expect? 

First, you'll see the latest version of Ping's InfoCard server, now featuring both Managed IdP as well as Service Provider capabilities. Ping's goal is to show how to seamlessly chain passive and active federation – allowing for on-the-fly privacy context switching.  They'll use real-world use-cases where passive federation gives way to active and vice-versa.

According to Andre Durand, Ping Identity's CEO:

“The Digital ID World demo will show two scenarios to depict how passive federation (via SAML 2.0 Web SSO Profiles or WS-Federation) and active federation (via CardSpace) can both play a role in enabling a seamless user experience for accessing outsourced applications. The plan is to demonstrate how passive and active federation work together to enable a myriad of different business use cases when chained together in different situations

“Scenario 1:

“An enterprise employee leverages her internal employee portal to access applications that are hosted externally. In the first case we show how SAML 2.0 Web SSO (passive federation) is used to enable seamless access into the SF.com web site. The user accepts this as part of her employment contract – the employer has deemed that the use of SF.com is critical to their business and they want no friction for their sales force in entering information for forecasting purposes.

“In the second case we'll show how CardSpace is used to ‘optionally’ enable seamless access into the employees Employee Benefits web site. As the Employee Benefits web site is made up of a mixture of personal and corporate information (i.e. 401k, health and payroll) the employee is given the choice of whether to enable SSO via the use of CardSpace. The Employee Benefits web site is enabled with CardSpace. After the user clicks on the ‘Benefits’ link in their corporate portal, she is prompted with different Cards (Employer and Benefits) which she can then choose between for accessing the Benefits web site. If she chooses ‘Employer’ then she will be enabled with SSO from the Corporate Portal in future interactions.”

By the way, Andre, please tell me there's some way for her to change her mind later!

“Scenario 2:

“An enterprise employee is traveling and loses her cell phone. She uses her laptop to access her corporate cell phone provider in an effort to have the phone replaced immediately. The employee would normally access this web site via SSO from her corporate portal. The cell phone provider web site is enabled with Card Space to simplify the IdP discovery and selection process. The employee is prompted to use her Employer card to authenticate to her employer's authentication service. The cell phone provider web site leverages CardSpace to handle IdP Selection rather than having to discover this themselves. Once the user has authenticated to her employer the returned security token contains the relevant information to service the employee's request for a new cell phone.”

It all sounds very interesting – amongst the first examples of what it means to have a full palette of identity options.  Ping is emblematic of an emerging ecology – many of us, across the industry, moving us towards the Identity Big Bang.

Doc Searls will be doing the closing Keynote.  I'm really looking forward to that and to seeing you in Santa Clara.

Namespace change in Cardspace release candidate

Via Steve Linehan, a pointer to Vittorio Bertocci's blog, Vibro.NET:

In RC1 (.NET framework 3.0, IE7.0 and/or Vista: for once, we have all nicely aligned) we discontinued the namespace http://schemas.microsoft.com/ws/2005/05/identity, substituted by http://schemas.xmlsoap.org/ws/2005/05/identity. That holds both for the claims in the self issued cards (s-i-c) and for the qname of the issuer associated to s-i-c. If you browse a pre-RC RP site from a RC1 machine, you may experience weird effects. For example, like the Identity Selector claiming that the website is asking for a managed card from the issuer http://schemas.microsoft.com/ws/2005/05/identity/issuer/self no longer recognized as the s-i-c special issuer. Note that often is not a good idea to explicitly ask for a specific issuer 🙂

 If you want to see a sample of this, check out the updated version of the sandbox.

Why this change? As you may know, relying parties specify the claims they want the identity provider to supply (for example, “lastname” or “givenname”) using URIs.

Everyone will agree that the benefit of this is that the system is very flexible – anyone can make up their own URIs, get relying parties to ask for them, and then supply them through their own identity provider. 

But a lot of synergy accrues if we can agree on sets of basic URIs – much like we did with LDAP attribute names and definitions.  

Given that a number of players are implementing systems that interoperate with our self-asserted identity provider, it made sense to change the namespace of the claims from microsoft.com to xmlsoap.org.  In fact this is an early outcome of our collaboration with the Open Source Identity Selector (OSIS) members.  Now that there are a bunch of people who want to support the same set of claims, it makes total sense to move them into a “neutral” namespace.

While this is therefore a “good and proper” refinement, it can pose a problem for people trying out the new software:  if you are using an early version of Cardspace with self-issued cards that respond to the “microsoft.com” namespace, it won't match new-fangled claims requested by a web site using the “xmlsoap.org” namespace.  And vica versa.  Further, the “card illumination” logic from one version won't recognize the claims from the other namespace.  Cardspace will think the relying party is looking for specialized claims supplied by a “managed card” provider (e.g. a third party).  Thus the confusing message.

After getting some complaints, I fixed this problem at identityblog: now I detect the version of cardspace a client is running and then dynamically request claims in either an old dialect or the new one.  I would say people would do well to build this capability into their implementation from day one.  My sample code is here.

Trying out certificate behavior

I'm trying out revocation of my www.identityblog.com certificate – and changing my site's private key.

Since we are going where few men have gone before, in the worst case this might lead to abnormal behavior for those logging in with Information Cards over the next twenty-four hours. 

Identity blog should only be used for demos with an extra dose of caveats until I report back that the test has been concluded.

Normally this would be a ten minute test.  But the task is more daunting since I run my blog in ye-olde-typical-hosted environment.  I have no direct access to the machines or web servers or configuration – or control over anyone's schedule or priorities. 

Techies will understand that when you're not used to this it makes you a bit nervous.  But of course this is the way a great many people will experience things – and that's what I'm trying to get a feel for.