As I said, I wasn’t suggesting that IGF replaces AD. But if you expect developers to migrate to a new way for developing client applications you need to give them a compelling business case.Well that's actually easily answered. If you are a developer who only needs to talk to one type of directory (e.g. Active Directory) and only one instance of it, you SHOULD continue to use your favorite LDAP API (e.g. ADSI).
However, many developers have encountered lots of issues building great inter-operable LDAP applications. Clayton Donley has some good examples here. For many of these developers, virtual directory has been the solution.
Putting the business value question aside (we discussed that in previous posts), the developer audience for the IGF-enabled Attribute Service API is all of the other developers working on applications that don't fit the above criteria (probably about 90%). Up until now, those developers have been stuck building their own "silos" of identity information. After-all if you can't figure out how to plug into an unknown environment, why not create your own?
With the advent of new user-centric protocols, the demand to use Identity Services is growing. But if the LDAP community was bad at tooling, user-centric systems are worse (if only because it is still early days for these protocols). I think the point of having an open source attribute service project is to begin the process of creating an API relevant to applications developers, supports the newer protocols, and most importantly, is worth moving away from the silo architectures of the past and moving towards an Identity Network approach that inherently makes the application better in compelling ways.
Jeff is correct, building this kind of tooling and a community of support is not going to be easy - but we have to start somewhere. To that end, your input is indeed welcomed and wanted! Please check out the IGF Attribute Service project at openLiberty.