My blog has moved and can now be found at http://blog.aniljohn.com

No action is needed on your part if you are already subscribed to this blog via e-mail or its syndication feed.

Sunday, September 12, 2010
« My first un-conference session at IIW-EA... | Main | Federation Flows 1 - Authentication »

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

  • 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?

Some of the vocal folks at this session, in no particular order, included (my apologies to folks I may have missed):

  • 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 an 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.


Tags:: Architecture | Security
9/12/2010 2:00 PM Eastern Daylight Time  |  Comments [1]  |  Disclaimer  |  Permalink   
Tuesday, September 14, 2010 3:05:15 PM (Eastern Daylight Time, UTC-04:00)
Anil,

Interesting topic attributes. Just a few comments/thoughts:

Agree the Oracle is there for the "immutable": name, birthday, birthplace,

There are difference between attribute_age and attribute_clearance

Most attributes_mutable are separate from the identity oracle,

In the case of first responders I was involved with colleagues in deploying an attribute infrastructure for the Federal government, contrary to the groups assumption that none exist, in 2006 or so that is still in place. The infrastructure supports emergency support function (ESF) designations for first responders.

As soon as you went below top level designation, we ran into differences in attribute definitions and requirements among state and local entities. E.g. swiftwater rescue was not the same across states in Firefighting ESF 4). You found the same in other categories e.g. ESF 8 medical and public health.

I don't think the idea of the BAE as identity oracle makes sense from a transactional perspective, I don't want to go to the authoritative source each time, much better to be able to be in charge (in possession) of my attributes and assert them to the RP, this is where the value of an oracle lies. It enables the RP to say yes.

Effort needs to take place on the definitions of the attributes and then the assignment of the object identifiers for them, then we can talk about the method of exchange.

Thanks for fostering further discussion on the topic

Sincerely,

Sal

Comments are closed.