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.
No comments:
Post a Comment