Role of Government as Identity Oracle (Attribute Provider)

Issue/Topic: Role of Government as Identity Oracle (Attribute Provider) (T1A)

Convener: Anil John

Conference: IIW-East September 9-10, 2010 in Washington DC Complete Set of Notes

Notes-taker(s): Anil John and Ian Glazer

Tags for the session - technology discussed/ideas considered:

Technorati Tags: #iiw,Attributes,Claims,Identity Oracle,ICAM del.icio.us Tags: #iiw,Attributes,Claims,Identity Oracle,ICAM

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

My proposal of this session at IIW East was driven by the following context:

Some of the vocal folks at this session, in no particular order, included (my apologies to folks I may have missed):
 * We are moving into an environment where dynamic, contextual, policy driven mechanisms are needed to make real time access control decisions at the moment of need
 * The input to these decisions are based on attributes/claims which reside in multiple authoritative sources
 * The authoritative-ness/relevance of these attributes are based on the closeness of a relationship that the keeper/data-steward of the source has with the subject. I would highly recommend reading the Burton Group paper (FREE) by Bob Blakley on "A Relationship Layer for the Web . . . and for Enterprises, Too” which provides very cogent and relevant reasoning as to why authoritativeness of attributes is driven by the relationship between the subject and the attribute provider
 * There are a set of attributes that the Government maintains thorough its lifecycle, on behalf of citizens, that have significant value in multiple transactions a citizen conducts. As such, is there a need for these attributes to be provided by the government for use and is there a market that could build value on top of what the government can offer?


 * Dr. Peter Alterman, NIH
 * Ian Glazer, Gartner
 * Gerry Beuchelt, MITRE
 * Nishant Kaushik, Oracle
 * Laura Hunter, Microsoft
 * Pamela Dingle, Ping Identity
 * Mary Ruddy, Meristic
 * Me,  Citizen

We started out the session converging on (an aspect of) an Identity Oracle as something that provides an answer to a question but not an attribute. The classic example of this is someone who wishes to buy alcohol which is age restricted in the US. The question that can be asked of an Oracle would be "Is this person old enough to buy alcohol?" and the answer that comes back is "Yes/No" with the Oracle handling all of the heavy lifting on the backend regarding state laws that may differ, preservation of Personally Identifiable Information (PII) etc. Contrast this to an Attribute Provider to whom you would be asking "What is this person's Birthday?" and which releases PII info.

It was noted that the Government (Federal/State/Local/Tribal) is authoritative for only a finite number of attributes such as Passport #, Citizenship, Driver's License, Social Security Number etc and that the issue at present is that there does not exist an "Attribute Infrastructure" within the Government. The Federal ICAM Backend Attribute Exchange (BAE) is seen as a mechanism that will move the Government along on this path, but while there is clarity around the technical implementation, there are still outstanding governance issues that need to be resolved.

There was significant discussion about Attribute Quality, Assurance Levels and Authoritativeness. In my own mind, I split them up into Operational Issues and Governance Principles. On the Operational Issue arena, existing experiences with attribute providers have shown the challenges that exist around the quality of data and service level agreements that need to be worked out and defined as part of a multi-party agreement rather than bi-lateral agreements. On the Governance Principals side, there are potentially two philosophies for how to deal with authoritativeness:

1.A source is designated as authoritative or not and what needs to be resolved from the perspective of on attribute service is how to show the provenance of that data as coming from the authoritative source 2.There are multiple sources of the same attribute and there needs to be the equivalent of a Level of Assurance that can be associated with each attribute

At this point, I am very much in camp (1) but as pointed out at the session, this does NOT preclude the existence of second party attribute services that add value on top of the services provided by the authoritative sources. An example of this is the desire of an organization to do due diligence checks on potential employees. As part of this process, they may find value in contracting the services of service provider that aggregates attributes from multiple sources (some gov't provided and others not) that are provided by them in an "Attribute Contract" that satisfies their business need. Contrast this to them having to build the infrastructure, capabilities and business agreements with multiple attribute providers. The second party provider may offer higher availability, a more targeted Attribute Contract, but with the caveat that some of the attributes that they provide may be 12-18 hours out-of-date etc. Ultimately, it was noted that all decisions are local and the decisions about factors such as authoritativeness and freshness are driven by the policies of the organization.

In a lot of ways, in this discussion we got away from the perspective of the Government as an Identity Oracle but focused on it more as an Attribute Provider. A path forward seemed to be more around encouraging an eco-system that leveraged attribute providers (Gov't and Others) to offer "Oracle Services" whether from the Cloud or not. As such the Oracle on the one end has a business relationship with the Government which is the authoritative source of attributes (because of its close relationship with the citizen) and on the other end has a close contractual relationship which organizations, such as financial service institutions, to leverage their services. This, I think, makes the relationship one removed from what was originally envisioned as what is meant by an Identity Oracle. This was something that Nishant brought up after the session in a sidebar with Ian and Myself. I hope that there is further conversation on this topic about this.

My take away from this session was that there is value and a business need in the Government being an attribute provider, technical infrastructure is being put into place that could enable this, and while many issues regarding governance and quality of data still remains to be resolved, there is a marketplace and opportunity for Attribute Aggregators/Oracles that would like to participate in this emerging identity eco-system.

Raw notes from the session can be found here courtesy of Ian Glazer.

Notes from the “Government as Identity Oracle” session at IIW East By Ian Glazer, on September 10th, 2010

These are my raw notes put here for reference purposes.

What is mean by identity oracle?
 * An oracle provides an answer to a question but not a specific attribute
 * If you ask an Oracle, is Peter over 21 it says yes. It does not hand back an attribute - birthdate

Peter: The Federal Govt is authoritative for very few attributes - State Dept - passport #, citizenship. State govt are authoritative for driver's license number. SSA for SSN.

eVerfify is an example of an oracle, says Gerry.

Peter - what will drive this is the requirement for LOA3 credentials needed to access to medical records.

P - "We do not have an attribute infrastructure." A lot of attributes are simply issued via IdP'

I - our examples so far have shown organizations that are authoritative for identifiers but not attributes

P - raises need for back end attribute exchange

Gerry - Problem with authoritative attribute provides is that the PDP makes a decision as to what is truly authoritative for a given context. Authoritative data source must provide SLA or MOU so that relying party can establish trust.

P - BAE is 1/2 of the equation and attribute provider (market?) is the other half

A - is there a business model for attribute providers?

G - have problems seeing attribute exchange at enterprise scale let alone government scale. Quality and availability are just some of the issues. Access decisions are fairly local and these decisions are not things that known often at the higher enterprise layer. Things are made authoritative by policy decision.

P - Second model for authoritative - a local decision to assign authoritative-ness to something

Nishant - should we get rid of the term authoritative?

Peter for sees multiple attribute providers having say over the same attribute for the same person

If I use an Oracle, do I have to know its sources? No, says Gerry, as you form an agreement with the Oracle ahead of time as to what happens when something goes wrong

P- I am running validation services which services 400 back-end apps. I am standing up a BAE to help. I could build that infrastructure or I could can contract out to an Oracle. The Oracle has to tell me its sources so I can make a decision to use it or not. Gerry comments that you may not want to know the Oracle's source of data.

Returning to the eVerify system - is a person allowed to work? eVerify doesn't disclose sources of info but DHS takes responsibility for its decisions.

Pam asks about redundancy of providers. Redundancy allows same decision to be made via separate paths.

Anil feels that there is a business case for multiple providers.

Mary raises the point that there are organizations who have a lot of data on people. These are often highly regulated organizations because they are related to financial services.

G - uses Health Vault and Google Health as an example of multiple providers of heath information data

A - Talked to financial roundtable - these ors not interested in B2C but very interested in B2B situations. Having the govt offering services to help vet people would be of great service.

Govt business for providing identity information? There are certainly companies that will aggregate public data for a fee. If a service provider helps get me as a business information I need to hire someone (citizenship for example), would I use it? Would I form a business to do this? N raises BT's You Are You service as an example of this.

Pam - talking about building cloud-services in this area. Definitely interest from small business for federation and using Google as authoritative source. Sees consumer-focused needs later down the road.

I ask P about persisting "over 18" information if it is acquitted from Equifax. P says they'd have to issues SORN and protect as PII.

I am curious about Govt as Oracle and the implications with respect to the Privacy Act. Peter wants to facilitate market for Oracles. NIH had MOU with InCommon which included use of attributes and information. This included agreed upon protections for those attributes which was coherent with InCommons users' requirements. Peter acknowledges this doesn't scale but he offers as a counterpoint that NIH is doing this federation to federation. He asserts there won’t be that many to federate to.

I many not want to maintain a BAE with hundreds of connections to attribute providers. Likely outsource the work to an Oracle. "It is easier to affiliate with a hubs than it is affiliate with each provider," says Peter A.

Peter says that NIH sees need to handle attributes and thus NIH is setting up BAE. He acknowledges that there needs to be policy and practice around this, which Peter is on the hook to build. FICAM roadmap says that if you are standing up an attribute service it must be a BAE if you want funding.

G - If I am a BAE affiliate and I want to consume other affiliate's data, what is the quality I can expect? Anil says that this is currently being discussed amongst architecture groups. G talked about the quality within his organization. There is no strong commitment to the data that internal data collectors collect. At the end of the day if something goes wrong, is it my fault or someone else's. This is part of the contractual relationship between data consumer and provider.

Hold Harmless clause within MOUs used the by the PKI Bridge. So long as org is acting in accordance with their own policies then they are to be held harmless. G - in certain situations this works, but in others it does not. I might have to run my own infrastructure or shop for another provider who can back up their assertions.

Pam asks if this is govt to govt discussion, would a private group come in an provide services for G2G? Anil says yes and that currently this is happening.

Because there are so many million of high level of assurance credentials, one would think that someone would want to build an ecommerce infrastructure to consume these creds - says Peter.

Peter asserts authentication is a solved problem and next up is authorization, claims, roles, etc.

Every application owner want to maintain control over who comes into the app. But this a way that  Peter gets people to plug into the federated SSO environment.

Are people building services to consider risk-based authorization in transaction, asks Pam. Anil mentions the consideration of environmental attributes for initial authorization. G says this is a hot space now. Anil brings up how PayPal takes a low assurance cred and uses it for financial transactions.