An initial challenge when entering the world of digital identity is deciphering the jargon and specialized terminology, like CSP and IdP. Mastering our industry’s unique terminology both provides job security for those familiar with it, and creates a barrier for those seeking enough knowledge to navigate the field. Many people in healthcare want to make sound decisions for their organizations without necessarily becoming digital identity experts, but there are some high-level terms that everyone should be familiar with.

In the realm of digital identity, there are two types of confusing terminology: overloaded terms, and synonyms. Overloaded terms are words that carry different meanings depending on their context. In contrast, synonyms refer to the situation where multiple different terms are used to describe the same concept. Tangential to the first two, an added challenge relates to the sheer volume of terminology and acronyms, which can be overwhelming.

In part one of this two-part series, we’ll delve further into two terms that fall within this third challenge, and can be confusing for both newcomers and experts alike: Credential Service Provider (CSP) and Identity Provider (IdP).

What is a Credential Service Provider (CSP)?

In the latest draft release from the NIST SP 800-63 series, NIST defines a Credential Service Provider (CSP) as: “A trusted entity whose functions include identity proofing applicants to the identity service and the registration of authenticators to subscriber accounts.”

A CSP is the broadest term for describing an organization that identifies individuals and issues credentials. Some might call it a ‘catch-all’ term. A classic example of a CSP is a Certification Authority. Another, perhaps more relatable example of a CSP is a Motor Vehicle Administration (MVA) issuing driver’s licenses or Mobile Drivers Licenses.

Credential Service Providers can take many forms. Their obligations or functions remain largely the same, regardless of the technology employed.

Where a CSP and an Identity Provider (IdP) start to differ is in the additional function that an IdP takes on, referred to as a Verifier.

Let’s Back up a Second. What exactly is a Verifier?

Before we can contrast an IdP with a CSP, we need to introduce yet another term: a Verifier. NIST defines a Verifier as: “An entity whose function is to verify the claimant’s identity by verifying the claimant’s possession and control of one or more authenticators using an authentication protocol. To do this, the verifier needs to confirm the binding of the authenticators with the subscriber account and check that the subscriber account is active.”

A Verifier functions both as an independent, concrete service, and as an integrated component within a CSP’s functions. When operating independently, think of the Verifier as a distinct service akin to a gateway responsible for authenticating users to access online applications. In this context, the Verifier’s primary responsibility is user authentication. After successful authentication, users gain access to the application.

At DirectTrust, we know that Verifiers serve an important role in healthcare and will continue to do so in the future. The draft DirectTrust Identity Provider Policy defines a uniquely capable type of Verifier called a Federated Trust Gateway. This specialized Gateway can process a variety of authenticators and credentials on behalf of a healthcare organization. It supports complex identity infrastructures to help automate tasks that are typically manual processes. Such a capability may allow digital identity in healthcare to scale across the nation in the not-so-distant future. We’ll delve more into the Federated Trust Gateway in blog two!

For those trying to keep their digital identity terminology straight, this is when it can get complex. A Verifier can morph into a different form. Some service providers have decided to combine the functions of a Verifier with the functions of a CSP, resulting in a new kind of service in which the Verifier role becomes more of a pseudo-service. The term ‘Verifier’ is used solely to describe the subset of responsibilities of the larger service rather than describing the functions of a separate entity.

Enter: The Identity Provider (IdP).

What is an IdP?

NIST describes an IdP as: “An entity in a federated model that performs both the CSP and Verifier functions. The IdP is responsible for authenticating the subscriber and issuing assertions to communicate with one or more RPs.”

IdPs are a special type of CSP. IdPs take on the additional responsibility of authenticating users on behalf of the applications that the user wants to access. A tangible example is, “Sign in with Google.”

How does an IdP work?

In order for a user to sign in with an IdP (i.e. Google), a few things need to happen.

The user needs to be identity proofed in mostly the same way as any CSP, then bind authenticators to their IdP account. You may have heard of Google Authenticator or Microsoft Authenticator or even enrolled your phone to receive SMS texts with a One-Time Password (OTP). These are all examples of authenticators that you must bind to an account managed by an IdP. A password is even a type of authenticator. In fact, many IdPs require a combination of more than one authenticator, or a muti-factor authentication (MFA).

Since the Verifier is built into the IdP, when a user wants to authenticate themselves, they don’t prove their identity to the application they want to access. Rather, they authenticate themselves with the IdP, and then the IdP tells the application that it can safely sign in the user.

The Role of Federation Assertions

Federation assertions are a core attribute of an IdP. If a CSP is responsible for authenticating its identity-proofed users and generating federation assertions, then it’s considered an IdP. Any application that a user wishes to sign into using their IdP must be configured to trust federation assertions, generated by the IdP. The federation assertion tells the application that they can sign in the user because they have successfully authenticated with the IdP. If the service trusts the IdP, they will let the user access whatever the user is allowed to access without having to prove their identity to the application. NIST SP 800-63C defines a set of requirements for securing federation assertions generated by IdPs.

Conclusion

In this first blog, we’ve uncovered some of the challenges that newcomers and experts alike face when grappling with the complexities of the digital identity field. From overloaded terms to synonyms and a plethora of acronyms, the landscape can be overwhelming.

As we embark on our quest for clarity, we’ve also introduced you to the roles of pivotal players in the digital identity realm: Credential Service Providers (CSPs), Verifiers, and Identity Providers (IdPs). These entities, while seemingly similar, possess distinct functions and responsibilities within the intricate web of digital identity. Whether you are a novice or an expert, understanding these nuances is not only essential but empowering for anyone navigating the digital identity landscape.

In part two of this series, we’ll delve deeper into the components that define digital identity as you navigate this ever-evolving field.

Kyle Neuman is DirectTrust’s Director of Trust Framework Development