Beyond Industrial Era Identity Management

(The following is the statement I’ll deliver today at the National Strategy For Trusted Identities in Cyberspace event at the White House.)

Our way of thinking about identity management is outdated. This outdated thinking poorly reflects the way we interact on Main Street, and it doesn’t fit the needs of people and enterprises trying to interact on the Internet.

On the whole, current thinking regarding identity management is that of the Industrial Era. Enterprises are creating “company towns” for identity. In the Industrial Era, companies, such as Pullman, created towns for their workers to live in, and these towns provided all the services that the employees could use. In today’s identity “company towns,” the enterprise has created your identity, owns your identity, and you cannot use your identity anywhere else – it has no value or meaning outside of “the town.”

This model is problematic. First, this is antithetical to our belief in self-determination. Second, this model is costly. Enterprises have to create and support extra services to manage identities. This also increases information security risk because the enterprise possesses potentially sensitive information that it must protect, not to mention the problems and risks related to over-collection of personal information. The last problem with this outdated way of thinking is that it doesn’t reflect how the non-digital world works.

In the “real” world, I can choose how I want to be known and how much I want to share with others. I can pick my nicknames; I can choose not to share my name. I can choose to tell a merchant my phone number or that my first car was made in America.

Businesses have grown to accommodate and augment the way we interact. Companies offer services to help an enterprise strengthen individually asserted claims, such as my name and my address. Credit bureaus and other services help businesses gain higher assurance that the “Ian” in front of them is really me.

We must leave the “company town” model of identity management. We must shift our digital interactions to be more like our day-to-day, face-to-face ones. The evolution toward federated identity would mean that our identities are no longer owned by parties other than ourselves.

Just as in the real world, third parties can be consulted to help an enterprise have greater assurance that the “@iglazer” using its service is me. Such third parties can help the enterprise have greater confidence that “@iglazer” is over-21 and has a verified mailing address here in DC. By the way, the services offered by these third parties are new business opportunities.

With both greater assurance about the individual’s identity and confidence in what they claim about themselves, business can:

  • avoid managing identities and thus not have to deploy extra services such as password reset
  • reduce information risk by collecting less information about individuals
  • deliver higher value services to the individual

In the last year, NSTIC has acted as a catalyst, not only for protocol and specification development, but has also driven policy conversations, and more importantly, business conversations. In a way, NSTIC has given the “all clear” signal for the business to get involved in this evolution of identity management.

I used to take calls from Fortune 500 companies asking, “Should we care about OpenID?” Now I take calls that ask:

  • “What are business models for identity providers?”
  • “What communities of interest are likely replying parties for our identity services?”

Within these questions are lie new business opportunities that my customers are looking to capitalize upon.

Now is the time to act. Study your current use of identity – are you the mayor of an identity “company town?” If you truly think you own other people’s identities, take a hard look at whether that ownership brings enough value to offset the expense and risk of maintaining those identities. For most organizations, the risk and expense of owning identities outweighs any tangible benefits. For most organizations, owning identities is a vestige of outdated thinking. As NSTIC gains momentum, now is the time to plan and deploy for our federated future. I am very eager to hear from my fellow panelists and the audience what they are doing and what they have planned.

 

Put 100 Relying Parties in a Room and What Do You Get?

It’s an open secret among us identity geeks that, despite all of federated identity’s progress, one thing has lagged significantly: relying party participation1. Getting relying parties to the table, to talk about challenges they have with identity on the Internet, has always been a hard problem. Although the identity community has grown, the number of relying parties getting involved with things like the Internet Identity Workshop hasn’t kept pace.

Willingly or not, NIST’s National Strategy for Trusted Identities in Cyberspace (NSTIC) has taken up the challenge of increasing relying party participation. Without real-life use cases based on actual business, actually problems, NSTIC is, though aspirational, vague. However, armed with a set of discrete use cases, NSTIC (and more importantly the identity community) can begin to craft solutions, discover unforeseen challenges, strengthen protocols, and tackle policy issues. But to get these needed use cases requires relying parties to be involved.

To that end, NSTIC is hosting an event at the White House Wednesday May 23rd. The program office has invited over 100 companies all of whom are potential relying parties. These companies are household names, spanning multiple industry sectors. In short, they are a cross-section of economic engines of this country, and by bringing them together in a safe space, the NSTIC program office hopes pick up the pace of relying party engagement and bolster the ranks of companies who can become more efficient and unlock new value by using federated identity.

But there’s only so much convincing the government can do directly. At the event, I’ll be participating on a panel of companies from different industries discussing the value they can recognize by using the techniques that NSTIC promotes. I am going to try and tweet as much as I can from the event and will follow up with a post on its results. If you want to keep tabs on NSTIC’s relying party party, follow me, and tune in on Wednesday May 23rd at 10am eastern.

 

1 I know that getting identity providers to play is an issue too but that seems to be an easier problem to solve.

Notes from the “Government as Identity Oracle” session at IIW East

These are my raw notes put here for reference purposes.

Attendees

  • Peter A
  • Mary R
  • Ian G
  • Gerry B
  • others

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 asks 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 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 wont 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 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.