Introducing JSR 351 - The Java Identity API

The Java JCP has approved a new JSR relating to the use of Identity information within Java. The JSR351 charter is:

To define application programming interfaces and identity interaction models that facilitate and control the use of identity by applications and in access control decisions.

Ron Monzillo gave a talk (presentation available here) at JavaOne on JSR 351, I'll paraphrase his presentation with some of the highlights here:

Privacy Day» Developer Tools» IGF

It's privacy day, and it seems like a good time to re-introduce folks on the long-running Identity Governance Framework project.

For a few years now, Oracle has been working hard on laying some privacy groundwork for developers. This project initially started with the development of a standard specification called the Identity Governance Framework. The objective of IGF was simple: define some declarations that define:

• What personal information applications are using
• What operations are performed against that data
• What are the constraints on its use?

Additionally we fed important data into the XACML standards process to ensure that XACML access control systems could be used to fine-grained access control to data and resources (especially personal attributes).

Oracle also initiated two open source projects called ArisID and OpenAz to implement these standards. Check them out. It seems simple, and it is. But what these tools do is enable a powerful attribute service platform that stands to improve the privacy capabilities that developers can include in new applications.

Oracle has begun to incorporate this technology into its Fusion products (see Oracle Reference Security Architecture here)bringing further validation to the technology. The good news? It is available to any developer to use under Apache 2.0 License. Check these projects out.

I'll also point you over to Ian Glazer's recent article in his continuing series on privacy called "I 'like' you, but I hate your apps".

WHAT ISN’T OUT THERE

Unfortunately, your needs and the needs of the app developers aren’t addressed by both UMA and personal data stores. In order to meet these needs, device and platform makers must build “concern for the other” into their products. This is a big “D” design problem that requires not just user-experience intelligence but also classically trained design expertise. Baking “concern for the other” into products can be used to gain a competitive advantage in a market. By acknowledging that referencing information and pulling it from the source when needed, is superior to copying it, app developers have an opportunity to both mitigate their risks as well as provide better controls.

Ian makes an important point here about "concern for the other". Whenever personal information needs to be shared or used, it is important that underlying data systems know the what, where, when, and why it will be used. ArisID and OpenAz help to do just that.

Work on IGF is still ongoing. At present we are looking at improved Java language support for developers including annotations, security integration, etc. Stay tuned for more info!

First Open Source Reference Implementation of IGF 1.0

Over the past few months, a good deal of progress has been made around IGF and the open source implementation around it. In particular, last fall, Liberty Alliance ratified the IGF 1.0 specification as final. In mid January we published ArisID 1.1, the first open source implementation of IGF 1.0. Finally in late January, we checked in the first implementation of an open source provider based on OpenDS 2.2 (more on that below).

ArisID is an API for accessing and managing personal or identity related information using CARML as an XML data model. In addition to being useful from a privacy perspective, CARML enables important new developer features:

• The ability to automatically generate a data model in the form of Java beans.
• The ability to use sophisticated data providers that can connect applications to personal information sources using multiple protocols and virtualization.

If the principles of using an XML data model sounds familiar, it should. ArisID follows very similar architecture to Java Persistence Architecture. The key difference is that use of the CARML data model does not assume the pre-existance of a particular database or LDAP schema. Instead, a developer is able to create an application specific data model and write code as if the data model were a straight forward database. Then, at runtime, the provider layers of the API can be configured to connect to many different types of data repositories and network configurations including multiple directories or databases. With little effort, developers are able to create sophisticated applications that have much greater deployment flexibility in the types of data sources and repositories they can support, including remote and third-party sources.

Starting with the Oracle Fusion Middleware 11gR1(PS2) release, Oracle began to integrating this technology into its own products, setting the stage for a new level of support for open protocols and scalable enterprise deployment scenarios. For more information on how Oracle is using IGF and ArisID in 11gR1, check out the whitepaper, "Oracle Identity Management 11gR1".

As mentioned earlier, ArisID depends on "provider" modules to do the work of implementing data model requirements as expressed in application specific CARML declarations. At present there are now 2 implementations available:

• The Oracle OVD Provider for ArisID "Preview" is the first provider to support the ArisID 1.0 API. A developer preview is available here. Expect an update in the next quarter regarding ArisID 1.1.
  
• A brand new OpenDS 2.2 provider for ArisID is now available in the openLiberty sourceforge project repository. The new OpenDS provider allows developers to use OpenDS instead of OVD as a repository for applications using ArisID 1.1. The OpenDS Provider for ArisiD the first fully open source ArisID Provider implementation. For more information consult the readme file contained in the OpenDS Provider for ArisID distribution zip.

Project Aristotle is now moving forward with efforts to support integration into popular IDEs. As always, new contributors are always welcome, please see the OpenLiberty.org web site for more information. Also, feel free to subscribe to the igf-dev mailing list.

Finally, thanks to the OpenDS team (Ludovic, Bo, Matthew) for their assistance in helping to get the first open source implementation of a provider for ArisID done. In some respects, the Oracle/Sun merger delayed a lot of this work, but now that it is done, we can get back to work and contribute more to our respective projects. As Nishant Kaushik says, Sun + Oracle = Exciting Days Ahead! By the way, click here for webcasts about Fusion Middleware and in particular Identity Management.

Talking IGF at the European Identity Conference

Felix Gaehtgens of Kuppinger Cole interviews Oracle's Dr. Prateek Mishra about IGF and its role in setting a foundation for privacy at this week's European Identity Conference.

Check out more interviews, and comments about the EIC here.

Big Changes!

Yesterday, my plan was to write a post announcing some changes at Project Liberty. I was distracted by the announcement that Oracle has entered into an agreement to acquire Sun Microsystems! Some other interesting coverage can be found here.

Now, the other big news!

The Liberty Alliance Project announced formation of a new organization known as the Kantara Initiative. Kantara is an organization with a much more accessible approach to its membership. It carries an Intellectual Property structure that is much more flexible and should allow for a greater ability to bridge between industry communities working on identity services. Brett McDowell, Executive Director of Liberty Alliance Project, gives an overview of the Kantara Initiative here:


One of the first big differences between Project Liberty and Kantara is that Kantara will be not be setting standards. Instead work groups will define recommendations to share with other standards setting organizations (SSOs). For example, the work on IGF AAPML, and various protocol profiles for IGF will likely each be referred to the SSO organization responsible for the parent specification.

For those following IGF and Project Aristotle, the work continues under the Kantara Initiative. One of the cool new features of the Kantara Initiative is the ability to support multiple open source projects with different licenses. This means it will be a lot easier to support a more diverse open source community. As an example, for Project Aristotle, it will make it a lot easier to work with the Higgins community now that we have a way to bridge between EPL and Apache licensing.

It seems that the themes of bridging and harmonization are in the air!

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...

Why Centricity Doesn't Support Privacy

Every now and then I see people putting forward the notion that they would like to physically control all their identity information and have it held in a single place of their choosing. But does that really solve the problem of privacy? It certainly seems like it does.

The problem is that this idea ignores the nature of relationships we establish with service providers and agencies on the Internet. Bob Blakley puts it nicely here:

Identity 2.0 mistook the symptom (inaccurate identities, and the damage to privacy and ability of users to transact effectively) for the cause and took up the banner of “user centricity.” User centricity will not solve the Identity 1.0 problem; indeed, it will make the problem worse by creating antagonism between individuals and businesses. This antagonism will undermine already weak relationships and thereby make it even more difficult for businesses to get the identity information they need.

Part of the antagonism that Bob Blakley is referring to is the assumption that service providers are doing bad things, and users must have control through a centralized identity provider of their choosing. Does centralizing information in a place of our choosing improve our privacy? Some have argued yes, because eventually vendors won't need to retain information. We can give it to them every time we communicate with them and audit when they use it. That would be a cool thing if that covered the entire issue.

We may want a vendor to never hold our identity information, but what about when we expect the vendor to actually do something with the information we provide such as ship a book or offer a subscription? Often, delivery of the service itself requires the use our personal information. Even using the services of a provider may in fact generate new personal information. That is the nature of having a strong relationship. As Bob indicates, relationship is something Identity 2.0 does not take into account.

When we use services, new information about ourselves is often generated. Privacy is not just about controlling and consenting to the use of information we give to a vendor, but also about what that vendor does with what it learns about us through the use of their service. For example, if I sell a bunch of items on a fictional electronic marketplace called eStuff, I will gain a reputation with eStuff. Reputation is not something self-asserted. In this case, "reputation" is a piece of my persona that gets generated as a result of using the eStuff service. The more transactions I successfully complete and the higher my trading partners rank me, the better my "reputation". In this case, "reputation" is a result of my relationship with eStuff.

Because "reputation" has value, we could conclude that there is value in making that assertion portable. Yet clearly, this personal information is information generated by eStuff based on my relationship with eStuff and its other customers. Because of my relationship with eStuff, the eStuff service could be said to be an "authoritative" source for reputation. eStuff, having invested in its reputation service, has a business interest in how the information is used.

Of course, we would like to feel we have control over our reputation and about how others get to see our reputation information. eStuff, the generator of this information also has its own interests. It is for this reason that moving the storage of this data to a third party provider who has no relationship with eStuff becomes problematic. We should have a say in the use of our own information, but the asserting party (eStuff) should also have a say. It is part of a healthy relationship! If this personal information is to be given to another party, both the person and asserting provider should have an opportunity to agree.

In practice, eStuff asserts its rights by being the issuer of claims, while the user, asserts rights by consenting. User-centric systems enhance this process by allowing the user themselves to become the vehicle of exchange generating implied consent.

eStuff is just a hypothetical example, but there are many other places where applications generate information about us. An employer's HR system generates information about who is an employee and knows our job roles. A travel agents knows our travel preferences and travel plans. The department of motor vehicles knows about our driving record. Facebook, LinkedIn and other social networks know about our relationships and about our interests. Each of these sources can be considered "authoritative" because we have a relationship with these sources. Used with our consent, authoritative personal information can improve our relationships with other service providers.

The challenge today is not how we effect transfer of information. There are lots of protocols to transfer information. The challenge is defining the programatic policy that describes when information should be shared or for that matter updated, and what constraints or consent have users stipulated. Oracle has proposed that XACML is the best tool for the job and in particular has proposed AAPML as a profiles XACML for use in relation to identity services. As XACML is now beginning to mature, watch this space for more information on the progress of AAPML towards standards.

Felix Gaehtgens on ArisID

Felix Gaehtgens of Kuppinger Cole comments on the birth of ArisID...

For one, Identity Governance is definitely a problem, but not one that is seen to be very urgent - there are typically many other open problems that have the focus and attention of IT professionals. This may be short-sighted however, because regulation is certain to become tighter and relate more directly how identity information is being treated and handled. The advantage of embracing ArisID is that its benefits in terms of Identity Governance come "for free" with the additional advantages that the framework brings.

ArisID Webcast Presentation and Demo Video

Thanks to all who attended the webcast on ArisID this morning! It’s always great to talk about this stuff and share ideas!

A copy of the presentation can be obtained here.

Also, as promised, here is a video of the Sonic Records ArisID demonstration. You can view it online here. Or, you can download the full-size video here (24MB).

Phil

Webcast on ArisID - Dec 11, at 8AM PDT

From Liberty Alliance:

ArisID, the first open source software implementing Liberty Identity Governance Framework (IGF) components, provides enterprise developers and system architects with a library for building enterprise-grade identity-enabled applications using multiple identity protocols, and lays the groundwork for allowing enterprises to manage and audit the identity requirements of business applications based on declarative IGF policy specifications. This webcast will provide participants with an overview of the ArisID API, discuss benefits for developers and enterprises, and review the project roadmap. Developers will understand how to begin using ArisID to build IGF-based applications and the identity community and vendors will gain insight into how the open source ArisID API and information providers help fulfill multi-protocol identity management requirements.

Registration

For those of you who have been following my blog, you'll know I've been talking for sometime about IGF and the need for a declarative identity API in order to making identity services more relevant to developers. Here's your chance to see more about what I've been talking about all this time.

For more information, check out Paul and Robin's blog posts, scooping me on my own presentation! :-)

Project Aristotle

Good news!

For some time now, there has been a lot of work going on at OpenLiberty to design a new "declarative" API that enables application developers to write applications that consume, and manage identity information in a way that allows infrastructure components take care of all the nasty problems like
* Which protocol to use
* What data providers are appropriate for the current transaction
* How do I write robust code given that I don't know the protocols or APIs very well?

Well, the answer is here. Release 1.0 of ArisId is now available at OpenLiberty.

The ArisID API implements the CARML (Client Attribute Requirements Markup Language) and Privacy Constraints IGF specifications Liberty Alliance released earlier this year. ArisID demonstrates how CARML and Privacy Constraints policies may be used by developers to create declarative identity applications. The open source ArisID declarative approach defines what identity-enabled transactions can be performed to ensure applications only use identity information required to complete a transaction. This allows developers to build secure identity-enabled enterprise applications that are easily auditable and protect the personally identifiable information (PII), such as a social security number or credit information, of people engaging in enterprise identity-enabled transactions.

Be sure to read the full press release here.

I would like to thank my Oracle colleagues who have contributed to the project, as well as the members of OpenLiberty for hosting this project. There is much more to come, stay tuned!

Further reading:
* Open Liberty Project Aris Site
* Liberty Alliance Press Release
* Frequently Asked Questions
* Oracle Provider for ArisID
* IGF Standards and CARML Specifications

IGF and App Development at DIDW

I will be doing a session on the Identity Governance Framework at Digital Id World on Wednesday September 10 at 3PM. In addition to a brief introduction to IGF, I will be spending time on the IGF open source project at www.openliberty.org. This will include a brief demo of our progress so far.

Wondering about how the next generation of applications will handle all these new and old Identity Services protocols and be privacy-centric at the same time? This session should be interesting.

Liberty Announces First Release of IGF and IAF Specifications

Great news! Liberty Alliance announced the release the first drafts of the Identity Governance Framework and the Identity Assurance Framework.

The current IGF draft has 3 major components:

• Privacy Constraints - This document describes a small set of atomic privacy constraints based on WS-Policy that can be used in other IGF specifications. Privacy constraints are atomic constraints on the use, display, retention, storage and propagation of identity data. When combined with policy frameworks such WS-Policy, such assertions can be used to describe composite constraints on identity data.
• Client Attributes Requirements Markup Language - This document describes an XML declaration format describing identity-related data usage by an application.
• CARML Profile for Privacy Constraints - This document profiles the use of privacy constraints within CARML.

The complete specifications page for IGF can be found here. I should also point out this is just the first release of an ongoing series of specifications around identity governance. Next steps will likely include profiling of IGF in connection with various communication protocols and Attribute Authority Policy Markup Language which is currently proposed as a profile of XACML.

The Identity Assurance Framework is a new specification that defines 4 levels of assurance that can be used between federated providers to define the level of assurance or trust-worthiness of information.

The four identity assurance levels outlined in the Liberty Identity Assurance Framework are based on a comprehensive set of process and policy criteria organizations must meet to participate in IAF-based federations. The IAF details authentication requirements to allow federation operators and federating organizations to address cross-industry business, policy and privacy requirements related to applications and services built using any federation protocol and falling into each identity assurance level. The first version of the Liberty Alliance Identity Assurance Framework released today is available for download.

For those of you wondering at this point, do these specifications represent new protocols? The answer is no. These specifications are really information-level policy declarations describing how and when to use identity-related information and its level of assurance. These declarations are intended to be used with any protocol system used to exchange information whether it be LDAP, ID-WSF, or WS-*. The diagram below should help show the relationship between IAF, IGF, and the various Identity protocols.

Many thanks to my fellow colleagues at Liberty Alliance who worked so hard to provide their input and contributions to these specifications. Without such excellent attention, this work would not have been possible!

IGF Demonstration at Catalyst

Burton Group's Catalyst Conference is coming up.

If you are coming to Catalyst, remember to stop by the Oracle hospitality suite on Wednesday and look for the OpenLiberty IGF demonstration. I'm excited to say that we are getting to the point where we can show how IGF will work in practice. I'll be there talking about the open source openLiberty IGF project and demoing how the IGF Attribute Service API works.

For those who have been following the Identity Bus discussion, you should also check out the demo. The Attribute Service API definitely shows off a lot of the desired requirements that the bloggers have been talking about.

See you there!

IGF Attribute Services API Demo

I've been meaning to create a demo showing what it might be like for a developer to write applications that access identity information using the new CARML-enabled Attribute Services API. Accordingly I've put together this brief 10 minute video that demos how easy it is to write a JSP script to access identity information through a declarative API without having to worry about protocols, vendors, or deployment environments - the Identity Bus/Metaverse/Network just deals with the application's requirements based on configuration and policy and the application benefits!

This video just shows the developer's experience and why I think developers might start to get excited. Yes, the API is privacy enhancing and all that stuff, but the reality is, any new API has to be easy, powerful, and open (as in Apache 2 License in this case) or developers just aren't going to care. Jeff, I hope this answers some of your important concerns!

The video does not cover how the API does its work, nor how is the deployment managed and configured. However, if you are planning on attending the Burton Group Catalyst Conference, please be sure to stop by the booth and I'll give you a walk thru! I'll try and post more video's of IGF in action as time permits!

I hope this video shows at least an initial concept that represents the kind of vision that Kim Cameron, Dale Olds, Jackson Shaw, Dave Kearns and many others have been talking about. I don't think we are there yet...for that, we're gonna need your input! Check out the openLiberty project today!

[Note: Oops!! I just saw the rendering that YouTube did of my video. With the downscaling the screen shots became incredibly blurry. I'm going to play around and see if I can post this video in a way that is clearer.]

IGF Webcast Slides

Thanks to all who attended the webcast today!

The slide-deck for the IGF presentation and the others in the "Privacy in Perspective" series are available at: http://www.projectliberty.org/liberty/resource_center/presentations_webcasts

Should Developers Move Away from LDAP APIs

While Jeff Bohren's previous post points out having to justify the business need (which I responded to here), yesterday afternoon, Jeff pointed out developers need to be convinced.

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.

What About IGF and Existing LDAP Systems?

Jeff Bohren responds in his latest blog post to a post from Clayton Donley. The gist of Jeff's post is the suggestion that IGF replaces or changes AD. That is not the case.

But the hardest thing is getting adoption of these standards. The point of my post was not to suggest that standards for identity services other than LDAP aren’t a good thing. The point was that to drive adoption you have to accept the reality that AD and other LDAPs have the predominant mind-share today.

To many enterprises, LDAP is their one identity hammer. And they see all their identity problems as nails. If we want them to put down the LDAP hammer and pick up the IGF pneumatic impact wrench, we have to explain to him in real world business cases why it’s better. Because they know the LDAP hammer will work and they already have it in their tool box. The IGF pneumatic impact wrench is a strange new tool to him that they must first understand and second justify purchasing.

To be clear. Enterprise LDAP is a key part of what we are thinking about for IGF. The plan for IGF (and its components CARML and AAPML) is to develop a profile against multiple protocols (LDAP, ID-WSF, WS-*) used for identity information. Each profile will explain how IGF is used in the context of a particular protocol. For LDAP, the big challenge is what to do about existing applications. After-all, these applications aren't going to change for a long time - and probably do not need to. IGF is not a replacement for these protocols but is instead a layer that runs on top of them.


The nice thing about CARML is that it is just a declaration. There is nothing saying a CARML declaration cannot be created by hand for an existing application. Though we are working on an open source implementation, it does not have to be used for applications and infrastructure managers to receive benefits from IGF. The new API is really about creating appeal for developers. Developers want something very different than enterprises. They want to be able to write flexible applications without having to spend 90% of their time writing code to support varied deployment scenarios and varied protocols.

For business, the benefits of IGF are going to be mainly around risk management and privacy as demand to use personal information increases beyond current traditional enterprise directory content. Enterprises wanting to use identity-related information from HR systems or CRM systems already have to worry about legislative and regulatory issues. While manageable today, the processes are largely manual and forensic in nature. It's a situation that cries out for standardization.

Finally we should be careful not to focus exclusively on classic enterprise identity and ignore other business systems that use identity-related information. Many businesses have customer relationship systems that hold and retain customer information have most often not been ActiveDirectory or LDAP based. This is why IGF can't exclusively focus on LDAP or any other single-protocol and why it must function at a higher level.

Kim Cameron On The New Generation of Metadirectory

As you may know, there has been an ongoing discussion on what does the next generation of meta-directory look like. Kim Cameron's latest post elaborates on what he thinks is needed for the next generation of "metadirectory".

• By “next generation application” I mean applications based on web service protocols. Our directories need to integrate completely into the web services fabric, and application developers must to be able to interact with them without knowing LDAP.
• Developers and users need places they can go to query for “core attributes”. They must be able to use those attributes to “locate” object metadata. Having done so, applications need to be able to understand what the known information content of the object is, and how they can reach it.
• Applications need to be able to register the information fields they can serve up.

These are actually some of the key reasons I have been advocating for a new approach to developing identity services APIs for developers. We are actually very close in our thinking. Here are my thoughts:

• There should be a new generation of APIs that de-couple developers from dependence on particular vendor implementations, protocols, and potentially even data schemas when it comes to accessing identity information. Applications should be able to define their requirements for data and simply let the infrastructure deal with how to deliver it.
• Instead of thinking of core attributes as those attributes that are used in common (e.g. such as surname is likely the same everywhere). I would like to propose we alter the definition slightly in terms of "authoritativeness". Application developers should think about what data is core to their application. What data is the application authoritative for? If an application isn't authoritative over an attribute, it probably shouldn't be storing or managing that attribute. Instead, this "non-core" attribute should be obtained from the "identity network" (or metaverse as Kim calls it). An application's "core" data should only be the data for which the application is authoritative. In that sense, I guess I may be saying the opposite of Kim. But the idea is the same, an application should have a sense of what is core and not core.
  
• Applications need to register the identity data they consume, use, and update. Additionally, applications need to register the transactions they intend to perform with that data. This enables identity services to be built around an application that can be performant to the application's requirements.
  

What I have just described was actually part of the original inspiration behind CARML(Client Attributes Requirements Markup Language) put forward by Oracle that the Liberty Alliance is working on now. It was our belief that in order to enable applications to connect to diverse identity service infrastructures, something like CARML was needed to make the identity network both possible, adaptive, and intelligent.

But, while CARML was cool in itself, the business benefit to CARML was that knowing how an application consumes and uses identity data would not only help the identity network but it would also greatly improve the ability of auditors to perform privacy impact assessments.

We've recently begun an open source project at OpenLiberty called the IGF Attribute Services API that does exactly what Kim is talking about (by the way, I'm looking for nominations for a cool project name - let me know your thoughts). The Attribute Services API is still in early development stages - we are only at milestone 0.3. But that said, now is a great time for broader input. I think we are beginning to show that a fully de-coupled API that meets the requirements above is possible and dramatically easier to use and yet at the same time, much more privacy centric in its approach.

The key to all of this is to get as many applications as possible in the future to support CARML as a standard form of declaration. CARML makes it possible for identity infrastructure product vendors and service providers to build the identity network or next generation of metadirectory as described by Kim.