Design Patterns for Blockchain-based

Self-Sovereign Identity
Yue Liu Qinghua Lu
College of Computer Science and Technology, Data61, CSIRO, Australia
China University of Petroleum (East China), China [email protected]
[email protected]

Hye-Young Paik Xiwei Xu

School of Computer Science and Engineering, Data61, CSIRO, Australia
University of New South Wales, Australia [email protected]
arXiv:2005.12112v3 [cs.CR] 16 Jun 2020

[email protected]

Abstract—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
Holder
any intermediary. Blockchain is an enabling technology for
building self-sovereign identity systems by providing a neutral Issuing a Presenting a
and trustable storage and computing infrastructure and can be credential credential
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
Verifying a credential
systems to help the architects understand and easily apply the Issuer Verifier
concepts in system design. Based on the lifecycles of three main
objects involved in self-sovereign identity, we categorise the pat- Fig. 1. Identity management overview
terns into three groups: key management patterns, decentralised
identifier management patterns, and credential design patterns.
The proposed patterns provide a systematic and holistic guide establishing a trust relationship with an issuer, anyone can be
for architects to design the architecture of blockchain-based self-
sovereign identity systems. a verifier (e.g. an employer) of a claim. A verifier requests
Index Terms—Blockchain, Self-sovereign Identity, Pattern, Ar- for a specific credential (e.g. birth certificate of a person), and
chitecture, Identity Management verifies the validity of the credential via the issuer’s signature.
Identity management is challenging if holders do not have
I. I NTRODUCTION a full control over their identity data, since the data are usu-
A legal entity’s identity (i.e., an individual or an organisa- ally maintained at third-party issuers’ sites (e.g., government
tion) can be represented using a set of attributes [1] associated agency). An issuer may disclose identity data to a third-party
with the entity (such as name and address). Identity manage- without the holder’s knowledge. Furthermore, the issuer may
ment includes maintaining the identity data and their access be compromised, consequently resulting in identity informa-
control. Fig. 1 depicts a conceptual overview of the main roles tion leakage (e.g., Aadhaar data leakage [3]). In addition,
and their relationships in identity management. Specifically, current credential verification processes are usually complex,
an entity who registers an identifier in a particular system costly and time consuming (e.g., taking weeks for verifying
is considered as a holder (e.g. legal individual / organisation a degree). It is also possible that a significant process incon-
name) of the identity data (e.g. date of birth, and role within sistency occurs within current identity management systems
the organisation) associated with the identifier, while all the as individuals must seek to verify (and re-verify) identities at
identity data of the holder are stored with an issuer (e.g. a multiple points with different service providers1 .
government agency). Note that the holder of an identifier can The concept of self-sovereign identity allows holders to
sometimes also be an issuer to identify itself. A credential is retain ownership of their identities and control over how their
a verifiable claim, which includes some facts that is attested identity data is used [1]. Such a notion is increasingly popular,
and digitally signed by the issuer about the holder [2]. The particularly in our digitised and privacy-sensitive society.
fact in a credential can be the holder’s identity data (e.g. date However, for legal identities in the real world, we argue that
of birth) or other types of factual data (e.g. a GPA). After self-sovereign identity does not mean holders can control all

Qinghua Lu is the corresponding author. 1 http://fsi.gov.au/publications/final-report/

aspects of their identity that are maintained by the issuers. II. BACKGROUND AND R ELATED W ORK
For example, holders are not able to include any additional A. Blockchain and Smart Contracts
information in their identity information (e.g., a name other
Blockchain is an emerging paradigm of building next gen-
than their legal name in their academic transcript), or remove
eration applications in a decentralised way, with two core
existing restrictions imposed upon registration. Rather, what
technologies: 1) a distributed ledger, and 2) a computing
is achievable via self-sovereign identity is that holders can
infrastructure.
control the use of their identity data without involving any
The distributed ledger maintained in a blockchain network
intermediary [1]. For example, through an effective implemen-
can verify and store transactions [4], without relying on any
tation of a digital wallet for self-sovereign identity to store
central trusted authority, while all participating nodes need to
and manage credentials, holders who own several identifiers
reach consensus on transactional data states to achieve trust. In
can choose to present any credentials associated with any of
the consensus mechanism proposed by Nakamoto, an honest
the identifiers to verifiers, without having to go through the
majority of nodes is assumed, achieving trust without a third
issuers.
party intermediary through game theoretic incentives [8]. The
Blockchain is an innovative distributed ledger technology data structure of blockchain is a list of identifiable blocks, and
(DLT) for building new forms of decentralised software ar- all the blocks are linked to the previous block and thus form
chitecture, which enables agreements on transactional data a chain. The blocks are containers for storing transactions,
sharing across a large network of untrusted participants, which are identifiable packages carrying the changing states
without relying on a central trusted authority [4]. Identity of data.
management is considered to be one of the most innovative Blockchain provides a programmable computing infrastruc-
applications of blockchain technology [5], as blockchain can ture via smart contracts, which are essentially the programs
be used to build an infrastructure or ecosystem to realise self- deployed and run on blockchain [9]. Smart contracts can
sovereign identity, where no intermediary is needed. Many express triggers, conditions to enable complex business logic.
organisations (e.g., start-ups, enterprises, and governments) are Ethereum is currently the most widely-used blockchain that
currently exploring how to leverage blockchain technology to supports Turing-complete smart contracts. The primary smart
implement self-sovereign identity solutions, examples include contract language used on Ethereum blockchain is Solidity4 .
uPort2 and Hyperledger Indy3 . However, as blockchain and Integrating blockchain technology into current software
self-sovereign identity are both emerging technologies with architecture brings both quality improvements and also
limited documentation, there can be a steep learning curve blockchain’s nature limitations. For instance, immutability and
for developers to design the architecture of blockchain-based transparency can ensure data integrity, while the underlying
self-sovereign identity systems. A recent survey by Gartner decentralisation enhances the availability of whole system.
[6] points to the current gap and scarcity of blockchain skills Nevertheless, data privacy and scalability are the main two
in the market. Having a systematic and holistic guidance limitations of public blockchains. Data privacy on public
for the architectural design of blockchain-based self-sovereign blockchain is limited because there is no privileged user,
identity systems can assist system architects and developers. and every participant can join the network to access all
In this regard, this paper presents 12 design patterns for the information on blockchain and validate new transactions.
the design of blockchain-based self-sovereign identity appli- There are scalability limits on (i) the size of the data on
cations. To correctly capture the use of the identities and blockchain, (ii) the transaction processing rate, and (iii) the
associated credentials, we analysed the lifecycles of the three latency of data transmission and commits, which is affected
key objects in self-sovereign identity (i.e., key, identifier, by the chosen consensus protocol. Furthermore, the number
and credential), and classified the patterns into three groups of transactions included in each block is also limited by the
accordingly: key management patterns, decentralised identifier bandwidth of nodes participating in the network.
management patterns, and credential design patterns. The
B. Self-Sovereign Identity
proposed patterns are connected to different state transitions in
the lifecyles of the three key objects, which provides a guide Identity management is a fundamental requirement in our
to the architects and developers when the design patterns can digitised society, since every entity is likely to have multiple
be effectively used. identities for different people or organisations [10], [11].
However, Internet users do not generally have complete control
The remainder of this paper is organised as follows.
over their digital identities stored by third-party issuers (e.g.
Section II discusses related work. Section III presents the
social networking sites or employers), which may disclose
design patterns of blockchain-based self-sovereign identity
one’s identity information to others without their permission
applications with the extended pattern form in [7]. Section IV
and/or knowledge.
concludes the paper.
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
2 https://www.uport.me/
3 https://www.hyperledger.org/projects/hyperledger-indy 4 https://solidity.readthedocs.io/
 Selective Disclosure - Lifecycle of a Credential
Selective Disclosure - Selective Period
Selective Content (One-Off,
Time-Constrained)

Requested Generated Stored Disclosed

Identifying Revoked /
entities Blockchain Anchor Verified
Expired

Lifecycle of a DID
Multiple
Resolved Dual Verification Identifier Registry
Registration

Blockchain &
Registered Social Media Revoked
Account Pair

Updated Delegate List

Key-DID Key Shards - Lifecycle of a Key

mapping Shard Distribution

Lost /
Created Stored Deleted
Compromised

Master & Sub Hot & Cold Key Shards -

Key Generation
Recovered
Wallet Storage Shard Combination

Interconnection Enabler of a
State transition State Design pattern
between objects design pattern

Fig. 2. Lifecycles of three main objects in self-sovereign identity

devices or cloud, and interact with multiple service providers. C. Related Work
To implement self-sovereign identity, the W3C Community
Group specifies a standard for decentralised identifier (DID) Previous works have characterised and applied design pat-
[12], which contains human-readable information and can terns for smart contract and blockchain applications [13],
be used across different platforms. A DID is a URL that [14]. originChain [15], [16] adopts design patterns for data
refers to an entity for trusted interactions. Each DID bonds management and smart contract design to improve the system
to a DID document (DDO) which describes how to use the adaptability. uBaaS encapsulates design patterns as services
specific DID through some given properties, such as context, to facilitate the development of blockchain-based applications
id, public key, and service endpoint. context expresses the [17]. Bartoletti and Pompianu [18] conduct an empirical
system environment for information exchange between two analysis of smart contracts, in which they collected hundreds
DIDs; id is the DID described by this DDO; publicKey is for of smart contracts and divided them into nine categories:
digital signatures and cryptographic operations; and service token, authorisation, oracle, randomness, poll, time constraint,
denotes service endpoints used for interactions among DIDs. termination, math and fork check. Eberhardt and Tai [19]
A DID and its corresponding DDO do not contain any identity propose five patterns, including challenge response pattern,
data which are stored in personal devices or database owned by off-chain signatures pattern, content-addressable storage pat-
the identity service providers. A credential [2] is a verifiable tern, delegated computation pattern, and low contract footprint
claim, carrying particular identity information attributes that pattern, mainly focusing on the separation of on-chain and
an issuer provides to attest to some specific characteristics of off-chain for data and computation. Zhang et al. [20] share
an entity. Within self-sovereign identity, entities are able to the experience of designing a blockchain-based healthcare
issue digitally-signed credentials about themselves and others platform, to which they apply four object-oriented software
linked to their DIDs, and these credentials can be verified patterns to improve the application scalability. Wohrer and
by anyone else. Blockchain has been widely recognised as a Zdun [21] collect six design patterns to address security issues
viable technology for enabling DID in terms of data integrity of smart contract design.
and privacy. As self-sovereign identity needs no intermediary, There have been significant efforts in both industry and
it aligns with the design nature of blockchain which eliminates academia to address many of the identity management chal-
the need for a centralised authority. lenges using blockchain technology [22], [23]. Many organ-
isations and companies have been developing self-sovereign
 TABLE I
PATTERN COLLECTION OVERVIEW

Category Name Summary

Each entity has a master-key for managing sub-keys which are used for signing transactions for different identity
Master & Sub Key
accounts.
Key
Management Hot & Cold Wallet
Patterns An entity can maintain a hot wallet connecting to internet and a cold wallet which is kept offline.
Storage
Key Sharding A key can be split up into several different pieces, and restored using enough key pieces.
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.
DID Bound with Social
Management A bidirectional binding is established between social media profile and blockchain-based identity.
Media
Patterns
To establish interactions, two entities can mutually acquire each other’s DDO for verification and communication
Dual Resolution
information.
Update by Delegates Each identifier maintains a list of delegates that can help the user recover the identity.
Selective Content An issuer generates a customised credential according to a holders specific requirements about credential contents.
Generation
Time-Constrained
A holder can share a link which is redirected to the credential content only for a specified period of time.
Credential Access
Design A holder can share a one-off link which is redirected to the credential content one time only to satisfy a temporary
Patterns One-Off Access
identification request.
Anchoring to
Periodically sending the unique hash value of off-chain data to blockchain.
Blockchain

identity platforms using blockchain, including Sovrin (Hy- discussion on the forces leading to the problem difficulty, the
perledger Indy) [24], uPort (Ethereum) [25], and Blockstack solution and its consequences, and some examples of real-
(Namecoin) [26]. Decentralised Identity Foundation5 aims to world known uses of the pattern. Note that the forces are
develop an open ecosystem for decentralised identity, and the identified with the quality attributes which may affect the
Internet Identity Workshop6 seeks to find, investigate, and application, and the solution sometimes proposes a trade-off
solve identity issues. There are also projects designing and to mitigate the dilemma.
developing self-sovereign identity systems [27]–[31].
Compared with the existing works, our study focuses on A. Key Management Patterns
the design patterns of blockchain-based self-sovereign iden- 1) Master & Sub Key Generation:
tity, aiming to facilitate the design and development of self-
sovereign identity applications. Some collected patterns are Summary: Each entity has a master-key for managing sub-
already applied in the related works, for instance, Identifier keys which are used to sign transactions for different identity
Registry, Multiple Registration, and Selective Content Gener- accounts. Fig. 4 is a graphical representation of the pattern.
ation can be found in the above projects and studies. Context: Public key cryptography and digital signatures are
III. PATTERNS FOR B LOCKCHAIN - BASED used to identify accounts and authorise transactions submitted
S ELF -S OVEREIGN I DENTITY to a blockchain.
This section introduces 12 patterns for the design of Problem: Using a single key for all transactions has serious
blockchain-based self-sovereign identity applications. We privacy implication for an identity owner since transactions
present the patterns in three groups: key management, DID can be correlated to expose all the identities an entity holds.
management and credential design. The patterns aim to make Forces: The problem requires balancing the following forces:
better use of three main objects in self-sovereign identity –
• Identifiability. An entity needs to create an identity for
key, DID, and identity credential, by understanding their use
sending transactions in the blockchain network.
in different stages of the lifecycles.
• Re-identification. Each entity can have more than one
Fig. 2 and Table I offer an overview of these patterns, while
identities in the real world. For example, one person is
Fig. 3 gives a glimpse of the relations between the patterns
both a client of a bank and a patient of a hospital. If an
collected in this study. We describe each pattern using the
entity handles all the identities via a single key, its privacy
extended pattern form in [7]. This includes the pattern name,
may be violated as all the transactions on blockchain are
a short summary, the usage context, the problem statement, a
transparent and can be correlated.
5 https://identity.foundation/ • Security. There is no a standard approach to protect or
6 https://internetidentityworkshop.com/ recover users’ secret keys.
 DID Management Patterns
Blockchain &
Dual
Resolving Linking Social Media
Resolution
DID other ID Account Pair

Identifier
Allowing multiple Updating DID Credential Design Patterns
Registry
identities ownership
Selective
Multiple Delegate Hashing Blockchain
Content
Registration List Anchor
Generation

Adding time- Adding

Registering with Key-DID
constrained one-off
multiple keys mapping
disclosure disclosure
Key Management Patterns Master & Time-
Recovering
One-Off
Sub Key Constrained
Splitting and Storing keys Alternative Access
Generation lost keys Access
recombining in wallet
keys
Hot & Cold
Key Shards Wallet
Integrating functionalities Storage

Fig. 3. Pattern relation overview

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

recovered by Key Shards.
. • Identifier Registry (Section III-B1) Entities can use sub-
.
User Master-key . keys to register identifiers in Identifier Registry.
• Multiple Registration (Section III-B2) Sub-keys are used
Sub-keys
to register identifiers for different identity relationships.
Fig. 4. Master & Sub Key Generation Pattern
Known uses:
2
• uPort A uPort user interacts with application smart
Solution: Each entity can have a master-key to manage sub- contracts via a proxy smart contract, thus the public
keys which are used for signing messages under different key of the proxy contract is considered as a layer of
identities. For example, a person can have a sub-key for the indirection between the users private key and the target
student identity and another sub-key for the company intern application contract.
7
identity. Each sub-key is linked to a unique identifier and • Ethereum Implementing the Ethereum ERC725 standard
stored as part of the identifier’s data in the identifier registry, key management functions8 requires the deployment of
which can be updated using the master-key. The use of master- ERC 725 identity smart contracts, which act as unique
key must be minimised (i.e., only used for controlling sub- identifiable proxy accounts and used by humans, groups,
keys) due to its importance. organisations, objects and machines.
9 10
• Trinity Trinity is a wallet application of IOTA ledger .
Consequences:
Each account has a seed acting as a master-key, to control
Benefits:
the addresses and IOTA tokens of that specific account.
• Identifiability. Identifiability is preserved as each transac-
2) Hot & Cold Wallet Storage:
tion is signed by a private key.
• Privacy. Each sub-key maintains its own identity. The Summary: An entity can maintain a hot wallet connecting to
transactions sent under different identities are less likely internet and a cold wallet which is kept offline. Fig. 5 is a
to be mapped and correlated in order to re-identify the graphical representation of the pattern.
user. Context: As a blockchain network participant, one entity can
• Availability. If a sub-key is lost or compromised, the rely on so-called “wallets” to manage its accounts and interact
master-key can be used to revoke the lost or compromised with blockchain.
key and update it with a new sub-key.
Problem: An entity’s wallet may suffer malicious attacks,
Drawbacks:
leading to key theft. The attacker can send transactions under
• Security. If the master-key is lost or compromised, the that entity’s name to blockchain using a compromised key.
identity owner loses control of all the sub-keys which
means loss of control of all the owned identities. Forces: The problem requires balancing the following forces:
7 https://ethereum.org/
Related patterns: 8 https://github.com/ethereum/EIPs/issues/725
• Hot & Cold Wallet Storage (Section III-A2) Entities’ keys 9 https://trinity.iota.org/

are stored in wallet applications. 10 https://www.iota.org/

 Private key
piece 1

Blockchain network
Private key
piece 2
.
.
Original private key
Hot wallet Cold wallet .
Private key
Fig. 5. Hot & Cold Wallet Storage Pattern piece N

Fig. 6. Key Shards Pattern

• Cyber security. A key may be hacked when being stored
in a device connected to internet.
• Usability. Some keys may be frequently used by •MyEtherWallet11 Ethereum blockchain network offers a
blockchain participants while other keys might act as software , MyEtherWallet, as hot wallet to users for in-
backup. stant payment and withdrawal. With a visual interface, it
is easy for users to operate without inputting complicated
Solution: Users can choose to store keys in two types of commands.
12
wallets, namely hot wallet and cold wallet. Hot wallet refers • Trezor Trezor is a cryptocurrency hardware wallet,
to the blockchain gateways that are connected to Internet. designed to store and encrypt users’ coins, passwords and
Through a hot wallet, a user is able to directly conduct other digital keys. It is a single-purpose computer with
specific operations (e.g. generation) to its accounts and related independent memory to save all private data.
13
decentralised identifiers stored on-chain. Cold wallet refers • Ledger Ledger provides hardware wallet products to
to key storage that is off-line, keeping the accounts from stores users’ private keys in a secure hardware device,
being hacked. A cold wallet can be any device disconnected protecting the cryptocurrencies.
from the internet or even a paper recording an entity’s keys. 3) Key Shards:
When the keys stored in a cold wallet are required for signing
transactions, the user needs to connect the cold wallet device Summary: A key can be split up into several different pieces,
to a computer and copy-paste the key in the relevant field. A and restored using enough key pieces. Fig. 6 is a graphical
user can combine these two wallets: storing accounts that are representation of the pattern.
frequently used in a hot wallet while using a cold wallet to Context: In self-sovereign identity, a participant may have
keep those that are not used often. multiple keys, for instance, signing key for transaction au-
Consequences: thorisation, public/private key pair for encryption/decryption,
Benefits: etc. Consequently, key management is significant to the users,
especially credential issuers and holders.
• Secure storage. Cold wallets are separated from internet,
which provide secure storage for entities’ keys. Problem: A user may lose or forget his/her secret keys under
• Usability. Such a secure storage also preserves the usabil- some circumstances, e.g. the device containing the keys is lost
ity of keys, as once a cold wallet is connected to Internet, or broken. Losing the keys denotes that the owner could lose
an entity can utilize those keys. control over its blockchain accounts in self-sovereign identity
Drawbacks: and the related identities.
• Security. Hot wallets store one’s secret keys on-line, Forces:
which is still vulnerable to theft. • Loss of keys. Private keys are usually long and hard
• Usability. Cold wallets are more secure than hot wallets to remember. Also, many blockchain platforms do not
but less convenient to use, as the user has to connect to provide a sound mechanism to recover the signing keys.
the cold wallet which might not be around. • Centralisation. A blockchain user’s keys are usually

Related patterns: stored in a wallet application installed on a mobile device,

and such a centralised approach to maintain keys may
• Master & Sub Key Generation (Section III-A1) Wallet
cause a single-point of failure. Once the device is lost or
applications are utilised to stored users’ keys.
hacked, the user may lose the control of all keys.
• Key Shards (Section III-A3) Splitting and recombining a
key should be conducted in a wallet application. Solution: To protect the security of a secret key, one can spilt
• Delegate List (Section III-B5) When being integrated into that key into several pieces as its requirement, and define a
wallet applications, predefined delegates can replace key
11 https://www.myetherwallet.com/
ownership if a key is compromised.
12 https://trezor.io/

Known uses: 13 https://www.ledger.com/

regrouping threshold. The key pieces can be kept in any way Off-chain On-chain
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
user needs to regain enough key pieces (more than the preset
regrouping threshold), and these pieces can help rebuild the
Identity data
complete key. Identifier registry
smart contract
Consequences:
Benefits: Fig. 7. Identifier Registry Pattern
• Tolerance of lost key. A lost key can be recovered by its
shards, which provides great convenience to blockchain
users. needs to be accessed for a specific purpose. An identifier is a
• Decentralisation. The shards are stored in a decentralised globally unique persistent series of digits and/or characters that
way, which reduces the risk of losing all shards in an is used to uniquely identify an entity (e.g. human, organisation,
attack. device) within one domain and can be used to retrieve the
• Flexibility. An entity does not have to input all but just storage location of the identity attribute data. A Decentralised
enough key shard when recombining a lost key. Identifier (DID) is a new type of identifier which is designed
Drawbacks: for cryptographically verifiable self-sovereign identity.
• Cost. Maintaining key shards needs extra vigor. If a key Problem: In traditional centralised software systems, map-
shard is lost, there is no way to restore it. pings between an identifier and the identity data storage
• Security. Having multiple key shards provides multiple location is maintained by a centralised single authority which
targets to attack. may become a potential single point of failure.
Related patterns: Forces: The problem requires balancing the following forces:
• Master & Sub Key Generation (Section III-A1) Key • Upgradability. The need to upgrade identity data over
Shards is applied to split and recombine entities’ keys. time is ultimately necessary for software applications.
• Hot & Cold Wallet Storage (Section III-A2) The key split- • Scalability. Blockchain provides limited scalability be-
ting and recombining functionalities should be integrated cause data is replicated across all nodes and kept per-
into wallet applications. manently.
• Delegate List (Section III-B5) Key Shards can restore a • Cost. Storing data to blockchain may have monetary cost
lost key, while Delegate List aims to replace a compro- (if choosing a public blockchain), and also occupies the
mised key with a new one. physical storage of all participating nodes.
Known uses:
Solution: Implementing an identifier registry designed as a
14
• Parity For each private key of an account, Parity dis- smart contract to maintain bindings between an identifier and
tributes 12-word phrase acting as an additional backup. the location of associated off-chain identity data attributes.
If a user loses the private key, this phrase can help fully This identifier registry smart contract is the main entry point
recover it. for accessing the attributes of an identity, which can map each
15
• Crypto++ A free and open-source C++ class library of identifier to a storage (e.g. IPFS, Dropbox, etc.) location for
cryptographic algorithms and schemes, which implements the respective identity attributes (e.g. an IPFS hash linking
the Shamir’s Secret Sharing scheme: spliting up a secret to the IPFS storage location containing the user’s identity
into defined number of pieces, and restoring the original attributes). Only the identifier owner is allowed to update the
secret when given enough secret pieces. storage location of identity attributes. Each identifier points to
an identifier document which describes how to use that specific
B. DID Management Patterns
identifier, e.g. public keys used for digital signatures, service
1) Identifier Registry: endpoints for interaction.
Summary: The identifier registry maintains bindings between Consequences:
an identifier and the address of an identity attribute (e.g. name,
Benefits:
profile, picture). Fig. 7 is a graphical representation of the
pattern. • Upgradability. Through the cryptographic access controls
built into the blockchain, it is guaranteed that only the
Context: Identity is defined as sets of attributes related to
owner of the identity (i.e. the key owner) has the right to
an entity16 . In software applications, identity attribute data
modify the data reference in identifier registry.
14 https://www.parity.io/ • Scalability. The data structure of identifier registry is
15 https://cryptopp.com/ simple and lightweight, which only stores identifiers and
16 https://www.iso.org/standard/77582.html locations of identity attributes.
 •Cost. If a public blockchain is used, the cost is low since Off-chain On-chain
the data size of identifiers and identity storage locations 0x2222… DDO
owner: 0x1111…
is fixed.
id:did:0x2...student
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 User
storage, the change will be detected. However, without 0x1111… Identifier registry
additional measures, it will neither be possible to recover 0x2222… smart contract 0x9999… DDO
… owner: 0x1111…
the original data nor to prevent the change from happen-
0x9999… id:did:0x9...patient
ing in the first place. ...
• Data loss. Since the raw data is stored off-chain, it may
be deleted or lost.
Fig. 8. Multiple Registration Pattern
Related patterns:
• Multiple Registration (Section III-B2) An entity can reg-
Context: An identifier is used to uniquely identify an entity
ister multiple identifiers at once in Identifier Registry. and to retrieve the identity attribute data.
• Blockchain & Social Media Account Pair (Section III-B3)
Identifier Registry maintains the mapping between an Problem: Sending all transactions using a single identifier
entity’s on-chain identity and social media. has serious privacy implication for an entity since these
• Dual Resolution (Section III-B4) Entities resolve each transactions can be correlated to expose all the identities this
other’s identifiers in Identifier Registry. entity holds.
• Delegate List (Section III-B5) Predefined delegates can Forces: The problem requires balancing the following forces:
change the binding key of a compromised identifier. • Transparency. All the historical transactions on
• Master & Sub Key Generation (Section III-A1) Entities
blockchain can be accessed by every participant
register identifiers in Identifier Registry through their sub- within the same blockchain network. The transactions
keys. on a public blockchain are also accessible to everyone
• Content-Addressable Storage Pattern [19] Identifier Reg-
on the internet.
istry is similar to Content-Addressable Storage Pattern, • Security. There is no standard approach to protect or
storing raw data off-chain while publishing a reference recover users’ secret keys.
in smart contract.
• Flyweight Pattern [20] Identifier Registry and Flyweight Solution: Each entity can establish a unique identifier for
Pattern both include a registry to maintain the mapping every relationship (i.e. every identity) they have, which allows
of identifiers and the respective reference pointing to off- keeping interactions with one entity entirely separate from any
chain data. other entity. For example, the relationship a person builds
with a hospital is completely separate to the one that is
Known uses: established with a university. Neither the hospital nor the
2
• uPort The registry contract maintains mappings between university could proactively use the identifiers to correlate this
a uPort identifier and an IPFS hash linking to a data person’s activities.
structure storing an entity’s attributes.
17 Consequences: Benefits:
• Sovrin Sovrin offers a registry for decentralised identi-
• Privacy. This pattern tackles with the nature transparency
fiers and the associated public keys and communications
endpoints. The operations (i.e. registration, update, reso- of blockchain to some extent, as an entity’s activities in
lution, and revocation) are all determined by the Sovrin different identity relationships can hardly be correlated.
• Availability. The loss of signing key of one identifier does
protocol.
• Jolocom
18
Jolocom distributed identity system integrates not affect the other identifiers.
Ethereum blockchain and Interplanetary File System Drawbacks:
(IPFS). A deployed smart contract maintains the mapping • Cost. Compared to a single identifier, multiple identifiers
from a DID to the corresponding DDO stored in IPFS. cost more for identifier registration and updates.
2) Multiple Registration: Related patterns:
Summary: Each entity can register a unique identifier for • Identifier Registry (Section III-B1) Registered identifiers
every relationship (i.e. every identity) they have. Fig. 8 is a are stored in Identifier Registry.
graphical representation of the pattern. • Master & Sub Key Generation (Section III-A1) Entities
use different sub-keys to conduct Multiple Registration.
17 https://sovrin.org/
18 https://jolocom.io/ Known uses:
 • Sovrin17 Sovrin suggests users to use a separate identifier • Security. The mapping needs to be stored securely from
for every relationship. Consequently, if a relationship suf- tampering.
fers a breach and the identifier is compromised, the user • Verified accounts. Social media applications verify ac-
can still have normal interactions in other relationships. counts via traditional identity documents.
19
• Blockstack Blockstack allows entities to create as many
Solution: An entity can create an attribute of social media
identities as they want. Each identity is represented by
in the identifier document. Signing the attribute with the
an identifier and a secret key. Entities can utilise their
blockchain signing key creates a claim that the blockchain-
identities to sign in different decentralised applications.
20 based identity controls the social media account. The attribute
• DAML In DAML ledger, participant nodes can use
also contains a URL which links to a social media post stating
human-readable strings as identifiers to identify them-
that the social media account also controls this particular
selves. A real-world entity is able to possess multiple
blockchain identity. Thus, a two-way link is established for
identifiers in the same ledger network to denote different
connecting the blockchain identity with the social media
identities.
profile. The two directional binding makes sure that that the
3) Blockchain & Social Media Account Pair: social media profile and blockchain-based identity have a 1-
Summary: A bidirectional binding is established between to-1 mapping.
social media profile and blockchain-based identity. Fig. 9 is a Consequences:
graphical representation of the pattern. Benefits:
• Authoritative source. The trustworthiness of social me-
Off-chain On-chain
dia account and blockchain-based identity can both be
Social media post 0x2222… DDO
improved by binding them together.
URL: https://… owner: 0x1111… • Secure storage. Blockchain provides a secure data store
did:0x2...student id:did:0x2...student through distributed ledger technology.
... socialMedia: https://... • Verified accounts. A social media verifies the legal iden-
...
Social media post of DDO stored in identifier
tity of a user.
on-chain identity registry smart contract Drawbacks:
• Trustworthiness. The trustworthiness of social media ac-
Fig. 9. Blockchain & Social Media Account Pair Pattern
count relies on the verification process while the the
trustworthiness of blockchain-based identity depends on
Context: Social media profiles can be considered as one of the trustworthiness of trusted participants.
the most important assets, which are critical to achieve more
exposure on the internet, attract more attention, or improve Related patterns:
online reputation. The trustworthiness of a social media profile • Identifier Registry (Section III-B1) Identifier Registry

can be improved by verifying the account using traditional maintains the mapping of an entity’s on-chain identity
identity issued by some central authority. On the other hand, and social media.
blockchain provides a decentralised infrastructure for self- Known uses:
sovereign identity, where entities are in control over their 21
• Onename Onename is a registrar for Blockstack which
own identities. To ensure the trustworthiness, some identity
is a decentralised naming and storage system. With One-
blockchains (e.g. Hyperledger Indy) are designed as public
name, a user can easily register a blockchain ID and cre-
permissioned blockchains, which are governed by a group of
ate corresponding profile on Blockstack, and completely
participants.
has control of his/her blockchain ID and profile. Users
Problem: In addition to verification by some certain people or can can link their Blockstack profiles with existing online
central authorities, a user can link his/her social media profile social media accounts (Twitter, Facebook, Github, etc),
(e.g. Twitter) to his/her identity registered on blockchain to and also embed their blockchain ID on their social media
improve the trustworthiness of both social media profile and posts.
blockchain-based identity. The problem here is how to bind a 4) Dual Resolution:
social media profile with the corresponding blockchain-based
Summary: To establish interactions, two entities can mutually
identity to ensure mapping.
acquire each other’s DDO to access information necessary
Forces: The problem requires balancing the following forces: for verification (e.g., public key) and communication (e.g.,
• Authoritative source. A 1-to-1 mapping is required be- service endpoints for provided services). Fig. 10 is a graphical
tween a social media account and its corresponding representation of the pattern.
blockchain-based identity. Context: In self-sovereign identity, entities interact with each
19 https://blockstack.org/
other.
20 https://daml.com/ 21 https://www.onename.com/
 Off-chain On-chain • Identifier Registry (Section III-B1) Entities resolve each
0x1111… DDO other’s identifiers in Identifier Registry.
owner: 0x1111…
id:did:0x1111… Known uses: The existing self-sovereign identity applications
... do not directly point out this feature as a provided functional-
User .
ity, but the users need to resolve each other’s DID when there
0x1111… .
.
is potential interaction.
5) Delegate List:
Identifier registry Summary: Each identifier maintains a list of delegates that
smart contract 0x2222… DDO
User owner: 0x2222… can help the user recover the identity. Fig. 11 is a graphical
0x2222… id:did:0x2222… representation of the pattern.
...
Off-chain On-chain Off-chain
request
Fig. 10. Dual Resolution Pattern update vote
id:did:0x2...student
User Delegate 2
0x5678… owner: 0x1111… (lost) 0x2234…
newOwner: 0x5678…
Problem: When two or more entities want to establish inter-
delegate: 0x1234…, .
actions (e.g., for business purposes), each entity first needs to 0x2234…, .
determine the target entity’s basic information and ways of …, .
0xn234…
communicating before going further. updateThreshold: m
…
Forces: The problem requires balancing the following forces: vote vote
DDO stored in identifier
• Interoperability. For two parties to interact, the ways of Delegate 1 registry smart contract Delegate n
0x1234… 0xn234…
communication have to be interoperable.
• Independence. The interacting entities should remain in- Fig. 11. Delegate List Pattern
dependent of each other and one should not be able to
pry on the other. Context: Each identity has a key pair to authenticate the trans-
Solution: A DDO contains verification methods (i.e. public actions initiated by the user by means of digital signatures.
keys) and service endpoints (e.g., messaging service details) Problem: A master-key may be compromised/stolen by mali-
which can be utilised by an entity to establish interactions cious hackers. A compromised master-key results in the loss of
with the corresponding DID owner. Before any formal activ- ownership over all sub-keys and corresponding identifiers. The
ity between two entities in a relationship, they should first hacker may utilise the identifiers to further steal the entity’s
mutually resolve each other’s DID and obtain the interaction identity data.
information stored in DDO. Such a process is considered as
Forces: The problem requires balancing the following forces:
“Dual Resolution” and it forms the first step for any entity to
establish an interoperation with its target entity. • Compromised private key. Authentication can be achieved
by using digital signatures. Currently, many blockchain
Consequences: platforms do not provide a sound mechanism to recover
Benefits: compromised keys, thus key theft results in permanent
• Interoperability. The Dual Resolution process allows the loss of control over related identifiers.
interacting entities in a relationship to obtain and check • Non-reusability. A compromised identity can be claimed
each other’s basic information on verification and services of no more use, but its owner has to spent extra time,
provided for interoperability. money, and energy to re-register a new identifier and
• Independence. Each DDO stores necessary interaction rebuild all corresponding relationships.
information only for its corresponding DID, hence, an
entity’s different identities are independent from each Solution: Delegate List relies on a web of trust architecture.
other and cannot be correlated. This requires an identity owner to designate its own set of
Drawbacks: trustees that the owner trusts to assist in identity ownership
update when the owner asks for it. An identifier maintains a
• Privacy. It is possible for an entity to store in DDO extra
list of recovery delegates and an update threshold that can help
information about itself other than what is necessary for
the user recover identity. These delegates can be individuals
communication, such as social media accounts, personal
(such as family members or friends) or organisations (such as
websites. Doing so may increase the trustworthiness of
banks). If key loss happens, the original identity owner needs
the entity as more identity information is shared with oth-
to request for ownership update using a new key pair, and a
ers. However, this also increases the risk of unwillingly
minimum number of the trustees (e.g. 2 out of 3) must sign
revealing the entity’s personal information.
a new identity record transaction respectively. When there are
Related patterns: enough confirmations (i.e. reaching the threshold) of the new
key pair, the ownership of the identifier is updated and thus • Baidu Cloud22 Baidu implemented its SSI solution via
the identity is recovered. A timelock period can be specified Quorum, an Ethereum-based DLT. In each user’s DDO, a
to prevent an attacker who tries to compromise an identity “recovery” attribute defines a list of public keys to recover
owner’s key and immediately change the owner’s identity the on-chain identity.
records, including his/her designated trustees to prevent iden-
tifier ownership recovery. C. Credential Design Patterns

Consequences: 1) Selective Content Generation:

Benefits:
issuer did: did:uBaaS:0x11…
• Tolerance of compromised private key. This pattern can holder did: did:uBaaS:0x22…
name: John Smith
guarantee security by maintaining a group of delegates DOB:
who can confirm a new key proposed by the identity age: above 18
owner to replace the compromised key, improving the country: Australia
job: student
tolerance of key compromise. address:
• 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. Fig. 12. Selective Content Generation Pattern
Drawbacks:
• Cost. Recovering an identity requires setting up a delegate Summary: An issuer generates a customised credential ac-
list in advance, and sending update requests/votes after cording to a holder’s specific requirements about credential
the identity is compromised. Each operation sends a contents. Fig. ?? (a) is a graphical representation of the pattern.
transaction to blockchain. Context: A verifier requires certain information to prove a
holder’s identity, thus, a holder only needs to share a credential
Related patterns: with necessary data to the verifer.
• Identifier Registry (Section III-B1) Delegates related to a Problem: If issuers publish general credentials to holders, a
specific identifier are stored in Identifier Registry. verifier can learn all identity data involved when only some
• Hot & Cold Wallet Storage (Section III-A2) When being particular attributes are needed. For instance, if a person shows
integrated into wallet applications, predefined delegates his/her ID to identify the age, his/her address is presented
can replace key ownership if a key is compromised. either. This may cause data leak as extra information is
• Key Shards (Section III-A3) Key Shards can restore a lost provided.
key, while Delegate List aims to replace a compromised
key with a new one. Forces: The problem requires balancing the following forces:
• Multiple Authorisation [13] Delegate List is derived from • Privacy. The disclosed credential should contain mini-
Multiple Authorisation that the change of a lost secret key mum amount of data necessary to identify some certain
in a DID requires enough confirmation. aspects of its holder.
• Mutex Pattern [21] Mutex Pattern can be applied to • Specific requirements. Each verifier may have specific
Delegate List, ensuring that no any other operation can requirements on inspecting a holder’s identity facts.
be conducted within an update procedure.
Solution: Selective Content Generation allows issuers to de-
Known uses: cide what identity attributes are contained in a credential. An
issued credential needs to satisfy the target verifier’s specific
• uPort2 In uPort, the user’s mobile device is the only place requirements of holder’s identity, without revealing extra data.
where stores the private key that controls a uPortID. To A credential with selective content disclosure can be generated
avoid the key loss issue caused by loss or theft of the via the following approaches23 .
mobile devices, users must nominate a group of delegates • Atomic credentials. An issuer generates multiple creden-
who can vote to replace the public key. Once a quorum is tials and each one only contains exactly one identity
achieved by the delegates on the newly proposed public attribute about the holder. Consequently, the holder can
key, the lost public key is replaced with the new public flexibly disclose those required credentials to a verifier.
key. • Selective disclosure signatures. A general credential is
• Sovrin17 Similar to uPort, Sovrin provides a key recovery issued to a holder, but some special signature schemes
mechanism for key recovery that relies on the user (e.g. Camenisch-Lysyanskaya signatures) allow them to
selecting a group of delegates. When the user requests only reveal necessary information.
the delegates to assist key recovery, a specified quorum
of delegates must sign a new identity record transaction 22 https://cloud.baidu.com/

that validator nodes must verify. 23 https://w3c.github.io/vc-imp-guide/

 • Hashed values. A general credential consists of multiple issuer did: did:uBaaS:0x11…
identity attributes, but each one is hashed with different holder did: did:uBaaS:0x22…
credential id: example123…
nonce. When verifying a credential, a verifier can only creation date: 08/20/2019
validate those with the actual values provided by the valid period: 30 days
holder, but cannot determine other hashed values. name: John Smith
age: above 18
• Zero-knowledge proof. When proving certain identity country: Australia
attributes, a holder can protect its information by giving ...
a range instead of precise value (e.g., age is over 18).
Consequences: Fig. 13. Time-Constrained Access Pattern
Benefits:
• Data minimisation. A credential with selective content
Problem: After receiving a credential, a verifier then has the
can disclose the identity data which satisfy the verifier’s ability to access, read, and verify certain identity data of the
individual requests while keeping other identity data holder. If the credential is long-term or even permanently
private. effective, the verifier then can verify the credential after current
Drawbacks: identification process, which means that it can still access and
• Cost. Determining the identity data within a credential check the holder’s identity data when there is not a legitimate
requires additional communication between holders and permission for proving the identity, resulting identity data leak.
verifiers for learning the verification requirements, and Forces: The problem requires balancing the following forces:
between holders and issuers for discussing the credential
content. Moreover, maintaining multiple credentials with • Privacy. A holder’s identity information should not be ac-
different contents can incur extra costs. cessed or verified when the current identification process
is finished.
Related patterns: • Inflexibility. Verifiers have their own identification pro-
• Time-Constrained Access (Section III-C2) Selective Con- cesses, which may take different amounts of time. The
tent Generation can work collaboratively with Time- cost to generate and maintain credentials for the process
Constrained Access, to generate credentials with fine- inconsistency is huge.
grained specifications.
Solution: A holder is able to generate an identifiable link, and
• One-Off Access (Section III-C3) Selective Content Gener-
define its accessible period (e.g. certain days). The link can
ation can also work collaboratively with One-Off Access,
redirect to a page presenting credential content. Afterwards,
to generate credentials with fine-grained specifications.
the holder can share the time-constrained link to verifiers
• Blockchain Anchor (Section III-C4) Off-chain credential
instead of the original credential itself. Within the predefined
contents need to be hashed and stored on-chain to pre-
accessible period, a verifier can visit and verify the credential
serve integrity.
for identification without limit. Nevertheless, when the link
Known uses: is expired, there is no approach for the verifier to obtain
2
• uPort A uPort user encrypts identity attributes using a
credential content again.
symmetric encryption key before disclosure. The sym- Consequences:
metric encryption key is then individually encrypted using Benefits:
a public encryption key owned by the other interacting
• Privacy. A holder can determine the accessible period
party.
17 of a shared link, which ensures that the holder’s identity
• Sovrin A cryptographic technique known as a zero-
information can only be fetched within a particular identi-
knowledge proof is utilised in Sovrin. A verifier can
fication process. An expired credential cannot be verified
check the authentication of an identity though the public
again. Consequently, a malicious verifier is unable to
key of the issuer, but never learns the actual data.
further utilised the identity data.
2) Time-Constrained Access: • Flexibility. Shared links does not affect the original cre-
Summary: A holder can share a link which is redirected to dential. Consequently, this pattern can be flexibly applied
the credential content only for a restricted accessible time to a long-term effective credential, links with different
period. The verifier can only access the credential content accessible periods can be sent to different verifiers.
within the determined time period. Fig. ?? (b) is a graphical Drawbacks:
representation of the pattern.
• Cost. Storing the credential replicas requires more stor-
Context: Usually an identification process lasts for a certain age.
time period. After proving the identity of an entity, the • Privacy. A malicious verifier may take a photo of the
presented credential has accomplished its mission and should credential when accessing it, then it has the credential
not be accessed again. content even if the shared link is expired. Although the
 compromised credential cannot reveal up-to-date infor- • Privacy. A holder’s identity information should not be ac-
mation of the holder, the attacker still maintains historical cessed or verified when the current identification process
identity attributes of the holder to some extent. is finished.
• Inflexibility. Using a long-term effective credential to
Related patterns: satisfy a temporary credential request is not appropriate,
• Selective Content Generation (Section III-C1) Time- as the holder cannot control the access to this credential
Constrained Access can work collaboratively with Se- after the temporary request.
lective Content Generation, to generate credentials with
fine-grained specifications. Solution: A holder is able to generate an identifiable link,
• One-Off Access (Section III-C3) One-Off Access can be
which redirects to a one-off page presenting the credential
seen as a derivative of Time-Constrained Access under an content. One-off links can be shared with verifiers on some
extreme condition. special occasions. After being visited once, the link becomes
invalid that no one can use it to access the credential content.
Known uses: Consequences:
24
• Snapchat Snapchat is a social media in which users Benefits:
can share their photos and videos. Every shared photo or • Privacy. The identity attributes presented via one-off links
video is automatically deleted after a certain amount of can only be read and verified for once. Similar to Time-
time. Constrained Access, malicious verifiers cannot further
25
• Snappass Snappass is a website where users can gen- violate holders’ privacy via expired links. Information
erate secret information and share it by URL. A user can within the link becomes unauthentic as there is no ap-
set a valid time period to each secret, within which the proach to verify it.
secret information can be read. • Flexibility. One-Off Access defines an extremely short
3) One-Off Access: period to visit the credential content, satisfying temporary
identification requests.
Drawbacks:
issuer did: did:uBaaS:0x11…
holder did: did:uBaaS:0x22… • Privacy. A malicious verifier may take a photo of the
credential id: example123… credential when accessing it, then it can read the content
creation date: 08/20/2019 even if the one-off link is expired. Although information
name: John Smith
age: above 18 within an expired link can no longer be used to prove
country: Australia anything, this still can cause a privacy issue for the holder.
...
Related patterns:
• Selective Content Generation (Section III-C1) One-Off
Fig. 14. One-Off Access Pattern
Access can work collaboratively with Selective Content
Generation, to generate credentials with fine-grained
Summary: A holder can share a “one-off” link which is specifications.
redirected to the credential content one time only. This may • Time-Constrained Access (Section III-C2) One-Off Ac-
be used to satisfy a temporary identification request. Fig. ?? cess can be seen as a derivative of Time-Constrained
(c) is a graphical representation of the pattern. Access under an extreme condition.
Context: A verifier does not require a long-term effective Known uses:
credential but only needs to check the identity of a holder • Snapchat
24
Snapchat can automatically delete user-
once for a specific purpose. uploaded photos or videos when once read, according
Problem: Sometimes an identification process does not require to the user’s setting.
25
a strict verification procedure, but only needs to check the • Snappass In Snappass, user-defined secret information
identity for once. For instance, travelling by train/airplane are delete and cannot be recovered after being read for
or going to a theme park only asks for checking credentials once.
before entering. If a holder presents a long-term effective link 4) Blockchain Anchor:
redirecting to the credential content, a malicious verifier may Summary: Instead of storing everything on-chain, one can
access the holder’s data illegally after identification process. periodically send the unique hash value of off-chain data to
This can be considered as an extreme version of Time- blockchain. Fig. 15 is a graphical representation of the pattern.
Constrained Access.
Context: Blockchain’s nature configurations may limit its
Forces: The problem requires balancing the following forces: performance when facing a large number of transactions.
24 https://www.snapchat.com/ Problem: Blockchain can ensure data integrity via storing data
25 https://oneoffsecret.com/ on-chain, but it costs real money to process the transaction in
 Off-chain On-chain • 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.
Off-chain data hashing • Low Contract Footprint Pattern [19] Blockchain Anchor
works similarly as Low Contract Footprint Pattern, which
concerns about the monetary cost and optimises the
Fig. 15. Blockchain Anchor Pattern writing operations to blockchain.
Known uses:
19
many public blockchain networks. In addition, according to • Blockstack Blockstack allows entities to register off-
the nature consensus mechanism, blockchain generates a block chain decentralised identifiers. To prove the existence
in a fixed period (i.e. block interval), which only includes of these off-chain identifiers, the system collects hashes
a restricted number of transactions due to the block size. of corresponding files and writes the hash values to
Consequently, blockchain’s performance may be restricted blockchain.
26
when users frequently initiate transactions. • Chainpoint Chainpoint is an open standard for creating
a timestamp proof of any data, file, or process by gener-
Forces: The problem requires balancing the following forces: ating a Merkle Tree, and publishing root of this tree to
• Cost. In a permissionless blockchain network, sending a the Bitcoin blockchain.
transaction charges real money, thus, frequently storing • Laava A blockchain-based system may need to serve
data to blockchain is expensive. Even in a permissioned different tenants simultaneously, who are not willing
blockchain, each full node maintains a local replica of all to expose private data to each other. Researchers from
historical transactions, handling plenty of transactions is Data61 and Laava ID Pty. Ltd. designed a scalable
also costly for physical storage. platform architecture for multitenant blockchain-based
• Scalability. Blockchain has nature performance restriction systems [32], in which every tenant has an individual
that within a block interval, only a limited number of permissioned blockchain to maintain their own data,
transactions can be processed while others need to wait in while all tenant chains are anchored into a main chain
the transaction pool. Utilising blockchain to record every periodically.
data change may result in the accumulation of waiting
transactions in the pool. IV. C ONCLUSION
We view blockchain as a fundamental component of large-
Solution: Blockchain Anchor relies on the hashing technology scale decentralised software systems. In self-sovereign iden-
that one does not need to store everything on-chain, but tity, blockchain provides an underlying computing infrastruc-
periodically sends the unique hash value of off-chain data to ture and decentralised pseudonym mechanism. In this paper,
blockchain. we summarise and propose 12 different design patterns as-
Consequences: sociated with the lifecycles of three main objects (i.e. key,
Benefits: decentralised identifier, and credential) in blockchain-based
• Cost. Anchoring reduces the cost of applying blockchain
self-sovereign identity. The pattern collection is considered as
in terms of monetary payment and physical storage, as a guidance for architects to better design blockchain-based
there are less transactions sent to blockchain. self-sovereign identity systems.
• Scalability. Anchoring keeps complex and tedious busi- R EFERENCES
ness processes off-chain, which enhances the scalability R EFERENCES
of blockchain-based systems that blockchain only needs
[1] C. Allen, “The path to self-sovereign identity,” http://www.
to record the hash values of all kinds of data and files. lifewithalacrity.com/2016/04/the-path-to-self-soverereign-identity.html,
• Opacity. Blockchain transactions are immutable and can accessed 15-February-2020.
be view by all participants. Thus, storing hash values [2] M. Sporny, D. Longley, and D. Chadwick, “Verifiable credentials data
model (expressing verifiable information on the web),” https://www.w3.
rather than original information can preserve data privacy. org/TR/verifiable-claims-data-model/, accessed 15-February-2020.
Drawbacks: [3] S. Banerjee, “Aadhaar: Digital inclusion and public services in india,”
World Development Report, pp. 81–92, 2016.
• Opacity. Hash values are neither human-readable or can [4] F. Tschorsch and B. Scheuermann, “Bitcoin and beyond: A technical
be restored into original files, which means that using survey on decentralized digital currencies,” IEEE Communications Sur-
anchoring may affect the transparency and auditability of veys & Tutorials, vol. 18, no. 3, p. 464, 2016.
[5] M. Swan, Blockchain: Blueprint for a New Economy. US: ” O’Reilly
on-chain data. Media, Inc.”, 2015.
[6] G. P. Release, “Gartner survey reveals the scarcity of current blockchain
Related patterns: deployments,” May 2018, accessed 15-February-2020. [Online].
Available: https://www.gartner.com/en/newsroom/press-releases/
• Selective Content Generation (Section III-C1) Off-chain
2018-05-03-gartner-survey-reveals-the-scarcity-of-current-blockchain-developments
credential contents need to be hashed and stored on-chain
to preserve integrity. 26 https://chainpoint.org/
 [7] G. Meszaros and J. Doble, Pattern languages of program design 3. [29] R. Soltani, U. Trang Nguyen, and A. An, “A new approach to client
Addison-Wesley Longman Publishing Co., Inc., 1997, p. 529574. onboarding using self-sovereign identity and distributed ledger,” in 2018
[8] S. Nakamoto, “Bitcoin: A peer-to-peer electronic cash system,” https: IEEE International Conference on Internet of Things (iThings) and
//bitcoinsv.io/bitcoin, 2008, accessed 15-February-2020. IEEE Green Computing and Communications (GreenCom) and IEEE
[9] S. Omohundro, “Cryptocurrencies, smart contracts, and artificial Cyber, Physical and Social Computing (CPSCom) and IEEE Smart Data
intelligence,” AI Matters, vol. 1, no. 2, pp. 19–21, Dec. 2014. [Online]. (SmartData), July 2018, pp. 1129–1136.
Available: http://doi.acm.org/10.1145/2685328.2685334 [30] Q. Stokkink and J. Pouwelse, “Deployment of a blockchain-based self-
[10] I. Modinis, “Common terminological framework for interoperable elec- sovereign identity,” in 2018 IEEE International Conference on Internet
tronic identity management,” The 2005 Modinis IDM Study Team, 2005. of Things (iThings) and IEEE Green Computing and Communications
[11] M. Dabrowski and P. Pacyna, “Generic and complete three-level identity (GreenCom) and IEEE Cyber, Physical and Social Computing (CP-
management model,” in 2008 Second International Conference on SCom) and IEEE Smart Data (SmartData). IEEE, 2018, pp. 1336–
Emerging Security Information, Systems and Technologies. IEEE, 2008, 1342.
pp. 232–237. [31] M. Takemiya and B. Vanieiev, “Sora identity: Secure, digital identity
[12] D. Reed, M. Sporny, D. Longley, C. Allen, R. Grant, and M. Sabadello, on the blockchain,” in 2018 IEEE 42nd Annual Computer Software and
“Decentralized identifiers (data model and syntaxes for decentralized Applications Conference (COMPSAC), vol. 2. IEEE, 2018, pp. 582–
identifiers),” https://w3c-ccg.github.io/did-spec/, accessed 15-February- 587.
2020. [32] I. Weber, Q. Lu, A. B. Tran, A. Deshmukh, M. Gorski, and M. Strazds,
[13] X. Xu, C. Pautasso, L. Zhu, Q. Lu, and I. Weber, “A pattern collection “A platform architecture for multi-tenant blockchain-based systems,” in
for blockchain-based applications,” in Proceedings of the 23rd European 2019 IEEE International Conference on Software Architecture (ICSA),
Conference on Pattern Languages of Programs, 2018, pp. 1–20. March 2019, pp. 101–110.
[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 con-
tracts: 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.