In Context

I’m very happy to announce that we’ve hired Jeff Carter, Bank of America veteran and the founder of MIT’s Center for the Future of Banking as CEO of Azigo. I’ll continue on as Azigo’s CTO with as much enthusiasm as ever. Even more! The press release about Jeff was covered here, here and here.

Jeff is flying back today from keynoting at Amplify 09 in Sydney. Here is a writeup of some of what Jeff had to say about the future of banking.

The White House has completed its 60 day Cyber Policy Review and published it as a 76 page PDF. This was announced on the whitehouse.gov blog post Securing Our Digital Future. I co-authored with Kim Taipale, Bill Coleman and John Clippinger of an invited paper entitled Identity and Resiliance (PDF), one of the 100 papers mentioned in that blog post that informed their recommendations.

Slowly but surely the understanding is growing in various pockets within our government that a user-centered, distributed, open identity layer (bus or metasystem, pick your poison) is critical infrastructure for both security and collaboration.

Privo, Microsoft and Azigo have announced Privo Puts Parents in Charge Online with Information Cards.

Denise Tayloe (CEO of Privo) is friend, colleague and an expert in the field of protecting children online. Denise has created web services for major online businesses that other experts have told me “can’t be done” while adhering to COPPA.

Azigo and Microsoft, each in different ways, have been very supportive of Denise, Privo, and the general concept that child-protecting solutions could be based Information Cards as a technology foundation. For our part, Privo’s new card issuing site is powered by Azigo CardPress. But our relationship goes much further. For example, last year Denise and I co-authored a paper that we submitted to the Berkman Center’s Internet Safety Technical Task Force. [I should dig that up and put a link to it]. Their final report is here. I blogged about it here.

See Acxiom Launches Online Identity Card to Help Businesses for the press release. More info from Acxiom.

I’m proud to say that the site is powered by Azigo CardPress.

[I'm not wild about calling these things "identity" cards, because they don't necessarily identify you. If the relying site (or local app) only requires non-identifying claims, then even if the Acxiom card supports identifying claims, these identifying claims won't be released to the relying party. Equifax chose the same language. Maybe they both know something I don't.]

Problem statement

We have no name for the “protocol that defines the interaction between a card selector and a relying party Website (or a local relying party application) that was originally defined by Microsoft in the “Identity Selector Interoperability Profile” (ISIP) documents, is now being standardized at the OASIS IMI TC and was first implemented by CardSpace™ (and later independently by others).”

[BTW, we also lack a name for the set of protocols (centered on WS-Trust, but including WS-MetadataExchange, and others) that define the interaction between a card selector and an STS (IdP), but I think calling this WS-Trust or WS-* will probably suffice for most cases. Since only IdPs care about this protocol suite, and since there are so many fewer of these than RPs this naming problem is a less pressing issue.]

Three candidates found in the wild

• Some folks call the <no-name> protocol “Information Card” (or InfoCard or I-Card). For example, major websites are telling us that they would like to support both the “OpenID” protocol and the “Information Card” protocol. The problem is, this usage confuses a user metaphor with a protocol. Information Cards (and selectors) will ultimately work with lots of protocols (e.g. <no-name>, OpenID, and SAML) as well as a with a perenial favorite of mine “username/password!”

• Some folks refer to the <no-name> protocol as “IMI” after the name of the OASIS Technical Committee mentioned in the problem statement above.

• Many folks (especially in Europe) refer to the <no-name> protocol as “CardSpace.”

My two cents…

In formal documents (e.g. at the ICF) we could refer to it as “IMI Protocol” and informally we could call it the IMI(CardSpace) Protocol.

Apologies all around

If this is the direction we as a community take, then I want to apologize to Stefan at Fun Communications and lots of other folks for my earlier confusion on this matter.

Having worked on selectors for so long I’ve needed to remind myself that there really is life before you have a Card Selector installed on your machine. And now that I look into it, I see that this selector pre-existence could use some improvement.

The Problem

Imagine a person without a selector goes to a website that displays three ways to log in: (1) username/password fields, (2) the purple I-Card Icon:

and an OpenID NASCAR like this (courtesy of JanRain’s very cool RPX):

The OpenID NASCAR consumes a vast amount of real estate and it has other issues that have been widely discussed. But compared to the purple icon, it’s much better. Why? The user might recognize some of the logos and best of all, if you click on one of them you’ll begin the process of getting an OpenID, and eventually logging in. By contrast the user probably doesn’t know what that purple icon even is and what to do next. There are no familiar logos, and no instructions as to what to do. It seems like the Information Card community has focused so much on the UX AFTER you have a selector, that the user’s life BEFORE they have a selector installed has been ignored.

Some Suggestions

The rest of this post gives some suggestions as to what might be done to help the selector-less user. First, perhaps the purple icon should always have some “hover” text that pops up. Something like this:

The hover text is there to try to make you click on the darn thing. When you click on it, what happens next depends on what cards the site trusts. If it only trusts one site then you might see this:

Or if it trusts a bunch of issuers, it might look like this:

And of course if you click on a card image from card issuer “A”, then you are redirected to site A and walked step by step through a card issuance process. Then, when you’re done getting the card, you can download site A’s recommended selector or click through to this page on the ICF’s site. [That page needs work too!]. And then when all of this is done perhaps site “A” could redirect you back to the original website with the purple icon, where you could try clicking it again. Armed with a selector the purple icon should have different hover text. And as we all know when you click it, it WILL launch your spanking new selector.

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.