Authentication mechanisms

Authentication is the process of ensuring that an individual is the person that they claim to be. This involves matching a person’s claimed identity—asserted through a credential (e.g., an ID card or unique ID number)—against one or more authentication factors that are bound to that credential. Potential authenticators include:

  1. Possession factors: Something that a person demonstrates that they have, such as a physical or virtual card or certificate, or a hardware token.

  2. Knowledge factors: Something that a person already knows (e.g., a challenge question or image) or memorizes (e.g., a password or PIN)

  3. Inherent factors: Some physical attribute that a person can demonstrate that they have (e.g., a fingerprint or iris scan).

Secure authentication (i.e., for higher levels of assurance) requires a multi-factor approach. In general, the combination of authentication factors should include some or all of the three above categories. In addition, sub-factors—such as location (where are you?) and time (when are you trying to authenticate?)—can be used in combination with the other core factors to create further conditionality when authenticating.

Digital authentication—i.e., authentication that involves electronic credentials and processes—can be done in-person (e.g., at a physical bank branch or government office) or remotely (e.g., via a mobile or web service). While remote digital authentication is by definition “online” (i.e., it requires an internet connection), in-person transactions can be digitally authenticated using online or offline mechanisms (see Figure 29).

Figure 29. Digital authentication modes

Digital authentication modes


Both online and offline authentication mechanisms have a common set of requirements in order to protect the person asserting their identity and to offer sufficient assurance to the identity consumer (a service, person, or relying party). In general, an authentication mechanism should:

  • Respond only with a “yes” or “no” depending on the result of the authentication, rather than sharing and/or exposing PII, with the exception of special circumstances—such as complying with anti-money laundering (AML) regulations for customer due diligence (CDD)—subject to a person’s informed consent and comprehensive information security measures.

  • Have known and easily accessible exception handling and grievance redress protocols in case the authentication mechanism fails (e.g., a false negative biometric result). A person should must never be denied a right, service, or entitlement (or their access made more difficult) as a result of a fault of the ID system.

  • Facilitate the auditability of transactions, including tamper proof logs, certifying authentication devices, and identifying relying parties as well as potentially the individual operator within those organizations.

  • Eliminate opportunities for the ID authority or other actors to use transaction metadata to track or profile the ID holder (e.g. through encryption, hashing, anonymization of data, decentralization of such data etc.).

  • When identity data shared by the ID system and stored by the relying party as part of the authentication mechanism, ensure that information is secured in order to prevent loss or compromise.

  • Implement security controls to reduce threats such as guessing, eavesdropping, replay or manipulation of communication by an attacker that could subvert the authentication mechanism.

  • Be mandated by relevant laws and regulations, and the specific relationship between the ID system and the relying party be governed by a legal agreement (e.g., a memorandum of understanding) setting out respective responsibilities.

This section describes some offline and online authentication mechanisms that are commonly used in foundational ID systems. The choice of which mechanisms to adopt is closely tied to the types of credentials issued by the ID system and should be appropriate to the intended use cases for the system and country-specific constraints such as connectivity and digital literacy (see Section II. Planning Roadmap).

Offline authentication

Offline authentication—used for in-person transactions when connectivity is unavailable or unnecessary—must provide a means of verifying that the person asserting their identity is who they claim to be without referring to other systems (e.g. remote identity databases, online services, etc.) and, if possible, that the credentials they present are genuine. In general, there are three primary options for offline authentication (summarized in Table 33):

  • Manual (non-digital) comparison (i.e., taking an ID card at face value): Traditionally, authentication processes have involved the manual inspection of credentials (commonly ID cards) to determine that they are genuine (e.g., via embedded security features) and assess whether the person or their physical signature resembles the photo or signature included on the credential. While this method is intuitive and requires less infrastructure (beyond providing the credentials themselves), it provides a lower level of assurance and more opportunities for corruption than digital authentication due to the potential for human error and/or discretion in applying the procedure. At the same time, this may be appropriate for certain low-risk transactions and/or the only viable solution in areas with no connectivity or electricity. If security features are to be a viable method of improving the reliability of authentication, relying parties need to be aware and appropriately equipped—e.g., I the case of level 2 (covert) security features, this might require a UV light.

  • Digital authentication against data stored on a smartcard: Smartcards are capable authenticating a person offline with a higher level of assurance. In combination with card reader (or receiver, in the case of a contactless card) equipped with text input and/or a biometric scanner (e.g., fingerprint or iris), a comparison can be made between the presented authenticators (e.g., a PIN or fingerprint) and the data stored in the chip of the card. Matching can be done by the card’s microprocessor itself or by the reader and associated software on the connected computer or device (e.g., a tablet or smartphone). Despite these benefits, however, smartcards can be expensive, and also require purchasing, distributing, and training operators on the use of card readers (e.g., POS devices). Some smartcards are being developed with their own embedded fingerprint scanner and power source, but these are very expensive. Smartcards used exclusively offline are also not necessarily much more secure than non-smartcard, as they could have been invalidated but continue functioning in isolation from the ID system. Furthermore, the security and integrity of data on a smartcard cannot be guaranteed after they have been issued (e.g., in 2018 Estonia had to recall and reissue a significant proportion of smartcards in circulation because of a security flaw related to the private key stored on the chip). Indeed, many countries have issued smartcards without implementing this infrastructure, in which case they offer little benefit over “non-smart” cards.

  • Digital authentication via a 2D barcode: Cards, certificates, or mobile apps with 2D barcodes (e.g., QR codes) also offer the possibility of digital, offline authentication when they are combined with readers and software that can match authenticators (e.g., PIN, fingerprint, photo) to those stored in the barcode itself or in a record in a local database that the QR code points to. In India, for example, the printed Aadhaar registration letters (“cards”) now include a secure barcode that contains biographic information and a low-resolution facial image of the Aadhaar holder in order to facilitate a manual comparison. Although QR-code documents may be cheaper than smartcards, they are less secure. For example, a photo can be taken of a QR code, which would compromise it. Likewise, they cannot store as much data and are limited to how much physical space they are allotted on the card. The higher density the barcode, the more likely that scratches or other damage will affect the ability of the data to be read without errors. Storing a fingerprint template on a QR code, for example, is likely to result in a very dense QR code and exposes the template to being replicated (e.g., printed on other cards). Another significant challenge with the use of barcodes for authentication factors in offline environments is the management of decryption keys: if a decryption key is widely available then an attacker can reverse engineer an applicable barcode to generate a fraudulent credential.

Table 33. Offline authentication mechanisms for in-person transactions

Type Mechanism Compatible Credentials System Requirements
Manual Visual comparison of a person to a physical credential

Any physical credential (e.g., a car or receipt) that has some information (e.g., a photo or signature) that can be compared to its bearer

Requires no equipment except the credential itself
Digital Comparison of authenticators to those stored on a 2D barcode

Physical or virtual cards (e.g., on a smartphone) or certificates with 2D barcodes + authenticators (e.g., PIN, biometric)

Input devices (i.e., card readers, text pads, fingerprint scanners, etc.) integrated in or connected to local device capable of matching the authenticators

Comparison of authenticators to those stored on a smartcard chip

Smartcard + authenticators (e.g., PIN, biometric) Input devices (i.e., card readers with text pads and/or fingerprint scanners)

Online authentication

Where relying parties and users have access to internet and/or mobile network connections, online authentication can be used for both in-person and remote transactions. The ability to refer to other systems—such as remote servers, data stored in the cloud, web- and mobile-based applications, etc.—increases the variety of potential online authentication mechanisms, as shown in Table 34, and the ability to check the validity of a credential. Ultimately, online authentication provides a higher level of assurance because it offers more potential authentication factors and a “live” source. At the same time, it may also bring greater data protection and cybersecurity risks.

The authentication level of assurance provided by online mechanisms varies according to the specific credentials, authenticators, and protocols used. In addition to choosing authentication methods with levels of assurance appropriate to the transaction, practitioners must consider their accessibility and convenience, particularly for vulnerable persons (e.g., low literacy, the elderly, and people with disabilities), and those with unreliable internet or mobile connections. For example, card-based authentication for remote transactions (e.g., e-services) would require the purchase and distribution of card and/or biometric readers to each person, which may be a barrier to adoption.

Table 34. Examples of online authentication mechanisms for in-person and/or remote transactions

Type Mechanism Compatible Credentials/Authenticators System Requirements
Matching against a database (“ID on the cloud”) Comparison of authentication factors to references stored in a central system Numbers, user names, etc. + authenticators (e.g., PIN, biometric, password)

Input devices (i.e., keypad/board and/or biometric scanners) and secure network connection of relying party to central system

Public key infrastructure (PKI)-based Using public key encryption to authenticate against a server Smartcard, card with 2D barcode, SIM card, or mobile device + authenticators (e.g., PIN, biometric)

Input devices (i.e., personal card reader/scanner, text pads and/or fingerprint scanners), PKI and secure network connection of relying party to central system

One-time passwords (OTP) Password or PIN generated on demand for one-time use

Device that can receive the password (e.g., SMS on a mobile phone or smartphone/computer to receive an email or smartphone ap that generates an OTP)

OTP infrastructure and secure network connection of relying party to central system
FIDO authentication

On-device match (fingerprint, iris, face, PIN) unlocks a private key used to authenticate against a server

FIDO-certified smartphone (e.g., Android, Windows) or external authenticator such as a FIDO Security Key + authenticators (biometrics or PIN) FIDO-certified smartphone (e.g., Android, Windows) or external authenticator such as a FIDO Security Key, plus network connection between that device and the relying party’s systems


Federation is the ability of one organization to accept another organization’s identity credentials for authentication based on inter-organizational trust. The trusting organization must be comfortable that the other identity provider has acceptable policies, and that those policies are being followed. Federation protocols and assurance and trust frameworks facilitate federation of digital identity between organizations. For federation to be effectively used globally, agreement and mapping with the ISO defined assurance framework and the adoption of standards are critical (Source: Catalog of Technical Standards).

Federation can occur at multiple levels:

  • A trusting organization can capture and send the credential to the issuing organization (i.e., an identity provider) for verification, to authenticate an identity. After verification of the credential, the issuing organization sends a yes/no confirmation and may, when warranted and consented, send a set of claims giving information about the person, using federation protocols like SAML (security assertion mark-up language). For example, service providers in the UK can accept the credentials of multiple identity providers via the GOV.UK verify system (see Box 38).

  • A trusting organization can accept credentials issued by another organization, but still authenticate and authorize the individual locally. For example, a passport issued one country is accepted as a valid credential by a receiving country (and could be validated, for example, through ICAO’s global Public Key Directory or PKD), but the receiving country’s immigration office still authenticates the holder and requires a visa to authorize travel.

  • A trusting organization can accept specific attributes describing an individual from another organization. For example, a bank can request credit score from a credit bureau, rather than maintaining its own registry of credit information.

  • A trusting organization can accept an authorization decision from another organization (i.e., mutual recognition). For example, a driver’s license authorizing a person to drive in one location may be accepted by another location.

In order to establish a framework for federation, practitioners must:

  • Establish a trust framework—i.e., a legally enforceable set of specifications, rules, and agreements that govern a multi-party system—that defines legal rules and operational rules (e.g., service-level agreements or SLAs).

  • Determine federation protocols to be used (e.g., SAML or Open ID Connect).

  • Determine which attributes—if any—will be shared by the identity provider to the relying party/service provider upon on successful authentication of the user. (For example, the combination of Open ID Connect and OAuth protocols allows for sharing different set of attributes, based on user consent.)

  • Establish a secure communication channel between the relying parting (service provider) and the identity provider to enable an authentication workflow between the service provider and identity provider application. This is typically done using digital certificates to secure communication and may also involve passwords (a shared secret) to authenticate the application.

  • Manage the digital identities including expiration, revocation, and renewal.

Box 38. GOV.UK Verify

Unlike many other countries, the UK has no single foundational ID system except for a civil registry. People hold a variety of credentials—such as driving licenses, passports, birth certificates, and more—and rely on some combinations of these to assert their identities for various purposes. In 2016, the UK government launched its GOV.UK Verify system to provide a digital identity layer that would allow UK citizens and residents to authenticate themselves online for a variety of public and private sector services.

Rather than relying on a single, centrally provided digital identity credential, the Government developed a federated system with multiple digital identity providers who are certified by the GOV.UK Verify platform to provide authentication services. GOV.UK Verify partnered with a number of private sector identity providers (e.g., banks) to issue digital identities with combinations of individual’s various credentials and other “dynamic” proofs of identity as a foundation (e.g., micro-payments to a bank account controlled by the individual with a unique reference code, which requires the user to access their online banking system to retrieve the code and complete the proofing). The provider issues a digital identity along with varying credentials, including USB keys and mobile authenticators. People can then use this identity to authenticate themselves online for various services.

This system was designed with privacy in mind, as it allows people choice over their identity provider and prevents identity providers from knowing the precise service for which the authentication is being requested. In addition, it uses back-end tokenization at the point of transaction to avoid the correlation of Personal Identifiers (PIDs) across databases.

Source: Whitley (2018), ID4D Tokenization note (forthcoming).