Establishing Trust

Research and Writing by Amber Sinha

At its core, digital ID seeks to solve the trust problem—how can an individual demonstrate who they claim to be, such that verifying parties may trust them. The current models for establishing this trust are largely top-down, with the primary motive of reducing identity fraud. However, there are multiple factors at play in determining the appropriate threshold for establishing trust which should guide the design of identity systems.


Reconceptualising Levels of Assurance

The popular meme by Peter Steiner in The New Yorker, ‘On the internet, nobody knows you’re a dog,’1 is an oft-quoted phrase in digital identity design discussions. As stated in the latest version of the Levels of Assurance technical guidelines by NIST2, ‘when accessing some low-risk digital services, “being a dog” is just fine; while other, high-risk services need a level of confidence that the digital identity accessing the service is the legitimate proxy to the real life subject.’ The most recent guidelines recognise the need for dynamic levels of assurance, retiring the ‘the concept of a level of assurance (LOA) as a single ordinal that drives implementation-specific requirements’ and instead suggesting combining ‘appropriate business and privacy risk management side-by-side with mission need.’ The essence of the guidelines are captured below:

Identity Proofing LOAs Authentication LOAs Federation LOAs
Attributes, if any, are self-asserted or should be treated as self-asserted; there is no proofing process. Provides some assurance that the claimant controls an authenticator registered to the user. AAL1 requires single-factor authentication using a wide range of available authentication technologies. Successful authentication requires that the claimant prove possession and control of the authenticator through a secure authentication protocol. Permits the relying party to receive a bearer assertion from an identity provider. The identity provider must sign the assertion using approved cryptography.
Either remote or in-person identity proofing is required using, at a minimum, the procedures given in SP 800-63A. Provides high confidence that the claimant controls authenticator(s) registered to the user. In order to authenticate at AAL2, claimants must prove possession and control of two distinct authentication factors through secure authentication protocol(s). Approved cryptographic techniques are required. Adds the requirement that the assertion be encrypted using approved cryptography such that the relying party is the only party that can decrypt it.
In-person or supervised-remote identity proofing is required. Identifying attributes must be verified through examination of physical documentation as described in SP 800-63A. Provides very high confidence that the claimant controls authenticator(s) registered to the user. Authentication at AAL3 is based on proof of possession of a key through a cryptographic protocol. AAL3 is like AAL2 but also requires a “hard” cryptographic authenticator that provides verifier impersonation resistance. Requires the user to present proof of possession of a cryptographic key reference to in the assertion and the assertion artifact itself. The assertion must be signed using approved cryptography and encrypted to the relying party using approved cryptography.

By introducing pseudonymous identifiers, and encouraging ‘minimizing the dissemination of identifying information by requiring federated identity providers (IdPs) to support a range of options for querying data, such as asserting whether an individual is older than a certain age rather than querying the entire date of birth,’ the guidelines clearly express its intent for privacy preserving decision making in the design of identity systems. However, it is limited in its view of approaching privacy and business interests are the primary competing values. This approach further continues the top-down approach in designing identity solutions by centering reduction of identity fraud. A competing value that is consistently ignored by LoA technical documents including the above, is that of inclusivity This is all the more perplexing as inclusivity has fast emerged as one of the primary rationales for digital identity systems.3 Centering ‘inclusivity’ in digital identity design would entail that the interest of individuals to not be excluded from services, benefits, entitlements and exercise of rights is a driving value.

Let us consider what inclusivity may (or may not) look like through an example. One of the biggest concerns around the Aadhaar project is its exclusionary impacts.4 The proviso to Section 7 of the Aadhaar (Targeted Delivery of Financial and other Subsidies, Benefits and Services) Act states that, “if an Aadhaar number is not assigned to an individual, the individual shall be offered alternate and viable means of identification for delivery of the subsidy, benefit or service.” This is an example of a legal provision attempting to factor the need for inclusivity in the implementation of an identity system. Despite this attempt, overall, it is an inadequate measure for the following reasons. First, instead of building inclusivity into the design of the digital identity solution, it seeks to retrospectively ‘fix’ through law what technology has ‘broken’. Second, the nature of protection it provides is limited and covers only those who have not been ‘assigned’ an Aadhaar Number yet. Therefore, those who have not applied for the Aadhaar Number or are unable to use the service due to technical glitches are offered recourse for inclusion.

Increasingly as digital identity solutions are used in exercise of both civil and political rights (use of identity in elections), and economic and social rights (access to essential benefits and services), the denial of services due to faulty design as well as failures of identity solutions imposes both real-life human costs as well as denial of fundamental human rights. Rather than a top-down approach where the ‘business’ or ‘state’ interests of those in charge with making decisions about what level of assurance to use dictates the design of identity solutions, it is imperative that levels of assurance are designed with ‘inclusivity’ as its guiding principle.




The digital identity system should be designed in such a way that a Relying Party is able to select levels of assurance based on consideration of privacy, inclusivity, and reduction of fraud.


IAL is selected to mitigate potential identity proofing errors in a privacy-preserving and inclusive manner. The definition of ‘privacy-preserving’ ought to draw from the proportionality standard.


If we look at the Authenticator Assurance Levels under NIST’s LoA, the range of choices available to individuals reduces as we go up to the levels. AAL1 requires single-factor authentication using a wide range of available authentication technologies. In AAL2, proof of possession and control of two different authentication factors is required through a secure authentication protocol. In AAL3, proof of possession of a key through a cryptographic protocol is required. An additional consideration that needs to be introduced is the degree of inclusivity that is non-negotiable. Access to civil and political rights, and social and economic rights may require the highest degree of inclusivity, and consequently, the need for a range of options of authentication technologies.


1 Glenn Fleishman, “Cartoon Captures Spirit of the Internet", The New York Times, December 14, 2000,
2 NIST: Digital Identity Guidelines (June 2017),
3 “Inclusive and Trusted Digital ID Can Unlock Opportunities for the World’s Most Vulnerable”, World Bank, August 14, 2019,
4 Prashant Reddy, “Aadhaar: Amid the debate about privacy, the more pressing issue of exclusion has been forgotten”,, March 29, 2017,