Identity assurance levels (IALs) and digital identity

There is more and more talk about digital identity, especially as COVID-19 accelerates the move to contactless and remote transactions. However, there are many types of digital identity, ranging from a Colorado, Louisiana, or Oklahoma digital driver’s license to your Facebook, Google, or Microsoft ID to the online equivalent of my old Radio Shack Battery Club card.

All of these different types of digital identities suggest that some identities are more rigorous than others. For example, I’ve lost track of how many digital identities I’ve created with Google over the years, but if California ever gets around to implementing a digital driver’s license, I’ll only have one of them. (And I won’t be able to get another license in Nevada.)

In this particular case, the government IS here to help.

The U.S. National Institute of Standards and Technology has defined “identity assurance levels” (IALs) that can be used when dealing with digital identities. It’s helpful to review how NIST has defined the IALs. (I’ll define the other acronyms as we go along.)

Assurance in a subscriber’s identity is described using one of three IALs:

IAL1: There is no requirement to link the applicant to a specific real-life identity. Any attributes provided in conjunction with the subject’s activities are self-asserted or should be treated as self-asserted (including attributes a [Credential Service Provider] CSP asserts to an [Relying Party] RP). Self-asserted attributes are neither validated nor verified.

IAL2: Evidence supports the real-world existence of the claimed identity and verifies that the applicant is appropriately associated with this real-world identity. IAL2 introduces the need for either remote or physically-present identity proofing. Attributes could be asserted by CSPs to RPs in support of pseudonymous identity with verified attributes. A CSP that supports IAL2 can support IAL1 transactions if the user consents.

IAL3: Physical presence is required for identity proofing. Identifying attributes must be verified by an authorized and trained CSP representative. As with IAL2, attributes could be asserted by CSPs to RPs in support of pseudonymous identity with verified attributes. A CSP that supports IAL3 can support IAL1 and IAL2 identity attributes if the user consents.

Interestingly, the standard assumes that pseudonymous identity can be proofed…but this requires that SOMEONE know the actual identity.

And in practice, the “physical presence” requirement of IAL3 can be met by either being “in-person,” or in a “supervised remote” case. (This is needed to make sure that I don’t register with someone else’s face, for example.)

So when considering the robustness of any digital identity scheme, it’s necessary to ascertain whether the digital identity can reliably be mapped to a real life identity. This doesn’t necessarily mean that IAL1 is bad per se; in some cases, such as my old Radio Shack Battery Club example, a robust mapping to a real life identity is NOT necessary.

But in other cases, such as a need to gain entrance to a nuclear power plant, that reliable mapping IS essential.

Someone once said that I look like this guy. By US Embassy London –, Public Domain,

Leave a Comment

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s