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

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.

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

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.

Specifications

There are two specifications of how to compute the PPID:

1. ISIP 1.0
2. IMI 1.0 (same as ISIP 1.5 submission). A clarification was added as described here: (see  Changes Made in ISIP V1.5 on page 72). It says: “To provide a migration path from non-EV to EV certs, the RP PPID Seed for a non-EV cert containing the same OLSC values is the same as for an EV cert, resulting in the same PPID”

In addition, here’s a very detailed article about this calculation, with example values. Mike suggests that anyone wanting to debug their implementation might want to check its calculations against these known-good values.

CardSpace Versions

1. .Net 3.0 version: implements ISIP 1.0 according to Mike
2. .Net 3.5 version: implements IMI 1.0 according to Mike
3. .Net 3.5 SP1 version: (i) implements IMI 1.0a for token of p-card (ii) implements both ISIP 1.0, and IMI 1.0 to find a p-card that matches the PPID credentials of a “backed” m-card.
4. .Net 3.5 SP2 version: same as #3 above
5. CardSpace 2.0 beta version: same as #3 above

Azigo Versions

• 2.0.0.35 –> 2.0.0.40 versions: implement IMI 1.0

Higgins STS

• Higgins 1.1 STS implements IMI 1.0

Avoco Versions

• It appears to use different PPID-related logic than CardSpace WRT to finding a matching p-card against the PPID of a backed m-card.

Known Incompatibilities (bugs):

1. Pam reported: You can’t export a p-card backed m-card from Azigo 2.0.0.35 and import into .Net 3.5 SP1 version of CardSpace.
2. Paul Battersby of Avoco reported: 1) An Azigo Managed card backed by a CardSpace Personal card using a crds imported from CardSpace. 2) An Azigo Managed card backed by an Azigo Personal card using a crds imported from Azigo Desktop selector. In the first case the PPID matches (i.e. the PPID calculated by the selector matches the PPID stored in the managed card). The algorithm uses a Relying Party Id generated from |O=”*.azigo.net”|L=””|S=””|C=””|. The second scenario fails. However, if I force the code to use a Relying Party Id generated from the public key of the certificate then the PPID matches. This is rather strange as the certificates in the Managed cards from both scenarios are exactly the same and the public key should only be used if the certificate is not valid or the Organizational units are empty.
3. JohnB recently pointed out that Azigo 2.0.0.40 and CardSpace .Net 3.5 SP2 generate different (and thus incompatible) PPID values on p-cards for the PayPal site (site with an EV cert)

The first two above are caused by the same set of inter-related issues. The root cause is an inability to validate the certificate of cardpres.azigo.net and as a result Azigo computes the wrong PPID for this site. We thought that we could fix this by including then entire certificate chain in the .crd. We did this today, but there are other related issues and we need another 2 days to deploy a new version of our hosted i-card service (service.azigo.com)

And while we’re being lazy, we just sit back and watch as these schema-creators evangelize their particular schema as far and as wide as they wish to. Today the only way an IdP can talk to an RP is if both know how to speak a common schema. This is true regardless of protocol or transport. It is as true of SAML tokens as OpenID attributes.

Its all a form of tight coupling. And tight coupling requires a lot of effort. You know what they say “consensus is harder than code.” Experience shows that the richer the schema the higher the costs to get everyone on board, the longer the process takes, and the narrower the diffusion/adoption. These economic realities drive the creation of more and newer schemas in each sub-ecosystem, even when common schemas could theoretically be agreed to.

But if we can’t all agree to the “one schema to rule them all” aren’t we doomed to a Tower of Babel?

Not entirely. There is another possible route to interoperability. Mapping. Instead of creating N*N mappings between each schema we create 2N mappings into and out from a common, rich, granualr, and horribly complicated schema (that nobody would use directly).

We use a mechanical process (think web service, library, etc.) that maps an input schema into a rich, intermediate schema, and from there to an output schema. This schema mapping process, being both algorithmic and data driven, can live at the RP, in the cloud, or at the IdP, depending on the need.

I will now describe one way to do this schema mapping. I have a personal bias towards declarative approaches that involve rich data and simple algorithms. The mapping rules that I’m about to describe can themselves be described as data with embedded names of a few simple functions. So that’s the design approach. Here are the details.

Every input attribute must come from some known namespace (schema name). A set of mapping rules must have already been created; one for each attribute in the input schema. The rule for the specific input attribute is then looked up and applied to transform this input attribute into its equivalent attribute(s) in the internal, intermediate data model (schema). To create the output attribute(s) the process is reversed. The target namespace (schema name) must be known, and a set of mapping rules must have been created for it. The output process takes the attribute in the internal data model, looks up the mapping rule for it and uses this rule to generate the output attribute.

This approach was discussed a lot on the second day of the recent Tao of Attributes workshop, and a some similar thinking was discussed a couple years ago regarding a Common Dictionary Service (CDS) on the IdentitySchemas.org list at Identity Commons

The Higgins project is starting work on an open source Persona Data Model that could serve as a common internal schema. A schema that nobody would actually use per se, but useful to map into and out from. We’re also experimenting with declarative mapping rules.

A quick aside:

The straw that broke the camel’s back for me happened recently. In the ICF’s Schema Working Group, we created a super-lightweight, email-based process to simply list whatever attribute/claim URIs that any party reasonably suggested they wanted. Here’s the catalog we created. When Equifax wanted an “I’m over 18″ URI we swung into action and minted http://schemas.informationcard.net/@ics/age-18-or-over/2008-11. Cool.

Then the ICF and OpenID foundations start working together with the GSA and other parts of the Federal government. There’s a need for a “Level of Assurance” 1 claim. No problem. We created http://schemas.informationcard.net/@ics/icam-assurance-level-1/2009-06. Trouble is, when the GSA’s profile for IMI Infocards was published the URI started with http://idmanagement.gov.

Why? Who knows. That’s what they wanted. And since (sadly) in SAML there are no sub-namespaces allowed with the URI namespace, one URI is as good as another since all must be treated as an opaque string. So it’s hard to push back on the “customer” and tell them that the attribute should really start off http://schemas.informationcard.net…  They think that the LOA 1 URI is theirs. To make a separate URI and thus define another schema over such a trifling matter, was all the convincing that I needed to rethink things.