NIST’s Concept of Credential

NIST is great in many areas but I find their material on identity management really stands out, and their set of Digital Digital Identity Guidelines in particular is a great resource. One thing that caught my attention while reading NIST Special Publication 800-63 is the distinction they make between an authenticator and a credential. I wondered: is it useful or even necessary to make this distinction? Should I be interrupting people to correct them on their use of the term “credential”, or is this more like correcting someone when they call a tomato a vegetable?

The NIST guidelines define authenticator in the classic way: something you know (e.g. a password), have (e.g. an ID card), or are (e.g., fingerprint). When you authenticate to a system you’re expected to be in control of one or more authenticators.

NIST describes a credential as such (CSP is a credential service provider): 

An object or data structure that authoritatively binds an identity – via an identifier or identifiers – and (optionally) additional attributes, to at least one authenticator possessed and controlled by a subscriber.

While common usage often assumes that the subscriber maintains the credential, these guidelines also use the term to refer to electronic records maintained by the CSP that establish binding between the subscriber’s authenticator(s) and identity.

And earlier in section 4.3.2:

As described in the preceding sections, a credential binds an authenticator to the subscriber, via an identifier, as part of the issuance process. A credential is stored and maintained by the CSP, though the claimant may possess it. The claimant possesses an authenticator, but is not necessarily in possession of the credential. For example, database entries containing the user attributes are considered to be credentials for the purpose of this document but are possessed by the verifier. X.509 public key certificates are a classic example of credentials the claimant can, and often does, possess.

In the 800-53 FAQ they further define a credential as part of answering the question: “Is an assertion a kind of authenticator or credential?”

The key mechanism here is the binding of the identity of the subscriber to a specific authenticator. In other words, a credential combines attributes about the subscriber with an authenticator. An example would be a certificate with subscriber attributes embedded within the certificate. An assertion may contain subscriber attributes, but it does not function as an authenticator, as discussed above.

The term that resonates with me is binding. And this seems to hold as I think through a few scenarios:

• Citizenship – NIST would say my credential as a Canadian citizen is my entry in the federal government’s database of citizens containing my photo, demographics, and passport number. This is a credential I can possess in the form of a passport, which also serves as an authenticator in some cases.
• Employment – A company-issued physical authenticator (e.g., a key fob) is not a credential since on its own it does not identify me. The credential is my record in my company’s identity management system binding my user ID to my current key fob. When I lose my fob this link has to be severed (once I report the missing fob) and then updated when I’m issued a new fob.

Where things get mixed together is in the area of passwords, and since passwords remain ubiquitous the term credential is most often used to refer an ID/password pair. This pair does indeed bind an identity to an authenticator and for many consumer online services, the credential and authenticator are effectively the same thing. A typical online service stores a credential that is your email address plus your (hashed) password and that might be the entire “data structure” NIST talks about that binds you as a subscriber to an authenticator. As the subscriber, you know both of these things and as a pair they are (often) the one authenticator you need to get into the online service.

So is the distinction between credential and authenticator an important one to make? I don’t think it is quite ready to be brought into your everyday conversations. The linkage between credential and username/password is too ingrained in everyone’s thinking.  I suspect you can often get your point across without trying to separate them, and it is more likely to cause a distraction if you were to try.

That said, I think it can be useful and even necessary to separate these terms if you are designing or analyzing an identity management system. I find it becomes especially helpful when you:

• are thinking about credentials in a broad sense and not only for online service logins. For example, how would you identify a valid police officer or a licensed medical doctor?
• are working with multiple authenticators and have adopted NIST’s thinking in terms of separating authenticator assurance level (AAL) from identity assurance level (IAL).