In Context

This post is an attempt to summarize in one place some interoperability issues related to IMI PPID computation that we’ve run into as we get ready for RSA next week.

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)

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