In Context

Saul Hansell wrote this article today in the Bits blog a post that is mostly about Equifax’s Information Card. It was an okay article, but this quote caught my eye:

[Information Card] is far more complex, and thus harder to use, than Open ID, a standard that lets you use your name and password from one site, say Google, to sign onto another site, for example, Facebook.

Saul has this backwards. As any good technologist will tell you, it is extraordinarily complex to make things easy for the user. Would you like to drive a car or use a mobile phone that was easy for the engineers to design and develop? I don’t think so. The Information Card metaphor, while complex underneath the hood, is surprisingly simple for the user. The only “complexity” if you can call it that, is something different. It is this: the user who doesn’t have a selector must first download and install one. But that doesn’t mean it’s hard to use. Nobody says Skype is hard to use because you first have to install it.

Secondly, while current Information Card implementations use the WS-* protocols and format, the metaphor can be applied to other protocols such as OpenID and others. In fact, there is a slow march in the OpenID world towards improving the OpenID user experience by adding a card-like, visual, point-and-click (vs. typing http://…etc. strings). Preferably integrated with the browser. Ever the optimist, I think there is a possbility of the OpenID Foundation and the Information Card Foundation working together to define OpenID Information Cards that will bring the beautiful simplicity of a visual interface to today’s OpenID user experience.

Why?

As we all try to make sense of identity technologies, we go through a process of fitting what we’re learning into our own mental map. It’s a lot of work. In the hope of possibly be of use to others I’m sharing my personal map. It consists of four actors and the six interconnections between them.

Four actors

Across a variety of identity technologies for identification, authentication, data sharing, authorization and so on there exist to varying extents four main kinds of actors. All of them are digital. The human user has been omitted in the interest of simplicity. If it were included it would be shown as interacting only with the user agent (U).

• U – A local user agent. It may just be a browser. Or it may include an OpenID, WS-*, password or SAML IdP,  selector client. It may include a local personal data store. It works on behalf of the user.
• R – A relying Website or Web service or a local application. This relying agent performs some service and/or provides access to some resources. In the non-local cases it is usually an agent of some organizational or individual entity other than the user.
• P – An Internet service (or local application) providing a specific service (e.g. a calendar service), an identity provider, an attribute/claim provider or an authorization provider. In the non-local case it is usually an agent of organizational or individual entity other than the user. Examples include a Plaxo Portable Contacts service, an OpenID OP, WS-* Security Token Service, or a SAML IdP
• A – A cloud-based agent that works on behalf of the user. It may act as an authorization manager to which you delegate authorization services. It may provide a service discovery service. It may provide storage of self-asserted identity data (sometimes called a personal data store). It may provide linkage of partial identities (attribute sets) across data sources. It may provide schema mapping of identity attributes and social relationships necessary to achieve data portability. It may provide an auditing service. It may provide Cloud Selector functionality (tunneling WS-* functionality through OpenID AX extensions). Finally, it may provide other “sync” services such as information card synchronization services (to synchronized cards across our browsers and devices). Various subsets of these functions are sometimes referred to as a relationship manager. I sometimes refer to the entire bundle as a personal identity agent.

Each developer community has chosen to name these same four actors different things. For example, in Oauth the “R” is called a “consumer”. Or in SAML the “R” is called a “service provider.” Here are some examples:

Actor	OpenID	SAML	WS-*	Oauth	VRM	ProtectServe	Higgins	ID-WSF
U	Browser	Browser or local app	Browser + Selector	Browser	Browser + [Selector]	Browser + [Selector]	Browser + [Selector]	Rich Web or local app
R	Service Provider	Service Provider	Relying Party	Consumer	Vendor	Consumer	Relying Party	Web Services Consumer
P	OP	IdP	IdP STS	Service Provider	Third Party	Service Provider	IdP STS	Web Services Provider
A	n/a	n/a	[future: CardSync]	n/a	4th Party	Authorization Manager	Cloud Selector, Identity Data Service, CardSync	ID-WSF Service Architecture/COT

Six interaction paths

As you can see there are a total six interaction paths between the four actors. Each path is named by the letters of its start and end. For example, path PA is the path between P and A. Similarly, PU, UA, etc.

So that’s the basics of the framework. With it we can more easily compare technologies and protocols like OpenID, Oauth, WS-*, ProtectServe, VRM, etc. I’ll begin to do so in future posts.

I really enjoyed the EIC conference in Munich last week. I flew in just in time to attend the launching of the German chapter of the ICF (informationcard.de). That meeting far exceeded my expectations. It was written up in here in a Heise Verlag site, Heise Online.

Of the many good things, one stands out. At that meeting Axel Nennker demonstrated an iPhone-based selector app. After the meeting I asked him how it launched the selector since there’s no way (legally) to add an HBX-like plugin to Mobile Safari. The Higgins iPhone selector that Markus Sabadello created requires you to jailbreak the phone. Axel’s answer was simplicity itself: you just define a URI scheme (e.g. “icard:”) and you associate the selector iPhone app with this scheme. The “RP Security Policy” is simply encoded as a set of parameters. And you can return (or post back) the security token. Oh, and he said the same approach will work on Android.

So now the ICF (and then likely the OASIS IMI TC) just has to define how the “Relying Party Security Policy” is encoded. Having struggled with the limitations of today’s <object> tag binding that Microsoft defined, I’m much more interested in us using another suggestion of Axel’s, namely that perhaps the first parameter is the URI of an XRD document. That way the API will be permanently stable while we slowly add new parameters and functionality to the XRD. Furthermore, this is compatible with recent conversations with David Recordon, John Bradley, Drummond, Bob Morgan, and so many others about a common “RP discovery” document.

Google and JanRain Release Support for the OpenID User Interface Extension. You can see it in action at UserVoice as implemented by RPX (see New from Google and RPX). The user experience of OpenID has just taken a step forward.

There’s been a lot of great progress at the ICF recently. RSA 2009 was the deadline we gave ourselves for much of it. Drummond Reed and his creative team have done an outstanding job renovating the ICF’s website. Have a look, it’s pretty wonderful. Craig Burton helped us create our first white paper entitled “The Information Card Ecosystem: The Fundamental Leap from Cookies and Passwords to Cards and Selectors.” Craig also provided lots of strategic advice behind the scenes. Best of all, the site features several example card projects. This really turned some heads. It showed that we’re starting to get some traction for Information Cards in the market. Andrew Nash demonstrated during his tutorial at RSA a prototype PayPal card that was used to log in to eBay. Drummond’s extraordinary performance in orchestrating all of this progress, led the ICF board to offer to Drummond that he be the permanent Executive Director, if he so chooses.