Building Internet Identity (WWDS Pt 2)

Last week, I responded to Dave Kearn's article "How a universal directory might work". I commented that there does not need to be some centralized service managed by one or a few vendors to unify directories or virtual directories. Rather, the solution needs to be akin to the kind of thing that created the Internet itself, TCP/IP's stack architecture.

Project Aristotle is the beginning of one such "stack" for identity services. Project Aristotle uses CARML (Client Attribute Requirements Markup Language) to act as an application's identity object model for identity services. When an application has declared an identity data model, it becomes possible to have a technology "stack" that can service an application's requirements in a protocol neutral way -- much the same way that TCP/IP could interconnect networks across many different types of media. Because the services layers below the application can understand the application's requirements (from the CARML data object model), they can begin to automate the complex processing it takes to map, route, and adapt to the necessary wire protocols. Further, this stack can also service other components of an application server, namely authentication and authorization services - bringing disperate components together to use a common identity service.

Aside: The idea of using an identity object information model for application development may seem radical and new. But actually, this has been done before in the database world. TopLink is an object-relational mapping package that was developed for SmallTalk and later Java. Learning from TopLink, means we can move ahead with a proven programming concept combined with proven technology such as virtual directories that can act as just one possible implementation of many in an open identity market.

For Oracle, Project Aristotle will make it much easier to develop applications that can use almost any type of identity service at a much lower cost, and with a lot more flexibility and reliability. More importantly it gives the businesses that deploy these applications, the ability to decide what protocols, policies, and technology systems are most appropriate for their enterprise environment without requiring customization of the application. Application developers are freed from having to become expert in many different types of identity services infrastructures and protocols. After-all developers shouldn't need to have a deep knowledge of identity protocols - they should be able to just use a well tested, easy-to-use stack-based approach that allows any vendor or open source technology to be used.

Project Aristotle is being developed at OpenLiberty. While OpenLiberty is receiving major contributions from Oracle, Project Aristotle is being developed in an open community of participants. Accordingly Project Aristotle (ArisID) welcomes and encourages contributions to this project! All that is required is the signing of the Apache CLA agreement. Oh, and by the way, if anyone wants to work on other programming language bindings for Project Aristotle, we're looking for that too!

Isn't it interesting that all this started from a desire to improve the transparency about how applications use identity-related information and to create Identity Governance within applications. The side-effect of governance, has been a new approach for dramatically improved identity services in the future!

Dave Kearns Suggests "World Wide Directory Service"

In his most recent column, Dave Kearns comments on IGF and how it could be used with virtual directories to form a world wide directory service.

This is a very interesting thought, but Mark Wilcox and I agree, a universal directory service operated or controlled by a single vendor isn't the right way to solve federated provisioning. For one thing, LDAP isn't the only requirement. Today's techniques for exchanging identity information involve many methods, and many modes (browser-based and backend-based). Any solution has to handle multiple identity protocols and should have no central point of control or storage. The implementation should not be owned by one vendor, it should be open, available for anyone to adopt and use. Rather than anything that approaches vendor lock-in, the solution has to be adjustable - preferably on-the-fly. The solution should be configurable and policy driven so that multiple technologies and providers can be used.

The need to link separate identity repositories around the world reminds me of the early days of enterprise networks. We used to talk about Ethernet networks, Token Ring, or even AppleTalk networks. These were standalone networks that tended to be isolated and self-sufficient with no concept of outside connectivity. Connections between networks were rare and expensive to implement. In part because the media (type of wire) for the network meant new protocols to handle communication. The TCP/IP "stack" came along and abstracted issues of network media and inter-network routing into layers. Everything changed. The Internet itself was born.

Applications today are at a similar crossroads. If they use identity services, the services are isolated to a single enterprise directory service. The problem? We as humans cross organization boundaries all the time. Applications are unable to expoit the power of the "Internet" when it comes to identity services. In the same way as TCP/IP solved media and inter-network challenges, applications need some way to handle the different protocols used in different enterprise networks. Most importantly, if we start networking identity information, applications and the enterprises that use them need a way to be able to respect privacy and ensure that the information being transferred is appropriate and secure.

What is needed is a multi-protocol identity networking "stack" that developers and service providers can use to interconnect systems. Instead of solving media and networking issues, this stack needs to solve identity mapping, routing, and protocol conversion. While IGF was originally specified for Identity Goverance, it turns out Dave Kearns is right, the IGF specifications may be an important part of the solution. More on that next time...