In Context

Comparing two “standards” stacks and one implementation project (Higgins):

I led a session about schema mapping at IIW last week. The basic idea is this. Rather than trying to get the world to agree to a single schema for attributes (e.g. OpenID AX, ICF Schema Catalog, Plaxo Portable Contacts, etc., etc., …you know the old saw that the great thing about standard is that there are so many of them (like 75!)) we just let the natural authorities for attributes mint their own URIs.

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 https://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 https://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 https://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 https://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.

Kudos to Kaliya and Phil for another great IIW. There was a great spirit of collaboration and I got the feeling that a lot of important work got done.

Browser Extension Convergence

I led a session on trying to converge towards a single browser extension for these four browsers: IE, FF, Safari, Chrome. Today we’ve got lots of browser extensions for different browsers each of which generally supports a specific protocol (e.g. OpenID or I-Card). What we’d like to get to is having one multi-protocol browser extension for each browser–that is, a total of four extensions. And eventually, we’d like to see these built into the browsers themselves. In the meeting we discovered that there was an opportunity to first agree on the specifications for auth discovery across protocols. This became the next part of the meeting…

Browser Support for RP Auth Discovery

Everyone agreed that creating common specs for this was a good idea, whether or not folks were interested in building implementations. (BTW, Phil was in this session and also blogged about this sub-topic). We saw that we could use XRDS as the basis for both OpenID as well as I-Card RP auth discovery, and perhaps others. Today I-Card tech embeds an HTML <object> tag, but Axel Nennker has put forward here and here a variation where instead of an embedded <object> tag we use a link/rel approach. Meanwhile, various OpenID folks have also been looking at using XRDS to discover RP auth metadata. Phil wrote:

Once the discovery protocol is decided upon, standard plugins could be written for Firefox, IE, Chrome, and Safari that would implement the discovery process for identity enable the browser for whatever identity system(s) the relying party supports. Four open source, community supported plugins could replace the myriad proprietary plugins available today. That would lead to greater penetration and also give browser manufacturers something to code against when the time comes that they want to build the discovery code into their product.

I can’t tell you excited I was a few weeks ago to get my hands on a copy of this book. The title pretty much says how the book is positioned. Being I guess what you’d call a “working ontologist” in the identity space, this was just the book I hoped it would be. You see, I wish I did have the time to attend the semweb-related conferences and invest enough time to become an expert, but I really don’t. In practice all I really can do is read a the few of the OWL and RDF books that I can find, buy the best tools that are out there (e.g. TopQuadrant), subscribe to the semweb IRC, and learn by making mistakes. The existing books are either out of date, poorly written or both. The problem with being self-taught is that I’m never quite sure that there isn’t some best practice that I’m not aware of. Here’s an example. In the last 18 months I’d been hearing more an more about SKOS. Being new, it isn’t covered in the existing books, so I sort of have to figure out for myself if it’s useful. It’s a lot more fun instead to read about it as presented by Dean and Jim. I have a lot of respect for both of them, and I was very eager to learn what I could from them. I appreciated the very practical sidebars, e.g. about the common misconceptions that OOP folks have with RDF, because I’ve struggled with these same issues myself. The book was rigorous enough to make me confident that I’m on the straight and narrow, without every lapsing into unnecessary formalism. I have recommended this book to the Higgins team, and highly recommend it to anyone.