Pete Rowley

Mike Beach is obviously a fellow who likes to ask the hard questions. This time he is asking how Higgins differs from a virtual directory. There is some level of confusion out there so in order to add a little clarity my answer would be that the difference is one of perspective and granularity. QED.

Well, I suppose I ought to explain that a little. You see, Higgins is either a lego brick or a gear stick. Which it is depends on whose favourite analogy you use, Dale’s or Kim’s. Dale might say it is a lego brick that you use to build other things, and Kim might say that it is a gear stick that works in a way we all understand because it works like other gear sticks. Or something like that. In any case, the point is that Paul Trevithick says Higgins is a framework. I suspect most would be happier with an explaination that it is a set of API’s for representing information about people along with the glue to connect one api to another and some other goodies like common schema. In object oriented pattern theory/design/voodoo it fits into the bridge pattern. Higgins is the bridge with the common interface to multiple systems. Yes, it’s a version of that lego brick that must also exist in virtual and meta-directories. So much for granularity.

Changing perspective lets get to the gear stick. Part of the Higgins project as a whole is to build a CardSpace like identity selector. Lets be clear - Higgins is the framework, the identity selector is one possible use of the framework. An identity selector requires a gear stick and Higgins looks like a gear stick. Of course, gear sticks don’t exist in a vacuum, they are usually accompanied by a steering wheel, a brake pedal, and an accellerator pedal. There needs to be a clutch pedal to aid gear changes and in some of the more luxurious gear stick implementations there will be a drivers seat right next to them. So, the Higgins identity selector is a bunch of co-operating parts that in some people’s blogs might look like a car, and the Higgins framework is one of the parts necessary to build a car.

Virtual Directories? Space ships, virtual directories are space ships with gear sticks. But that’s for another blog.

Ping Identity has re-affirmed what they were saying at the Digital ID World recently, that they will open source their Java STS code primarily for use by the OSIS project as a Managed Card IdP/SP Server. This is a welcome development that should help speed along various projects. Cheers to the guys at Ping.

Paul Madsen has spoken on the SAML Enhanced Client Profile and his verdict is it’s like a donut. Now far be it from me to contradict Paul and his immeasurable skills in producing professional looking diagrams, but perhaps he should note the words of Mark Wahl in his comment that it looks like it “might have a ‘hole’ at its very center where it does not provide coverage?”

Paul, I suggest using carrots. Nice high profile colour, tapered end useful for zeroing in on the axis position, no holes.

So, where is the digital you?

There has been a lot of focus on user-centric identity in recent months, but let us not forget about the identity metasystem. The identity metasystem concept is important because it recognizes that even if it is desirable for there to be one protocol that everyone speaks, to get there from here requires a pragmatic acceptance that there will be more than one protocol in the meantime. While choice is a marvelous thing in many situations, it isn’t something that the vendor relishes at the protocol level. When the customer comes calling must you turn them away because they speak OpenID and your software speaks SAML? Recalling my blog regarding the Microsoft Open Specification Promise, multiple standards mean your bolts don’t fit your nuts unless you buy them both from the same vendor. The identity metasystem must provide the necessary adapters so that different systems produced by different vendors on different platforms can at least understand each other, even if they don’t speak the same language.

One might ask who will be building the parts that make the system a metasystem. Clearly, one vendor who is doing that is Microsoft with CardSpace. However, one vendor a metasystem doesn’t make. To make the identity metasystem a reality it must come from multiple vendors, it must be ubiquitous, and it must be in the DNA of the platform. This is why open source efforts such as the Higgins project are so important, because they provide the means to make the identity metasystem cross-platform, cross-vendor, and cross-identity context. This might be considered the primary focus of the OSIS project as a whole - to make the identity metasystem happen. Red Hat supports the efforts of these projects and any project that works to make the identity metasystem a reality.

The correct answer to the question “where is the digital you?”

Everywhere.

Andre Durand has been blogging about the mash-up between user-centric identity and federated identity. His company, Ping Identity has put forward the idea of active versus passive federation. Active federation is essentially user-centric federation, and passive federation is the classic federation model where big business gets together and talks about us while we all watch the pretty pictures. In his recent presentation at Digital ID World, Ping CTO Patrick Harding had some great enterprise use cases where user-centric identity added the element of consent to the transaction, for example, access to a 401k account, or outsourced payroll services.

Now, while marketing must have its marketing phrases and there is nothing inherently wrong with active/passive federation, I think the rest of us might find the phrase consentual federation a little more descriptive. After all, consent is the major difference between the two. Oh, but what then to call the other type of federation… sneaky federation?

Sometimes a promise is better than just any old promise, sometimes it is worded in such a way as to legally bind the promiser from reneging on that promise in any meaningful way. There is a legal term used for this kind of binding promise: estoppel. Sometimes such a promise might be made by mistake, and estoppel is used to make the promising party honor the promise in court. That is, it is used to defeat a lawsuit made by the promiser against you. Sometimes the promise is made by the promiser with the intention of binding themselves to the promise with full knowledge the promise essentially relinquishes any legal claim.

Why is that useful? Well, in many spheres standards are used to ensure interoperability between vendors, so that for example a nut and bolt vendor can produce nuts and bolts compatible with other nut and bolt vendors, and software vendors can produce software that interoperates with the software of other vendors. This is why when you buy a nut or a bolt you are concerned only with the size of the part and not which vendor made the part with which it is to connect. However, standards that have technology that is covered by current patents or even patent applications present a problem for the vendors that do not own the patents. At any time the patent owner may reveal the patent ownership, charge fees, or even deny a vendor the ability to create or sell technology based on the compromised standard. It doesn’t stop there, patents allow the holders to sue end users, i.e. the customers of those vendors. The term open standard is often used to describe these standards that are intended for interoperability, but of course the current system of software patents prevalent in the US can often render the “open” part redundant. However, a patent holder might decide that their interests are better served by wide implementation of a standard, and in these cases a binding promise makes good sense.

As much as patents might be painful for corporations, they have an especially chilling effect on open source. You see corporations can assess a risk of being sued and decide that the level of risk is acceptable. It has become a cost of doing business. However, in the open source world each code contributor to a project is potentially liable, each end user is liable, and each distributor is liable. A distributor of open source software has a special, moral, responsibility to protect those to whom they distribute and those who are subsequent recipients. It is not possible to assess risk in the same way as a proprietary software company because all of those subsequently effected by the decision cannot possibly have an input. If it is known that there are even potential patent issues with a software technology, it behoves the potential distributor to pass. In fact, the GPL requires it. That is why you will not find an mp3 player as part of any Red Hat distribution - the mpeg 3 “open standard” specifies patented technology, so despite what you may have believed, it isn’t “free”, not as in beer, nor any other way.

But make a promise, a legally binding promise, that you will not assert your patent claims against anyone who implements those claims in their software and you have something that open source can work with. That is what Microsoft just did with regards to the WS-* set of web services standards. This step enables open source implementations of the underlying protocols of CardSpace a.k.a. infocards. Given the interest that OSIS has in this space, that is pretty significant. Without such a promise, infocards would be a single vendor proprietary technology, and that would be in violation of law 5.

Let’s review the opening:

Microsoft irrevocably promises not to assert any Microsoft Necessary Claims against you for making, using, selling, offering for sale, importing or distributing any implementation to the extent it conforms to a Covered Specification…

I think we have a winner, and in no small part due to the efforts of Kim Cameron and Mike Jones of Microsoft. Thanks guys!