Privacy Preserving Attribute Validation using XACML

I’ve always considered Attribute Providers to be a first class citizens of an Identity Ecosystem that are distinct and separate from Identity Providers. But as we move into an era where identity assurance becomes more critical for high assurance online transactions, a use case that is becoming main stream is the validation of self-asserted attributes rather than pure attribute retrieval.

The use case goes something like this:

1. A person needs to complete a transaction with a (commercial) entity (Obtain a high assurance credential, Open an account etc.)
2. Person self-asserts a set of claims/attributes; this may be via documents or electronic; in person or remote
3. The authoritative source of the claims/attributes is typically not a commercial entity. e.g. Federal Government and/or State Government Agencies where there are significant privacy implications to the release of this data to commercial entities who may re-sell this information or use it for non-authorized secondary purposes

The ability to interact with these authoritative sources requires more than simple connectivity given the privacy implications of the data, so how can this transaction be completed in a manner that satisfies the needs of all parties?

This, of course, is the classic case of Government as an Attribute Provider but with a twist in that the use case is not looking at retrieving attributes in order to make access control decisions, but about validating self-asserted attributes for purpose X. The aspects that need to be kept in mind when looking at this use case, at least in the United States, are:

• Federal Government Agencies consider citizen information to be highly sensitive from a privacy perspective and are very leery of releasing that information even to other government agencies. Commercial entities have an even higher bar to cross

• The authoritative source is typically not allowed to release actual attribute/claim values due to regulatory and/or privacy policy constraints

• The only potential way to thread this minefield would be if there is a policy that supports the release of this information for a clear authorized purpose with no other downstream re-use for any other purpose. If so, an option they will typically entertain is to return information that validates the value of a self-asserted claim. i.e. An Agency can provide a [yes|no] answer regarding a comparison match result between a self-asserted claim and what they have in the system for that person, but not much more.

• To make this scale across sectors and authoritative sources, not to mention the lack of desire to build custom/proprietary interfaces, there needs to be some standardization of the technical interfaces that are used to complete this transaction.

I am, for now, going to put aside the justification that needs to be built in order to support the authorized purpose policy and am going to focus purely on the technical aspects. Some of the criteria I was considering were:

• Do NOT want to reinvent the wheel by coming up with an API or interface that is bright/shiny/new; the folks that this needs to appeal to are the no-nonsense types that like to minimize the number of moving parts they need to manage in their Enterprise, and are highly concerned about security and policy compliance
• Would like to leverage an existing and standardized protocol standard
• Would like to have support for that standard in existing infrastructure elements that may already be deployed

Initially I was looking at SAML as a potential solution, but that does not map well to this use case. The SAML AttributeQuery requires that the subject be clearly identified (typically via some sort of authentication step), but in thinking a bit more about this, it looks like XACML 3.0 may very well address the need more cleanly.

I want to emphasize that what is being proposed is not using XACML for Authorization but simply using the standardization and capabilities of XACML messages on the wire as a mechanism to fulfill a particular purpose which may potentially torque off the purists. As such XACML 3.0 provides:

• Attribute Categories (pre-defined and custom) for Subject, which can carry the self-asserted attributes of the subject, and Resource, which can be used to route the request to the appropriate authoritative sources.

• XACML Advice that can be returned to inform the requester of errors (Don’t want to use obligations here given that the standard requires that PEP must discharge obligations)

• Commercial implementation of XACML Externalized Authorization Managers that have the ability to call out to external attribute sources using LDAP(S), SAML, JDBC/ODBC, Web Services etc. And if not, it would be relatively straight forward to integrate the engine with a Virtual Directory Infrastructure to provide this capability.

• XACML Compliant Decisioning Engines that can be used to do attribute matching based on clearly defined and verifiable policies.

• Ability to layer in cross-cutting security functionality, at both the message and transport level using existing infrastructure

I ran this by some smart folks that I know of in the community and the conversation survived the questions and issues that were brought up. To take this to its natural conclusion would potentially require work to define an “Attribute Validation Profile of XACML 3.0”. But ultimately, I would also throw this in the ring as a potential way to implement the technical aspects of an Identity Oracle. Comments?

UPDATE (12/30/11): @NishantK brought up a great point that I wanted to highlight given the privacy concerns. The request message format allows for capturing the consent of the subject for attribute release, which it turn can be used to drive the go/no-go at the decision engine.

UPDATE (2/15/14): Updated text (but not image) to align with validation/verification terminology

RELATED INFO

• Identity Oracles and their role in the Identity Eco-System
• Identity Oracles - Trust is Ephemeral, Contracts are Eternal