Digital Identity: Market Overview
Stakeholders (customers/ users, issuers (processors, controller, data protection officer, supervising authority), verifier)
There are 3 main stakeholders (entities) involved in Digital identity management. Figure 2.1 shows these stakeholders and their respective roles.
Subject – An entity (individual or organisation) whom the data is about and/or actually owns the data and, as a result, would suffer losses if their privacy is violated. A privacy violation occurs when Subject’s data is [BBHRSG17] [HB08]:
• Used by a third party that is not desired by Subject.
• Used in a period that is not desired by Subject and/or
• Used for a purpose that is not desired by the Subject.
In short, the Subject’s main goal is to get some desired resource(s) or service(s) while simultaneously preventing a privacy violation. It should be noted that sometimes subjects may choose to relax their privacy policy to some degree if they perceive that the gain (resource or service) is more valuable than some specific personal information.
Authentication agent
An entity that verifies that the Subject is who they claim to be or has what they claim to have. This could be a verification of whether the Subject is registered (has subscribed) to a particular service, exceeded a certain age, has a particular nationality, is human and not a robot, etc. Typically (not strictly), an Authentication agent
• Stores the Subject’s data pre-verification and also (issues claims)
• Provides a mechanism for the Subject to verify their claims).
An example is a simple website login interface with a backend database. It should be noted that the Authentication agent is usually an implicitly trusted agent (someone the Subject knows can violate their privacy policy without getting caught) [BDP04]. The goal of this entity is to maintain trusted information about Subjects and increase the number of Subjects they have if it increases its gains. Thus, the more data they have on Subjects, the more support they can provide for Authorization agents; hence, the more valuable they become.
Authentication can be done in the real world (fingerprint verification, DNA test, facial recognition) or virtually. When Authentication is done in the real world, it is usually referred to as identification. Identification can be expensive and, if not done right, can expose sensitive information. Therefore, there is a need to minimise real-world authentications as much as possible. Thus, performing them only when absolutely necessary.
Authorisation agent
An entity that provides some resource(s) or service(s) to a Subject after they have been authenticated. The main goal of this agent is to link the right person to their respective allowed resource(s) or service(s). This entity may obtain some profit from the Subject in exchange for the resource(s) or service(s) provided.
Decentralised Identifiers (DID)
Definition
A working group with the World Wide Web Consortium (W3C) is currently developing the Decentralised Identifiers (DIDs) standard (W3C DID, 2019). A DID is “a new type of identifier that enables verifiable and decentralised digital identity. A DID identifies any subject (e.g., a person, organisation, thing, data model, abstract entity, etc.) that the controller of the DID decides that it identifies.”
The different realisations of the DID standard are referred to as DID methods.
DID Documents
A DID should point to a DID document that contains information about the authentication methods to prove ownership of that DID, endpoints, and other attributes. As sorted by NIST, a DID document is comprised of the following standard elements (NIST-TA, 2020):
• A Uniform Resource Identifier (URI) to uniquely identify terminology and protocols that allow parties to read the DID document
• A DID that identifies the subject of the DID document
• A set of authenticators (i.e. public keys) used for authentication, authorization, and communication mechanisms
• A set of authentication methods used for the DID subject to prove ownership of the DID to another entity
• A set of authorization and delegation methods for allowing other entities to operate on behalf
of the DID subject (i.e. holders different from the subject).
• A set of service endpoints to describe where and how to interact with the DID subject
• A timestamp for when the document was created • A timestamp for when the document was last updated
• Cryptographic proof of identity (e.g. digital signature)
Additionally, we believe that DID documents should also contain an element that indicates the status of the DID document (active, suspended, or revoked). This would allow the holder to revoke it in case they do not want to use it anymore. By doing that, all the digital documents associated with the DID would no longer accomplish successful verifications, as the verification of the DID subject would fail.
In the simplest model, a DID would be a public key generated from a private key using asymmetric cryptographic algorithms such as RSA, elliptic curves (EC), or discrete logarithms. In the case of public keys, the authentication mechanism requires solving a cryptographic challenge, using the private key associated with the public key that constitutes the DID. However, this should be avoided for security and privacy reasons. DID documents should contain more than one authentication mechanism and the private key used to generate the DID should not be used as one of them.
The most widely adopted elliptic curve and hash function in the DLT space are secp256k1 and keccak-256, respectively. Unfortunately, neither are endorsed in SP 800-186 (NIST-ECDM, 2019) and FIPS 186-5 (NIST-DSS, 2019). A joint effort between Consensys, the Decentralised Identity Foundation (DIF), the Enterprise Ethereum Alliance (EEA), the World Wide Web Consortium (W3C) Credentials Community Group, Hyperledger, and individual W3C member companies submitted a request for NIST to “include the secp256k1 curve as part of the endorsed ECDSA schemes, and the use of keccak-256 in the secp256k1 signature schemes,” arguing that “there are no significant security differences between, for example, the NIST endorsed secp256r1 and secp256k1 or the sha3-256 hash versus keccak-256”. They claim that this would “minimise the damage to innovation and markets caused by the difference between the standards being adopted by the world and those currently endorsed by NIST”. (Consensys et al, 2019)
As emphasised in Section 5 of this paper, it is very important for protocols and standards used in blockchain and self-sovereign identity to be recognized by international standards organisations. This includes cryptographic algorithms as well. Additionally, it is essential that the blockchain community does not underestimate the need to start testing quantum-safe algorithms too. Any cryptography based on RSA, elliptic curves, or discrete logarithms will be broken by quantum computers when they are large enough, which NSA (NSA, 2016), NIST (NIST-Q, 2016), and ETSI (ETSI, 2015) warned back in 2015 and 2016.
The DIF maintains an interface for JavaScript applications to resolve DID documents from Decentralised Identifiers39, and LACChain also provides a service to resolve DIDs40.
DID Registries
The benefits of using blockchain technology for SSI. Some of these benefits are actually requirements for scalable implementations of DIDs. For example, when working with DIDs, it is necessary to have DID registries. Because any entity can generate its own DIDs, having centralised and independent databases used as DID registries would not work. DIDs are expected to serve as identifiers for many different applications. For each of these applications to know where the registry is and how to verify the ownership of the DID against it, would be impractical. This is similar to the issue with the centralised identity model. With centralised registries, we would keep having dependency on centralised entities, which facilitates hacks and attacks and limits accessibility and scalability. Instead, decentralised ledgers that all entities know and have a copy of seem to be the most suitable “databases” for DID registries.
NIST has proposed a classification model for the types of DID registries when using blockchain networks, especially Ethereum-based, which allows for leveraging smart-contract-based functionalities. (NIST-TA, 2020) Table 10 shows the description of each type, the related standards and implementations, and the pros and cons.
In the case of the global identifiers registry, “governance models can range from the entity deploying the contract having complete control of the system, having only limited control of it, or having no control of it. In the case of no control, the governance of the contract would be run by participating users (e.g., with a DAO).”
In the case of the anchor's registry, “the bundling (grouping) of identifier management operations is executed by a second layer protocol that sits on top of the blockchain to which the anchor's registry is located. The protocol then adds the hashes of those anchors in the registry, and uses decentralised storage systems such as the Inter-Planetary File System (IPFS).”
In the case of bringing one’s own blockchain address, “the identifier creation and storage is usually done locally in the identity wallet. Resolving a DID to its DID document consists in iterating over the DID operations that may have been posted.”
DID Methods
Realisations of the DID standard are called DID methods. DID methods may vary in terms of the mechanism proposed for the generation of DIDs, the authentication methods, or the decentralised ledgers used as registries. There are no official lists of DID methods. However, the W3C42 and the DIF43 maintain informal lists.
DID methods should comply with the following requirements:
• Allow responsible use of biometrics (by wallets and applications used to operate these DIDs) • Contain all the elements listed in Section 7.1.2,
including the status of the DID document. • Have more than one authentication method (i.e. RSA, EC, post-quantum keys, and biometrics) • Use quantum-safe cryptography for the authentication, encryption, and signature
• Destroy the seed of the DID so it cannot be re-generated by a hacker in case of theft • Do not disclose any personal data or information in the DID documents
• Guarantee privacy and pseudonymity in the use of the DIDs.
• Have more than one authenticator for each authentication method (e.g. several RSA public keys).
• If the DID was generated from a private key, do not use the associated public key for authentication, encryption, or signature.
• Register the DIDs in a smart contract with well-defined governance (an on-chain DID registry)
• Be scalable enough to economically afford the generation of the required amount of DID for the specific use case in the chosen network.
• Set different functionalities for the different keys, so that some primary keys can be used for authentication, some secondary keys can be used for temporary delegation, and some tertiary keys can be used for retrieving primary and secondary keys
• Store the DID documents in the blockchain so that issuers or verifiers that must resolve specific DID can easily find them
The standardisation of this basic structure is, in fact, revolutionary. The self-sovereign identity model starts with unique identifiers that entities can self-generate, manage, and prove ownership of.
Establishing the rules for their use and getting them recognized internationally is essential.
One could argue that traditional standards, such as X.509 certificates, could play the role of a DID document in the SSI model. However, they cannot offer the minimum requirements needed for solutions that are scalable, reliable, and guarantee data privacy. In fact, in the SSI model, X.509 certificates are replaced by the combination of a decentralised identifier and a verifiable credential issued by a trusted entity. However, in the short term, it is very possible that existing X.509 certificates will be used to generate verifiable credentials.
Types of Identity
Forms of Identity
Email addresses are our Digital IDs and is core of everything we do online.
log into accounts, portals, and dashboards;
register for webinars, workshops, and courses;
subscribe to blogs, podcasts, company updates, promotional notifications, and loyalty programs;
sign up for events or social programs;
download mobile apps, PDFs, guides, and the like; and
make purchases of almost any kind, whether online, via an app, or in-store.
Phone
Mobile identity
Mobile phones and other devices can be used to provide portable digital identity and authentication for a variety of online transactions. For example, providers can issue SIM cards with digital certificates or use other mobile network assets that can enable secure and convenient identity and authentication of users for eGovernment (eGov) services and other public or private platforms.
Mobile SIM Authentication
With the ubiquity of mobile phones, there is increasing interest in using unique identification numbers associated with mobile subscriber identity modules or SIM cards. The algorithms contained in the SIM card allow for encrypted communication between the user and the network. For authentication, the authenticating body generates a random sequence of numbers that is sent to the user’s mobile- this is the user’s public key.
The public key, together with the user’s private key and authentication algorithm contained in the SIM, verifies the user.
Countries that have adopted cryptographic SIM cards include Estonia, Moldova, and Finland. Norwegian mobile operators offer their subscribers secure mobile authentication through a local BankID solution to provide secure online user identification and user digital signature verification. In 2012, the Bank of Mexico issued a regulation establishing that banks in Mexico must allow their deposit account holders to associate their cellphone numbers to their accounts in order to facilitate electronic transfers of funds across bank accounts. Each cellphone number can be associated with only one account in a given bank but with multiple accounts, each from a different bank. Once the association is established, a customer can provide her cellphone number as an identifier to receive transfers.
However, it is important to note that mobile authentication is more viable when used in combination with other authentication methods rather than as a standalone technique due to practical challenges such as sharing of mobile phones between individuals.
Linked to this and a relevant point to be aware of is that many countries now require that pre-paid SIM cards only be activated when registered with proof of identity; those who lack this ID could be denied access to mobile communication, further exacerbating digital, social and financial exclusion.
GPS
“Presence” is a particularly hot issue, with upwards of 70% of participants in the upcoming benchmark saying they anticipate presence technologies to become pervasive in their organisations within the next 12 months. Presence - most often associated with real-time communications systems such as IM - describes the state of a user’s interaction with a system: which computer they are accessing, whether they are idle or working, and perhaps also which task they are currently performing (reading a document, composing email etc.).
“Location” refers to the user’s physical location - typically, it includes latitude, longitude and (sometimes) altitude. Location is most often associated with GPS-enabled mobile devices.
Though presence and location are not often discussed in an information security context, they can contribute to the security of the enterprise in quite surprising ways.
Authentication and authorization mechanisms generally focus on determining the “who” aspect of identity. But knowing “where” (location) and “what” (presence) can assist in user authentication/authorization through consistency checking. If a user is attempting to access a company’s network from an IP address in China, while the user’s GPS device locates them in San Jose, the system can raise a red flag and refuse access.
IP address
Geolocation service firms provide specifics about where a consumer is located based on the IP address from the HTTP header on the order placed at a merchant’s site. This can then be compared to the consumer’s stated location, helping a company determine whether the order was made by a fraudster. The whereabouts of an IP address can be examined against the billing or shipping address, ZIP code and area code. Geodata cannot be limited to IP addresses, as fraudsters can fool IP data, and banks that rely on IP-specific location data for users and companies may hurt rather than help the situation.
Trevor Wingert, a senior know your customer (KYC) and anti-fraud solutions consultant for GeoGuard, told PYMNTS in a recent interview that moving beyond IP addresses for determining location is critical, especially when it involves the verification of data.
Crypto Wallet
A user’s crypto wallet will be integral to everyone’s online identity in the Web 3 space and function as a key, accessing all their domains, real estate, NFTs and other virtual properties.
Digital Identities (Avatar)
Digital Identities in Metaverse are unique. The identification module will be built into the protocol, and supplementary applications will be developed. Users will have autonomy over their identity—a self-sovereign identity—meaning that they are in full control of their personal identification information and hence need not rely on any central entity or third party for identity verification. With truly self-sovereign identity, users can create, sign and verify claims, while parties who interact with a user will be able to prove their identity. Additionally, users will be able to selectively disclose their information.
Digital identities are an integral part of the virtual world and can take many forms, such as that of an individual or value intermediary (institutions and entities). Therefore, a user can have different digital identities under different scenarios (such as a workplace identity and personal identity), but they are ultimately all based on the user’s real-world identity.
Users can establish a reputation on Metaverse through digital identities, improving the way we exchange value. Value is exchanged through digital signatures, requests for verification and transactions; these transactions then allow a user to gradually build a reputation which can be inspected and verified by other digital identities and value intermediaries. If a centralised entity’s servers crash, the identities and reputations established by their users over the years could be permanently lost. With Metaverse, a user’s digital identity and reputation will be protected by blockchains.
Biometric - Fingerprint, eye, facial recognition, DNA, chip
Biometric recognition uses an individual’s unique physiological and behavioural attributes to identify and authenticate his or her identity. Physiological attributes include elements related to the shape or composition of the body, such as fingerprints ridges, iris patterns, and facial characteristics. Examples of behavioural attributes include gait, signature, keystroke patterns, and mouse usage. The type of attribute collected and matched is called modality. For example, fingerprints and iris are different biometric modalities.
In the sections that follow, a number of biometric modalities are reviewed—including iris, fingerprint, face, voice, behaviour, vascular, and DNA. (See Figure 6.)
Figure 6: Biometric Sub-Technologies
In the assessment, biometric capture and matching are distinguished from each other. The reason is that the technologies are maturing at different rates. And although they are related, they are selected based on specific needs that may not be related. For example, ease of capture has little to do with matching speed. Capture is the process of collecting biometric data from the user. Matching is the process where an individual’s probe biometric record is matched against the stored record (candidate) when an end user requests access to any biometrically protected system (such as for authentication), or is matched against all candidates during a de-duplication (i.e., identification) search. Certain modalities also have different levels of maturity and technology advancement for capture and matching. Moreover, the ratings are an average of different devices and subjects. The devices may vary in terms of cost, speed, features, and other characteristics, while subjects may vary based on age, profession, and other factors that make the capture process easier or difficult for the specific demographic group.
Even though the capture and matching technologies for each modality have been evaluated separately, in the biometrics assessment summary shown in Figure 7, the different assessments for capture and matching are combined into one graph using gradients. The inner colour represents the rating for the respective modality’s capture technology, and the outer colour represents the rating for matching technology.
In determining which modalities to incorporate in a biometric-recognition system, decision makers must consider the following criteria:
Accuracy: false acceptance rate (FAR) and false rejection rate (FRR) under operational conditions
Universality: presence of the trait in members of the relevant population—important because certain traits (like fingerprints) may be poor or damaged in certain demographics and can lead to a failure to enrol (FTE) the individual
Stability: permanence of the trait over time or after disease or injury
Collectability: ease with which good quality samples can be acquired
Resistance to circumvention: vulnerability of the modality to fraud
Acceptability: degree of public openness for use of the modality
Usability: ease with which individuals can interact with the technology used to capture the biometric data
Cost: costs of sample collection and matching; namely, hardware, and software costs In evaluating how well different biometrics meet these criteria for effectiveness, the biometrics can be thought of as falling into two major categories:
Primary biometrics are associated with modalities such as fingerprint, face, and iris recognition, and have relatively low FARs and FRRs. Identification systems that must search across large galleries of biometric samples use primary biometrics because they yield more accurate results.
Soft biometrics relate to an individual’s behavioural characteristics, such as keystroke patterns, signature, and gait. Error rates are typically too high for identification searches, but these modalities are used for continuous authentication to verify the identity of the user throughout a session. Through analysis of a user’s behaviours and interactions with a device, continuous authentication can detect anomalies during a session.
Personal Identification Number (PIN)
The Personal Identification Number, or PIN, is the authentication technology used by almost all payment card services worldwide, particularly for ATM cash transactions. A PIN differs from a password in that it is transformed into a reference value using encryption keys which are then stored on the authorisation systems of the FSP, while the PIN itself is transient in nature. The security relies on having a robust transformation process that provides a high degree of confidence that the PIN cannot be derived from the reference value. A PIN is intended to be remembered by the user, and when used safely and as required by prevalent standards, provides a good degree of protection and certainty.
However, there is a commonly held view that some customer segments cannot use PINs reliably due to illiteracy, innumeracy or lack of familiarity with the technology and other issues. The security of the PIN lies in being able to commit it to memory. However, low frequency of use forms a tenuous link with memory since many of these customers access financial services infrequently, perhaps as little as once every 3 months or even less. Further, the infrequency of use leads people to write their PINs down, often on the back of the card or mobile phone they are using, leading to PIN compromise.
In addition, PINs can and often are easily shared with others, which can present a security risk. For example, national and global fears around terrorism are beginning to influence PIN use. The 2015 terrorist attacks in Paris were reported to have been financed using prepaid cards. This reflects a broader issue with payment cards in that one person who passes the necessary CDD checks can acquire the card and top it up, whilst another person uses the funds. The PIN is forwarded by post or text message, or even word of mouth, making it increasingly difficult to track.
Regulatory authorities in several countries have concerns that a PIN is not secure enough for at least some financial transactions. For example, in India, online biometric authentication for bank transactions is becoming available. The diminishing reliance on solely PIN use for security is further evidenced by the announcement that the Payments Association of South Africa (PASA), in partnership with Visa and MasterCard, is seeking to introduce biometric authentication of payment cards in South Africa.
Smartcards
A Smartcard is a card that has an embedded integrated circuit or chip. Smartcards can be used to store attributes and credentials such as PINs or biometric data (see next section) and, with the appropriate application, can enable interaction with recorded data. For example, a smartcard can be used to verify that a fingerprint sample collected by a connected device is the same as a template stored in the Smartcard. Smartcards can either be “contact” cards that are read when in direct physical contact with a reader or a “contactless” card that uses Near Field Communication (NFC) or radio frequency identification (RFID) technology. In general, “contact” smartcards also have the capability of requiring a pin for identification.
Smart Cards are most commonly used for payments, public transport, or access to office buildings. Many countries also issue national ID cards and other credentials that use smart cards. Digital ID cards in global circulation are expected to increase from 1.75 billion in 2013 to 3.3 billion in 2021. Of this, a total of 3.2 billion national ID smart cards will be issued by 103 countries. As of early 2017, 82 per cent of all countries issuing official ID cards have implemented programs that depend on smart cards or plastic cards and biometrics. These are typically contact cards, although some, including Germany’s ID card (Personalausweis) and Malaysia’s MyKad, use contactless technology.
In addition to using smart cards as standard IDs, some emerging cases have attempted to combine identity and payment capabilities on one smart card, potentially offering great convenience to users and service providers alike.
For example, the Government of Maldives, in collaboration with Mastercard, has recently launched a biometric smartcard-based national ID called the ‘Passport Card’ for its citizens. The card contains 10 fingerprints for secure verification and a unique combination of dual interface chips for contactless and contact card reading. This card functions as the passport, driving licence, and national ID of the cardholder, and can be used to provide health and e-services by the government. It also functions as a payment card to make payments.70
However, like most innovative technologies, integrating identification and payments also introduces a layer of complications and risks, such as data privacy, dilution of data ownership, liability between state identity authorities, payment service providers and banks, and general risk and fraud management. In addition, while smart cards are more secure than non-chip-based cards, they are only as secure as the features installed onto them at the time of production. Estonia, for example, had to re-issue 750,000 national e-ID cards because of a security risk found in the chips of those cards.
Using Existing Legal IDs
In many countries, as a matter of general practice, all FSPs collect a specific ID which is generally considered reliable and universal. In general, the financial sector relies on existing legal IDs, traditionally based on physical interactions and physical exchange of documents- between the user and the relying party, to allow access to services (public or private) such as healthcare, education, and financial services. With the rapid development in technology, FSPs in many countries have access to identification systems to help validate credentials. In the case of digital IDs, the validation and subsequent verification can be conducted in real time at the time of account opening, either in person or even remotely. (Please refer to Annex 2 for details of the validation and verification process)
Identity Governance Models
Digital Identity is defined as the collection of attributes and information about an entity that is used to represent and distinguish the entity in an interaction with the outside world. More specifically, identity refers to what actors look for in the representation of an entity to recognise such an entity as being unique or matching existing criteria.
Identity can be defined in many different ways, especially when viewed from a “digital identity” perspective. Christopher Allen (2016) separates online/digital identities into four different types, namely, centralised, federated, user-centric and self-sovereign. Those types can be categorised along the axis of user control and portability. Whereas user control refers to how much control a user has over her own identity. For example, low control would mean access to identity can be withdrawn by a centralised authority like a database. Portability describes how easy an identity can be reused across different systems or applications (Allen, 2016).
Digital identity: “A digital identity is the unique representation of a subject engaged in an online transaction. A digital identity is always unique in the context of a digital service, but does not necessarily need to uniquely identify the subject in all contexts.”—National Institute of Standards and Technology, 2018
Centralised Identity
With the introduction of online interactions and transactions, it became clear that users needed some form of digital identity. Usually, this consisted of a personalised account created for individual users. A user account included associated credentials (typically a username and password) and other information relevant to the interactions and transactions they were authorised to take.
According to Allen (2016), centralised identities are issued by a centralised authority. Here the underlying authority controls the access to the identity. This can be, for example, an online service like Amazon. The service can easily deny access to the identity by revoking the user's credentials. Moreover, if it is centralised, there is only one single source of truth. This can result in fake identities which have been only confirmed by the centralised authority. This, in general, gives more power to the issuing authority than to the users that actually own the identity. Centralised identity systems also lead to high Balkanisation of identities. Many websites and online services force users into creating separate identities, leading to data silos, less user control, and more website power. Those services could easily disappear or block users from using their own data. However, this is not in the best interest of users since most of the current online identities are issued through centralised systems (Laurent et al., 2015).
This identity model is organised by those who want to exclusively connect subjects to organisations (employees, customers, etc.). This makes it naturally centralised, with few or no incentives to share data or collaborate between database organisers and owners.
Federated & User-Centric Identity
There are numerous downsides to centralised identity management, including security vulnerabilities (e.g., most people reuse passwords) and usability challenges (inconvenience of creating and handling a great number of accounts each with its own username and password). Further examples are later detailed in Section 1.3: Limitations & Challenges of Centralised & Federated Identity.
Given the negative aspects associated with centralised identity management, a new approach emerged within the past ten years: federated and user-centric identity. The core idea behind these approaches was to allow individuals to use the same credentials to access services on different sites (separate entities). Following the first initiatives in this field (e.g., Microsoft Passport, Liberty Alliance), the main form of innovation was to introduce so-called “Identity Providers” (IdPs) — trusted authorities that handle user’s identity data and accounts. As a result, users do not have to manually create separate accounts with unique usernames and passwords. Instead, users can click a single button and let an IdP manage their information.
Federated Identities
Federated identities are those that can be used within a collaboration of systems. Here users are able to log in with the same credentials to different services that form a federation. For example, Google offers its users to log into multiple applications that are affiliated with each other. Users can, for example, use the same credentials for their Google mail account as for their YouTube account. Thus, after a user logs into one application, she can also use other applications within the collaboration. This is possible because they are using a federated identity which is shared across services. Most literature defines this type of login mechanism as Single-Sign-On (SSO) which is a subset of federated identity management. However, federated Identity Management is usually referred to as a collaboration of trust where Identity Providers never share user credentials with external Service Providers (Laurent et al., 2015). Thus, it does not rely on a collaboration of single systems but more on a specific Identity Provider. This leads to a more user-centric approach to managing identities.
User-centric Identities
In a user-centric approach, users are able to control their identities outside a specified collaboration of systems. Here the federated systems refer more to a collaboration of trust between an Identity Provider and any type of external application. Thus, creating a trusting relationship between each other. This trust relationship opens up the possibility of using Service Providers by only exchanging credentials through the Identity Provider. In such a system, a user only grants permission to the Service Provider to use the identity provided by the Identity Provider to manage the service. For example, the Facebook feature “Login with Facebook” allows users to use their Facebook account to use any application that integrates it without exposing their identity credentials to them on authentication. However, user-centric identities improve the portability of identity; they don’t give full control over identity. Thus, if users, for example, get banned by the Identity Provider, they lose access to any application they have been using. Truly user-centric identities are those that allow the user to fully control their identity in an infinite amount of systems. This is also referred to as Self-sovereign Identity.
Self-Sovereign Identity
The self-sovereign identity aims at putting the user into the centre of control of their own identity. This means that a user can fully decide over her identity. Thus, a Self-sovereign Identity creates full autonomy of uses over any type of identity system. In previous systems, users relied on a centralised Identity Provider to be authorised and give access to identity information to third parties. However, in Self-sovereign Identity systems, identities are decoupled from any centralised source that could block, alter, or delete their identity. Identity claims are stored within the identity itself that is controlled by the user (Wagner et al., 2018). Christopher Allen (2016) outlines ten guiding principles for a Self-sovereign Identity. According to him, a Self-sovereign Identity consists of the following principles:
Principle
Meaning
Existence
An identity must be linked to a real person outside the digital world. Thus, having an independent existence.
Control
The user has full control and authority over the usage of her identity and its claims.
Access
A user needs to be able to access all claims and data related to her identity.
Transparency
The system that operates and manages identities needs to be fully transparent.
Persistence
An identity needs to be long-lived. If data changes, the identity keeps the same.
Portability
Identities cannot be linked to one specific party. They need to be portable to any other type of system.
Interoperability
Identities should be possible to be used in any type of system.
Consent
Sharing of data can only happen when the user consents.
Minimization
Data should be exposed only to verify claims.
Protection
The freedom and rights of individual users are most important to the network.
However, these are only guiding principles, and there is no clear consensus yet on how a Self-sovereign Identity is truly defined. Thus, a Self-sovereign Identity can be an identity that fulfils only a few of those principles. Nonetheless, it can be assumed that identity becomes self-sovereign if the user grants full control over it and it does not rely on a centralised system. Thus, moving towards a decentralised Identity Management solution where no central institution holds control over it would pave the way to a Self-sovereign Identity system.
Identity Management Ecosystem
Identity management is a crucial concept when it comes to managing access rights and authentication of services. There are three important roles when it comes to modern online Identity Management Systems. The following will explain the concept of Identity Owner, Identity Providers and services providers, which is used throughout this research.
Identity Owners
Identity Owners are those who receive credentials from different services. The wallet may also contain further personal information about the Identity Owner, the so-called self-attested claims. The Identity Owner could present entire credentials, parts of them or even combinations of multiple credentials in the form of proofs to Service Providers. The credentials can be entirely or selectively disclosed. Therefore, the Identity Owners have full control over their data on how data is used and what is shared.
Identity Providers
An Identity Provider (IdP) is a trusted system that manages identities on behalf of an entity. The IdP provides authentication and authorisation for external Service Providers when requested. Thus, an IdP stores the credentials of an identity issuer and generates claims for a relying party. Thus, Identity Providers act as third parties that are responsible for a seamless exchange of credentials in order to authenticate users with services that are integrated within the ecosystem of IdPs. Through the integration with IdP, users are able to use the same credentials across systems. This reduces the Balkanisation of user accounts across the Internet (Wagner et al., 2018).
Service Providers
Service providers are those who consume and verify identities in order to provide a specific service. The Service Provider needs an identifier in order to recognise existing users and associate them with their data. Many Service Providers are at the same time also issuers. This is because many services use their own IdMS and databases to authenticate and onboard new users (Windley, 2005). Thus, the identity-consuming entity is, in most cases, also the service-providing entity. Here identity credentials are exchanged for services in order to provide a customised user experience.
Legal Frameworks, Standards and protocols
Data Privacy & GDPR
Data privacy through GDPR is an important consideration in the system objectives. Thus, the system needs to account for any type of privacy concern and act along the lines of European data regulations. Therefore, the underlying technology needs to be examined on whether it satisfies the GDPR requirements and to what extent. In other words, several requirements will be derived from GDPR and arguments will be made about whether Blockchain Technology satisfies them.
According to GDPR, any personal data of a subject shall be accessible by other entities with the informed consent of the subject. Data recorded on a Blockchain is pseudonymous which means that it does not contain explicit personal data but only unique references to it. However, on some Blockchains the identifiers can be traced back to an IP address which inevitably classifies as personal data. Verifiable claims that are recorded off the Blockchain are shared only with the informed consent of the subject with other entities. In addition to this requirement, another GDPR consideration is to provide means for the subject to control consent. This allows them to decide who they share personal data with and whether consent can be provided or revoked. Consequently, a Blockchain-based system can provide suitable methods to record and revoke consent by recording on the ledger an immutable and granular proof of consent. In a similar manner, a consent revocation can be published by the subject and can be recorded on the ledger.
Article 17 of GDPR states the right to erasure or the so-called “right to be forgotten” constitutes a major consideration when designing a system. According to the aforementioned article, any records of personal data owned by other entities shall be erased when requested by the subject without undue delay. Therefore, the system shall not record any private claims or proofs on the Blockchain but only a proof of issuance or revocation can be published on the Blockchain. However, if an entity publishes a public statement on the Blockchain, it cannot be erased. In order to fully comply with GDPR, the entity also has to erase copies of personal data on its servers, which is out of the scope of the SSI system.
Furthermore, two more considerations arise from GDPR that shall be addressed by the system. The first is concerned with the portability of personal data in an automated fashion. On a Blockchain-based system, personal data is stored in a machine-readable format in the subject’s claims repository which makes it Blockchain-independent and, therefore, can be ported to other systems. The second is to ensure that personal data is managed in a secure and private manner by design, through the underlying technology of the system. Data stored on a Blockchain is cryptographically secure by default. The system shall not be utilised to record private data since it may pose risks to a lack of privacy due to the transparent nature of Blockchains. Thus, only non-private data should be stored on the ledger.
KYC / AML (anti-money laundering)
Know Your Customer (KYC) is a procedure that a business follows in order to identify and verify the identity of its clients. [17]. KYC can be described in the following steps undertaken by a financial institution or any business entity:
Establish the identity of the customer.
Find out about the client’s financial activity (The primary goal here is to verify that the customer’s income comes from a legitimate source).
Calculate the risk associated with the client in order to set up monitoring the client's activity and managing risk. These include steps taken for Customer Due Diligence (CDD) which is divided into simplified, basic, and enhanced Customer Due Diligence, each with an increasing level of risk management.
These procedures serve a critical function in assessing the risk associated with the customer as well as monitoring the client’s financial activity due to several institutions being required to follow regulation for fraud prevention and Anti money Laundering (AmL).
Nowadays, financial institutes and cryptocurrency exchanges are required to abide by the KYC requirements. To be fully compliant under regulations, banks are required to have the highest possible standard of KYC process and yet be easily accessible for services. It is designed to prevent fraud as well as conform to international laws for Anti-money Laundering (AmL) compliance requirements.
The government holds financial institutions to high standards when it comes to “Know Your Customer” (KYC) laws. These were introduced in 2001 as part of the Patriot Act. The core idea here is that they need to know their customer (i.e. verify their identity, make sure they are real, ensure they are not on a prohibited lists and keep money laundering, terrorism financing and fraud schemes at bay).
These help establish and verify the identity of the customer by using reliable and independent data or sources of information. On the flip side, these processes can be extremely manual, cumbersome and expensive for the entities involved. It is reported that the average institution spends in the region of $60M every year ensuring adherence to these checks.
eIDAS2.0/WIDOW and other initiatives in the EU
The eIDAS Regulation, SSI, and Blockchain
The European Union (EU) has the most advanced and globally recognized regional regulation on electronic transactions, signatures, and documents to date. Adopted on July 23, 2014,33 the regulation 910/2014 on electronic identification and trust services for electronic transactions in the internal market (eIDAS) “provides a predictable regulatory environment to enable secure and seamless electronic interactions between businesses, citizens and public authorities”34 (EU-eIDAS, 2014). The eIDAS Regulation (EU, 2019):
Ensures that people and businesses can use their own national electronic identification schemes (eIDs) to access public services in other EU countries where eIDs are available.
Creates a European internal market for electronic trust services by ensuring that they will work across borders and have the same legal status as traditional paper-based processes.
eIDAS recognizes different electronic elements defined in Article 3. We are particularly interested in the following: Electronic document: any content stored in electronic form, in particular text or sound, visual or audiovisual recording. Electronic identification: the process of using person identification data in an electronic form uniquely representing either a natural or legal person, or a natural person representing a legal person.
Electronic signature: data in electronic form which is attached to or logically associated with other data in electronic form and which is used by the signatory to sign. Electronic time stamp: data in electronic form which binds other data in the electronic form to a particular time, establishing evidence that the latter data existed at that time. Electronic seal: data in electronic form, which is attached to or logically associated with other data in the electronic form to ensure the latter’s origin and integrity.
eIDAS also distinguishes 3 types of degrees of confidence:
Simple
Advanced
Qualified
Annexes I, II, III, and IV of eIDAS specify requirements for qualified certificates for electronic signatures, qualified electronic signature creation devices, qualified certificates for electronic seals, and qualified certificates for website authentication, respectively. Qualified electronic signatures have the same legal effect as hand-written signatures.
In regard to legal recognition, any electronic signature or seal, regardless of its classification as “ordinary” or “simple”, or “advanced” or “qualified,” serve the same objective of attributing the content of the document to the natural or legal person, and therefore are potentially valid and, depending on the case, perfectly acceptable.
The new technological elements introduced in the SSI schema shall not be considered different from the electronic elements already defined and regulated by eIDAS. Instead, they shall be classified using the existing taxonomy. For instance, smart contracts could be considered electronic documents and electronic signatures used to sign blockchain transactions could be considered electronic signatures, with all the legal consequences it implies.
The major question to be asked in this context is: Is eIDAS, the most advanced regulation on electronic transactions, signatures, and documents, already suitable for SSI and blockchain technology? The eIDAS Bridge35, an initiative to promote eIDAS as a trust framework for the SSI ecosystem, and EBSI ESSIF36, the European Self-Sovereign Identity Framework, have identified legal considerations and scenarios with respect to SSI and the eIDAS Regulation37:
Very Short-Term Scenarios – No Need of Legal Changes in eIDAS
Use of notified eIDAS eID means and qualified certificates to issue verifiable credentials
eIDASBridge: increasing verifiable credentials’ legal value and cross-border recognition
Use current eID nodes to issue a SAML assertion based on verifiable credentials/presentations.
Short-term scenarios – Mild technological changes and slight modifications of eIDAS
Use of Verifiable IDs as eIDAS electronic identification means.
Issuance of qualified certificates based on a specific DID method and verifiable credentials
Mid- to Long-Term Scenarios – Stronger Modification of eIDAS
Extend the eIDAS notification mechanism to Verifiable Attestations: enhanced Trusted Issuers management.
Regulate the issuance of Verifiable Attestations as a new trust service.
Regulate Identity Hubs as a new trust service in support of SSI-based TOOP.Regulate delegated key management as an independent trust service.
Regulate a specific type of DLT/node as a trusted service. Decentralised Identifiers (DID)
Therefore, the eIDAS Regulation will need some modifications to become the legal and trust framework for self-sovereign identity in the European Union. This is a reasonable conclusion, as the eIDAS Regulation was created as a legal framework supporting a digital identity metasystem mainly based in delegated authentication, which is more limited than the self-sovereign approach that enables, among other things, pseudonymity and selective disclosure mechanisms, presented in Section 7.3.7 of this paper. Additionally, it will be necessary an effort from both the regulators and the developers to allow blockchain networks and nodes, and digital wallets to qualify and be certified as trust services.
Aligned with this, after analysing the compatibility between eIDAS and verifiable credentials, Alamillo makes two key points.
Verifiable credentials must be considered as electronic documents and thus, should not be denied legal effect and admissibility as evidence in legal proceedings, prohibiting its denial just because it is in electronic form.
There should be defined classes of verifiable credentials with well-defined semantics according to a specific governance framework (e.g. a Verifiable ID or a Verifiable Diploma). This would enable specific recognition for particular purposes.
As a trust framework, eIDAS also establishes communication channels that have been proved vulnerable and could be replaced by the decentralised ledger.
Conceptual regulatory model of eIDAS Regulation
HIPAA compliance
HIPAA — the United States Health Insurance Portability and Accountability Act — is the primary healthcare compliance regulation. HIPAA was introduced in 1996 and established mandatory regulations that changed the way healthcare providers in the US do business.
Before HIPAA, every organisation freely used its own IT systems to manage patient and employee information. Some had legacy systems inherited from the olden days of computing, while others developed new IT systems based on their own criteria. With the introduction of HIPAA, the days of ad hoc IT systems in healthcare came to an abrupt end.
There are two parts to the HIPAA Act. The first deals with protecting health insurance coverage for people who lose or change jobs. The second mandates standardised IT systems. The reason for unifying the way electronic data is managed and exchanged is to put security mechanisms in place for every healthcare organisation to ensure both confidentiality and data integrity. HIPAA also stipulates that organisations use unique ID numbers — known as digital identity — for each healthcare worker, employer, and health plan.
Not surprisingly, the introduction of HIPAA elicited a collective groan from healthcare professionals. Of course, most clinicians respect their patients’ privacy rights, but they couldn’t help but wonder if HIPAA privacy regulations would add a cumbersome layer of complexity to providing healthcare.
While HIPAA created a headache for healthcare IT workers across the country, the impetus behind its implementation was legit. In an example from the year 2000, a hacker downloaded medical records, health information, and social security numbers of more than 5,000 patients at the University of Washington Medical Centre just to expose how vulnerable electronic medical records were. By introducing HIPAA, the government was trying to prevent incidents like that one from happening:
Under HIPAA, an open and imperfectly understood network that doesn’t regulate data is unacceptable. In fact, it was the introduction of strict compliance regulations like HIPAA that initiated the development of policy networking.
What Is Policy Networking?
Simply put, policy networking regulates who can access private computer networks. In a perfect world, a policy-based network follows these guiding principles:
It defines identity and trust policies for an organisation. These policies define who gets access to the corporate network.
The network stores the identity of every user in a directory.
It authenticates a user’s identity before allowing them to access the network.
It compares the user’s computer to the network’s software security policies to make sure the computer joining the network has up-to-date virus protection and won’t infect the corporate network.
It provides connectivity depending on the user’s identity and system profile. For example, in a healthcare setting, if the user only has permission to access email, then they won’t be able to retrieve patient data or physician’s schedules. Additionally, if something within the organisation changes — an employee is fired, a remote device is infected with a worm, a new software application comes online, etc. — policy-based networks automatically reconfigure to modify access.