In Context

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

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

RPs are the most important actors. Open identity technologies (OpenID, Infocard, SAML, etc.) will only succeed as websites and apps (aka Relying Parties) adopt them. And since by definition the concept of open identity involves reuse of existing accounts from external identity providers, there will always be more RPs than providers.

RP developers aren’t identity experts we need to create libraries and web services to make it as easy as possible for them to implement all this stuff. This has been widely recognized. But another factor in making open identity tech RP-friendly is to make sure that these libraries, etc. support the semantics that are natural from the RP’s point of view.

What RPs want. An RP wants to rely on some attributes from an external source. Sometimes they only want a single identifier attribute (e.g. Google OpenID)). Sometimes they want more (e.g. the institution that you are a student of, etc.).

Of course the authority asserting the attribute is also important. But this varies by attribute. For example, an RP site may be perfectly fine letting the user self-assert a “ship to” address, or asserting an email address to send a confirmation to. Whereas they’d like a third party like the city fire department to be the provider of an attribute that states that this user a registered fireman and thus should be allowed have access to a federal first responder portal.

Attribute request semantics. If this is what RPs want, then they should be able to express their desires in a natural way. A list of attributes with some extra fields would seem to make sense. How about a list of attribute request tuples each of which holds:

• Attribute – e.g. email, age > 21, GPS location, first name, employer…
• Optional – true if the RP requires  v.s desires this attribute
• Authorities – list of authorities that the RP trusts for this attribute (if nil, then self-asserted data by the user is fine). This is essentially the RP’s white list.

Mismatch. Do OpenID, Infocard etc. allow the above semantics to be expressed? The short answer is no. In essense, we can’t express things from the point of view of the RP.

Moving forward. The attributes first principle has grown out of a growing recognition of the critical role RPs play in the adoption of open identity technology. It now influences my thinking about RP identity infrastructure, and is being incorporated into our thinking about “next gen” selectors.

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:

Nat has started a blog post on this topic here. Back when the Identity Gang was young I used to spend a lot of time on this definitional work as editor of the Identity Commons Lexicon. A topic near and dear to my heart. I particularly Nat’s image:

Identity in Context

It properly captures the contextual nature of identity. Maybe underplays it a little.

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 in yahoo finance, CNBC, here and in Mass High Tech article

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.

Acxiom is now an Information Card issuer! 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.

[A nit. 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.