Authentication mechanisms

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

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

Federation

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.