Self-Sovereign Identities

Aug 15, 2019 | Privacy & Security, Technology & Innovation

Anonyome Labs is a privacy focused company. We build mobile applications and a partner platform that enable users to share the identity details they choose while keeping the rest private. This allows users to interact offline and online in a way that is more safe, secure, and private.

Most users setup their online identity with contact points like a phone number, an email address, and a credit card. People use those details to identify each other online. People also create additional identity sets that let others identify them in various activity scenarios, such as work, home, hobbies, or even as a coach (see Figure 1).

The Anonyome Labs applications and platforms allow users and partners to create and manage their various digital identities (we call the digital identity a Sudo), with each Sudo providing a range of privacy protecting capabilities. Our core reference application for providing these capabilities is MySudo [1] and it currently provides for secure and compartmentalized communication [2].

Figure 1: MySudo Identity Selection

Given our focus on digital identity management we have been following closely the evolution of self-sovereign identities. They are a unique concept in that they move the control of the digital identity to the user. And most important for Anonyome Labs’ users, self-sovereign identities provide a level of privacy and security that is unknown with current identity management models.

Recently, Anonyome Labs was accepted as a Founding Steward on the Sovrin Network [3], a global decentralized ledger network [4] for implementing self-sovereign identity. Our initial goal is to assist with the operation and management of the Sovrin Network. In addition, we are currently enhancing our platform to allow our users and partners to have access to self-sovereign identities using the Sovrin Network.

The Road to a Self-Sovereign Identity

Self-sovereign identity is a new approach to digital identity. To understand where it came from, this section examines the two most common approaches for digital identity management today. An excellent article discussing this topic in more depth is The Three Models of Digital Identity Relationships [5].

Centralized Identity Management

Traditionally, the computing industry has used centralized identity management platforms. When we want to access a service, we connect to that service and create an account that it maintains. The assumption is the service knows nothing about us and begins the interaction by asking us to set up a username and password and often asks for other personal information such as name, email address, cell phone number, and credit card details. For many services two factor authentication is also supported to strengthen the authentication process – using SMS, one-time password apps, or hardware keys.

This centralized identity management approach is very straight forward but has several serious limitations:

Volume: users have to manage dozens, if not hundreds, of these service accounts. Due to the difficulty (perhaps impossibility) of a user remembering all of their account passwords, users either repeat their passwords (often following a pattern) or use password managers such as 1Password [6]. As an example, I have around 200 accounts set up in my password manager. And I seem to add a new account almost every week. This type of password reuse is problematic for the entire industry, because passwords disclosed from a data breach on an insecure website might also be able to access the user’s accounts on other (even secure) websites.
Personal Data Exposure Risk: when personal data is stored at these services, it is vulnerable to exposure. Not every service where you have an account has the expertise needed to make your data secure. Therefore, your personal data is at all times at high risk. Also, due to the large numbers of accounts, and a user’s tendency to re-use passwords, the main consequence of this centralized model is growth in financial and identity theft as we have seen with countless high-profile incidents [7]. Figure 2 shows the trends for data breaches and record disclosures from 2005-2018 [8].

Figure 2: Data Breaches and Records Disclosed 2005-2018

Federated Identity Management

Often called a social login [9], federated identity management involves a third party providing a single sign-on experience to users. Users with an account at one of the large social login providers (e.g. Facebook, Google, Twitter, LinkedIn) can use their account as a way to access another service without requiring the creation of an account at that service. The service relies on the social login provider for identity information. Underlying this system is a set of federated protocols, including: SAML 2.0 [10], OAuth 2.0 [11] and Open ID Connect [12].

The federated identity management approach is very user friendly and reduces the number of accounts the user has to set up, but it also has a number of serious limitations:

Poor Privacy: it is a very poor model for protecting user privacy. The social login provider is incentivized to get their users to use this model at as many services as possible, to increase their visibility into the user’s behavior. This behavioral information is very valuable to the social login provider for selling advertising to the user or even to other advertising services.
Weak Security: the model is perceived to be too weak from a security and privacy point of view to allow high value services, for example banking and government, to use this type of model. Hence the user still must use a centralized model for higher valued services.

What is a Self-Sovereign Identity?

There isn’t a single authoritative definition of self-sovereign identity, although The Path to Self-Sovereign Identity [13] makes an excellent attempt at defining the core characteristics. Self-sovereign identities have been designed to address the weaknesses inherit in centralized and federated identity management systems.

In contrast with conventional identification systems, a self-sovereign identity isn’t created by an internet-based service or an organization and given to a user, but rather it is created by a user and then voluntarily provided to a service where the user chooses to interact. When a user provides their self-sovereign identity to a service, the service responds by creating a cryptographic credential for the user. At a very high level, this credential consists of a cryptographic set of values created by the user, signed by the service, and returned to the user. The user stores this credential in their wallet and the service stores the corresponding values in theirs. While this sounds complex, these cryptographic processes are transparent to the user, and the net result is that the user and the service will have exchanged values that can be used for subsequent authentication and encrypted communications. Among other things, this mechanism lets the user login to the service without having to use (or remember) a cumbersome (and much less secure) password.

Another important point about self-sovereign identities is that they are multi-source identities. A multi-source identity is one that emphasizes attributes or relationships over identifiers (e.g., usernames and passwords). When a self-sovereign identity is used to obtain a credential from a website or service, it is exchanging values that are linked to public keys. These public keys are the root of critical identification processes (e.g., public key cryptography, zero knowledge proofs, etc.) and are used to enable secure communications, perform data verification, encrypt / decrypt data, and perform mutual authentication, which can enable password-free login processes. Since self-sovereign identities are controlled by the owning user and are used to collect relationship credentials, they enable every individual with the ability to control his or her own online identity, which they use to connect with other self-sovereign identities or digital services.

Perhaps, the best way to understand the self-sovereign model is to back up a moment and review the physical world. We each carry a set of physical credentials, issued to us by various organizations, that in turn can be presented for service at other organizations (see Figure 3). The key components in the physical world are:

Credential Issuer: The organization that creates the credential for the user. An example is a Government Transport Department that issues drivers licenses.
Credential: The physical token that carries a set of attributes (known as ‘claims’) about the holder. For a driver’s license, claims can include: name, birth date, license specifics/limitations, and home address.
Wallet: A place for the user to physically store their credentials so they are accessible when needed.
Credential Verifier: The organization that verifies that the credential presented is valid and has the appropriate claims.

Figure 3: Issuing and Presenting Credentials in the Physical World

A credential can be used in a wide range of circumstances. For example, I can use my driver’s license to prove that I am licensed driver (when the police ask). I can also use it at a bar to prove that I am of legal age, and I can use it to prove my identity at the post office when picking up a parcel. This one credential is very versatile and can be used for multiple purposes.

Many credentials provide the same personal information and a service can accept any one of multiple credentials for a user. For example, I could just have easily used my passport at the bar or post office to prove my age and validate my identity.

The self-sovereign system maps this physical experience into the digital world. The same components that people use in the physical world exist digitally:

Digital Credential Issuer: The organization that collaborates with users to create digital credentials for the user.
Digital Credential: The digital token that carries a set of digital attributes or claims about the user’s relationship with the credential issuer.
Digital Wallet: A place to store the digital credentials (or a reference to other credentials) for the user, so they are ready to be presented. A mobile application is a very handy place for implementing a digital wallet.
Digital Credential Verifier: The organization that verifies the digital credential that is presented is valid and has the appropriate digital claims.

Figure 4: Self-Sovereign Identity Flow

Figure 4 provides a good overview of how credentials are created, stored, used, and verified when a potential employee is looking for a new job. In this example, the university where Alice completed her degree issues her a diploma along with a cryptographic credential, which is digitally-signed by the university’s credential that it has anchored on the distributed ledger (blockchain). When Alice applies for a job, she verifies that her graduation credential is still valid and uses it to provide the data specified in the proof that has been requested by the potential employer. The employer, then, validates Alice’s credential, by checking the digital signatures of the items in the proof, which have been anchored on the distributed ledger.

Using the credential flow method depicted in Figure 4, any organization can issue credentials that can be immediately and deterministically verified using the distributed ledger technology. This also eliminates time-consuming processes of manually verifying key data items that are provided by job candidates to potential employers.

There are three distinct advantages of the digital credential versus the physical credential:

Relevant Disclosure: the user can decide to present only certain claims in the credential (e.g., age, but not home address).
Verification: the credential can be mathematically verified as being unaltered.
Revocable: The credential can be instantly revoked.

An organization may decide to only accept credentials they produce, or may decide to accept third party credentials, or even credentials created by the user.

The Sovrin Network

Separate from the concept of a self-sovereign identity are the infrastructure, standards, and protocols on which to build a self-sovereign identity. At Anonyome Labs, we are building our self-sovereign capabilities on the Sovrin Network, the leading network for supporting self-sovereign identities.

Sovrin Foundation

The mission of the Sovrin Foundation [14] is to develop and administer a global public decentralized utility that enables users to create their own self-sovereign identities. These identities are controlled by the users and are not under the control of any centralized organization. The Foundation has four key principles:

All users have equal access to the Sovrin Network.
The Sovrin Network must not be controlled by any particular organization or government.
The Foundation administers the Sovrin Governance Framework, recruits Stewards to run the network, and contributes to the open source software running the Sovrin protocols.
Provides thought leadership and advocacy for the concept of the self-sovereign identity.

The Sovrin Foundation is a non-profit organization led by a set of diverse volunteers. Currently it is funded through donations, although in time the Sovrin Foundation may be supported by small transaction fees on the network.

Sovrin Governance Framework

The Sovrin Governance Framework is the constitution of the Sovrin Network. It defines the business, legal and technical aspects of the Sovrin Network. Figure 5 provides a high-level summary of the Sovrin Network components and duties, but for a more complete description of the Sovrin Network, please see the official Sovrin documentation [14]. The Sovrin Governance Framework defines five specific roles on the Sovrin Network:

Identity Owners: Any person or organization that uses the Sovrin Network is an identity owner. Identity Owners have legal responsibility to use the Sovrin Network for legitimate use only.
Stewards: Stewards are responsible for operating the validation nodes that maintain the Sovrin distributed ledger.
Trust Anchors: Are identity owners and protect access to the Sovrin Public Ledger for everyone in the Sovrin community.
Agencies: Are Service Providers that host Sovrin cloud agents on behalf of identity owners.
Developers: Collaborate to design and build the Sovrin components. They contribute code to the Hyperledger Indy project [15] and create applications and services that leverage the Sovrin Network.

Figure 5: Sovrin Governance Framework Components

Anonyome Lab’s Platform Support of Self-Sovereign Identity

At Anonyome Labs we are enhancing the MySudo application and our privacy platform to support self-sovereign identities using the Sovrin Network. Supporting the self-sovereign identity features and functionality is a key privacy enhancing capability for MySudo users and partners. This will provide users with expanded control over their Sudo identities, as well as, the determinism and persistence of the Sovrin decentralized ledger.

The first area where we are focusing our development efforts is to integrate the Sovrin wallet and agent functionality within MySudo. As part of MySudo’s premium services, this will introduce the ability to generate and manage Decentralized Identifiers (DIDs) for each Sudo, as well as, enable Sudos to participate in self-sovereign identity activities with other Sudos, such as:

Decentralized Identifiers (DIDs) [13]: enabling Sudos to generate, transmit, receive, verify, and store DIDs (which include private/public keys pairs).
Pairwise DIDs: Sudos will be able to create and use pairwise DIDs, which provide for secure off-chain operations. Pairwise DIDs are not recorded on the decentralized ledger.
Agent Interactions: adding agent functionality to MySudo will enable Sudos to interact with other self-sovereign identities – including those from outside of the Sudo ecosystem. This will enable Sudos to receive, hold, and present credentials originating from third-party credential issuers that conform to the Sovrin self-sovereign identity standards.

These capabilities will initially be available through the MySudo app and subsequently the Anonyome Labs’ partners that deploy the platform. Future self-sovereign identity additions to the MySudo ecosystem will provide the ability to interact with non-Sudo self-sovereign identity agents that implement the Sovrin architectural standards. Anonyome Labs is a Sovrin Founding Steward and will continue to assist in the operation of the Sovrin Network by maintaining and upgrading the Anonyome Labs Steward Node according to the required service level agreements and upgrade cycles.