Standards and Implementations

Kim Cameron posted a response today to my post yesterday about requirements for his next generation Meta-directory and how IGF aims to do just that. It seems Kim and I are in total agreement on these points and developer appeal is definitely key. I do want to clarify one paragraph from his response:

I haven’t seen CARML - perhaps it is still a private proposal? [UPDATE: I’ve been advised that CARML and the IGF Attribute Servces API are the same thing.] I think having a richer common representation for people will be the most important ingredient for success. I’m a little bit skeptical about confining developers to a single API - is this likely to fly in a world where people want to innovate? But details aside, it sounds like CARML will be a helpful input to an important industry discussion. Above all, this needs to be a wide-ranging and inclusive discussion, where we take lots of input. To get “as many applications as possible” involved we need to win the participation and support of application developers - this is not just an “infrastructure’ problem.

IGF is a collection of specifications (e.g. CARML, AAPML) that Oracle and others announced in November of 2006. With the positive response and encouragement from other vendors we quickly took the initial proposal for IGF to the Liberty Alliance on its way to making IGF an important identity information standard.

The AttributeServices API I spoke of is an Apache 2.0 License open source project under openLiberty.org that demonstrates just one possible implementation of the use of the IGF specifications. In other words, I totally agree with Kim on his skepticism about one API - the last thing we want to do is confine developers to a single API implementation. This was one reason why we went to the Apache License. We want to make it easy for other developers to take what we've done and port and adapt the implementation for their own purpose. From my perspective, the key is that all APIs should share implementation of IGF as a future standard.

To expand on Kim's point there are many communities that need to buy in: Developers, Privacy Officers, Deployment Managers, Infrastructure Managers for a start. But it goes without saying that if developers don't use it, none of this matters. Developers won't do this simply because the other parties (like infrastructure managers) want it. The key benefit I see for developers is the ability to write applications without having to worry about issues of deployment or issues surrounding protocol implementation through powerful development tooling.

Kim is correct about needing a wide-ranging inclusive discussion. We're doing that by developing the standard inside Liberty Alliance and by simultaneously developing the first reference implementation under openLiberty.org. I know there may be issues, particularly for small vendors to join the Liberty Alliance, but feel free to check out the mailing lists, and by all means, join up with OpenLiberty, which in contrast has wide open membership.