Design Patterns for Blockchain-based Self-Sovereign Identity

05/25/2020
by   Yue Liu, et al.
CSIRO
UNSW
china university of petroleum
0

Self-sovereign identity is a new identity management paradigm that allows entities to really have the ownership of their identity data and control their use without involving any intermediary. Blockchain is an enabling technology for building self-sovereign identity systems by providing a neutral and trustable storage and computing infrastructure and can be viewed as a component of the systems. Both blockchain and self-sovereign identity are emerging technologies which could present a steep learning curve for architects. We collect and propose 12 design patterns for blockchain-based self-sovereign identity systems to help the architects understand and easily apply the concepts in system design. Based on the lifecycles of three main objects involved in self-sovereign identity, we categorise the patterns into three groups: key management patterns, decentralised identifier management patterns, and credential design patterns. The proposed patterns provide a systematic and holistic guide for architects to design the architecture of blockchain-based self-sovereign identity systems.

READ FULL TEXT VIEW PDF
POST COMMENT

Comments

There are no comments yet.

Authors

page 1

page 2

page 3

page 4

02/19/2021

Design Patterns for Blockchain-Based Payment Applications

As the killer application of blockchain technology, blockchain-based pay...
05/04/2020

Design-Pattern-as-a-Service for Blockchain-based Self-Sovereign Identity

Self-sovereign identity (SSI) is considered to be a "killer application"...
01/10/2018

A First Look at Identity Management Schemes on the Blockchain

The emergence of distributed ledger technology (DLT) based upon a blockc...
07/21/2018

On the Relevance of Blockchain in Identity Management

The ubiquitous application of emerging blockchain technology in numerous...
09/07/2020

A Blockchain-based Platform Architecture for Multimedia Data Management

Massive amounts of multimedia data (i.e., text, audio, video, graphics a...
09/09/2020

Towards a Modelling Framework for Self-Sovereign Identity Systems

Self-sovereign Identity promises to give users control of their own data...
01/01/2022

An automatized Identity and Access Management system for IoT combining Self-Sovereign Identity and smart contracts

Nowadays, open standards for self-sovereign identity and access manageme...
This week in AI

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

I Introduction

A legal entity’s identity (i.e., an individual or an organisation) can be represented using a set of attributes [1] associated with the entity (such as name and address). Identity management includes maintaining the identity data and their access control. Fig. 1 depicts a conceptual overview of the main roles and their relationships in identity management. Specifically, an entity who registers an identifier in a particular system is considered as a holder (e.g. legal individual / organisation name) of the identity data (e.g. date of birth, and role within the organisation) associated with the identifier, while all the identity data of the holder are stored with an issuer (e.g. a government agency). Note that the holder of an identifier can sometimes also be an issuer to identify itself. A credential is a verifiable claim, which includes some facts that is attested and digitally signed by the issuer about the holder [2]. The fact in a credential can be the holder’s identity data (e.g. date of birth) or other types of factual data (e.g. a GPA). After establishing a trust relationship with an issuer, anyone can be a verifier (e.g. an employer) of a claim. A verifier requests for a specific credential (e.g. birth certificate of a person), and verifies the validity of the credential via the issuer’s signature.

Fig. 1: Identity management overview

Identity management is challenging if holders do not have a full control over their identity data, since the data are usually maintained at third-party issuers’ sites (e.g., government agency). An issuer may disclose identity data to a third-party without the holder’s knowledge. Furthermore, the issuer may be compromised, consequently resulting in identity information leakage (e.g., Aadhaar data leakage [3]). In addition, current credential verification processes are usually complex, costly and time consuming (e.g., taking weeks for verifying a degree). It is also possible that a significant process inconsistency occurs within current identity management systems as individuals must seek to verify (and re-verify) identities at multiple points with different service providers111http://fsi.gov.au/publications/final-report/.

The concept of self-sovereign identity allows holders to retain ownership of their identities and control over how their identity data is used [1]. Such a notion is increasingly popular, particularly in our digitised and privacy-sensitive society. However, for legal identities in the real world, we argue that self-sovereign identity does not mean holders can control all aspects of their identity that are maintained by the issuers. For example, holders are not able to include any additional information in their identity information (e.g., a name other than their legal name in their academic transcript), or remove existing restrictions imposed upon registration. Rather, what is achievable via self-sovereign identity is that holders can control the use of their identity data without involving any intermediary [1]. For example, through an effective implementation of a digital wallet for self-sovereign identity to store and manage credentials, holders who own several identifiers can choose to present any credentials associated with any of the identifiers to verifiers, without having to go through the issuers.

Blockchain is an innovative distributed ledger technology (DLT) for building new forms of decentralised software architecture, which enables agreements on transactional data sharing across a large network of untrusted participants, without relying on a central trusted authority [4]. Identity management is considered to be one of the most innovative applications of blockchain technology [5], as blockchain can be used to build an infrastructure or ecosystem to realise self-sovereign identity, where no intermediary is needed. Many organisations (e.g., start-ups, enterprises, and governments) are currently exploring how to leverage blockchain technology to implement self-sovereign identity solutions, examples include uPort222https://www.uport.me/ and Hyperledger Indy333https://www.hyperledger.org/projects/hyperledger-indy. However, as blockchain and self-sovereign identity are both emerging technologies with limited documentation, there can be a steep learning curve for developers to design the architecture of blockchain-based self-sovereign identity systems. A recent survey by Gartner [6] points to the current gap and scarcity of blockchain skills in the market. Having a systematic and holistic guidance for the architectural design of blockchain-based self-sovereign identity systems can assist system architects and developers.

In this regard, this paper presents 12 design patterns for the design of blockchain-based self-sovereign identity applications. To correctly capture the use of the identities and associated credentials, we analysed the lifecycles of the three key objects in self-sovereign identity (i.e., key, identifier, and credential), and classified the patterns into three groups accordingly: key management patterns, decentralised identifier management patterns, and credential design patterns. The proposed patterns are connected to different state transitions in the lifecyles of the three key objects, which provides a guide to the architects and developers when the design patterns can be effectively used.

The remainder of this paper is organised as follows. Section II discusses related work. Section III presents the design patterns of blockchain-based self-sovereign identity applications with the extended pattern form in [7]. Section IV concludes the paper.

Ii Background and Related Work

Ii-a Blockchain and Smart Contracts

Blockchain is an emerging paradigm of building next generation applications in a decentralised way, with two core technologies: 1) a distributed ledger, and 2) a computing infrastructure.

The distributed ledger maintained in a blockchain network can verify and store transactions [4], without relying on any central trusted authority, while all participating nodes need to reach consensus on transactional data states to achieve trust. In the consensus mechanism proposed by Nakamoto, an honest majority of nodes is assumed, achieving trust without a third party intermediary through game theoretic incentives [8]. The data structure of blockchain is a list of identifiable blocks, and all the blocks are linked to the previous block and thus form a chain. The blocks are containers for storing transactions, which are identifiable packages carrying the changing states of data.

Blockchain provides a programmable computing infrastructure via smart contracts, which are essentially the programs deployed and run on blockchain [9]. Smart contracts can express triggers, conditions to enable complex business logic. Ethereum is currently the most widely-used blockchain that supports Turing-complete smart contracts. The primary smart contract language used on Ethereum blockchain is Solidity444https://solidity.readthedocs.io/.

Integrating blockchain technology into current software architecture brings both quality improvements and also blockchain’s nature limitations. For instance, immutability and transparency can ensure data integrity, while the underlying decentralisation enhances the availability of whole system. Nevertheless, data privacy and scalability are the main two limitations of public blockchains. Data privacy on public blockchain is limited because there is no privileged user, and every participant can join the network to access all the information on blockchain and validate new transactions. There are scalability limits on (i) the size of the data on blockchain, (ii) the transaction processing rate, and (iii) the latency of data transmission and commits, which is affected by the chosen consensus protocol. Furthermore, the number of transactions included in each block is also limited by the bandwidth of nodes participating in the network.

Fig. 2: Lifecycles of three main objects in self-sovereign identity
Category Name Summary
Key Management Patterns Master & Sub Key Each entity has a master-key for managing sub-keys which are used for signing transactions for different identity accounts.
Hot & Cold Wallet Storage An entity can maintain a hot wallet connecting to internet and a cold wallet which is kept offline.
Key Sharding A key can be split up into several different pieces, and restored using enough key pieces.
DID Management Patterns Identifier Registry The identifier registry maintains bindings between an identifier and the address of an identity attribute.
Multiple Registration Each entity can register a unique identifier for each relationship.
Bound with Social Media A bidirectional binding is established between social media profile and blockchain-based identity.
Dual Resolution To establish interactions, two entities can mutually acquire each other’s DDO for verification and communication information.
Update by Delegates Each identifier maintains a list of delegates that can help the user recover the identity.
Credential Design Patterns Selective Content Generation An issuer generates a customised credential according to a holder’s specific requirements about credential contents.
Time-Constrained Access A holder can share a link which is redirected to the credential content only for a specified period of time.
One-Off Access A holder can share a one-off link which is redirected to the credential content one time only to satisfy a temporary identification request.
Anchoring to Blockchain Periodically sending the unique hash value of off-chain data to blockchain.
TABLE I: Pattern collection overview

Ii-B Self-Sovereign Identity

Identity management is a fundamental requirement in our digitised society, since every entity is likely to have multiple identities for different people or organisations [10, 11]. However, Internet users do not generally have complete control over their digital identities stored by third-party issuers (e.g. social networking sites or employers), which may disclose one’s identity information to others without their permission and/or knowledge.

In self-sovereign identity [1], identity owners are central to the administration of the identities, in the sense that they are able to manage their identities on personal mobile devices or cloud, and interact with multiple service providers. To implement self-sovereign identity, the W3C Community Group specifies a standard for decentralised identifier (DID) [12], which contains human-readable information and can be used across different platforms. A DID is a URL that refers to an entity for trusted interactions. Each DID bonds to a DID document (DDO) which describes how to use the specific DID through some given properties, such as context, id, public key, and service endpoint. context expresses the system environment for information exchange between two DIDs; id is the DID described by this DDO; publicKey is for digital signatures and cryptographic operations; and service denotes service endpoints used for interactions among DIDs. A DID and its corresponding DDO do not contain any identity data which are stored in personal devices or database owned by the identity service providers. A credential [2] is a verifiable claim, carrying particular identity information attributes that an issuer provides to attest to some specific characteristics of an entity. Within self-sovereign identity, entities are able to issue digitally-signed credentials about themselves and others linked to their DIDs, and these credentials can be verified by anyone else. Blockchain has been widely recognised as a viable technology for enabling DID in terms of data integrity and privacy. As self-sovereign identity needs no intermediary, it aligns with the design nature of blockchain which eliminates the need for a centralised authority.

Ii-C Related Work

Previous works have characterised and applied design patterns for smart contract and blockchain applications [13, 14]. originChain [15, 16] adopts design patterns for data management and smart contract design to improve the system adaptability. uBaaS encapsulates design patterns as services to facilitate the development of blockchain-based applications [17]. Bartoletti and Pompianu [18] conduct an empirical analysis of smart contracts, in which they collected hundreds of smart contracts and divided them into nine categories: token, authorisation, oracle, randomness, poll, time constraint, termination, math and fork check. Eberhardt and Tai [19] propose five patterns, including challenge response pattern, off-chain signatures pattern, content-addressable storage pattern, delegated computation pattern, and low contract footprint pattern, mainly focusing on the separation of on-chain and off-chain for data and computation. Zhang et al. [20] share the experience of designing a blockchain-based healthcare platform, to which they apply four object-oriented software patterns to improve the application scalability. Wohrer and Zdun [21] collect six design patterns to address security issues of smart contract design.

There have been significant efforts in both industry and academia to address many of the identity management challenges using blockchain technology [22, 23]. Many organisations and companies have been developing self-sovereign identity platforms using blockchain, including Sovrin (Hyperledger Indy) [24], uPort (Ethereum) [25], and Blockstack (Namecoin) [26]. Decentralised Identity Foundation555https://identity.foundation/ aims to develop an open ecosystem for decentralised identity, and the Internet Identity Workshop666https://internetidentityworkshop.com/ seeks to find, investigate, and solve identity issues. There are also projects designing and developing self-sovereign identity systems [27, 28, 29, 30, 31].

Compared with the existing works, our study focuses on the design patterns of blockchain-based self-sovereign identity, aiming to facilitate the design and development of self-sovereign identity applications. Some collected patterns are already applied in the related works, for instance, Identifier Registry, Multiple Registration, and Selective Content Generation can be found in the above projects and studies.

Fig. 3: Pattern relation overview

Iii Patterns for Blockchain-based Self-Sovereign Identity

This section introduces 12 patterns for the design of blockchain-based self-sovereign identity applications. We present the patterns in three groups: key management, DID management and credential design. The patterns aim to make better use of three main objects in self-sovereign identity – key, DID, and identity credential, by understanding their use in different stages of the lifecycles.

Fig. 2 and Table I offer an overview of these patterns, while Fig. 3 gives a glimpse of the relations between the patterns collected in this study. We describe each pattern using the extended pattern form in [7]. This includes the pattern name, a short summary, the usage context, the problem statement, a discussion on the forces leading to the problem difficulty, the solution and its consequences, and some examples of real-world known uses of the pattern. Note that the forces are identified with the quality attributes which may affect the application, and the solution sometimes proposes a trade-off to mitigate the dilemma.

Iii-a Key Management Patterns

Iii-A1 Master & Sub Key Generation

Summary: Each entity has a master-key for managing sub-keys which are used to sign transactions for different identity accounts. Fig. 4 is a graphical representation of the pattern.

Fig. 4: Master & Sub Key Generation Pattern

Context: Public key cryptography and digital signatures are used to identify accounts and authorise transactions submitted to a blockchain.

Problem: Using a single key for all transactions has serious privacy implication for an identity owner since transactions can be correlated to expose all the identities an entity holds.

Forces: The problem requires balancing the following forces:

  • Identifiability. An entity needs to create an identity for sending transactions in the blockchain network.

  • Re-identification. Each entity can have more than one identities in the real world. For example, one person is both a client of a bank and a patient of a hospital. If an entity handles all the identities via a single key, its privacy may be violated as all the transactions on blockchain are transparent and can be correlated.

  • Security. There is no a standard approach to protect or recover users’ secret keys.

Solution: Each entity can have a master-key to manage sub-keys which are used for signing messages under different identities. For example, a person can have a sub-key for the student identity and another sub-key for the company intern identity. Each sub-key is linked to a unique identifier and stored as part of the identifier’s data in the identifier registry, which can be updated using the master-key. The use of master-key must be minimised (i.e., only used for controlling sub-keys) due to its importance.

Consequences:

Benefits:

  • Identifiability. Identifiability is preserved as each transaction is signed by a private key.

  • Privacy. Each sub-key maintains its own identity. The transactions sent under different identities are less likely to be mapped and correlated in order to re-identify the user.

  • Availability. If a sub-key is lost or compromised, the master-key can be used to revoke the lost or compromised key and update it with a new sub-key.

Drawbacks:

  • Security. If the master-key is lost or compromised, the identity owner loses control of all the sub-keys which means loss of control of all the owned identities.

Related patterns:

  • Hot & Cold Wallet Storage (Section III-A2) Entities’ keys are stored in wallet applications.

  • Key Shards (Section III-A3) Keys can be protected and recovered by Key Shards.

  • Identifier Registry (Section III-B1) Entities can use sub-keys to register identifiers in Identifier Registry.

  • Multiple Registration (Section III-B2) Sub-keys are used to register identifiers for different identity relationships.

Known uses:

  • uPort2 A uPort user interacts with application smart contracts via a proxy smart contract, thus the public key of the proxy contract is considered as a layer of indirection between the user’s private key and the target application contract.

  • Ethereum777https://ethereum.org/ Implementing the Ethereum ERC725 standard key management functions888https://github.com/ethereum/EIPs/issues/725 requires the deployment of ERC 725 identity smart contracts, which act as unique identifiable proxy accounts and used by humans, groups, organisations, objects and machines.

  • Trinity999https://trinity.iota.org/ Trinity is a wallet application of IOTA ledger101010https://www.iota.org/. Each account has a seed acting as a master-key, to control the addresses and IOTA tokens of that specific account.

Iii-A2 Hot & Cold Wallet Storage

Summary: An entity can maintain a hot wallet connecting to internet and a cold wallet which is kept offline. Fig. 5 is a graphical representation of the pattern.

Fig. 5: Hot & Cold Wallet Storage Pattern

Context: As a blockchain network participant, one entity can rely on so-called “wallets” to manage its accounts and interact with blockchain.

Problem: An entity’s wallet may suffer malicious attacks, leading to key theft. The attacker can send transactions under that entity’s name to blockchain using a compromised key.

Forces: The problem requires balancing the following forces:

  • Cyber security. A key may be hacked when being stored in a device connected to internet.

  • Usability. Some keys may be frequently used by blockchain participants while other keys might act as backup.

Solution: Users can choose to store keys in two types of wallets, namely hot wallet and cold wallet. Hot wallet refers to the blockchain gateways that are connected to Internet. Through a hot wallet, a user is able to directly conduct specific operations (e.g. generation) to its accounts and related decentralised identifiers stored on-chain. Cold wallet refers to key storage that is off-line, keeping the accounts from being hacked. A cold wallet can be any device disconnected from the internet or even a paper recording an entity’s keys. When the keys stored in a cold wallet are required for signing transactions, the user needs to connect the cold wallet device to a computer and copy-paste the key in the relevant field. A user can combine these two wallets: storing accounts that are frequently used in a hot wallet while using a cold wallet to keep those that are not used often.

Consequences:

Benefits:

  • Secure storage. Cold wallets are separated from internet, which provide secure storage for entities’ keys.

  • Usability. Such a secure storage also preserves the usability of keys, as once a cold wallet is connected to Internet, an entity can utilize those keys.

Drawbacks:

  • Security. Hot wallets store one’s secret keys on-line, which is still vulnerable to theft.

  • Usability. Cold wallets are more secure than hot wallets but less convenient to use, as the user has to connect to the cold wallet which might not be around.

Related patterns:

  • Master & Sub Key Generation (Section III-A1) Wallet applications are utilised to stored users’ keys.

  • Key Shards (Section III-A3) Splitting and recombining a key should be conducted in a wallet application.

  • Delegate List (Section III-B5) When being integrated into wallet applications, predefined delegates can replace key ownership if a key is compromised.

Known uses:

  • MyEtherWallet111111https://www.myetherwallet.com/ Ethereum blockchain network offers a software , MyEtherWallet, as hot wallet to users for instant payment and withdrawal. With a visual interface, it is easy for users to operate without inputting complicated commands.

  • Trezor121212https://trezor.io/ Trezor is a cryptocurrency hardware wallet, designed to store and encrypt users’ coins, passwords and other digital keys. It is a single-purpose computer with independent memory to save all private data.

  • Ledger131313https://www.ledger.com/ Ledger provides hardware wallet products to stores users’ private keys in a secure hardware device, protecting the cryptocurrencies.

Iii-A3 Key Shards

Fig. 6: Key Shards Pattern

Summary: A key can be split up into several different pieces, and restored using enough key pieces. Fig. 6 is a graphical representation of the pattern.

Context: In self-sovereign identity, a participant may have multiple keys, for instance, signing key for transaction authorisation, public/private key pair for encryption/decryption, etc. Consequently, key management is significant to the users, especially credential issuers and holders.

Problem: A user may lose or forget his/her secret keys under some circumstances, e.g. the device containing the keys is lost or broken. Losing the keys denotes that the owner could lose control over its blockchain accounts in self-sovereign identity and the related identities.

Forces:

  • Loss of keys. Private keys are usually long and hard to remember. Also, many blockchain platforms do not provide a sound mechanism to recover the signing keys.

  • Centralisation. A blockchain user’s keys are usually stored in a wallet application installed on a mobile device, and such a centralised approach to maintain keys may cause a single-point of failure. Once the device is lost or hacked, the user may lose the control of all keys.

Solution: To protect the security of a secret key, one can spilt that key into several pieces as its requirement, and define a regrouping threshold. The key pieces can be kept in any way the user prefers, e.g., wrote on a paper and locked in a safe box, given to family and friends, etc. When a key is lost, the user needs to regain enough key pieces (more than the preset regrouping threshold), and these pieces can help rebuild the complete key.

Consequences:

Benefits:

  • Tolerance of lost key. A lost key can be recovered by its shards, which provides great convenience to blockchain users.

  • Decentralisation. The shards are stored in a decentralised way, which reduces the risk of losing all shards in an attack.

  • Flexibility. An entity does not have to input all but just enough key shard when recombining a lost key.

Drawbacks:

  • Cost. Maintaining key shards needs extra vigor. If a key shard is lost, there is no way to restore it.

  • Security. Having multiple key shards provides multiple targets to attack.

Related patterns:

  • Master & Sub Key Generation (Section III-A1) Key Shards is applied to split and recombine entities’ keys.

  • Hot & Cold Wallet Storage (Section III-A2) The key splitting and recombining functionalities should be integrated into wallet applications.

  • Delegate List (Section III-B5) Key Shards can restore a lost key, while Delegate List aims to replace a compromised key with a new one.

Known uses:

  • Parity141414https://www.parity.io/ For each private key of an account, Parity distributes 12-word phrase acting as an additional backup. If a user loses the private key, this phrase can help fully recover it.

  • Crypto++151515https://cryptopp.com/

    A free and open-source C++ class library of cryptographic algorithms and schemes, which implements the Shamir’s Secret Sharing scheme: spliting up a secret into defined number of pieces, and restoring the original secret when given enough secret pieces.

Iii-B DID Management Patterns

Iii-B1 Identifier Registry

Summary: The identifier registry maintains bindings between an identifier and the address of an identity attribute (e.g. name, profile, picture). Fig. 7 is a graphical representation of the pattern.

Fig. 7: Identifier Registry Pattern

Context: Identity is defined as sets of attributes related to an entity161616https://www.iso.org/standard/77582.html. In software applications, identity attribute data needs to be accessed for a specific purpose. An identifier is a globally unique persistent series of digits and/or characters that is used to uniquely identify an entity (e.g. human, organisation, device) within one domain and can be used to retrieve the storage location of the identity attribute data. A Decentralised Identifier (DID) is a new type of identifier which is designed for cryptographically verifiable self-sovereign identity.

Problem: In traditional centralised software systems, mappings between an identifier and the identity data storage location is maintained by a centralised single authority which may become a potential single point of failure.

Forces: The problem requires balancing the following forces:

  • Upgradability. The need to upgrade identity data over time is ultimately necessary for software applications.

  • Scalability. Blockchain provides limited scalability because data is replicated across all nodes and kept permanently.

  • Cost. Storing data to blockchain may have monetary cost (if choosing a public blockchain), and also occupies the physical storage of all participating nodes.

Solution: Implementing an identifier registry designed as a smart contract to maintain bindings between an identifier and the location of associated off-chain identity data attributes. This identifier registry smart contract is the main entry point for accessing the attributes of an identity, which can map each identifier to a storage (e.g. IPFS, Dropbox, etc.) location for the respective identity attributes (e.g. an IPFS hash linking to the IPFS storage location containing the user’s identity attributes). Only the identifier owner is allowed to update the storage location of identity attributes. Each identifier points to an identifier document which describes how to use that specific identifier, e.g. public keys used for digital signatures, service endpoints for interaction.

Consequences:

Benefits:

  • Upgradability. Through the cryptographic access controls built into the blockchain, it is guaranteed that only the owner of the identity (i.e. the key owner) has the right to modify the data reference in identifier registry.

  • Scalability. The data structure of identifier registry is simple and lightweight, which only stores identifiers and locations of identity attributes.

  • Cost. If a public blockchain is used, the cost is low since the data size of identifiers and identity storage locations is fixed.

Drawbacks:

  • Integrity. The off-chain identity data store might not be as secure as blockchain. The raw data may be changed without authorisation. If IPFS is used for identity data storage, the change will be detected. However, without additional measures, it will neither be possible to recover the original data nor to prevent the change from happening in the first place.

  • Data loss. Since the raw data is stored off-chain, it may be deleted or lost.

Related patterns:

  • Multiple Registration (Section III-B2) An entity can register multiple identifiers at once in Identifier Registry.

  • Blockchain & Social Media Account Pair (Section III-B3) Identifier Registry maintains the mapping between an entity’s on-chain identity and social media.

  • Dual Resolution (Section III-B4) Entities resolve each other’s identifiers in Identifier Registry.

  • Delegate List (Section III-B5) Predefined delegates can change the binding key of a compromised identifier.

  • Master & Sub Key Generation (Section III-A1) Entities register identifiers in Identifier Registry through their sub-keys.

  • Content-Addressable Storage Pattern [19] Identifier Registry is similar to Content-Addressable Storage Pattern, storing raw data off-chain while publishing a reference in smart contract.

  • Flyweight Pattern [20] Identifier Registry and Flyweight Pattern both include a registry to maintain the mapping of identifiers and the respective reference pointing to off-chain data.

Known uses:

  • uPort2 The registry contract maintains mappings between a uPort identifier and an IPFS hash linking to a data structure storing an entity’s attributes.

  • Sovrin171717https://sovrin.org/ Sovrin offers a registry for decentralised identifiers and the associated public keys and communications endpoints. The operations (i.e. registration, update, resolution, and revocation) are all determined by the Sovrin protocol.

  • Jolocom181818https://jolocom.io/ Jolocom distributed identity system integrates Ethereum blockchain and Interplanetary File System (IPFS). A deployed smart contract maintains the mapping from a DID to the corresponding DDO stored in IPFS.

Iii-B2 Multiple Registration

Summary: Each entity can register a unique identifier for every relationship (i.e. every identity) they have. Fig. 8 is a graphical representation of the pattern.

Fig. 8: Multiple Registration Pattern

Context: An identifier is used to uniquely identify an entity and to retrieve the identity attribute data.

Problem: Sending all transactions using a single identifier has serious privacy implication for an entity since these transactions can be correlated to expose all the identities this entity holds.

Forces: The problem requires balancing the following forces:

  • Transparency. All the historical transactions on blockchain can be accessed by every participant within the same blockchain network. The transactions on a public blockchain are also accessible to everyone on the internet.

  • Security. There is no standard approach to protect or recover users’ secret keys.

Solution: Each entity can establish a unique identifier for every relationship (i.e. every identity) they have, which allows keeping interactions with one entity entirely separate from any other entity. For example, the relationship a person builds with a hospital is completely separate to the one that is established with a university. Neither the hospital nor the university could proactively use the identifiers to correlate this person’s activities.

Consequences: Benefits:

  • Privacy. This pattern tackles with the nature transparency of blockchain to some extent, as an entity’s activities in different identity relationships can hardly be correlated.

  • Availability. The loss of signing key of one identifier does not affect the other identifiers.

Drawbacks:

  • Cost. Compared to a single identifier, multiple identifiers cost more for identifier registration and updates.

Related patterns:

  • Identifier Registry (Section III-B1) Registered identifiers are stored in Identifier Registry.

  • Master & Sub Key Generation (Section III-A1) Entities use different sub-keys to conduct Multiple Registration.

Known uses:

  • Sovrin17 Sovrin suggests users to use a separate identifier for every relationship. Consequently, if a relationship suffers a breach and the identifier is compromised, the user can still have normal interactions in other relationships.

  • Blockstack191919https://blockstack.org/ Blockstack allows entities to create as many identities as they want. Each identity is represented by an identifier and a secret key. Entities can utilise their identities to sign in different decentralised applications.

  • DAML202020https://daml.com/ In DAML ledger, participant nodes can use human-readable strings as identifiers to identify themselves. A real-world entity is able to possess multiple identifiers in the same ledger network to denote different identities.

Iii-B3 Blockchain & Social Media Account Pair

Summary: A bidirectional binding is established between social media profile and blockchain-based identity. Fig. 9 is a graphical representation of the pattern.

Fig. 9: Blockchain & Social Media Account Pair Pattern

Context: Social media profiles can be considered as one of the most important assets, which are critical to achieve more exposure on the internet, attract more attention, or improve online reputation. The trustworthiness of a social media profile can be improved by verifying the account using traditional identity issued by some central authority. On the other hand, blockchain provides a decentralised infrastructure for self-sovereign identity, where entities are in control over their own identities. To ensure the trustworthiness, some identity blockchains (e.g. Hyperledger Indy) are designed as public permissioned blockchains, which are governed by a group of participants.

Problem: In addition to verification by some certain people or central authorities, a user can link his/her social media profile (e.g. Twitter) to his/her identity registered on blockchain to improve the trustworthiness of both social media profile and blockchain-based identity. The problem here is how to bind a social media profile with the corresponding blockchain-based identity to ensure mapping.

Forces: The problem requires balancing the following forces:

  • Authoritative source. A 1-to-1 mapping is required between a social media account and its corresponding blockchain-based identity.

  • Security. The mapping needs to be stored securely from tampering.

  • Verified accounts. Social media applications verify accounts via traditional identity documents.

Solution: An entity can create an attribute of social media in the identifier document. Signing the attribute with the blockchain signing key creates a claim that the blockchain-based identity controls the social media account. The attribute also contains a URL which links to a social media post stating that the social media account also controls this particular blockchain identity. Thus, a two-way link is established for connecting the blockchain identity with the social media profile. The two directional binding makes sure that that the social media profile and blockchain-based identity have a 1-to-1 mapping.

Consequences:

Benefits:

  • Authoritative source. The trustworthiness of social media account and blockchain-based identity can both be improved by binding them together.

  • Secure storage. Blockchain provides a secure data store through distributed ledger technology.

  • Verified accounts. A social media verifies the legal identity of a user.

Drawbacks:

  • Trustworthiness. The trustworthiness of social media account relies on the verification process while the the trustworthiness of blockchain-based identity depends on the trustworthiness of trusted participants.

Related patterns:

  • Identifier Registry (Section III-B1) Identifier Registry maintains the mapping of an entity’s on-chain identity and social media.

Known uses:

  • Onename212121https://www.onename.com/ Onename is a registrar for Blockstack which is a decentralised naming and storage system. With Onename, a user can easily register a blockchain ID and create corresponding profile on Blockstack, and completely has control of his/her blockchain ID and profile. Users can can link their Blockstack profiles with existing online social media accounts (Twitter, Facebook, Github, etc), and also embed their blockchain ID on their social media posts.

Iii-B4 Dual Resolution

Summary: To establish interactions, two entities can mutually acquire each other’s DDO to access information necessary for verification (e.g., public key) and communication (e.g., service endpoints for provided services). Fig. 10 is a graphical representation of the pattern.

Fig. 10: Dual Resolution Pattern

Context: In self-sovereign identity, entities interact with each other.

Problem: When two or more entities want to establish interactions (e.g., for business purposes), each entity first needs to determine the target entity’s basic information and ways of communicating before going further.

Forces: The problem requires balancing the following forces:

  • Interoperability. For two parties to interact, the ways of communication have to be interoperable.

  • Independence. The interacting entities should remain independent of each other and one should not be able to pry on the other.

Solution: A DDO contains verification methods (i.e. public keys) and service endpoints (e.g., messaging service details) which can be utilised by an entity to establish interactions with the corresponding DID owner. Before any formal activity between two entities in a relationship, they should first mutually resolve each other’s DID and obtain the interaction information stored in DDO. Such a process is considered as “Dual Resolution” and it forms the first step for any entity to establish an interoperation with its target entity.

Consequences:

Benefits:

  • Interoperability. The Dual Resolution process allows the interacting entities in a relationship to obtain and check each other’s basic information on verification and services provided for interoperability.

  • Independence. Each DDO stores necessary interaction information only for its corresponding DID, hence, an entity’s different identities are independent from each other and cannot be correlated.

Drawbacks:

  • Privacy. It is possible for an entity to store in DDO extra information about itself other than what is necessary for communication, such as social media accounts, personal websites. Doing so may increase the trustworthiness of the entity as more identity information is shared with others. However, this also increases the risk of unwillingly revealing the entity’s personal information.

Related patterns:

  • Identifier Registry (Section III-B1) Entities resolve each other’s identifiers in Identifier Registry.

Known uses: The existing self-sovereign identity applications do not directly point out this feature as a provided functionality, but the users need to resolve each other’s DID when there is potential interaction.

Iii-B5 Delegate List

Summary: Each identifier maintains a list of delegates that can help the user recover the identity. Fig. 11 is a graphical representation of the pattern.

Fig. 11: Delegate List Pattern

Context: Each identity has a key pair to authenticate the transactions initiated by the user by means of digital signatures.

Problem: A master-key may be compromised/stolen by malicious hackers. A compromised master-key results in the loss of ownership over all sub-keys and corresponding identifiers. The hacker may utilise the identifiers to further steal the entity’s identity data.

Forces: The problem requires balancing the following forces:

  • Compromised private key. Authentication can be achieved by using digital signatures. Currently, many blockchain platforms do not provide a sound mechanism to recover compromised keys, thus key theft results in permanent loss of control over related identifiers.

  • Non-reusability. A compromised identity can be claimed of no more use, but its owner has to spent extra time, money, and energy to re-register a new identifier and rebuild all corresponding relationships.

Solution: Delegate List relies on a web of trust architecture. This requires an identity owner to designate its own set of trustees that the owner trusts to assist in identity ownership update when the owner asks for it. An identifier maintains a list of recovery delegates and an update threshold that can help the user recover identity. These delegates can be individuals (such as family members or friends) or organisations (such as banks). If key loss happens, the original identity owner needs to request for ownership update using a new key pair, and a minimum number of the trustees (e.g. 2 out of 3) must sign a new identity record transaction respectively. When there are enough confirmations (i.e. reaching the threshold) of the new key pair, the ownership of the identifier is updated and thus the identity is recovered. A timelock period can be specified to prevent an attacker who tries to compromise an identity owner’s key and immediately change the owner’s identity records, including his/her designated trustees to prevent identifier ownership recovery.

Consequences:

Benefits:

  • Tolerance of compromised private key. This pattern can guarantee security by maintaining a group of delegates who can confirm a new key proposed by the identity owner to replace the compromised key, improving the tolerance of key compromise.

  • Reusability. The ownership of a compromised identity can be recovered and then put into use again, which mitigates the burden of rebuilding another same identity.

Drawbacks:

  • Cost. Recovering an identity requires setting up a delegate list in advance, and sending update requests/votes after the identity is compromised. Each operation sends a transaction to blockchain.

Related patterns:

  • Identifier Registry (Section III-B1) Delegates related to a specific identifier are stored in Identifier Registry.

  • Hot & Cold Wallet Storage (Section III-A2) When being integrated into wallet applications, predefined delegates can replace key ownership if a key is compromised.

  • Key Shards (Section III-A3) Key Shards can restore a lost key, while Delegate List aims to replace a compromised key with a new one.

  • Multiple Authorisation [13] Delegate List is derived from Multiple Authorisation that the change of a lost secret key in a DID requires enough confirmation.

  • Mutex Pattern [21] Mutex Pattern can be applied to Delegate List, ensuring that no any other operation can be conducted within an update procedure.

Known uses:

  • uPort2 In uPort, the user’s mobile device is the only place where stores the private key that controls a uPortID. To avoid the key loss issue caused by loss or theft of the mobile devices, users must nominate a group of delegates who can vote to replace the public key. Once a quorum is achieved by the delegates on the newly proposed public key, the lost public key is replaced with the new public key.

  • Sovrin17 Similar to uPort, Sovrin provides a key recovery mechanism for key recovery that relies on the user selecting a group of delegates. When the user requests the delegates to assist key recovery, a specified quorum of delegates must sign a new identity record transaction that validator nodes must verify.

  • Baidu Cloud222222https://cloud.baidu.com/ Baidu implemented its SSI solution via Quorum, an Ethereum-based DLT. In each user’s DDO, a “recovery” attribute defines a list of public keys to recover the on-chain identity.

Iii-C Credential Design Patterns

Iii-C1 Selective Content Generation

Fig. 12: Selective Content Generation Pattern

Summary: An issuer generates a customised credential according to a holder’s specific requirements about credential contents. Fig. LABEL:credential (a) is a graphical representation of the pattern.

Context: A verifier requires certain information to prove a holder’s identity, thus, a holder only needs to share a credential with necessary data to the verifer.

Problem: If issuers publish general credentials to holders, a verifier can learn all identity data involved when only some particular attributes are needed. For instance, if a person shows his/her ID to identify the age, his/her address is presented either. This may cause data leak as extra information is provided.

Forces: The problem requires balancing the following forces:

  • Privacy. The disclosed credential should contain minimum amount of data necessary to identify some certain aspects of its holder.

  • Specific requirements. Each verifier may have specific requirements on inspecting a holder’s identity facts.

Solution: Selective Content Generation allows issuers to decide what identity attributes are contained in a credential. An issued credential needs to satisfy the target verifier’s specific requirements of holder’s identity, without revealing extra data. A credential with selective content disclosure can be generated via the following approaches232323https://w3c.github.io/vc-imp-guide/.

  • Atomic credentials. An issuer generates multiple credentials and each one only contains exactly one identity attribute about the holder. Consequently, the holder can flexibly disclose those required credentials to a verifier.

  • Selective disclosure signatures. A general credential is issued to a holder, but some special signature schemes (e.g. Camenisch-Lysyanskaya signatures) allow them to only reveal necessary information.

  • Hashed values. A general credential consists of multiple identity attributes, but each one is hashed with different nonce. When verifying a credential, a verifier can only validate those with the actual values provided by the holder, but cannot determine other hashed values.

  • Zero-knowledge proof. When proving certain identity attributes, a holder can protect its information by giving a range instead of precise value (e.g., age is over 18).

Consequences:

Benefits:

  • Data minimisation. A credential with selective content can disclose the identity data which satisfy the verifier’s individual requests while keeping other identity data private.

Drawbacks:

  • Cost. Determining the identity data within a credential requires additional communication between holders and verifiers for learning the verification requirements, and between holders and issuers for discussing the credential content. Moreover, maintaining multiple credentials with different contents can incur extra costs.

Related patterns:

  • Time-Constrained Access (Section III-C2) Selective Content Generation can work collaboratively with Time-Constrained Access, to generate credentials with fine-grained specifications.

  • One-Off Access (Section III-C3) Selective Content Generation can also work collaboratively with One-Off Access, to generate credentials with fine-grained specifications.

  • Blockchain Anchor (Section III-C4) Off-chain credential contents need to be hashed and stored on-chain to preserve integrity.

Known uses:

  • uPort2 A uPort user encrypts identity attributes using a symmetric encryption key before disclosure. The symmetric encryption key is then individually encrypted using a public encryption key owned by the other interacting party.

  • Sovrin17 A cryptographic technique known as a zero-knowledge proof is utilised in Sovrin. A verifier can check the authentication of an identity though the public key of the issuer, but never learns the actual data.

Iii-C2 Time-Constrained Access

Fig. 13: Time-Constrained Access Pattern

Summary: A holder can share a link which is redirected to the credential content only for a restricted accessible time period. The verifier can only access the credential content within the determined time period. Fig. LABEL:credential (b) is a graphical representation of the pattern.

Context: Usually an identification process lasts for a certain time period. After proving the identity of an entity, the presented credential has accomplished its mission and should not be accessed again.

Problem: After receiving a credential, a verifier then has the ability to access, read, and verify certain identity data of the holder. If the credential is long-term or even permanently effective, the verifier then can verify the credential after current identification process, which means that it can still access and check the holder’s identity data when there is not a legitimate permission for proving the identity, resulting identity data leak.

Forces: The problem requires balancing the following forces:

  • Privacy. A holder’s identity information should not be accessed or verified when the current identification process is finished.

  • Inflexibility. Verifiers have their own identification processes, which may take different amounts of time. The cost to generate and maintain credentials for the process inconsistency is huge.

Solution: A holder is able to generate an identifiable link, and define its accessible period (e.g. certain days). The link can redirect to a page presenting credential content. Afterwards, the holder can share the time-constrained link to verifiers instead of the original credential itself. Within the predefined accessible period, a verifier can visit and verify the credential for identification without limit. Nevertheless, when the link is expired, there is no approach for the verifier to obtain credential content again.

Consequences:

Benefits:

  • Privacy. A holder can determine the accessible period of a shared link, which ensures that the holder’s identity information can only be fetched within a particular identification process. An expired credential cannot be verified again. Consequently, a malicious verifier is unable to further utilised the identity data.

  • Flexibility. Shared links does not affect the original credential. Consequently, this pattern can be flexibly applied to a long-term effective credential, links with different accessible periods can be sent to different verifiers.

Drawbacks:

  • Cost. Storing the credential replicas requires more storage.

  • Privacy. A malicious verifier may take a photo of the credential when accessing it, then it has the credential content even if the shared link is expired. Although the compromised credential cannot reveal up-to-date information of the holder, the attacker still maintains historical identity attributes of the holder to some extent.

Related patterns:

  • Selective Content Generation (Section III-C1) Time-Constrained Access can work collaboratively with Selective Content Generation, to generate credentials with fine-grained specifications.

  • One-Off Access (Section III-C3) One-Off Access can be seen as a derivative of Time-Constrained Access under an extreme condition.

Known uses:

  • Snapchat242424https://www.snapchat.com/ Snapchat is a social media in which users can share their photos and videos. Every shared photo or video is automatically deleted after a certain amount of time.

  • Snappass252525https://oneoffsecret.com/ Snappass is a website where users can generate secret information and share it by URL. A user can set a valid time period to each secret, within which the secret information can be read.

Iii-C3 One-Off Access

Fig. 14: One-Off Access Pattern

Summary: A holder can share a “one-off” link which is redirected to the credential content one time only. This may be used to satisfy a temporary identification request. Fig. LABEL:credential (c) is a graphical representation of the pattern.

Context: A verifier does not require a long-term effective credential but only needs to check the identity of a holder once for a specific purpose.

Problem: Sometimes an identification process does not require a strict verification procedure, but only needs to check the identity for once. For instance, travelling by train/airplane or going to a theme park only asks for checking credentials before entering. If a holder presents a long-term effective link redirecting to the credential content, a malicious verifier may access the holder’s data illegally after identification process. This can be considered as an extreme version of Time-Constrained Access.

Forces: The problem requires balancing the following forces:

  • Privacy. A holder’s identity information should not be accessed or verified when the current identification process is finished.

  • Inflexibility. Using a long-term effective credential to satisfy a temporary credential request is not appropriate, as the holder cannot control the access to this credential after the temporary request.

Solution: A holder is able to generate an identifiable link, which redirects to a one-off page presenting the credential content. One-off links can be shared with verifiers on some special occasions. After being visited once, the link becomes invalid that no one can use it to access the credential content.

Consequences:

Benefits:

  • Privacy. The identity attributes presented via one-off links can only be read and verified for once. Similar to Time-Constrained Access, malicious verifiers cannot further violate holders’ privacy via expired links. Information within the link becomes unauthentic as there is no approach to verify it.

  • Flexibility. One-Off Access defines an extremely short period to visit the credential content, satisfying temporary identification requests.

Drawbacks:

  • Privacy. A malicious verifier may take a photo of the credential when accessing it, then it can read the content even if the one-off link is expired. Although information within an expired link can no longer be used to prove anything, this still can cause a privacy issue for the holder.

Related patterns:

  • Selective Content Generation (Section III-C1) One-Off Access can work collaboratively with Selective Content Generation, to generate credentials with fine-grained specifications.

  • Time-Constrained Access (Section III-C2) One-Off Access can be seen as a derivative of Time-Constrained Access under an extreme condition.

Known uses:

  • Snapchat24 Snapchat can automatically delete user-uploaded photos or videos when once read, according to the user’s setting.

  • Snappass25 In Snappass, user-defined secret information are delete and cannot be recovered after being read for once.

Iii-C4 Blockchain Anchor

Summary: Instead of storing everything on-chain, one can periodically send the unique hash value of off-chain data to blockchain. Fig. 15 is a graphical representation of the pattern.

Fig. 15: Blockchain Anchor Pattern

Context: Blockchain’s nature configurations may limit its performance when facing a large number of transactions.

Problem: Blockchain can ensure data integrity via storing data on-chain, but it costs real money to process the transaction in many public blockchain networks. In addition, according to the nature consensus mechanism, blockchain generates a block in a fixed period (i.e. block interval), which only includes a restricted number of transactions due to the block size. Consequently, blockchain’s performance may be restricted when users frequently initiate transactions.

Forces: The problem requires balancing the following forces:

  • Cost. In a permissionless blockchain network, sending a transaction charges real money, thus, frequently storing data to blockchain is expensive. Even in a permissioned blockchain, each full node maintains a local replica of all historical transactions, handling plenty of transactions is also costly for physical storage.

  • Scalability. Blockchain has nature performance restriction that within a block interval, only a limited number of transactions can be processed while others need to wait in the transaction pool. Utilising blockchain to record every data change may result in the accumulation of waiting transactions in the pool.

Solution: Blockchain Anchor relies on the hashing technology that one does not need to store everything on-chain, but periodically sends the unique hash value of off-chain data to blockchain.

Consequences:

Benefits:

  • Cost. Anchoring reduces the cost of applying blockchain in terms of monetary payment and physical storage, as there are less transactions sent to blockchain.

  • Scalability. Anchoring keeps complex and tedious business processes off-chain, which enhances the scalability of blockchain-based systems that blockchain only needs to record the hash values of all kinds of data and files.

  • Opacity. Blockchain transactions are immutable and can be view by all participants. Thus, storing hash values rather than original information can preserve data privacy.

Drawbacks:

  • Opacity. Hash values are neither human-readable or can be restored into original files, which means that using anchoring may affect the transparency and auditability of on-chain data.

Related patterns:

  • Selective Content Generation (Section III-C1) Off-chain credential contents need to be hashed and stored on-chain to preserve integrity.

  • Off-Chain Data Storage [13] Blockchain Anchor works similarly as Off-Chain Data Storage, calculating the hash of raw off-chain and storing the hash values on-chain.

  • Low Contract Footprint Pattern [19] Blockchain Anchor works similarly as Low Contract Footprint Pattern, which concerns about the monetary cost and optimises the writing operations to blockchain.

Known uses:

  • Blockstack19 Blockstack allows entities to register off-chain decentralised identifiers. To prove the existence of these off-chain identifiers, the system collects hashes of corresponding files and writes the hash values to blockchain.

  • Chainpoint262626https://chainpoint.org/ Chainpoint is an open standard for creating a timestamp proof of any data, file, or process by generating a Merkle Tree, and publishing root of this tree to the Bitcoin blockchain.

  • Laava A blockchain-based system may need to serve different tenants simultaneously, who are not willing to expose private data to each other. Researchers from Data61 and Laava ID Pty. Ltd. designed a scalable platform architecture for multitenant blockchain-based systems [32], in which every tenant has an individual permissioned blockchain to maintain their own data, while all tenant chains are anchored into a main chain periodically.

Iv Conclusion

We view blockchain as a fundamental component of large-scale decentralised software systems. In self-sovereign identity, blockchain provides an underlying computing infrastructure and decentralised pseudonym mechanism. In this paper, we summarise and propose 12 different design patterns associated with the lifecycles of three main objects (i.e. key, decentralised identifier, and credential) in blockchain-based self-sovereign identity. The pattern collection is considered as a guidance for architects to better design blockchain-based self-sovereign identity systems.

References

References

  • [1] C. Allen, “The path to self-sovereign identity,” http://www.lifewithalacrity.com/2016/04/the-path-to-self-soverereign-identity.html, accessed 15-February-2020.
  • [2] M. Sporny, D. Longley, and D. Chadwick, “Verifiable credentials data model (expressing verifiable information on the web),” https://www.w3.org/TR/verifiable-claims-data-model/, accessed 15-February-2020.
  • [3] S. Banerjee, “Aadhaar: Digital inclusion and public services in india,” World Development Report, pp. 81–92, 2016.
  • [4] F. Tschorsch and B. Scheuermann, “Bitcoin and beyond: A technical survey on decentralized digital currencies,” IEEE Communications Surveys & Tutorials, vol. 18, no. 3, p. 464, 2016.
  • [5] M. Swan, Blockchain: Blueprint for a New Economy.   US: ” O’Reilly Media, Inc.”, 2015.
  • [6] G. P. Release, “Gartner survey reveals the scarcity of current blockchain deployments,” May 2018, accessed 15-February-2020. [Online]. Available: https://www.gartner.com/en/newsroom/press-releases/2018-05-03-gartner-survey-reveals-the-scarcity-of-current-blockchain-developments
  • [7] G. Meszaros and J. Doble, Pattern languages of program design 3.   Addison-Wesley Longman Publishing Co., Inc., 1997, p. 529–574.
  • [8] S. Nakamoto, “Bitcoin: A peer-to-peer electronic cash system,” https://bitcoinsv.io/bitcoin, 2008, accessed 15-February-2020.
  • [9]

    S. Omohundro, “Cryptocurrencies, smart contracts, and artificial intelligence,”

    AI Matters, vol. 1, no. 2, pp. 19–21, Dec. 2014. [Online]. Available: http://doi.acm.org/10.1145/2685328.2685334
  • [10] I. Modinis, “Common terminological framework for interoperable electronic identity management,” The 2005 Modinis IDM Study Team, 2005.
  • [11] M. Dabrowski and P. Pacyna, “Generic and complete three-level identity management model,” in 2008 Second International Conference on Emerging Security Information, Systems and Technologies.   IEEE, 2008, pp. 232–237.
  • [12] D. Reed, M. Sporny, D. Longley, C. Allen, R. Grant, and M. Sabadello, “Decentralized identifiers (data model and syntaxes for decentralized identifiers),” https://w3c-ccg.github.io/did-spec/, accessed 15-February-2020.
  • [13] X. Xu, C. Pautasso, L. Zhu, Q. Lu, and I. Weber, “A pattern collection for blockchain-based applications,” in Proceedings of the 23rd European Conference on Pattern Languages of Programs, 2018, pp. 1–20.
  • [14] Y. Liu, Q. Lu, X. Xu, L. Zhu, and H. Yao, “Applying design patterns in smart contracts,” 06 2018, pp. 92–106.
  • [15] Q. Lu and X. Xu, “Adaptable blockchain-based systems: A case study for product traceability,” IEEE Software, vol. 34, no. 6, pp. 21–27, November 2017.
  • [16] X. Xu, Q. Lu, Y. Liu, L. Zhu, H. Yao, and A. V. Vasilakos, “Designing blockchain-based applications a case study for imported product traceability,” Future Generation Computer Systems, vol. 92, pp. 399 – 406, 2019. [Online]. Available: http://www.sciencedirect.com/science/article/pii/S0167739X18314298
  • [17] Q. Lu, X. Xu, Y. Liu, I. Weber, L. Zhu, and W. Zhang, “ubaas: A unified blockchain as a service platform,” Future Generation Computer Systems, vol. 101, pp. 564 – 575, 2019. [Online]. Available: http://www.sciencedirect.com/science/article/pii/S0167739X18319873
  • [18] M. Bartoletti and L. Pompianu, “An empirical analysis of smart contracts: platforms, applications, and design patterns,” in International conference on financial cryptography and data security.   Springer, 2017, pp. 494–509.
  • [19] J. Eberhardt and S. Tai, “On or off the blockchain? insights on off-chaining computation and data,” in European Conference on Service-Oriented and Cloud Computing.   Springer, 2017, pp. 3–15.
  • [20] P. Zhang, J. White, D. C. Schmidt, and G. Lenz, “Applying software patterns to address interoperability in blockchain-based healthcare apps,” arXiv preprint arXiv:1706.03700, 2017.
  • [21] M. Wohrer and U. Zdun, “Smart contracts: security patterns in the ethereum ecosystem and solidity,” in 2018 International Workshop on Blockchain Oriented Software Engineering (IWBOSE).   IEEE, 2018, pp. 2–8.
  • [22] A. Mühle, A. Grüner, T. Gayvoronskaya, and C. Meinel, “A survey on essential components of a self-sovereign identity,” Computer Science Review, vol. 30, pp. 80–86, 2018.
  • [23] S. Y. Lim, P. T. Fotsing, A. Almasri, O. Musa, M. L. M. Kiah, T. F. Ang, and R. Ismail, “Blockchain technology the identity management and authentication service disruptor: a survey,” International Journal on Advanced Science, Engineering and Information Technology, vol. 8, no. 4-2, pp. 1735–1745, 2018.
  • [24] P. Windley and D. Reed, “Sovrin: A protocol and token for self-sovereign identity and decentralized trust),” https://sovrin.org/wp-content/uploads/Sovrin-Protocol-and-Token-White-Paper.pdf, accessed 15-February-2020.
  • [25] C. Lundkvist, R. Heck, J. Torstensson, Z. Mitton, and M. Sena, “Uport: A platform for self-sovereign identity,” URL: https://whitepaper. uport. me/uPort_ whitepaper_DRAFT20170221. pdf, 2017.
  • [26] M. Ali, J. Nelson, R. Shea, and M. J. Freedman, “Blockstack: A global naming and storage system secured by blockchains,” in 2016 USENIX Annual Technical Conference, 2016, pp. 181–194.
  • [27] W. Gräther, S. Kolvenbach, R. Ruland, J. Schütte, C. Torres, and F. Wendland, “Blockchain for education: lifelong learning passport,” in Proceedings of 1st ERCIM Blockchain Workshop 2018.   European Society for Socially Embedded Technologies (EUSSET), 2018.
  • [28] X. Liang, J. Zhao, S. Shetty, J. Liu, and D. Li, “Integrating blockchain for data sharing and collaboration in mobile healthcare applications,” in 2017 IEEE 28th Annual International Symposium on Personal, Indoor, and Mobile Radio Communications (PIMRC).   IEEE, 2017, pp. 1–5.
  • [29] R. Soltani, U. Trang Nguyen, and A. An, “A new approach to client onboarding using self-sovereign identity and distributed ledger,” in 2018 IEEE International Conference on Internet of Things (iThings) and IEEE Green Computing and Communications (GreenCom) and IEEE Cyber, Physical and Social Computing (CPSCom) and IEEE Smart Data (SmartData), July 2018, pp. 1129–1136.
  • [30] Q. Stokkink and J. Pouwelse, “Deployment of a blockchain-based self-sovereign identity,” in 2018 IEEE International Conference on Internet of Things (iThings) and IEEE Green Computing and Communications (GreenCom) and IEEE Cyber, Physical and Social Computing (CPSCom) and IEEE Smart Data (SmartData).   IEEE, 2018, pp. 1336–1342.
  • [31] M. Takemiya and B. Vanieiev, “Sora identity: Secure, digital identity on the blockchain,” in 2018 IEEE 42nd Annual Computer Software and Applications Conference (COMPSAC), vol. 2.   IEEE, 2018, pp. 582–587.
  • [32] I. Weber, Q. Lu, A. B. Tran, A. Deshmukh, M. Gorski, and M. Strazds, “A platform architecture for multi-tenant blockchain-based systems,” in 2019 IEEE International Conference on Software Architecture (ICSA), March 2019, pp. 101–110.