Identity Assurance Means Never Having To Say “Who Are You, Again?”

A decade after launching the SAML standard and seeing its, shall we say, stately pace of adoption, it’s wild to see real single sign-on and federated attribute sharing starting to take off for social networking, retail sites, online gaming, and more — not to mention seeing the US government starting to consume private-sector identities on citizen-facing websites.

Last week, we published a report on Outsourcing Identity Assurance. In it, I examine this “Government 2.0” effort, including the National Strategy for Trusted Identities in Cyberspace (NSTIC), and its innovations around identity assurance, and the confidence you can have in the real-world verification of the identity you’ve been given by an identity provider. We’re predicting you’ll see new Web 2.0-ish ways to outsource identity verification in the coming three years, driven by use cases like e-prescribing, high-value eCommerce, and even online dating.

But perhaps the US government’s four convenient “levels of assurance” (LOAs), which tie strong authentication to strong identity proofing, don’t apply to every use case under the sun. On the recent teleconference where I discussed these findings, we ended up looking at the example of World of Warcraft, which offers strong authentication but had to back off strong proofing. And over the weekend, I had a great back-and-forth with Stephen Wilson and others in the Twittersphere over the applicability of LOAs to financial Know Your Customer programs.

What do you think? Would it be helpful for you to “pick a level” if you outsourced authentication to a third-party identity provider, or would your use cases fall through the cracks?


My answer is clearly: "It

My answer is clearly: "It depends".

One of the concerns that I am dealing with is how sourcing authentication (and potentially even some authorization) within an organization. While having a single enterprise makes it easier to deal with the transfer of authority (and liability), I can see a parallel universe to classical outsourcing.

It might be easier to tackle the intra-enterprise sourcing of authN and authZ and determine what imapct LOAs might have there. Examples for different LOA requirements might be HR and HIPAA data versus Financials versus Product Marketing (and trade secrets) versus intranet wiki access.


Authentication/attribute separation

I'm a strong proponent of the principle of separating authentication (and credential management) from attributes. The draft NSTIC strategy also describes a separation between identity providers and attribute providers.

I consider identity proofing to be a determimation that there is a binding (association) between a principal (user or non-person entity) and some attribute like a name or identification number. The thoroughness of that proof, made at enrollment time, determines the LOA of that attribute.

There is also a LOA associated with the authentication process, made at transaction time. A low-assurance authentication could be used when there is a high assurance attribute, and vice versa. The overall LOA is the lesser of the attribute and the authentication LOA.

Unfortunately, NIST SP 800-63 which gives the technical descriptions of LOAs doesn't separate authentication and attribute LOAs in this way. It only describes the composite result.

Authentication lifecycle

Many thanks Eve for the blogs and the dialogue.
I think an important key to understanding LOA may be to distinguish authentication at enrolment/registration time from authentication at transaction time. I am not sure that NSTIC for example has yet contributed much to that subtlty.
In fact I'm thinking now there's a whole authentication management lifecycle that starts before anyone ever signs up to a system. Decisions are made about identification protocols at design time, and those decisions are made on behalf of all sorts of stakeholders (users, RPs, IdPs etc.). Users are then identified at enrolment time, when the scheme concerned tries to manage misidentification risk by various means like face-to-face vetting, and without ever reducing the impersonation risk to zero. Subsequently users sally forth online with the issued identities and use them to authenticate themselves in connection with different transactions. In routine transactions, few RPs stop to ponder the "trust level" of a Subject: they are either qualified or they're not.
I think LOAs have a role to play in design and enrolment. But at transaction time, I believe that introducing LOAs into transaction settings where Subjects are traditionally either authorised or not (trust there is binary) is a radical change.
Steve Wilson

The Kantara Initiative’s

The Kantara Initiative’s Consumer Identity WG issued an Interim Report in October 2010 that addressed LOA issues. In particular, the report advocated that “high assurance” should be redefined to reflect a linking of strong authentication technology with rigorous verification of any type of claim. So for instance, upon enrollment in a high value service such as a credit card account, the service provider may want high assurance that it knows the identity of the person enrolling. Once enrolled, a service provider needs high assurance that anyone seeking access to the service is authorized to do so. To use the credit card example, an online merchant that accepts credit cards for payment needs high assurance that someone attempting to pay using a particular credit card number is authorized to do so. This type of high assurance is not covered under the government’s four LOAs. While a credential used during enrollment may be backed with the same authentication technology (OTP, PKI, etc) as a credential used during subsequent transactions, the claims may be very different.

Great comments

Thanks to all for the thoughtful contributions. Sorry it's taken so long for me to see them. Herewith some responses...

Gerry, your suggestion about different business functions having different needs seems right on. While OMB M-04-04 isn't necessarily the be-all and end-all, its risk profiling buckets seem to be a good organizational tools. I found a lot of use cases that could easily be plopped into the Levels.

Jim, excellent point about needing to "fail down to" the lower assurance. In my teleconference, I talked a bit about the "chain of evidence" that you need in order to bind an attribute to the person it showed up with to achieve a certain risk exposure.

Stephen, it's great to engage with you here where we have more than 140 characters to spend! Agreed that the leap to just-in-time authentication quality (mostly the ICAM-layer stuff) from the proofing piece (mostly the 04-04/800-63 layer) goes quite a distance. The other thing I wonder about in 800-63 is the front-loading of proofing, with no guidance (that I'm aware of??) around a continuum of verification over the credential usage lifetime. Is this left simply as an exercise for the (as yet somewhat incomplete) legal liability infrastructure?

Bob, thanks for mentioning the Consumer Identity interim report, which can be found here:

I'd be interested to hear Stephen's take on it in particular, given his focus on mismatches in the financial world. FWIW, I had a few more thoughts on this general financial vs. LOA impedance mismatch question and other potential mismatches in this blog post a while back...