In late 2006, several companies got together and created the Identity Governance Framework (IGF), an initiative of the Liberty alliance. 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. How can the inherent risks associated with the creation, copying, maintenance and use of identity 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 (Client Attribute Request Markup Language) 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. On the other side of the spectrum there is AAPML ('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, so that AAPML policies can be consumed directly by a policy enforcement point (PEP) to enforce access over the requests for identity data...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.
Read the complete blog post by Felix Gaehtgens.
