Over the last few weeks, the Liberty Alliance's IGF caught my attention several times. Fulup Ar Foll and Jason Baragry, both working for Sun Microsystems wrote a paper called "Next Generation of Digital Identity". About a month ago, HP's Marco Casassa Mont and Oracle's Phil Hunt published an article in "Sarbanes-Oxley Compliance Journal" entitled "Identity Governance Framework". I've been wanting to blog about this for several weeks, but kept putting it off. Last week I had the fortune to be briefed by Prateek Mishra, Oracle's Director of Security Standards, who explained in detail what the IGF was about and clarified some of the questions I still had.
In late 2006, several companies got together and created the Identity Governance Framework (IGF), an initiative of the Liberty alliance. Originally driven by Oracle, other companies in the space quickly joined the effort. The purpose of the IGF is to provide an open architecture that addresses governance of identity related information. This architecture is meant to bridge the gap between regulatory requirements and the lower-level protocols and architecture.
What does this mean and why is it so important? I like examples to understand things, so let's start with a few of them. For a starter, many enterprises still have private identity data stored in many different data stores. Even though the trend is to minimise the number of "data silos" (places where identity data is stored), the reality is still that data can be found in many places. This creates a problem in our globalising society, where the HR department might be run in one country, and the support desk in another, and a myriad of services being outsourced yet to other locations. How can one ensure that the flow of data is controlled in such a way to ensure that all privacy laws are being complied with? Another example could be a federated environment of several suppliers working together in order to process an order. The order is received by company A, which then sends out several orders for parts to companies B1, B2 and B3, who then ship everything to company C that assembles everything and uses company D to ship out the finalised order to the customer.
In both cases, identity data is transferred and processed. How can the inherent risks associated with the creation, copying, maintenance and use of this data be mitigated? Who has access to what data for which purpose, and under what conditions? Ideally, policies on data usage are created by sources (attribute authorities) and consumers (attribute authorities) of identity data. These policies can then then be used for the implementation and auditing of governance. In other words: if you know what the rules are, express them in a policy, and make sure your policy is watertight when the next audit comes.
Exactly this is what the IGF attempts to create: a standardised mechanism for expression and implementation of these policies. The IGF is working on several standards and components to make this happen. One of them is the CARML protocol. It defines application identity requirements, in other words what type of identity information an application needs, and what that application will do with that information. CARML stands for "Client Attribute Request Markup Language", and yes you've guessed right - it's XML-based. As stated previously, CARML defines what attributes an application wishes to consume, and the privacy rules of the application: Will the data be persisted (stored) by application? If so, how long? What purpose is it used for? Will it be forwarded? When an application is then made available, administrators can review the CARML file for that application, ensure that privacy constraints are being met, and then connect the application to the respective data stores to make the information available.
On the other side of the spectrum there is AAPML, the "Attribute Authority Policy Markup Language" that describes the constraints on the use of the provided identity information - under what conditions specific pieces of identity data is made available to applications, and how this data may be used, and possibly modified. For example: what part of the users data can be modified by the users directly at a self-service portal? Or: under which condition may a marketing application use a users data, and what type of explicit consent needs to be given by the user? AAPML is proposed as a profile of XACML, the "extensible Access Control Markup Language" so that AAPML policies can be consumed directly by a policy enforcement point (PEP) to enforce access over the requests for identity data.
So now you can probably see where this is going. In one side, you have the applications, and CARML that specifies the identity information that they need. On the other hand you have the identity data sources (attribute providers), and the policies under which they make data available. In the middle, an identity service can broker between both sides. This identity service can read the CARML requirements from the applications, and the AAPML policies from the attribute providers, or use an external identity policy engine that enforces the AAPML policies.
So why another set of protocols? Isn't this already addressed in some other standards? Liberty's ID-WSF springs to mind, or SAML 2.0's AttributeQuery, SPML, or even - to a certain extent - WS-Trusts Security Token Service. However, CARML and AAPML bridge a very important gap that is not addressed anywhere else: not how to request and receive attributes, but to express the need and purpose of identity data, and on the other side the allowed use and conditions for its consumption. IGF's framework conceptually fits seamlessly into architectures harnessing today's frameworks and picks up where CardSpace, Higgins, Bandit and WS-Trust, leave off.
In my mind, the IGF makes some very important contributions for important issues that have somehow "fallen through the cracks" in the last few years. The IGF's standards ensure that privacy requirements can be met and audited against, and facilite the secure and controlled exchange if identity data. This has the potential to fuel adoption of technologies such as federated identity, and open up business opportunities that were up to now constrained by uncertainty about privacy or lack of tangible technology in that area. I will definitely keep the IGF on my radar!