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…
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.
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:
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).
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.
Here’s an idea that will let your trusty selector log you in to the other 99.999…% of sites that don’t yet support I-Card, OpenID, SAML, Facebook Connect, or Google Friend Connect.
One of the long term goals of the Higgins project is to provide universal login. This is the ability to log you in to almost any website or app (aka Relying Party (RP)) using a variety of methods including I-Card (as defined in ISIP 1.5 and soon here-ish), OpenID and username/password.
As a step towards universal login, I’ve written up this summary of password cards based on input from many folks. The basic idea is to enhance the Higgins browser extension with “password manager” capabilities, and to enhance the selector such that it can store your usernames and passwords as claim values on personal cards, and to do so with special care to prevent phishing attacks.
As I mentioned here, I see this work as a step towards convergence on single browser extension that “just works” (universal login). Beyond un/pw and I-Card we’d like to integrate support for what the IDIB folks, Axel Nennker, and others are doing with OpenID. And then there’s SAML.
Odd as it may seem, by embracing passwords, we’ll help eliminate them. Or at least I hope so.
Dave Kearns has written an article explaining that, if solutions are architected correctly, there’s no meaningful difference between the two. He writes:
We start by defining identity as a group of “personas” (see “Defining identity, persona, role”). Any persona can be made up of a group of personas or roles. Each of those personas can be linked, or separated, as the entity identified by them wishes. One of those personas is (or, rather, could be) an “enterprise persona.” That one brings together “…all the activities and attributes of a single entity” performed for or related to that enterprise “into a readily accessible (and reportable and auditable) form.”
So there is no “user-centric” or “enterprise-centric” identity. There is just an entity with AN identity made up of various personas some of which may be controlled or limited in some way by an outside organization – not only by the enterprise but also by governments, social organizations, etc. The ability to keep these personas separate, where legally able to do so, must be a given. Each persona will have different identity needs and requirements, of course, but that’s what will drive the “identity economy” as vendors seek to satisfy those needs and requirements in accordance with the laws. The government’s laws, the enterprise’s “laws”, the fraternal and social organization’s “laws” and the Laws of Identity as laid down by Cameron.
I really didn’t understand this when I started the Higgins project back in 2003. I was trying to scratch a personal itch. I wanted a personal dashboard that would pull together all of my profiles and social relationships. I felt like my various personas and buddy lists were scattered all over the web in hundreds of silos/sites.
Later when my colleague Mary Ruddy described the Higgins project to Jamie Lewis, Jamie suggested that we talk to Tony Nadalin (IBM) and Kim Cameron. My initial reaction was “no,” and “no way” [respectively]. I figured that I was working on a user-centric solution that would work for me, as an individual. So why would we talk to IBM, they sell to enterprises [so surely what we're working on can't be of interest]. And as for talking to Microsoft (I didn’t know Kim at the time)…why would I talk to the folks that brought us Hailstorm and Passport?
As history has shown, I was wrong on both counts. Luckily, Jamie was persuasive and Mary was insistent. We have since joined forces with Tony and Kim. Tony explained to us that the problems facing the enterprise were extremely relevant to Higgins and that there was no conflict. And Kim (and later Mike Jones and others) won us over by showing that Microsoft could be a good actor in this space. [So much so that the Higgins project decided to invest a ton of resources on making sure that its "card-based" metaphor and file formats were a pure super-set conceptually, functionally, and architecturally WRT CardSpace.]
It’s a common misconception that Information Card technology is proprietary to Microsoft. In the past there there has been some truth to this, and I realize that most people think it remains true, but it isn’t. Quite the contrary.
The design work behind what is now called Information Card technology started about five years ago at Microsoft, IBM (e.g. in the co-development of WS-Trust), Higgins, and a few other places. The pereception that it was a “Microsoft” technology was created by a series of actions and omissions by Microsoft over the intervening years. Some were intentional, some not. Many had unforeseen consequences.
From the beginning Microsoft was focused on shipping a product as soon as possible. Although getting CardSpace to ship in Nov 2006 was in and of itself a good thing, their lack of progress in other areas had consequences that worked against creating a vibrant ecosystem of interoperable, competing implementations based on open standards.
To some extent getting a 1.0 product out the door so far ahead of when others could ship helped create the perception that indeed this was a Microsoft dominated technology. The other projects were held up a combination of IPR issues, resource issues and the difficulty of understanding how CardSpace worked in some cases. Even little things contributed. For a time Microsoft used the term Information Card in Microsoft documents in a way that implied that it was a Microsoft term rather than an open, industry term. Nor did code-naming the product, “InfoCard”. More troublesome was how long it took Microsoft to release the CardSpace-related IP behind under the Microsoft OSP. Worst of all, it has only been in recent weeks that the last few remaining protocol design documents have been submitted to an SDO–in this case the new OASIS IMI TC.
Of course, Kim, Mike, and others always knew that to be successful there had to be open, standard protocols and multiple competing selectors (and other IdP and RP services) running on all platforms and mobile devices. I’ve always felt that they saw the big picture. And I think it’s fair to say that compared to Microsoft’s normal modus operandi there has been unprecedented level of openness, collaboration, and good will.
And in the end, and to Microsoft’s credit, everything did get done. Today there are open source implementations that interoperate with CardSpace, and in various ways go beyond CardSpace, living in open source projects like Higgins, Novell’s Bandit, OpenInfoCard, Pamela and others. The technology has recently gotten its own Information Card Foundation. The ICF and its members, with the addition of IBM, have provided most of the funding and resources for the OSIS series of interop events involving card issuing sites, selectors and relying sites (and relying apps). The one at RSA had 53 companies and open source projects collaborating together. The next and fourth one will be at DIDW.
So today, Information Card, InfoCard, I-Card (or whatever you call it) technology is open, free, and not a Microsoft proprietary technology.
-Paul
PS: Ben Laurie’s voice is echoing in my head right now. How Information Card implementations work interoperably between Microsoft’s Credentica-developed selective disclosure technology and the IBM Zurich Idemix technology has yet to be seen. I’d say there’s reason to be hopeful. Fingers crossed.
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.
I’m very glad I’ve come to Doc’s Vendor Relationship Management (VRM) workshop at the Berkman center this week Among other things, I’ve met some wonderful new fellow travelers in this promising new space. I was particularly interested in the discussions centered on defining the value proposition for the “v” in VRM–the merchants, manufacturers, and so on that would like a better relationship with there customers, members, patients and citizens. I also enjoyed the chance to up with the other startups in this area.
On a tech level, I remain convinced that VRM is an application layer over identity infrastructure. More specifically, it seems that the VRM “rel button” concept blends well with r-cards.
Powered by WordPress