This article will take you through the concepts of Digital Identity and Authentication, and how they are generally implemented in IT environments to automate access to websites, services and applications. While this article does not require any specific technical knowledge, it is not a trivial topic, and I have purposely tried to not oversimplify some of the concepts. I have done my best to keep it easy to read, but feel free to send some feedback if some parts are too complex and you would like further clarifications.
Also, number of the concepts in this article are from the NIST Special Publication 800-63-3.

Digital identity is the unique representation of a subject engaged in an online transaction. The information contained in a digital identity allows for assessment and authentication of a user interacting with a system on the web, without the involvement of human operators. Digital identities allow our access to computers and the services they provide to be automated.
A digital identity is always unique in the context of a digital service. Identity proofing establishes that a subject is who they claim to be. So you might have different accounts to access a single service, but each of these accounts is considered as a single identity.

Digital authentication is the process of determining the validity of one or more authenticators used to claim a digital identity. Authentication establishes that a subject attempting to access a digital service is in control of the technologies used to authenticate. Successful authentication provides reasonable assurances that the subject accessing the service today is the same as that which previously accessed the service.

For organisations, digital identity presents a technical challenge because this process involves proofing individuals over the web, and typically involves the authentication of individual subjects. There are multiple opportunities for impersonation and other attacks that fraudulently claim another subject’s digital identity.

Digital Identity Model

Overview

Digital identity is the unique representation of a subject engaged in an online transaction. The process used to verify a subject’s association with their real-world identity is called identity proofing. In this article, the party to be proofed is called an applicant. When the applicant successfully completes the proofing process, they are referred to as a subscriber. The identity is provided and managed by a Digital Identity Service Provider, that we commonly refer to as the Identity Provider.

In most applications context, identity proofing is required, and the application may request the Identity Provider assert information about the subscriber, such as verified attribute values (name, email address, etc.)

Some applications follow a federated identity approach, also known as Single Sign-On. This is where the applications outsource all identity proofing, attribute collection, and attribute storage to an Identity Provider shared with other services. Using your Facebook account to connect to Netflix and Spotify (both services being not owned by or associated to Facebook) is an example of federated identity.

When it comes to authenticating, the party to be authenticated (the user) is called a claimant and the party verifying that identity is called a verifier. The verifier and the Identity Provider are often combined in a single service, however in specific cases, they might be separate. For example, if using digital certificates as authentication, the verifier would be the certificate authority and not the Identity Provider. In this document, we will keep them separated in order to facilitate the distinction between the identity proofing part and the authentication part of the workflow.

When a claimant successfully demonstrates possession and control of one or more authenticators (such as password, SMS one-time passcode&hellip to a verifier through an authentication protocol, the verifier can verify that the claimant is a valid subscriber. The verifier passes on an assertion about the subscriber to the application. That assertion includes an identifier, and may include identity information about the subscriber, such as the name, or other attributes that were collected in the enrolment process.

Authentication establishes confidence that the claimant has possession of the authenticator(s) bound to the credential. Authentication does not determine the claimant’s authorisations or access privileges; this is a separate decision and is out of this article’s scope. Applications can use a subscriber’s authenticated identity and attributes with other factors to make authorisation decisions.

The various entities and interactions that comprise the digital identity model used here are illustrated below:


The left side of the diagram shows the enrolment, credential issuance, lifecycle management activities, and various states of an identity proofing and authentication process. The usual sequence of interactions is as follows:

1. An applicant applies to an Identity Provider through an enrolment process.
   
2. The Identity Provider identity proofs that applicant. Upon successful proofing, the applicant becomes a subscriber.
   
3. Authenticator(s) and a corresponding credential are established between the Identity Provider and the subscriber.
   
4. The Identity Provider maintains the credential, its status, and the enrolment data collected for the lifetime of the credential (at a minimum). The subscriber maintains his or her authenticator(s).
   

Other sequences are less common, but could also achieve the same functional requirements.

The right side of the diagram shows the entities and interactions involved in using an authenticator to perform digital authentication. A subscriber is referred to as a claimant when he or she needs to authenticate to a verifier. The interactions are as follows:

1. The claimant proves possession and control of the authenticator(s) to the verifier through an authentication protocol.
   
2. The verifier interacts with the Identity Provider to validate the credential that binds the subscriber’s identity to their authenticator and to optionally obtain claimant attributes.
   
3. The Identity Provider or verifier provides an assertion about the subscriber to the application, which may use the information in the assertion to make an authorization decision.
   
4. An authenticated session is established between the subscriber and the application.
   

In all cases, the application should request the attributes it requires from an Identity Provider before authenticating the claimant. In addition, the claimant should be requested to consent to the release of those attributes prior to generation and release of an assertion.

In some cases, the verifier does not need to communicate in real time with the Identity Provider to complete the authentication activity (e.g., some uses of digital certificates). Therefore, the dashed line between the verifier and the Identity Provider represents a logical link between the two entities. In some implementations, the verifier, application, and Identity Provider functions may be distributed and separated. However, if these functions reside on the same platform, the interactions between the components are local messages between applications running on the same system rather than protocols over shared, untrusted networks. While the Identity Provider and verifier can be separated or part of the same platform, it is generally a good practice for the application to always a separate platform and avoid managing its own identity and credentials.

As noted above, an Identity Provider maintains status information about the credentials it issues. Identity Providers must assign a finite lifetime when issuing credentials to limit the maintenance period. When the status changes, or when the credentials near expiration, credentials may be renewed or reissued; or, the credential may be revoked and destroyed. Typically, the subscriber authenticates to the Identity Provider using their existing, unexpired authenticator and credential in order to request issuance of a new authenticator and credential. If the subscriber fails to request authenticator and credential re-issuance prior to their expiration or revocation, they may be required to repeat the enrolment process to obtain a new authenticator and credential.

Enrolment and Identity Proofing

The previous section introduced the conceptual digital identity model. This section provides additional details regarding the enrolment and identity proofing.

An individual, referred to as an applicant at this stage, opts to be identity proofed by an Identity Provider. If the applicant is successfully proofed, the individual is then termed a subscriber of that Identity Provider.

The Identity Provider establishes a mechanism to uniquely identify each subscriber, register the subscriber’s credentials, and track the authenticators issued to that subscriber. The subscriber may be given authenticators at the time of enrolment, the Identity Provider may bind authenticators the subscriber already has, or they may be generated later as needed. Subscribers have a duty to maintain control of their authenticators and comply with Identity Provider policies in order to maintain active authenticators. The Identity Provider maintains enrolment records for each subscriber to allow recovery of authenticators, for example, when they are lost or stolen.

Authentication and Lifecycle Management

Authenticators

The classic paradigm for authentication systems identifies three factors as the cornerstones of authentication:

• Something you know (e.g., a password).
  
• Something you have (e.g., a SMS one-time password).
  
• Something you are (e.g., a fingerprint or other biometric data).
  

Multi-Factor Authentication (MFA) refers to the use of more than one of the above factors. The strength of authentication systems is largely determined by the number of factors incorporated by the system — the more factors employed, the more robust the authentication system.

Other types of information, such as location data or device identity, may be used by an application or verifier to evaluate the risk in a claimed identity, but they are not considered authentication factors.

In digital authentication the claimant possesses and controls one or more authenticators that have been registered with the Identity Provider and are used to prove the claimant’s identity. The authenticator(s) contains secrets the claimant can use to prove that he or she is a valid subscriber, the claimant authenticates to a system or application over a network by proving that he or she has possession and control of one or more authenticators.

The secrets contained in authenticators are based on either shared secrets (for example passwords or pins) or public key pairs (for example USB authentication keys). Public key pairs are less vulnerable to guessing or brute force attack but are still not wildly used by the general public.

Usually, authenticators always contain a secret. Some of the classic authentication factors do not apply directly to digital authentication. For example, a physical driver’s license is something you have, and may be useful when authenticating to a human (e.g., a security guard), but is not in itself an authenticator for digital authentication. Authentication factors classified as something you know are not necessarily secrets, either. Knowledge-based authentication, where the claimant is prompted to answer questions that are presumably known only by the claimant (i.e. so-called “security questions&rdquo, also does not constitute an acceptable secret for digital authentication. A biometric also does not constitute a secret.

Authentication Process

The authentication process begins with the claimant demonstrating to the verifier possession and control of an authenticator that is bound to the asserted identity through an authentication protocol. Once possession and control have been demonstrated, the verifier verifies that the credential remains valid, usually by interacting with the Identity Provider.

The exact nature of the interaction between the verifier and the claimant during the authentication protocol is extremely important in determining the overall security of the system. Well-designed protocols can protect the integrity and confidentiality of communication between the claimant and the verifier both during and after the authentication and can help limit the damage that can be done by an attacker masquerading as a legitimate verifier.

Additionally, mechanisms located at the verifier can mitigate online guessing attacks against weak secrets — like passwords and PINs — by limiting the number of authentication attempts, or otherwise delaying incorrect attempts.

Federation and Assertions (“Single Sign On")

Federated identity architecture, generally referred as Single Sign On (SSO), focuses on using a unique Identity Provider for a given customer.
Federated architectures have many significant benefits, including, but not limited to:

• Enhanced user experience. For example, an individual can be identity proofed once and reuse the issued credential at multiple applications.
  
• Cost reduction to both the user (reduction in number of passwords to remember) and the service (reduction in information technology infrastructure).
  
• Data minimization as applications do not need to pay for collection, storage, disposal, and compliance activities related to storing personal information. So even if the application gets breached, only a limited set of personal information can be extracted from it.
  
• Service enablement as applications can focus on service, rather than the business of identity management.

The following sections discuss the components of a federated identity architecture:

Assertions

Upon completion of the authentication process, the verifier generates an assertion containing the result of the authentication and provides it to the application. The assertion is used to communicate the result of the authentication process, and optionally information about the subscriber, from the verifier to the application. Assertions may be communicated directly to the application, or can be forwarded through the subscriber, which has further implications for system design.

An application trusts an assertion based on the source, the time of creation, how long the assertion is valid from time of creation, and the corresponding trust framework that governs the policies and processes of Identity Providers and applications. The verifier is responsible for providing a mechanism by which the integrity of the assertion can be confirmed.

The application is responsible for authenticating the source (the verifier) and for confirming the integrity of the assertion. When the verifier passes the assertion through the subscriber, the verifier must protect the integrity of the assertion in such a way that it cannot be modified. However, if the verifier and the application communicate directly, a protected session may be used to preserve the integrity of the assertion. When sending assertions across an open network, the verifier is responsible for ensuring that any sensitive subscriber information contained in the assertion can only be extracted by an application that it trusts to maintain the information’s confidentiality.

Examples of assertions include:

• Security Assertion Markup Language (SAML) assertions are specified using a mark-up language intended for describing security assertions. They can be used by a verifier to make a statement to an application about the identity of a claimant. SAML assertions may optionally be digitally signed.
  
• OpenID Connect claims are specified using JavaScript Object Notation (JSON) for describing security, and optionally, user claims. JSON user info claims may optionally be digitally signed.
  
• Kerberos tickets allow a ticket-granting authority to issue session keys to two authenticated parties using symmetric key based encapsulation schemes.
  

Relying Parties

An application relies on results of an authentication protocol to establish confidence in the identity or attributes of a subscriber for the purpose of conducting an online transaction. Applications may use a subscriber’s authenticated identity and other factors to make authorization decisions.

The application normally receives an assertion from the verifier. The application ensures that the assertion came from a verifier trusted by the application. The application also processes any additional information in the assertion, such as personal attributes or expiration times. The application is the final arbiter concerning whether a specific assertion presented by a verifier meets the application’s established criteria for system access.

Disclamer

This article is not legal or regulatory advice. You should seek independent legal advice on your legal and regulatory obligations. The views and opinions expressed in this article are solely those of the author. These views and opinions do not necessarily represent those of Xinja or its staff.