A Decentralised Digital Identity Architecture

02/23/2019
by   Geoff Goodell, et al.
UCL
0

Current architectures to validate, certify, and manage identity are based on centralised, top-down approaches that rely on trusted authorities and third-party operators. We approach the problem of digital identity starting from a human rights perspective, asserting that individual persons must be allowed to manage their personal information in a multitude of different ways in different contexts and that to do so, each individual must be able to create multiple unrelated identities. Therefore, we first define a set of fundamental constraints that digital identity systems must satisfy to preserve and promote human rights. With these constraints in mind, we then propose a decentralised, standards-based approach, using a combination of distributed ledger technology and thoughtful regulation, to facilitate many-to-many relationships among providers of key services. Our proposal for digital identity differs from others in its approach to trust: by avoiding centralisation and the imposition of trust from the top down, we can encourage individuals and organisations to embrace the system and share in its benefits.

READ FULL TEXT VIEW PDF
POST COMMENT

Comments

There are no comments yet.

Authors

page 1

page 2

page 3

page 4

06/09/2019

A Federated Authorization Framework for Distributed Personal Data and Digital Identity

The digital identity problem is a complex one in large part because it i...
09/16/2019

Data management for platform-mediated public services: Challenges and best practices

Services mediated by ICT platforms have shaped the landscape of the digi...
06/24/2019

Towards a Blockchain based digital identity verification, record attestation and record sharing system

In this study, we investigated the utilization of Blockchain technology ...
12/05/2017

Self-sovereign Identity - Opportunities and Challenges for the Digital Revolution

The interconnectedness of people, services and devices is a defining asp...
04/21/2019

Foundation for Genuine Global Identities

About 1Bn people around the globe are born and live without identity doc...
08/10/2021

Decentralised Trust for the Digital Economy

We propose a research initiative to explore and evaluate end-user techno...
02/26/2018

Shaping Influence and Influencing Shaping: A Computational Red Teaming Trust-based Swarm Intelligence Model

Sociotechnical systems are complex systems, where nonlinear interaction ...
This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

1 Motivation

Establishing meaningful credentials for individuals and organisations in an environment in which the various authorities are not uniformly trustworthy presents a problem for currently deployed services, which are often based on hierarchical trust networks, all-purpose identity cards, and other artifacts of the surveillance economy. In the context of interactions between natural persons, identities are neither universal nor hierarchical, and a top-down approach to identity generally assumes that it is possible to impose a universal hierarchy. Consider “Zooko’s trilemma,” which states that names can be global, secure, or human-meaningful, but not all three [1]. The stage names of artists may be globally unique and human-meaningful but are not really secure since they rely upon trusted authorities to resolve conflicts. The names that an individual assigns to friends or that a small community assigns to its members (“petnames” [2]) are secure and human-meaningful but not global. We extend the reasoning behind the paradox to the problem of identity itself and assert that the search for unitary identities for individual persons is problematic. It is technically problematic because there is no endogenous way to ensure that an individual has only one self-certifying name [3], there is no way to be sure about the trustworthiness or universality of an assigned name, and there is no way to ensure that an individual exists only within one specific community. More importantly, we assert that the ability to manage one’s identities in a multitude of different contexts, including the creation of multiple unrelated identities, is an essential human right.

1.1 Manufacturing Trust

The current state-of-the-art identity systems, from technology platforms to bank cards, impose asymmetric trust relationships and contracts of adhesion on their users, including both the ultimate users as well as local authorities, businesses, cooperatives, and community groups. Such trust relationships, often take the form of a hierarchical trust infrastructure, requiring that users accept either a particular set of trusted certification authorities (“trust anchors”) or identity cards with private keys generated by a trusted third party. In such cases, the systems are susceptible to socially destructive business practices, corrupt or unscrupulous operators, poor security practices, or control points that risk coercion by politically or economically powerful actors.

Often, asymmetric trust relationships set the stage for security breaches. Rogue certification authorities constitute a well-known risk, even to sophisticated government actors [4, 5], and forged signatures have been responsible for a range of cyber-attacks including the Stuxnet worm, an alleged cyber-weapon believed to have caused damage to Iran’s nuclear programme [6], as well as a potential response to Stuxnet by the government of Iran [7]. Corporations that operate the largest trust anchors have proven to be vulnerable. Forged credentials were responsible for the Symantec data breach [8], and other popular trust anchors such as Equifax are not immune to security breaches [9]. Google has published a list of certification authorities that it thinks are untrustworthy [10], and IT administrators have at times undermined the trust model that relies upon root certification authorities [11]. Finally, even if their systems are secure and their operators are upstanding, trust anchors are only as secure as their ability to resist coercion, and they are sometimes misappropriated by governments [12].

Such problems are global, affecting the developed world and emerging economies alike. Identity systems that rely upon a single technology, a single implementation, or a single set of operators have proven unreliable [13, 14]. Widely-acclaimed national identity systems, including but not limited to X-Road in Estonia [15] and Aadhaar in India [16], are characterised by centralised control points, single points of failure, security risks, and surveillance.

Recent trends in technology and consumer services suggest that concerns about mobility and scalability will lead to the deployment of systems for identity management that identify consumers across a variety of different services, with a new marketplace for providers of identification services [17]. In general, the reuse of credentials has important privacy implications as a consumer’s activities may be tracked across multiple services or multiple uses of the same service. For this reason, the potential for a system to collect and aggregate transaction data must be evaluated whilst evaluating its impact on the privacy of its users.

While data analytics are becoming increasingly effective in identifying and linking the digital trails of individual persons, it has become correspondingly necessary to defend the privacy of individual users and implement instruments that allow and facilitate anonymous access to services. This reality was recognised by the government of the United Kingdom in the design of its GOV.UK Verify programme [19], a federated network of identity providers and services. However, the system as deployed has significant technical shortcomings with the potential to jeopardise the privacy of its users [20, 21], including a central hub and vulnerabilities that can be exploited to link individuals with the services they use [22].

Unfortunately, not only do many of the recently-designed systems furnish or reveal data about their users against their interests, but they have been explicitly designed to do so. For example, consider digital rights management systems that require users to identify themselves ex ante and then use digital watermarks to reveal their identities [23]. In some cases, demonstrable privacy has been considered an undesirable feature and designs that protect the user’s identity intrinsically are explicitly excluded, for example in the case of vehicular ad-hoc networks [18], with the implication that systems without exceptional access features are dangerous. Finally, of particular concern are systems that rely upon biometrics for identification. By binding identification to a characteristic that users (and in most cases even governments) cannot change, biometrics implicitly prevent a user from transacting within a system without connecting each transaction to each other and potentially to a permanent record. In recent years, a variety of US patents have been filed and granted for general-purpose identity systems that rely upon biometric data to create a “root” identity linking all transactions in this manner [24, 25].

1.2 A Different Approach

The prevailing identity systems commonly require users to accept third parties as trustworthy. The alternative to imposing new trust relationships is to work with existing trust relationships by allowing users, businesses, and communities to deploy technology on their own terms, independently of external service providers. We propose a system-level approach to allow existing institutions and service providers to retain their relative authority and decision-making power without forcibly requiring them to cooperate with central authorities (such as governments and institutions), service providers (such as system operators), or the implementors of core technology. Our approach would encourage existing institutions and service providers to be self-sufficient, while concordantly allowing groups such as regulators and consultants to act as advisors, not operators.

Modern identity systems are used to coordinate three activities: identification, authentication, and authorisation. The central problem to address is how to manage those functions in a decentralised context with no universally trusted authorities. Rather than trying to force all participants to use a specific new technology or platform, we suggest using a multi-stakeholder process to develop common standards that define a set of rules for interaction. Any organisation would be able to develop and use their own systems that would interoperate with those developed by any other organisation without seeking permission from any particular authority or agreeing to deploy any particular technology.

A variety of practitioners have recently proposed using a distributed ledger to decentralise the administration of an identity system [26], and we agree that the properties of distributed ledger technologies are appropriate for the task. In particular, distributed ledgers allow their participants to share control of the system. They also provide a common view of transactions ensuring that everyone sees the same transaction history.

Distributed ledgers might also be used to mitigate the risk that one powerful, central actor might seize control under the mantle of operational efficiency. However, it is less clear that this lofty goal is achieved in practice. Existing examples of DLT-enabled identity management systems include the following:

  • ShoCard [27] is operated by a commercial entity that serves as a trusted intermediary [26].

  • Sovrin [28] relies on a foundation to manage the set of approved certification authorities [29], and it is not clear that it could manage them with equanimity.

  • uPort [30] does not rely upon a central authority, instead allowing for mechanisms such as social recovery. However, its design features an optional central registry that might introduce a means of linking together transactions that users would prefer to keep separate [26].

Researchers have proposed alternative designs to address some of the concerns. A design suggested by Kaaniche and Laurent does not require a central authority for its blockchain infrastructure but does require a trusted central entity for its key infrastructure [31]. Coconut, a selective disclosure credential scheme, is designed to be robust against malicious authorities and may be deployed in a way that addresses such concerns [32]. We imagine that both of these and similar infrastructures may be adapted to implement a protocol that is broadly compatible with what we describe.

1.3 Participants in an Identity System

We shall use the following notation to represent the various parties that interact with a typical identity system:

  • (1) A “certification provider” (CP). This would be an entity or organisation responsible for establishing a credential based upon foundational data. The credential can be used as a form of identity and generally represents that the organisation has checked the personal identity of the user in some way. In the context of digital payments, this might be a bank.

  • (2) An “authentication provider” (AP). This would be any entity or organisation that might be trusted to verify that a credential is valid and has not been revoked. In current systems, this function is typically performed by a platform or network, for example a payment network such as those associated with credit cards.

  • (3) An “end-user service provider” (Service). This would be a service that requires a user to provide credentials. It might be a merchant selling a product, a government service, or some other kind of gatekeeper, for example a club or online forum.

  • (4) A user (user). This would be a human operator, in most cases aided by a device or a machine, whether acting independently or representing an organisation or business.

As an example of how this might work, suppose that a user wants to make an appointment with a local consular office. The consular office wants to know that a user is domiciled in a particular region. The user has a bank account with a bank that is willing to certify that the user is domiciled in that region. In addition, a well-known authentication provider is willing to accept certifications from the bank, and the consular office accepts signed statements from that authentication provider. Thus, the user can first ask the bank to sign a statement certifying that he is domiciled in the region in question. When the consular office asks for proof of domicile, the user can present the signed statement from the bank to the authentication provider and ask the authentication provider to sign a new statement vouching for the user’s region of domicile, using information from the bank as a basis for the statement, without providing any information related to the bank to the consular office.

2 Human Rights Constraints

We reflected on the various identity systems used today, including but not limited to residence permits, bank accounts, payment cards, transit passes, and online platform logins, and we found a plethora of features with weaknesses and vulnerabilities concerning privacy (and in some cases security) that could potentially infringe upon human rights. With this in mind, we identified the following eight fundamental constraints to frame the human rights requirements for technology infrastructure [34]:

  1. Minimise control points that can be used to co-opt the system. A single point of trust is a single point of failure, and both state actors and technology firms have historically been proven to abuse such trust.

  2. Mitigate architectural characteristics that lead to surveillance. Surveillance is about control as much as it is about discovery: people behave differently when they believe that their activities are being monitored or evaluated [35]. Powerful actors sometimes employ monitoring to create incentives for individual persons, for example to conduct marketing promotions or credit scoring operations. Such incentives may prevent individuals from acting autonomously, and the chance to discover irregularities, patterns, or even misbehaviour often does not justify such mechanisms of control.

  3. Do not impose non-consensual trust relationships upon beneficiaries. It is an act of coercion for a service provider to require a client to maintain a direct trust relationship with a specific third-party platform provider or certification authority. Infrastructure providers must not explicitly or implicitly engage in such coercion, which should be recognised for what it is and not tolerated in the name of convenience.

  4. Prevent solution providers from establishing a monopoly position. Some business models are justified by the opportunity to achieve status as monopoly infrastructure. Monopoly infrastructure is problematic not only because it deprives its users of consumer surplus but also because it empowers the operator to dictate the terms by which the infrastructure can be used.

  5. Empower local businesses and cooperatives to establish their own trust relationships. The opportunity to establish trust relationships on their own terms is important both for businesses to compete in a free marketplace and for businesses to act in a manner that reflects the interests of their communities.

  6. Empower service providers to establish their own business practices and methods. Providers of key services must adopt practices that work within the values and context of their communities.

  7. Empower individual users to manage the linkages among their activities. To be truly free and autonomous, individuals must be able to manage the cross sections of their activities that are seen by various institutions, businesses, and state actors.

  8. Resist establishing potentially abusive processes and practices, including legal processes, that rely upon centralised infrastructure. Infrastructure that can be used to abuse and control individual persons is problematic even if those who oversee its establishment are genuinely benign. Once infrastructure is created, it may in the future be used for other purposes that benefit its operators.

Experience shows that control points will eventually be co-opted by powerful parties, irrespective of the intentions of those who build, own, or operate the control points. Consider, for example, how Cambridge Analytica allegedly abused the data assets of Facebook Inc to manipulate voters in Britain and the US [36] and how the Russian government asserted its influence on global businesses that engaged in domain-fronting [37, 38]. The inherent risk that centrally aggregated datasets may be abused, not only by the parties doing the aggregating but also by third parties, implies value in system design that avoids control points and trusted infrastructure operators, particularly when personal data and livelihoods are involved.

3 A Digital Identity System

ID System

User

Service

ESTABLISH

VERIFY

ASSERT
Figure 1: A generalisation of identity systems. Users first establish a credential with the system, then use the system to verify the credential, and then use the verified identity to assert that they are authorised to receive a service.

Various digital identity architectures and deployments exist today to perform the three distinct functions we mentioned earlier: identification, authentication, and authorisation [39]. We characterise the three functions:

  • Identification. A user first establishes some kind of credential or identifier. The credential might be a simple registration, for example with an authority, institution, or other organisation. In other cases, it might imply a particular attribute. The implication might be implicit, as a passport might imply citizenship of a particular country or a credential issued by a bank might imply a banking relationship, or it might be explicit, as in the case of attribute-backed credentials such as those issued by Identity Mixer [40, 41].111We do not describe how to use attribute-backed credentials here.

  • Authentication. Next, when the provider of a service seeks to authenticate a user, the user must be able to verify that a credential in question is valid.

  • Authorisation. Finally, the user can use the authenticated credential to assert to the service provider that she is entitled to a particular service.

request a request for a credential.
request a request for a credential with a parameter, .
A(m) A message signed by party .
identify the foundational identifying elements that a user presents to a certification
provider, encrypted so that other parties (including AP) cannot read them.
revoke a message invalidating an earlier signature.
[m] blinded version of message .
A([m]) blind signature of by .
prove-owner proof of ownership of some private key , for example via a challenge-response
(which would imply two extra messages not shown) or by using the key to sign a
pre-existing secret created by the recipient and shared with the sender.
verify request to the distributed ledger system to determine whether a credential has
been revoked.
success response from the distributed ledger system indicating that the requested credential
has not been revoked.
receipt response from the distributed ledger system indicating that a transaction completed
successfully.
object physical, tamper-resistant object containing a unique receipt for a transaction.
Table 1: Notation used in the subsequent figures.

Figure 1 gives a pictorial representation of the functions. Table 1 defines the notation that we shall use in our figures. With the constraints enumerated in Section 2 taken as design requirements, we propose a generalised architecture that achieves our objectives for an identity system. The candidate systems identified in Section 1 can be evaluated by comparing their features to our architecture. Since we intend to argue for a practical solution, we start with a system currently enjoying widespread deployment.

3.1 SecureKey Concierge

As a baseline example of an identity framework, we consider a system that uses banks as certification providers whilst circumventing the global payment networks. SecureKey Concierge (SKC) [42] is a solution used by the government of Canada to provide users with access to its various systems in a standard way. The SKC architecture seeks the following benefits:

  1. Leverage existing “certification providers” such as banks and other financial institutions with well-established, institutional procedures for ascertaining the identities of their customers. Often such procedures are buttressed by legal frameworks such as Anti-Money Laundering (AML) and “Know Your Customer” (KYC) regulations that broadly deputise banks and substantially all financial institutions [45] to collect identifying information on the various parties that make use of their services, establish the expected pattern for the transactions that will take place over time, and monitor the transactions for anomalous activity inconsistent with the expectations [46].

  2. Isolate service providers from personally identifying bank details and eliminate the need to share specific service-related details with the certification provider, whilst avoiding traditional authentication service providers such as payment networks.

CP

AP

User

Service

(1) request

(2) identify

(3) identify

(4) CP()

(5) AP()

(6) AP()
Figure 2: A stylised representation of the SecureKey Concierge (SKC) system. The parties are represented by the symbols “CP”, “AP”, “User”, and “Service”, and the arrows represent messages between the parties. The numbers associated with each arrow show the sequence, and the symbol following the number represents the contents of a message. First, the service provider (Service) requests authorisation from the user, who in turn sends identifying information to the authentication provider (AP) to share with the certification provider (CP). If the CP accepts the identifying information, it sends a signed credential to the AP, which in turn issues a new credential for consumption by the Service, which can now authorise the user.

Figure 2 offers a stylised representation of the SKC architecture, as interpreted from its online documentation [42]. When a user wants to access a service, the service provider sends a request to the user (1)222The numbers in italics correspond to messages in the figure indicated, in this case Figure 2. for credentials. The user then sends encrypted identifying information (for example, bank account login details) to the authentication provider (2), which in this case is SKC, which then forwards it to the certification provider (3). Next, the certification provider responds affirmatively with a “meaningless but unique” identifier representing the user, and sends it to the authentication provider (4). The authentication provider then responds by signing its own identifier representing the user and sending the message to the user (5), which in turn passes it along to the service provider (6). At this point the service provider can accept the user’s credentials as valid. The SKC documentation indicates that SKC uses different, unlinked values of for each service provider.

3.2 A Two-Phase Approach

We propose modifying the SKC architecture so that the user does not need to log in to the CP each time it requests a service. To achieve this, we divide the protocol into two phases, as shown in Figure 3: a setup phase (Figure 3a) in which a user establishes credentials with an “certification provider” (CP) for use with the service, and an operating phase (Figure 3b) in which a user uses the credentials in an authentication process with a service provider. So, the setup phase is done once, and the operating phase is done once per service request. In the setup phase, the user first sends authentication credentials, such as those used to withdraw money from a bank account, to an authentication provider (1). The authentication provider then uses the credentials to authenticate to the certification provider (2), which generates a unique identifier that can be used for subsequent interactions with service providers and sends it to the authentication provider (3), which forwards it to the user (4). Then, in the operating phase, a service provider requests credentials from the user (5), which in turn uses the previously established unique identifier to request credentials from the authentication provider (6). This means that the user would implicitly maintain a relationship with the authentication provider, including a way to log in. The authentication provider then verifies that the credentials have not been revoked by the certification provider. The process for verifying that the CP credential is still valid may be offline, via a periodic check, or online, either requiring the AP to reach out to the AP when it intends to revoke a credential or requiring the AP to send a request to the CP in real-time. In the latter case, the AP is looking only for updates on the set of users who have been through the setup phase, and it does not need to identify which user has made a request. Once the AP is satisfied, it sends a signed certification of its identifier to the user (7), which forwards it to the service provider as before (8).

CP

AP

User

(1) identify

(2) identify

(3) CP()

(4) CP()

(3a) Setup phase.

CP

AP

User

Service

(5) request

(6) request

(7) AP()

(8) AP()

revoke

(3b) Operating phase.
Figure 3: A modified version of the SKC system with a stateful authentication provider and one-time identifiers for services. The user first establishes credentials in the setup phase (3a). Then, when a service provider requests credentials from the user in the operating phase (3b), the user reaches out to the authentication provider for verification, which assigns a different identifier each time.

Unfortunately, even if we can avoid the need for users to log in to the CP every time they want to use a service, the authentication provider itself serves as a trusted third party. Although the SKC architecture may eliminate the need to trust the existing payment networks, the authentication provider maintains the mapping between service providers and the certification providers used by individuals to request services. It is also implicitly trusted to manage all of the certification tokens, and there is no way to ensure that it does not choose them in a way that discloses information to service providers or certification providers. In particular, users need to trust the authentication provider to use identifiers that do not allow service providers to correlate their activities, and users may also also want to use different identifiers from time to time to communicate with the same service provider. As a monopoly platform, it also has the ability to tax or deny service to certification providers, users, or service providers according to its own interests, and it serves as a single point of control vulnerable to exploitation. For all of these reasons, we maintain that the SKC architecture remains problematic from a public interest perspective.

4 A User-Oriented Identity Architecture

In each of the architectures presented in Section 3, the authentication provider occupies a position of control. In networked systems, control points confer economic advantages on those who occupy them [43], and the business incentives associated with the opportunity to build platform businesses around control points have been used to justify their continued proliferation [44].

However, control points also expose consumers to risk, not only because the occupier of the control point may abuse its position but also because the control point itself creates a vector for attack by third parties. For both of these reasons, we seek to prevent an authentication provider from holding too much information about users. In particular, we do not want an authentication provider to maintain a mapping between a user and the particular services that a user requests, and we do not want a single authentication provider to establish a monopoly position in which it can dictate the terms by which users and service providers interact. For this reason, we put the user, and not the authentication provider, in the centre of the architecture.

For a user to be certain that she is not providing a channel by which authentication providers can leak her identity or by which service providers can trace her activity, then she must isolate the different participants in the system. The constraints allow us to define three isolation objectives as follows:

  1. Have users generate unlinked identifiers on hardware that they own and trust. Unless they generate the identifiers themselves, users have no way of knowing for sure whether identifiers assigned to them do not contain personally identifying information. For users to verify that the identifiers will not disclose information that might identify them later, they would need to generate random identifiers using devices and software that they control and trust.

  2. Ensure that authentication providers do not learn about the user’s identity or use of services. Authentication providers that require foundational information about a user, or are able to associate different requests over time with the same user, are in a position to collect information beyond what is strictly needed for the purpose of the operation. The role of the authentication provider is to act as a neutral channel that confers authority on certification providers, time-shifts requests for credentials, and separates the certification providers from providers of services. Performing this function does not require it to collect information about individual users at any point.

  3. Ensure that information given to service providers is not shared with authentication providers.. The user must be able to credibly trust that his or her interaction with service providers must remain private.

The communication among the four parties that we propose can be done via simple, synchronous (e.g. HTTP) protocols that are easily performed by smartphones and other mobile devices. The cryptography handling public keys can be done using standard public-key-based technologies.

4.1 Procedure to Achieve the Three Objectives

CP

AP

User

(1) identify,

(2) CP(),…,CP()

(3) CP(),…,CP()

(4a) Setup phase.

CP

AP

User

Service

(4) request

(5) request []

(6) AP([])

(7) AP()

revoke

(4b) Operating phase.
Figure 4: A user-oriented approach. The new protocol uses user-generated identifiers and blind signatures to isolate the authentication provider. The authentication provider cannot inject identifying information into the identifiers, nor can it associate the user with the services that she requests.

Figure 4 shows how we can modify the system shown in Figure 3 to achieve the three isolation objectives defined above.

Figure 4a depicts the new setup phase. First, on her own trusted hardware, the user generates her own set of identifiers that she intends to use, at most once each, in future correspondence with the authentication provider. Generating the identifiers is not computationally demanding and can be done with an ordinary smartphone. By generating her own identifiers, the user has better control that nothing encoded in the identifiers that might reduce her anonymity. The user then sends both its identifying information and the identifiers to the certification provider (1). The certification provider then responds with a set of signatures corresponding to each of the identifiers (2). The user then sends the set of signatures to the authentication provider for future use (3).

Figure 4b depicts the new operating phase. First, the service sends a request to the user along with a new one-time identifier corresponding to the request (4). The user then applies a blinding function to , creating . The user chooses one of the identifiers that she had generated during the setup phase and sends that identifier along with to the authentication provider (5). Provided that the signature on has not been revoked, the authentication provider confirms that it is valid by signing and sending the signature to the user (6). The user in turn unblinds and sends the unblinded signature to the service provider (7). The use of blind signatures ensures that the authentication provider cannot link what it sees to specific interactions between the user and the service provider.

4.2 Architectural Considerations

To satisfy the constraints listed in Section 2, all three process steps (identification, authentication, and authorisation) must be isolated from each other. Although our proposed architecture introduces additional interaction and computation, we assert that the complexity of the proposed architecture is both parsimonious and justified:

  1. If the certification provider were the same as the service provider, then the user would be subject to direct control and surveillance by that organisation, violating Constraints 1, 2, and 7.

  2. If the authentication provider were the same as the certification provider, then the user would have no choice but to return to the same organisation each time it requests a service, violating Constraints 1 and 3. That organisation would then be positioned to discern patterns in its activity, violating Constraints 2 and 7. There would be no separate authentication provider to face competition for its services as distinct from the certification services, violating Constraint 4.

  3. If the authentication provider were the same as the service provider, then the service provider would be positioned to compel the user to use a particular certification provider, violating Constraints 1 and 3. The service provider could also impose constraints upon what a certification provider might reveal about an individual, violating Constraint 2, or how the certification provider establishes the identity of individuals, violating Constraint 6.

  4. If the user could not generate her own identifiers, then the certification provider could generate identifiers that reveal information about the user, violating Constraint 2.

  5. If the user were not to use blind signatures to protect the requests from service providers, then service providers and authentication providers could compare notes to discern patterns of a user’s activity, violating Constraint 7.

The proposed architecture does not achieve its objectives if either the certification provider or the service provider colludes with the authentication provider; we assume that effective institutional policy will complement appropriate technology to ensure that sensitive data are not shared in a manner that would compromise the interests of the user.

5 A Decentralised Identity Architecture

A significant problem remains with the design described in Section 4 in that it requires relationships among authentication providers and certification providers (i.e., with each authentication provider connected directly to each certification provider that it considers valid) to be truly decentralised. Recall that the system relies critically upon the ability of an certification provider to revoke credentials issued to users, and authentication providers need a way to learn from the certification provider whether a credential in question has been revoked. Online registries such as OCSP [47], which are operated by a certification provider or trusted authority, are a common way to address this problem, although the need for third-party trust violates Constraint 1. The issue associated with requiring each authentication provider to establish its own judgment of each candidate certification provider is a business problem rather than a technical one. Hierarchical trust relationships emerge because relationships are expensive to maintain and introduce risks; all else being equal, business owners prefer to have fewer of them. Considered in this context, concentration and lack of competition among authentication providers makes sense. If one or a small number of authentication providers have already established relationships with a broad set of certification providers, just as payment networks such as Visa and Mastercard have done with a broad set of banks, then the cost to a certification provider of a relationship with a new authentication provider would become a barrier of entry to new authentication providers. The market for authentication could fall under the control of a monopoly or cartel.

Ledger

CP

AP

ESTABLISH

VERIFY

User

Service

ASSERT
Figure 5: A decentralised identity system with a distributed ledger. The user is not required to interact directly with the distributed ledger (represented by a dashed circle) and can rely upon the services offered by certification providers and authentication providers.

We propose using distributed ledger technology to allow both certification providers and authentication providers to proliferate whilst avoiding industry concentration. The distributed ledger would serve as a standard way for certification providers to establish relationships with any or all of the authentication providers at once, or vice-versa. The ledger itself would be a mechanism for distributing signatures and revocations; it would be shared by participants and not controlled by any single party. Figure 5 shows that users would not interact with the distributed ledger directly but via their chosen certification providers and authentication providers. Additionally, users would not be bound to use any particular authentication provider when verifying a particular credential and could even use a different authentication provider each time. Provided that the community of participants in the distributed ledger remains sufficiently diverse, the locus of control would not be concentrated within any particular group or context, and the market for authentication can remain competitive.

Because the distributed ledger architecture inherently does not require each new certification provider to establish relationships with all relevant authentication providers, or vice-versa, it facilitates the entry of new authentication providers and certification providers, thus allowing the possibility of decentralisation.

We argue that a distributed ledger is an appropriate technology to maintain the authoritative record of which credentials have been issued (or revoked) and which transactions have taken place. We do not trust any specific third party to manage the list of official records, and we would need the system to be robust in the event that a substantial fraction of its constituent parts are compromised. The distributed ledger can potentially take many forms, including but not limited to blockchain, and, although a variety of fault-tolerant consensus algorithms may be appropriate, we assume that the set of node operators is well-known, a characteristic that we believe may be needed to ensure appropriate governance.

5.1 Achieving Decentralisation with Distributed Ledger Technology

CP

Ledger

User

(1) identify,

(2) (CP(),),…,(CP(),)

(6a) Setup phase.

CP

Ledger

User

AP

Service

(3) request

(4) prove-owner ,request []

(5) verify

(6) success

(7) AP([])

(8) AP()

revoke

(6b) “Online mode” operating phase.

CP

Ledger

User

AP

Service

(7) request

prove-owner ,(3) request

(4) verify

(5) success

(6) AP()

(8) AP()

revoke

(6c) “Offline mode” operating phase.

Figure 6: A decentralised identity architecture for scalable deployment. Diagrams (6a) and (6b) show the setup and operating phases for our final proposed design, which uses a distributed ledger to promote a scalable marketplace that allows users to choose certification providers and authentication providers that suit their needs. Diagram (6c) shows a variant design of the operating phase that can be used in an offline context, in which the authentication provider might be disconnected from the certification provider, the service provider, or both.

Figure 6 shows how the modified architecture with the distributed ledger technology would work. Figure 6a shows the setup phase. The first two messages from the user to the certification provider are similar to their counterparts in the protocol shown in Figure 4a. However, now the user also generates asymmetric key pairs , where is the public key and is the private key of pair , and includes a public key along with each blinded identifier in its message to the certification provider (1). Then, rather than sending the signed messages to the authentication provider via the user, the certification provider then instead writes the signed certificates directly to the distributed ledger, along with the public keys (2). Figure 6b shows the operating phase. The certification provider can revoke certificates simply by transacting on the distributed ledger and without interacting with the authentication provider at all. Because the user and the authentication provider are no longer assumed to mutually trust one another, the user must now prove to the authentication provider that it holds the private key (4). The authentication provider then refers to the distributed ledger to determine whether a certificate has been revoked (5,6). The following messages are carried out as they are done in Figure 4b. For simplicity, we assume that each certification provider and authentication provider has a distinct signing key for each possible policy.

5.2 Offline Operation

The proposed approach can also be adapted to work offline, specifically when various service providers are not connected to the network. Importantly, the use of a distributed ledger allows the authentication provider to avoid the need to send a query in real-time.333Not sending the query over the network may also improve the privacy of the transaction. If the authentication provider is disconnected from the network, then it can use its most recent version of the distributed ledger to check for revocation. If the authentication provider is satisfied that the record is sufficiently recent, then it can sign the record along with a timestamp444Or sequence number of the distributed ledger.. If the authentication provider is disconnected from the network with the distributed ledger but connected to the network with the service provider, then it can sign the request from the service provider as usual.

However, if the service provider is disconnected from the network, then it will still require an indication of the timeliness of the authentication provider’s signature. The solution is to adapt the operating phase of the protocol as illustrated by Figure 6c. Here, we assume that the user knows in advance that she intends to request a service at some point in the near future, so she sends the request to the authentication provider pre-emptively, along with a one-time identifier (3). Then, the authentication provider verifies the identifier via the ledger (4,5), and signs the one-time identifier with a key AP that is presumed to be irrevocable but valid for a limited time only (6). Later, when the service provider requests authorisation (7), the user responds with the signed one-time identifier that it had obtained from the authentication provider (8).

5.3 Adapted Design for Spending Tokens

CP

Ledger

User

Service

(1) service details

(2) identify,

(3) tokens

(4) CP([]),…,CP([])

(7a) Setup phase.

CP

Ledger

User

AP

Service

(5) request

(6) CP(),(Service)

(7) CP(),(Service)

(8) receipt

(9) AP(receipt)

(10) AP(receipt)

freeze

(7b) “Online mode” operating phase.

CP

Ledger

User

AP

Service

(9) request

(5) CP(),(Service)

(6) CP(),(Service)

(7) receipt

(8) object

(10) object

freeze

(7c) “Offline mode” operating phase.

Figure 7: A decentralised identity architecture for exchanging tokens. This protocol may be used as a way to allow users to pay for services. Diagrams (7a) and (7b) show the setup and operating phases, analogous to the online example shown in Figure 6; Diagram (7c) offers the corresponding offline variant.

The architecture defined in Section 5.1 can also be adapted to allow users to spend tokens on a one-time basis. This option may be of particular interest for social and humanitarian services, in which tokens to be used to purchase food, medicine, or essential services may be issued by a government authority or aid organisation to a community at large. In such cases, the human rights constraints are particularly important. Figure 7 shows how a certification provider might work with an issuer of tokens to issue spendable tokens to users, who may in turn represent themselves or organisations.

Figure 7a shows the setup phase. We assume that the service provider first tells the user that it will accept tokens issued by the certification provider (1). The user then sends a set of blinded, newly-generated self-certifying identifiers, along with any required identity or credential information, to the certification provider (2). We assume that the tokens are intended to be fungible, so the certification provider issues new, fungible tokens on the ledger (3). We need not specify the details of how the second message works in practice; depending upon the trust model for the ledger it may be as simple as signing a statement incrementing the value associated with the certification provider’s account, or it may be a request to move tokens explicitly from one account to another. Then, the certification provider signs a set of messages, each containing one of the blinded identifiers, and sends them to the user (4). The messages will function as promissory notes, redeemable by the user that generated the self-certifying identifiers, for control over the tokens.

Figure 7b shows the operating phase. When a service provider requests a token (5), the user sends a message to an authentication provider demonstrating both that it has the right to control the token issued by the certification provider and that it wishes to sign the token over to the service provider (6). The authentication provider, who never learns identifying information about the user, lodges a transaction on the ledger that assigns the rights associated with the token to the service provider (7), generating a receipt (8). Once the transaction is complete, the authentication provider shares a receipt with the user (9), which the user may then share with the service provider (10), who may now accept that the payment as complete.

Like the “main” architecture described in Section 5.1, the “token” architecture can also be configured to work in an offline context by modifying the operating phase. Figure 7c shows how this would work. The user requests from the authentication provider one or more physical “objects”, which may take the form of non-transferrable electronic receipts or physical tokens, that can be redeemed for services from the service provider (5). The authentication provider sends the objects to the user (8), who then redeems them with the service provider in a future interaction (9,10).

6 Governance Considerations

An important challenge that remains with the distributed ledger system described in Section 5 is the management of the organisations that participate in the consensus mechanism of the distributed ledger. We believe that this will require the careful coordination of local businesses and cooperatives to ensure that the system itself does not impose any non-consensual trust relationships (Constraint 3), that no single market participant would gain dominance (Constraint 4), and that participating businesses and cooperatives will be able to continue to establish their own business practices and trust relationships on their own terms (Constraint 5), even while consenting to the decisions of the community of organisations participating in the shared ledger. We believe that our approach will be enhanced by the establishment of a multi-stakeholder process to develop the protocols for participating in the distributed ledger and ultimately facilitate a multiplicity of different implementations of the technology needed to participate. Industry groups and regulators will still need to address the important questions of determining the rules and participants. Consultative organisations, ranging from consulting firms to aid organisations, will be positioned to offer guidance to community participants in the network, without imposing new constraints.

The case for a common, industry-wide platform for exchanging critical data via a distributed ledger is strong. Analogous mechanisms have been successfully deployed in the financial industry. Established mechanisms take the form of centrally-managed cooperative platforms such as SWIFT [48], which securely carries messages on behalf of financial markets participants, while others take the form of consensus-based industry standards, such as the Electronic Data Interchange (EDI) standards promulgated by X12 [49] and EDIFACT [50]. Distributed ledgers such as Ripple [51] and Hyperledger [52] have been proposed to complement or replace the existing mechanisms.

For the digital identity infrastructure, we suggest that the most appropriate application for the distributed ledger system described in Section 5 would be a technical standard for business transactions promulgated by a self-regulatory organisation working concordantly with government regulators. A prime example from the financial industry is Regulation NMS [53], which led to the dismantling of a structural monopoly in electronic equities trading in the United States. Although the US Securities and Exchange Commission had the authority to compel exchanges to participate in a national market system since 1975, it was not until thirty years later that the SEC moved to explicitly address the monopoly enjoyed by the New York Stock Exchange (NYSE). The Order Protection Rule imposed by the 2005 regulation (Rule 611) “requir[ed] market participants to honor the best prices displayed in the national market system by automated trading centers, thus establishing a critical linkage framework” [54]. The monopoly was broken, NYSE member firms became less profitable, and NYSE was ultimately bought by Intercontinental Exchange in 2013 [55].

We believe that distributed ledgers offer a useful mechanism by which self-regulatory organisations satisfy regulations precisely intended to prevent the emergence of control points, market concentration, or systems whose design reflects a conflict of interest between their operators and their users.

7 Conclusions and Future Work

We argue that the ability of individuals to create and maintain multiple unrelated identities is a fundamental, inalienable human right. For the digital economy to function while supporting this human right, individuals must be able to control and limit what others can learn about them over the course of their many interactions with services, including government and institutional services.

We have introduced an open digital identity architecture that promotes the implementation of identity architectures that satisfy constraints that we consider essential to the protection of human rights, and we believe that a combination of strong technology and thoughtful policy will be necessary to promote and ensure the implementation, deployment, and use of technology that satisfies them. We have elaborated eight requirements for technology infrastructure and demonstrated that they can be achieved by means of a decentralised architecture. We discussed issues associated with scalability and governance, also demonstrating how tokens can be spent via such a system.

The specific mechanism for fostering a community of participating organisations will depend upon the relationship between those organisations and the group that ultimately assumes the role of ensuring that the system does not impose non-consensual trust relationships on its users. It must be noted that any system that puts control in the hands of end-users carries the burden of education, both for the well-functioning of the system as well as for safeguarding its role in protecting the public interest. Future research, therefore, must include case studies of how similar systems have been developed, deployed, and maintained over time, in a variety of different social and business contexts.

8 Acknowledgements

We thank Valerie Khan, Edgar Whitley, and Paul Makin for their thoughtful insights. Geoff Goodell is also affiliated with the Centre for Technology and Global Affairs at the University of Oxford.

References