In Context

I created these slides in response to a request 48 hours ago from Harry Halpin of the W3C’s social web experts group for a briefing on my views of the identity ecosystem.

If I’d had a bit more notice I should have added a discussion of the oStatus stack, XDI, RDF syndication and other things related to the pubsub of attributes. And VRM.

The open identity landscape today is semi-organized chaos. At an organizational level is perceived of as Kantara vs. ICF vs. OIDF vs. OIX vs. Identity Commons vs. …. At a tech level it is perceived of as OpenID vs. I-Cards vs. SAML vs. passwords vs. OpenID vNext vs. Oauth vs. UMA vs….  Some have buzz. Some have security. Some have maturity. There’s been lots of great work, and lots of progress. But all the same, we’re at an inflection point.

What our experience with open tech has taught us is that no single approach can address all of the use cases, security levels, levels of convenience, etc.  The fact both OpenID and I-Cards are underway with next generation efforts that will introduce at least some breaking changes speaks for itself. And username/password isn’t going away either. Heterogeneity is here to stay.

Let me illustrate. If you just look at authentication, and you ignore hardware-based solutions and look at cost (where cost means the hard dollar cost per user that an organziation will have to pay including help desk, user education, systems integration, operating costs, fees, etc.) plotted against the level of security required, my intuition is that the tradeoffs look roughly like this:

Or here’s another way to frame the issue. Different tech is suitable for different “volume” vs. long tail use cases:

If you need a third perspective, consider certification and the need for trust frameworks. The OIDF and ICF both jointly created the OIX organization to meet this (clearly cross-protocol) need. Yet there is still confusion about how this relates to Kantara’s IAF. Clearly certification and trust frameworks cut across the existing lines. Every technology needs a certification listing service. Every technology needs interoperability testing.

Based on just these examples of cross-cutting realities, I contend that most of the non-profits as we know them have outlived their usefulness in their current form:

• High overhead. Each spends money duplicating the resources, executive directors, infrastructure, etc. The result is that less work gets done promoting, say, OpenID, than it could otherwise.
• Lack of coherent messaging. In the enterprise market, for example, the louder each non-profit shouts the more the buyers sit on the fence and say “let’s wait and see which cat emerges from the bag.”
• Poor and inconsistent UX. The user experiences of each isn’t great. Try putting two or three together and the result is nonsensical.
• Not enough focus on relying parties. Relying parties are who adopt this stuff. We need clear messaging and we need great enabling libraries and services. After all, Janrain can only do so much!

The next step is consolidation

Creating a new consolidated non-profit for open identity that would combine existing groups and thereby create something quite different and new is an obvious and unoriginal idea. The question, as ever, is one of timing. Is now the moment? Kantara tried to pull this off a couple years ago, but that was too early. As my fellow board members on the ICF can attest, my sense of timing on this topic is too hurried. But all the same I can’t shake the feeling that now is the time to try to make some kind of progress. So I continue to have private conversations with friends and colleagues.

To protect the innocent I won’t name names, but I get generally supportive reactions. A recent plum was, “Good idea Paul, we’ll sit on the sidelines and watch you run around getting arrows in your back; we might even pull one out for you.”  For the moment and the record, I’m doing this without being duly authorized by Identity Commons, ICF, Kantara, or any other board I sit on.

Beyond reducing duplication and waste the most compelling argument for NewCo (what Bob Blakley might call IDTBD 2.0) is that we have no place to work on critical projects including:

• Cross protocol analytic framework (and common messaging). We need an analytic framework that helps RPs decide what open technology is right for what use case, cost target, LOA, etc. For example, I think we need a project team put together that takes my sketch of cost vs. security and calibrates it to actual “all in” costs and security levels by studying real world deployments. Let’s move away from the religious wars over whose tech is better.
• A consistent UX across technologies. The Kantara ULX group is doing good work but lives in a silo beside the OIDF’s efforts.
• A set of cross-protocol RP libraries and enabling technologies.
• R&D on active clients. A consensus has emerged. An active client has to build on, and work with OpenID (and other protocols) and not compete with it(them). I think an active client must also be a password manager. An active client must be optional; things should work without it and work “better with” it. The ICF is supposed to support active clients, yet work on OpenID v.Next goes on at the OIDF. This makes no sense to either organization.

Lastly, from a marketing point of view a startling amount of energy would be created by consolidating several websites into one. Of course true alignment will take years, but the perception of alignment even if we just start at the top would be powerful.

This post presents an architecture comprised of apps, a dashboard, and a personal data store (PDS) that can be implemented by multiple developers, hosted by multiple operators over an open, personal data network and whose goal is to give users more control over their own identity (personal data, profiles, preferences, affiliations, and relationships). It is in support of aspirations that have been widely reported by others and called variously VRM, data portability, user-centric identity, the Data Web, Augmented Social Network (2003), and so on.

I’ve annotated the diagram above with little “H” and “A” markers so you can see specifically the areas that Higgins and Azigo are working on respectively. Lots of other folks are also working on other parts of the picture too, of course.

Apps

Apps are of course the most important kind of component since they are what the end user sees and appreciates. Apps gain access to the user’s data by making calls (e.g. getAttribute) to an API exposed by the PDS Client. Architecturally, we’ve seen the need to support both conventional kinds of apps: web, mobile (iPhone, Android, etc.), and desktop, as well as a more unusual kind of app, I’ll call a Javascript app.  In this latter case Javascript is fetched from a web service (e.g. from Kynetx KNS) injected locally into your browser by a browser extension. This same browser extension exposes the same PDS Client API to this Javascript program.

Dashboard

The dashboard is an admin GUI app for your personal data. It is an occasional-use tool that provides: (a) a control panel to manage the permissioning policies that control which of your attributes are shared with whom (including so-called “selector” functionality to approve the release of your info)  (b) a dashboard GUI to see and manage all of your identity data attributes (including profile data, credentials, friends lists, etc.) whether stored in your own PDS or managed by others (c) a place to directly enter self-asserted attributes (d) an embedded app marketplace (e) a canvas area where apps can extend the UI to add their own admin interfaces (f) a place to import & manage your i-cards and OpenID OP relationships.

ASIDE: Dashboard is a new word I’m trying out. The reality is that this piece of software is a bit of a swiss army knife where each blade/tool is called something different. A few examples: Microsoft calls the aspect that pops up to give notice and consent to release a set of attributes an identity selector. Inside Google they call identity-related client add-ons to a browser an active client. The “show me all of my stuff” aspect does sound like a dashboard. On the other hand, the permissioning aspect is something Eve would call a relationship manager (or I think she would). And I think Bob Blakley would too.

The dashboard combines aspects of earlier client efforts. In 2006-2007 we saw Information Card Selectors like Windows CardSpace as well as the Higgins selectors provide an interface to view and manage multiple digital identities displayed as visual cards, as well as provide notice and consent to the release of your selected digital identity. In 2009 Azigo augmented the selector concept support for Kynetx apps in Azigo (along with cross-platform and card roaming support). Prototypes shown by Microsoft (e.g. OpenID Active Client) and Higgins at IIW in 2009 added OpenID support thus demonstrating multi-protocol support. Mozilla Lab’s Account Manager is doing some great work in this area. The Higgins project is working on a next-generation client as part of the Higgins 2.0 Active Client expected in 2011.

Personal Data Store

A PDS is a web service that works on your behalf, giving you more control over your own personal data whether it is stored in the PDS or managed elsewhere. PDS stores local attributes in blinded form so that only the user has the decryption key–not the PDS service provider. The PDS is an idea that has been underdevelopment for years. For some background see Joe Andrieu, Joe again, and Iain Henderson. As part of Higgins 2.0 the PDS is being developed. Another interesting PDS development project is Mine!

PDS Client

The PDS Client has no UI, but provides an API for apps that wish to read/write attributes from the PDS. Here are some of its functions:

• Maintains (and syncs to the PDS and other clients) the user’s ”permissions”–the decisions that the user has make as to who (what app or relying party) has access to what attributes. For example, the first time a new app/RP asks for a certain set of attributes, the PDS Client will trigger the PDS Dashboard to present the policy decision to the user. The next time this same request happens, the PDS Client remembers the grant and usually doesn’t have to bother the user about it this time.
• Maintains a local copy of some or all of the person’s personal data stored in the remote PDS
• Maintains an OAuth WRAP access token that it gets by authenticating itself to an external authentication service. It passes this token along in XDI messages to the remote PDS service.
• Can be configured to encrypt attribute values before they are sent over the wire (e.g. in XDI messages) to the remote PDS
• Contains a local Security Token Service (STS) that allows it to create and sign SAML (for example) tokens for self-asserted attributes.
• Contains an STS client to support remote IdP/STSes managed by external parties (e.g. to support managed i-cards).
• Performs cross-context schema mapping.

The Higgins 2.0 PDS Client is packaged as either a C++ or Java code library or as a separate operating system process (e.g. on Windows it is a Windows Service).

Network Protocol

Drummond Reed with his OASIS XDI and OASIS XRI work was first to my knowledge to define an open data web. A few years later Tim published his Linked Data paper. We’re starting to see implementations of Linked Data so now the Semweb folks also have a data web. Both of these approaches are important.

An open community is starting to form around the XDI that is focused on PDS-related use cases and create might be called a profile of XDI in this area. The community is leveraging XDI’s existing strengths in the areas of identity management integration, security, access control, data sharing and versioning, as well as extending them where needed in order to meet the PDS-related requirements.

This focus probably provides a critical time-to-adoption advantage over the Linked Data effort in this PDS area. Since the objective is interoperability (i.e. an interoperable ecosystem of PDSes and apps over a common protocol) assembling a community focused on this area would seem to be the fasted way to get there. Linked Data (like “vanilla” XDI) has a much broader link-all-the-worlds-data-together mission and lacks direct support for many of the PDS-related requirements. As a consequence RDF developers (including Higgins) define ad-hoc extensions to RDF to make it support the PDS use cases that are only interoperable within their own developer community.

PDS Schema

The Higgins PDS uses its own internal schema called the Persona data model. This is not to say that the PDS architecture imposes a single ontology on its clients. Quite the opposite. Every attribute call (e.g. getAttribute) may request attributes in any vocabulary. As I’ve mentioned in my schema mapping post, we follow the philosophy of mapping into and out from the internal schema.

Authorization Manager (AM)

The AM provides the “back end” authorization manager for access control of attributes managed by data services other than your own PDS. The Higgins project has been tracking the promising UMA Authorization Manager effort that Eve Maler and others have been developing.

Kynetx KNS

KNS is a web service that serves up compiled Javascript apps for injection into browsers. The app developer uses the Kynetx AppBuilder tool to create apps. Each app is packaged as an information card. The developer puts this app on their website for folks to download and install. If you click on it and already have a PDS Dashboard the new app gets installed in about one second. If you click on it an you don’t already have a PDS Dashboard, then you download an installation package that includes a Dashboard (with the app pre-installed inside it).

• Kantara ULX WG – a quick intro to what we’re trying to do
• Relationship cards – newbie intro

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 (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.