What's All This Plumbing For?

Johannes Ernst blogs "If the Open Stack Is Mere Plumbing: The Plumbing Of What?". That question seems surprising from one of the proponents of OpenID. I thought it was all about simple identity for blog comments? Seriously though, he has a point.

If we look beyond OpenID, I would have to say it is the plumbing of layer 7 of the network - Applications! So, while I was joking when I said that I thought OpenID was only for blog comments, I was serious too. That's what it was designed to do. But was OpenID designed for the enterprise, for consumer applications, for social networking? Not yet. Hopefully some day in the future.

Of course user-centricity, which used to be all the rage, is still very important. But at the end of the day for the "users", centricity is just another tool, one of the plumbing options. Real people interact with businesses web sites. Notions of OPs, InfoCards, RPs are just plumbing lingo.

No, the real action is with applications. This is what consumers, users, and business people think about when they interact with the web. For the few of us, we might obsess about how a web site is built, and does it support UX protocol. But for the vast majority, identity plumbing for its own sake, doesn't mean much. Its hard to define a business model because well, there is no business.

What are the services that applications really need from identity plumbing? How about vetting, verification, privacy, assurance to name a few. Are they being delivered now? Many applications not only do their own identity management, but these as well. I would argue that in large part, many of the needed identity services are ill-defined and missing. This is why major web applications will continue to make mistakes as they try to learn, by managing personal identity information in a standalone silo.

The question I have, as specialist in IDM standards, does the application layer have all that it needs? When do we move beyond specific protocols and plumbing debates and ask what are the application-centric requirements that are needed to compliment the user-centric developments, we've had to date?

Johannes. Thanks for a great question!

Kuppinger-Cole: Finally, An Open XACML API

Felix Gaehtgens of Kuppinger-Cole writes about his conversation with Prateek Mishra of Oracle, who indicated that Cisco and Oracle have posted a new XACML API to the OASIS XACML TC.

It was a “soft launch” that was announced at the Kantara meetings on Monday at Burton Catalyst (which very unfortunately, I missed). When Prateek mentioned it to me, it stopped me dead in my tracks, because I find it really significant news – a very important step towards flexible access control policy based on XACML.

Felix's article gives a great example of why Attribute Based Access Control (ABAC) is going to be the next generation of access control and why it will ultimately replace Role Based Access Control (RBAC).

In my opinion, this will be a space to watch closely. RBAC has always been a lot like physical building security guards. They are very good at protected the building entrances and exits; but when it comes to determining who should be able to go where inside the building, or who should be able to interact with whom, the building guard model quickly reaches limits. It is easy to see that one of the enforcement points in security architecture has to be within applications themselves. ABAC and the open XACML API will make this possible.