In Context

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

Goodbye, Passwords. You Aren’t a Good Defense written by Randy Stross of the NY Times appeared today. The article starts off well and focuses entirely on the problem of passwords. I particularly like the line:

In short, we need a log-on system that relies on cryptography, not mnemonics.

Very nice. As for the rest of the article, well, everyone knows I’m a fan of Information Cards so I was glad of the mentions (especially of the Information Card Foundation). But I’m also a fan of OpenID, though not in its current form nor how it is being presented as web-scale SSO. The essence of OpenID provides a missing piece of the puzzle that Information Cards don’t. The concept is to provide the user with a web address to a set of services that work (continuously) on behalf of that user. “Pure” i-cards don’t. Pure i-card solutions (e.g. CardSpace) only work when the user is sitting in front of their machine.

Pitting one technology against another and focusing on getting rid of passwords, probably creates a more exciting story. But what we need to do is combine the best ideas from a set of complementary technologies, to create a great solution. With the right combination, you also get synergy. For example, many limitations of “pure” OpenID go away when combined with Information Card’s client architecture.

I really don’t think we’ll get Internet scale adoption with any of the “pure-play,” partial solutions, on their own. Instead, take an “extract” of OpenID, mix in a derivative of Liberty (esp. ID-WSF) services at that endpoint, top it off with i-cards, browser integration, and run it on all platforms (including mobile), and maybe we’ll have a recipe for something that works in enough real world situations to be generally useful.

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.