In the age of attributes, personal data, and data brokers, the concept of Identity Oracles and how they can help to mediate between diverse entities is something worthwhile to consider. This blog post provides a short introduction to the Identity Oracle concept and discusses the work FICAM is starting in order to address the technical intersection of Identity Oracles and Attribute Providers via a new Backend Attribute Exchange (BAE) Protocol Profile.
The original definition of an "Identity Oracle" which was coined back in 2006 by Bob Blakley, the current NSTIC IDESG Plenary Chair, is:
- An organization which derives all of its profit from collection & use of your private information…
- And therefore treats your information as an asset…
- And therefore protects your information by answering questions (i.e. providing meta-identity information) based on your information without disclosing your information…
- Thus keeping both the Relying Party and you happy, while making money.
While that applies to commercial entities pretty well, let me tweak that a bit for the Government sector:
- An organization which is the authoritative source of some of your private information…
- And is constrained by law and policy to safeguard your information…
- And therefore protects your information by answering questions (i.e. providing meta-identity information) based on your information, with your consent and without disclosing your information…
- Thus keeping both You and the Relying Party happy, while enabling you to conduct safe, secure and privacy preserving online transactions
A potential technical interaction between the three entities could be:
- Person establishes a relationship with the Identity Oracle. The Identity Oracle provides the person with token(s) that allow the person to vouch for his relationship with the Identity Oracle in different contexts
- When the Person needs to conduct a transaction with a Relying Party, he presents the appropriate token, which establishes his relationship to the Identity Oracle
- The Relying Party asks the Identity Oracle “Am I allowed to offer service X to the Person with a token Y from You under condition Z?”. The Identity Oracle answers “Yes or No”
Conceptually, this type of question is something you would want to ask an Attribute Provider, but current protocols for attribute query and response are really not set up to enable this type of capability. So putting aside the business and policy aspects, which are huge, a technical piece that needs to happen is to define how the interaction in step (3) above can happen using widely deployed protocols.
Based on multiple information sharing use cases that have come up, and an internal review of need and value, we have decided to address this requirement within FICAM by working to define a "XACML 3.0 Attribute Verification Profile for BAE 2.0":
The intent of this effort will be to profile XACML 3.0 messages on the wire, not for authorization, but to enable the construction of a verification request and corresponding response, while keeping the message level and transport level security mechanisms consistent between this new profile and the original SAML 2.0 Identifier & Protocol Profile for BAE 2.0.
RELATED POSTS
- Attributes Anytime, Anywhere. Extending BAE to Support New Protocols
- Challenges in Operationalizing Privacy in Identity Federations - Part 3
:- by Anil John
