In Context

I thought I’d start with the diagram above and add the explanatory text later. But for now, as I hope you can see, I’ve been trying to create a visual summary of these three tech stacks and how they implement different necessary capabilities for user-centric personal information sharing. More later…

On the morning of July 5th I had breakfast with Iain Henderson and David Alexander of Mydex. And then, within 5 minutes of walking in to the IoS meeting I met Serge, Sampo and Graham. Between meeting them on the one hand and the breakfast on the other I knew the whole trip was worthwhile. It’s a great pleasure to spend time with people who share the vision of giving individuals more control over their own personal data. We all had a chance to share what we’re all learning about creating Personal Data Stores, VRM (TRM?), user managed identity, data portability, etc.

Check out Internet of Subjects. This is a new effort that deserves our support. I particularly like the fact that it’s not based in the (privacy-challenged) US. The effort is being indirectly supported by EU investments in TAS3, a project that I’m only now learning about.

Here’s a quote from Graham Sadd’s post about the IoS meeting:

Serge Ravet, CEO of EIfEL, prefaced the Eifel Learning Forum with the inaugural Internet of Subjects Forum to an international audience in London yesterday. The plenary presentations were made by Sampo Kellomaki, Chief Architect at Symlabs, Graham Sadd, Founder & CEO of PAOGA (read interview) and Paul Trevithick – Founder of Higgins Project and CEO of Azigo.

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:

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.

Well, here’s a new organization, iosf.org, that I should have known about. I hope I can get to their event. It’s on July 5th and I have to be in Paris on the 6th for an Information Card workshop with FC2. Hmmm…should be possible.

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

At RSA Ely Kahn (Director of Cybersecurity Policy at National Security Staff) and some of his contractors/staff met with members of the ICF board as well as with members of the OIDF and OIX boards. During the meeting the foundations were asked to respond to a questionnaire that was designed inform the “National Strategy for Secure Online Transactions” (NS-SOT) –a name chosen to sidestep the big brother alarm raised whenever words like identity management are used by the feds. He mentioned that Obama would be announcing this strategy in June.

Instead of answering the questionnaire the ICF board decided to write and send this NS-SOT ICF Response to Ely. Ely is one of the good guys, so I’m glad to spend time on this sort of thing. The jist of the paper is that relatively small, short term (not FY12 !) investment in turning a few Federal agencies into buyers of federated/externalized identities would jump-start an entire ecosystem. It would be particularly good for i-cards and OpenID.

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

Open Trust Frameworks for Open Government. Jointly created by the OpenID Foundation and the Information Card Foundation.

I’m just back from DC at the GSA’s IdManagement Privacy Workshop where this paper was presented by Don and Drummond (the two E.D.s) on a panel moderated by Mary Ruddy.

Don’s related post.

Axel contributed this: