In Context

Next week is the Higgins F2F Meeting in Provo, Utah. All are invited! (easy for me to say, as Dale Olds is our host!). As you can see the topics range from unification with OpenID, to Selector UI harmonization, to Selector Selector design work, to SAML/STS IdP harmonization, IDF requirements for IdAS, XDI restful web service binding for IdAS, XDI, Introduction to R-Cards, etc. At best we’ll only scratch the surface of these topics. But it’s going to be really fun and exciting. [Besides, a bunch of us are really just going for the skiing days on Monday and Friday].

Higgins 1.0 in the middle of final IP review followed by “graduation” from Incubation/Release review by the Eclipse Foundation. Assuming all goes well and we can quickly accommodate any issues, Higgins 1.0 should be formally released (with press releases, etc.) in February (2008). March for sure.

So what that means is that for the first time in many moons we’re actually talking about new/interesting things. The road ahead. New capabilities. New challenges. How to drive Higgins adoption. Setting up a non-profit foundation. Stepping up our outreach and participation with other groups (e.g. http://dataportability.org, among others).

If you start with the premise that people should be able to choose whatever Identity Selector they’d like to use on their favorite computers and devices, and look at the state of selectors that are available or in the works, you realize that, as they say in Maine, you can’t get there from here.

Today, lacking any commonly agreed upon way of launching selectors, selector developers usually create their own browser extensions to act as launchers of their selectors. The result is not only that user’s usually have to install a different browser extension for each kind of selector. There’s no easy way to switch what your default selector is without more installing and uninstalling. You can’t just click a radio button on a dialog box that says “Would you like to make <brand XYZ> your default selector?” as you can when switching between browsers.

Kevin Miller’s Perpetual Motion extension for Firefox was a first step in the right direction, we just need to take it much further. We need a Selector Selector that will:

1. Provide a consistent UX on all platforms to allow you to configure what selector you would like to be your default
2. Provide a standard API that browsers (often via a browser extension) as well as local apps can use
3. Decouple browser <object> tag parsing/handling implementation from selector implementation.

Here’s the basic idea:

User Experience

Users could click on a “Selector Selector” icon somewhere in the OS preferences/control-panel/etc. of their machines that would enumerate the installed selectors and display a simple dialog box showing your choices and allowing you to pick one to be your default.

API

Here is a “starter” list of functions:

• <list> getSelectors() –return a list of installed selectorIds
• setDefaultSelector(<selectorId>)
• getDigitalIdentity(<relying-party-security-policy>)
• launchSelector() –start the selector app
• importCard(<card data stream>)

The UI would use the first two methods. The third one is used by the browser extension after it has determined the relying party’s (website’s) security policy and needs the user’s default selector to do its thing (display a list of i-card, etc.) and return a Digital Identity in the form of a security token.

Higgins SS

The concept of a selector selector was first discussed within the Higgins project at the Oct 1st F2F in Austin in 2007 (though it was called a selector broker in that meeting) and has been under development since then. The goal is to have a SS that runs on at least: Windows (XP&Vista), OSX and Linux using IE7, Firefox or Safari. The Higgins SS will be discussed at the upcoming Higgins F2F in Provo Jan 29-31.