How to rest assured

Everybody’s talking about identity assurance these days, meaning, generically, the confidence a relying party needs to have in the identity information it’s getting about someone so that it can manage its risk exposure.

A lot of the conversation to date has revolved around NIST Special Publication 800-63 (newer draft version here) and its global cousins, which boil down assurance into four levels — hence all the loose talk of LOA (for “level of assurance” or sometimes AL for “assurance level”), even when people aren’t focusing on specific levels or even systems of assurance numbering. NIST 800-63 is intended to answer the use cases defined in OMB Memo 04-04, which deals with making sure users of the U.S. Federal government’s online systems are who they purport to be. Here’s an example given in OMB M-04-04 for one particular need for level 3 assurance:

A First Responder accesses a disaster management reporting website to report an incident, share operational information, and coordinate response activities.

And here’s how NIST 800-63 defines assurance (I’m quoting the Dec 2008 draft here; strangely, the official Apr 2006 version doesn’t include a formal definition):

In the context of OMB M-04-04 and this document, assurance is defined as 1) the degree of confidence in the vetting process used to establish the identity of an individual to whom the credential was issued, and 2) the degree of confidence that the individual who uses the credential is the individual to whom the credential was issued.

So there’s an identity proofing component at registration time that nails down the precise real-world human being being referred to, and there’s a security/protocol soundness/authentication component at run time that establishes that the credential is being waved around legitimately. These get added up into four levels defined roughly like this (leaving aside the security and protocol soundness factors):

nist-matrix

(Here, “same unique user” means that the same user can be correlated by the RP across sessions. And “verified name provided” means that the user’s real-world name is exposed to the RP, versus some sort of pseudonym; level 1, where no proofing is done, is implicitly pseudonymous, while level 2 offers a choice.)

I don’t mean at all to criticize this rolled-up four-level approach. It seems to have met the needs set out in M-04-04, and it predated both the “user-centric” movement (Dale Olds has a nice rundown of its use cases here) and truly modern notions of online privacy.

But I think we need more clarity about assurance use cases and terminology, for two reasons: One is to help ensure that identity providers can give RPs what they need, rather than what might just be a poor approximation based on NIST 800-63’s fame. The other is to help ensure that IdPs give RPs only what they need, since more assurance is likely to involve more personal information exposure.


To that end, let me explain some assurance use case buckets I’m seeing in the wild, and their relationship to the NIST requirements and each other. First, here are some use case buckets hiding in plain sight in the NIST levels:

buried-use-cases

Simple cross-session correlation: While NIST 800-63 doesn’t formally include “same unique user” as a goal, it’s in there:

Level 1 – Although there is no identity proofing requirement at this level, the authentication mechanism provides some assurance that the same claimant is accessing the protected transaction or data.

Funnily enough, cross-session correlation (without the baggage of proofing) is a key requirement of many enterprise and Web federated identity interactions. Lots of sites don’t need or want to know you’re a dog; they just need to know you’re the same dog as last time. This way, they can authorize various kinds of ongoing access and give you something of a personalized experience across sessions. Though NIST treats this as an also-ran and couples it with weak authentication in level 1, other use cases may have reason to match up “mere correlation” with higher authentication.

Identity proofability: If an RP can trust that it’s dealing with a human being who has some level of serious representation in civil society, it’s a powerful kind of assurance for lots of purposes. More about this below.

Real-world identity mapping: When level 3 or 4, or verified-name level 2, is used, this means a user’s real name is used to build up the unique identifier that the RP sees, and this verified name leaks PII like crazy, even if it’s not itself unique. (As far as I know, I’m the only Eve Maler out there…) This is strong stuff, and in a modern federated identity environment, it is to be hoped that most RPs simply don’t need this information. (John Bradley — that is, the John Bradley who works with the U.S. government on its ICAM Open Identity Solutions program — tells me he believes pseudonyms should be an acceptable choice all up and down the four levels, indicating that this use case bucket is fairly rare.)


Now things get really interesting, because there are other use case buckets that you can sort of see in this matrix if you squint, but really they’re just different:

addl-use-cases

Anonymous authorization/personalization: This is the flip side of cross-session correlation. OMB M-04-04 talks about “attribute authentication” and the potential for user attributes to serve as “anonymous credentials” (where an RP simply can’t know if this is the same unique user coming back but can still base its authorization decisions and personalization actions on the veracity of the attributes it’s getting). The attributes in question can range from “this user is over 18″ to “this user is a student at University ABC” to “this user is of nationality XYZ”.

Ultimately M-04-04 puts the whole area of attribute authentication firmly out of scope, but lots of folks have been picking at the general problem of attribute assurance in the last several months — like Internet2 in its Tao of Attributes workshop, and the Concordia group in a forthcoming survey (stay tuned for more on that).

This bucket often requires being able to check who issued some assertion or claim, and considering whether they’re properly authoritative for that kind of info. The way I think about this is: Who has the least incentive to lie? That’s why you can be said to be truly authoritative for self-asserted preferences such as “aisle vs. window”. Any other way lies madness (“What is your favorite color?” “Blue. No yel– Auuuuuuuugh!”).

Of course, there are cases where an RP really does need attribute assurance along with other kinds, like correlation or identity mapping. And don’t forget that it takes precious little in the way of personal information for an RP to figure out “who you really are” anyway. (Check out this cool Tao of Attributes diagram, which touches on all these points.)

Financial engagement: Sometimes an RP just just wants some assurance they’re dealing with someone who has sufficient ties to the world’s legitimate financial systems not to screw them over entirely. It turns out that identity proofability can often be a serviceable proxy for this kind of confidence. (Financial account numbers are one kind of proofing documentation in NIST 800-63.) And the reverse is also true: financial engagement can sometimes give a modicum of confidence in identity proofability.

Interestingly, this bucket can be useful even without any of the other kinds, partly because the parties can lean on a mature parallel financial system instead of just lobbing identifiers and attributes all over the place. For example, users often “self-assert” credit card numbers (which RPs then validate out of band with the card issuer), or use third-party payment services like PayPal (where the service provider does a lot of the risk-calculation heavy lifting).


No doubt there are other assurance use cases. Understanding them more deeply can, I think, help us get better at sharing the truth and nothing but the truth about people online — without having to expose the whole truth.

(Thanks to John Bradley, Jeff Hodges, and Andrew Nash for comments on early drafts of this post. And check out Paul Madsen’s many excellent commentaries on assurance matters.)

Tags: , ,

11 Comments to “How to rest assured”

  1. Paul Madsen 4 January 2010 at 12:47 pm #

    There is a Venn in here, and I will not rest until I find it :-)

    paul

  2. Gerald Beuchelt 4 January 2010 at 1:35 pm #

    Using pseudonyms is ok (and actually potentially preferred) in most cases, at least as long as they can be de-referenced into real-name at audit time.

    As far as attributes go: authoritativeness is really consumer dependent – in many cases the authority of a source may be perfectly acceptable for a given consumer, while not at all acceptable for another. A better concept here might be “data originator”, i.e. the original author of some data. If you use this concept, you can build on (context dependent) reputation schemes for the data originator (who might actually an aggregator or deriver of data). I find this overall easier than introducing yet another artificial concept such as “authoritativeness”.

  3. Eve 4 January 2010 at 2:13 pm #

    Gerry– Your attribute assurance point is excellent. If you as an RP can specify who you’ll accept as a source/data origin (including a trusted aggregator who deals only with trusted sources “further back”), the whole question of authority sort devolves into this. Regarding pseudonymity, I gather from John B. that the verified name stuff is largely a holdover from the PKI heritage of NIST SP 800-63, and it’s arguable what is truly required in this area at a technical level. To the extent that it’s possible to argue for more-minimal disclosure as a fair reading, that would be a good thing!

    Paul– My mouse did hover over the “Venn” category button for a moment, but it seemed too impure to get away with. ;-) By all means, have at it…

  4. Rich Salz 7 January 2010 at 10:00 pm #

    If only CertCo had succeeded; we were in this space 10 years ago. See my blog on it.

  5. Eve 8 January 2010 at 9:22 am #

    (For ease of reference, Rich’s post is here.) Maybe you should take another run at it!

    To be sure, the U.S. government and lots of other governments already have PKI-based systems in place to handle the single-axis space they’ve developed in NIST SP 800-63. (Whether revocation is handled properly in those systems, I don’t know…) But the richness of the types of confidence really needed in the wild — that is, not just in government applications but others — suggests that more is needed. We’re certainly finding that to be true in the UMA work, where we’re trying to do data-sharing terms negotiation through a freshened-up “claims” mechanism. (More on that very shortly. Hey, Rich, we could use you on the team!)

    And in the meantime, many web developers push back on doing the tiniest bit of crypto, which makes it awfully hard to achieve even the sorts of security and confidence we know how to do pretty well. (See Ben Laurie’s recent lament about WRAP on this score.)

  6. […] Pushing String » How to rest assured (tags: evemaler identityassurance identity identityproofing) […]

  7. […] How the U.S. government’s need for assurance may or may not match commercial/social requirements for assurance: How to rest assured. […]

  8. […] by trusted issuers in some fashion. Attribute assurance is akin to identity assurance (as discussed previously here), except that it’s about the quality of specific types of information and their binding […]

  9. Robin Wilton 16 April 2012 at 2:01 am #

    Great post, Eve. Captures the salient points so clearly. Re: Gerry’s comment about attribute assurance, another analogy to use is with cash payment.

    In the online world, sometimes all the RP needs is an assurance that “x is good for $10″… it doesn’t matter who x is, provided they can offer a trustworthy assertion of creditworthiness from somewhere. (Self assertion is probably not best in this instance, for the same reasons online as offline… ;^).

    In the offline world, presenting the RP (merchant) with $10 is an anonymous assertion of creditworthiness, but its trustworthiness depends on the reliability of the issuing bank and the integrity of the banknote.

    R

  10. Lance Peterman 16 April 2012 at 7:54 pm #

    Just realized how old this post was, and yet still quite insightful. Thanks for sharing, Eve!

  11. Eve 17 April 2012 at 7:49 am #

    Thanks to Robin and Lance for the “modern” comments on this somewhat aged post! Indeed the topic of assurance is very much alive, and it seems like the state of the art has a chance to improve. (See Anil John’s contemporary blog post and the comment thread for more context…)