How To Implement the Technical Aspects of an Identity Oracle

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:

1. 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
2. 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
3. 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

Challenges in Operationalizing Privacy in Identity Federations

A critical part of the job of an identity/information management professional is to operationalize privacy in the systems they architect, build and deploy. Unfortunately, it is easier to make that statement than to come up with a rigorous and repeatable process to do it. It is hard because privacy is contextual in nature, and data often moves across organizational and system boundaries where shared context may not exist. This blog post is an attempt to articulate some definitions and considerations regarding operationalizing privacy within the narrow realm of identity federation.

NIST, in its DRAFT SP 800-130 "A Framework for Designing Cryptographic Key Management Systems" (PDF) articulates the three privacy characteristics (Section 4.7) of Anonymity, Unlinkability and Unobservability:

An information management and security policy may state that users of the secure information processing system can be assured of anonymity, unlinkability, and unobservability, if these protections are required. Anonymity assures that public data cannot be related to the owner. Unlinkability assures that two or more related events in an information processing system cannot be related to each other. Finally, unobservability assures that an observer is unable to identify or infer the identities of the parties involved in a transaction.

In his write-up of the NIST CKMS Workshop, Dr. Francisco Corella had this to say as it relates to identity federation:

"[...] One way of reducing the number of passwords to be remembered is to rely on a third-party identity provider (IdP), so that one password (presented to the IdP) can be used to authenticate to any number of relying parties. The Federal Government allows citizens to access government web sites through redirection to several Approved Identity Providers.

But third party login has privacy drawbacks. In usual implementations, anonymity is lost because the relying party learns the user’s identity at the IdP, unlinkability is lost by the use of that identity at multiple relying parties, and unobservability is lost because the IdP is informed of the user’s logins. Profiles of third-party login protocols approved for citizen login to government sites mitigate some of these drawbacks by asking the identity provider to provide different identities for the same user to different relying parties. This mitigates the loss of anonymity, and the loss of unlinkability to a certain extent. (Relying parties by themselves cannot track the user, but they can track the user in collusion with the IdP.) But the loss of unobservability is not mitigated, because the IdP is still informed of the user’s activities.

I believe that the Government should work to develop and promote authentication methods that eliminate passwords while preserving anonymity, unlinkability and unobservability."

Agreed.

The Fair Information Practice Principles (FIPPs) are a core part of the NSTIC vision for the Identity Eco-System, and more concretely, a critical part of the Federal Government's implementation of that vision (FICAM). The FICAM Identity Schemes (i.e. Protocol Profiles for Authentication) require the use of pair-wise pseudonymous identifiers to mitigate the loss of anonymity and loss of unlinkability. The loss of unobservability is still very much a concern, which is why as we move out on our FCCX initiative, we are specifically calling out the issue of "panopticality" as something that is critical for us to address.

We are investing both attention and resources to this area, but have little desire to build a closed eco-system of proprietary technologies with limited interoperability that becomes expensive technology road-kill due to lack of support in the marketplace.

We need the help of standards bodies, technology vendors and other stakeholders in making sure the ability to support these privacy characteristics are baked into the current and future generation of identity protocols and standards. Even more so, we need support for these privacy enhancing characteristics to be adopted and used in the implementations of the same protocols and technologies by the identity thought leaders in this space so that Government can leverage and utilize them as part of delivering Citizen facing services.

RELATED POSTS

• Challenges in Operationalizing Privacy in Identity Federations - Part 2
• Challenges in Operationalizing Privacy in Identity Federations - Part 3

:- by Anil John

Level of Confidence of What, When, Where and Who?

Last week's blog post by Dr. Peter Alterman on "Why LOA for Attributes Don’t Really Exist" has generated a good bit of conversation on this topic within FICAM working groups, in the Twitter-verse (@Steve_Lockstep, @independentid, @TimW2JIG, @dak3...) and in may other places.  I also wanted to call out the recent release of the Kantara Initiative's "Attribute Management Discussion Group - Final Report and Recommendations" (via @IDMachines) as being relevant to this conversation as well.

One challenge with this type of discussion is to make sure that at a specific point in the conversation, we are all discussing the same topic from the same perspective. So before attempting to go further, I wanted to put together a simple framework, and hopefully a common frame of reference, to hang this discussion on:

 

"What"	Separate out the discussion on Attribute Providers from the discussion on individual Attributes Separate out the discussion on making a decision (to trust/rely-upon/use) based on inputs provided vs making a decision (to trust/rely-upon/use) based on a "score" that has been provided
"When" (to trust/rely-upon/use)	"Design time" and "Run time"
"Where"	Where is the calculation done (local or remote)? Where is the decision (to trust/rely-upon/use) done?
"Who"	Party relying on attributes to make a calculation, a decision and/or use in a transaction Provider, aggregator and/or re-seller of attributes Value added service that takes in attributes and other information to provide results/judgements/scores based on those inputs

 

Given the above, some common themes and points that surfaced across these conversations are:

1. Don't blur the conversations on governance/policy and score/criteria  i.e. The conversation around "This is how you will do this within a community of interest" is distinct and separate from the "The criteria for evaluating an Attribute/AP is x, y and z" 
2. Decisions/Choices regarding Attributes and Attribute Providers, while related, need to be addressed  separately ["What"] 
3. Decision to trust/rely-upon/use is always local ["Where"], whether it is for attributes or attribute providers
4. The decision to trust/rely-upon/use an Attribute Provider is typically a design time decision ["When"]
1. The criteria that feeds this decision (i.e. input to a confidence in AP calculation) is typically more business/process centric e.g. security practices, data quality practices, auditing etc.
2. There is value in standardizing the above, but it is unknown at present if this standardization can extend beyond a community of interest 
5. Given that the decision to trust/rely-upon/use an Attribute Provider is typically made out-of-band and at design-time, it is hard to envision a use case for a run-time evaluation based on a confidence score for making a judgement for doing business with an Attribute Provider ["When"]
6. The decision to trust/rely-upon/use an Attribute is typically a local decision at the Relying Party ["Where"]
7. The decision to trust/rely-upon/use an Attribute is typically a run-time decision ["When"], given that some of the potential properties associated with an attribute (e.g. unique, authoritative or self-reported, time since last verified, last time changed, last time accessed, last time consented or others) may change in real time
1. There is value in standardizing these 'attributes of an attribute'
2. It is currently unknown if these 'attributes of an attribute' can scale beyond a specific community of interest
8. A Relying Party may choose to directly make the calculation about an Attribute (i.e. local confidence calculation based using the 'attributes of an attribute' as input) or depend on an externally provided confidence "score" ["What"]
1. The "score" calculation may be outsourced to an external service/capability ["Where"]
2. This choice of doing it yourself or outsourcing should be left up to the discretion of the RP based on their capabilities and risk profile ["Who"]

Given that we have to evaluate both Attribute Providers and Attributes it is probably in all of our shared interest to come up with a common terminology for what we call these evaluation criteria. A recommendation, taking into account many of the conversations in this space to date:

• Attribute Provider Practice Statement (APPS) for Attribute Providers, Aggregators, Re-Sellers
• Level of Confidence Criteria (LOCC) for Attributes

As always, this conversation is just starting... 

 

 

:- by Anil John

It Depends a.k.a. Access Decisions are Contextual

This week, I had the pleasure of attending and presenting at the InCommon Confab. It was a great day and a half event organized by Jacob Farmer at Indiana University and many others from the InCommon Team.

InCommon's mission is to support a common trust framework for U.S. Education and Research, and their Identity Assurance Program offers its more than 200 Identity Providers the ability to certify their practices at the InCommon Bronze (LOA 1) and InCommon Silver (LOA 2) Levels. Given their scope and reach across the Research and Education Sector, as well as their maturity in the Identity Federation space, we are very fortunate that they have chosen to become a FICAM approved Trust Framework Provider whose Bronze (LOA 1) and Silver (LOA 2) certified IdP Credentials can be used to access Federal Government Web Sites.

Ian Glazer (Gartner), one of the other keynote speakers, has a good write-up on his blog about the event, so won't repeat it here [Go, read, and come back. I'll wait].  The great thing about the conversation that took place is that we are finally getting past the authentication and LOA conversations to what really matters when it comes to getting things done, which is tackling the hard challenges around distributed/federated/cross-organizational authorization to enable collaboration and the sharing of information.

In my presentation, I had the following slide, which broke out attributes of a person into Identity, Authority, Contextual and Preference.

In my own mind, I had lumped together what I, and many others over the years, had taken to calling "Environmental" attributes into the Contextual bucket. But, as you can also see, I had subordinated that context element under the Person umbrella.

The conversation that we had over the last couple of days, in my own mind, called that bucketing into question.

A potential starting point, as articulated by Ian, is that Context is anything that is not Person or Resource related, and as such it promotes Context to be a first class citizen along-side Person and Resource Attributes. This leads to:

The "External Attribute" component of Context maps pretty easily into what we have traditionally called "Environmental Attributes":

• Operational Status e.g. Threat-Level-1, Declared-DSCA-Event
• Inside the building on business/agency infrastructure
• Coming from a specific IP block
• Connecting using VPN
• Host based scans report as healthy
• etc.

But the "Shared Contextual Attributes" are something new to think about and explore, as they bring a relationship component into the mix that could potentially be very interesting and, if we can work through it to a shared understanding, address questions such as:

• Is context where we can convey data handling expectations that come along with access to data? 
• Obligations and responsibilities? 
• Where semantics can be attached to and sent along with authority attributes?
• ?

There was pretty general agreement that we really are not sure at this point, but that we do need to put some think-time on this. What it should NOT BE is that Context becomes the grab-all bucket into which everything that is not Subject and Resource gets stuffed as that would make it quickly irrelevant and useless from an access control decision point of view.

Really looking forward to further conversations on this topic.

:- by Anil John