Decentralized Identiﬁcation and Information Exchange in Distributed,

Blockchain-Based Internet Architectures: A Technology Review

Laura Maria Marques da Fonseca, Hamid R. Barzegar and Claus Pahl

Faculty of Engineering, Free University of Bozen-Bolzano, Bolzano, Italy

Keywords:

Decentralized Identity, W3C DID Standard, Identity Management, Veriﬁable Credentials, Blockchain.

Abstract:

In many Web and Internet-based systems, sharing Personally Identiﬁable Information (PII) to identify persons

and other entities is common, but centralized systems such as central registries have limitations in terms of

control of privacy and identity that a decentralized identity management architecture could address. This study

aims to compare the current and potential systems, analyze protocols for decentralized identiﬁcation and data

exchange, propose a protocol selection method, and provide a simple code example. The goal is to assess

the feasibility of decentralized processes in software-based business workﬂows. The methodology involves

reviewing protocol materials, including white-papers, articles, and code docs, alongside ontological aspects of

identiﬁcation. Challenges to implementing Decentralized Identiﬁers (DIDs) include interoperability and the

evolving Web/Internet landscape towards more decentralization, openness, and greater user utility.

1 INTRODUCTION

Automation has allowed to execute business tasks

more efﬁciently and error-free than human actors

since the 1970s. The great threat for such systems

consists in the human misuse of their capacities or

information, an issue often addressed by protecting

either the access through an identiﬁcation system,

known as access control systems, or other personal

identiﬁcation information (Bowers, 1988). Access

control is neither new as a procedure nor exclusive

for computerized business environments. With the

ubiquity of computer and internet-based tasks, the ex-

change of Personally Identiﬁable Information (PII)

has immensely expanded in the last 20 years, which

has raised awareness about privacy and identity own-

ership, problems tightly related to the centralized con-

trol of and access to the information. Today, decen-

tralized variants of the identiﬁcation and exchange

of PII are proposed such as the W3C DID standard

(W3C , 2023) that builds on the URI Uniform Re-

source Identiﬁer mechanism of the Web, but with a

mechanism that is relatively complex, which requires

a thorough analysis.

The objectives of this research are to: (i) introduce

the concepts of the Decentralized IDentiﬁer (DID)

and understand which problems it addresses; (ii) map

the state-of-the-art of the protocols implementing the

DID; (iii) offer a decision framework for the choice of

one protocol for an application given its requirements;

(iv) apply the decision framework to one sample de-

cision process and suggest an implementation of the

protocol chosen; and (v) provide arguments for the

comprehension and discussion about the feasibility of

implementing this technology (in its current state) for

common identiﬁcation and PII exchange processes.

The motivation is the concern regarding control

and ownership (and their management) of personal

identifying data by companies and other organisations

in the Web space, which often misuse this data for

ﬁnancial and surveillance reasons. This motivation

extends to a personal desire for an identiﬁcation and

data-exchanging processing where the data ownership

is held by the data owner (Dodevski and Trajkovik,

2018). Assessing the feasibility of this new identiﬁ-

cation architecture is the ﬁnal objective.

We outline our methodology in Section 2. Section

3 explains the decentralized identiﬁer concept, Sec-

tion 4 describes the construction and application of

the decision framework, Section 5 evaluates the deci-

sion procedure, code implementation is explained in

Section 6, and conclusions are presented in Section 7.

2 METHODOLOGY

We carry out a technology review of suitable pro-

tocols (Werth et al., 2023a), following a systematic

Marques da Fonseca, L., Barzegar, H. and Pahl, C.

Decentralized Identiﬁcation and Information Exchange in Distributed, Blockchain-Based Internet Architectures: A Technology Review.

DOI: 10.5220/0012254900003584

In Proceedings of the 19th International Conference on Web Information Systems and Technologies (WEBIST 2023), pages 535-544

ISBN: 978-989-758-672-9; ISSN: 2184-3252

535

selection and classiﬁcation approach (Werth et al.,

2023b). We use a sample implementation to discuss

the feasibility of protocol implementation for con-

crete application scenarios. The approach taken in-

volved studying the DID mechanism according to the

W3C standard and exploring projects with decentral-

ized ledger-based DID implementations. Here, iden-

tiﬁcation and data exchange processes are closely re-

lated, with identiﬁcation as the initial step followed by

data provision (Fukami et al., 2021). We treat identi-

ﬁcation as distinct from data exchange. The research

questions led to a decision framework methodology,

incorporating objective criteria (Pahl et al., 2018).

The stages included evaluating protocols through

an analysis of white-papers, blogs, social media, and

web content to assess their alignment with the cho-

sen criteria. Outcomes were organized into a decision

matrix for protocol selection. An identiﬁcation pro-

cess was selected and the decision framework applied,

leading to an illustrative protocol implementation.

Reﬂections on decentralized app viability and DID

challenges form the conclusion. Literature was se-

lected from diverse sources, including blog posts and

social media, recognizing that blockchain and other

technology discussions often occur outside academia

and its publications. The goal is a comprehensive ex-

ploration of emerging personally identiﬁable informa-

tion (PII) exchange architectures.

• Question 1 concerns Beneﬁts and Limitations

of Architectures for Identiﬁcation and Data Ex-

change. This requires an investigation of the au-

thentication process’s nature and its relationship

with information systems. This question also

addresses drawbacks of centralized identiﬁcation

and data exchange, aiming to identify improved

processes to rectify them.

• Question 2 addresses the analysis of Beneﬁts and

Limitations of the DID Concept and its Proposed

Standard. We examined DID privacy compliance,

potential drawbacks, and the impact of DID adop-

tion on digital business processes.

• Question 3 concerns the Feasibility of Decision

Frameworks and Protocol Implementations. This

explores the current state of DID implementation

and enhancements, protocol selection strategies,

feasibility, and strategies to address limitations in

existing protocols.

These inquiries constitute an in-depth exploration of

decentralized identiﬁcation and data exchange sys-

tems. By systematically investigating these questions,

this research aims to contribute to a comprehensive

understanding of the implications, challenges, and po-

tential beneﬁts of emerging decentralized information

exchange architectures.

3 THE DECENTRALIZED

IDENTIFIER

The core of a decentralized identiﬁcation system is

the mechanism of the decentralized identiﬁer (DID),

as proposed by the World Wide Web Consortium

(W3C). The understanding of the new identiﬁcation

paradigm implies a broader comprehension of the

DID internal mechanism and its external effect on

digital business processes.

Decentralized identity empowers users by remov-

ing centralized data storage, offering control over per-

sonal information for authentication and claims ex-

change. It employs three core elements: the De-

centralized Identiﬁer (DID), blockchain, and Veriﬁ-

able Credential (VC). DID is a unique cryptographic

global identiﬁer. W3C standardized this system in

late 2021 for decentralized, persistent, and crypto-

graphically veriﬁable identity creation and resolution

(Serto Suite Documentation, 2023),(Shilina, 2022).

3.1 DID Mechanism

The DID serves as a unique identiﬁer, offering access

to a speciﬁc value from a veriﬁable data registry -—

an essential DID document DIDstring: document.

This document contains details on the DID controller,

cryptographic keys, and potential external references.

The controller, acting as the document’s key, has sole

authority to modify it. Notably, the controller might

differ from the DID subject (e.g., a CEO controlling

a company’s DID). Subjects can encompass individu-

als, institutions, data models, etc.

The W3C standard does not specify a preferred

veriﬁable data registry, so for example blockchain is

not mandated. However, for improved quality and

security, an ideal registry should possess the follow-

ing key attributes: (1) Immutability: prevent unautho-

rized identiﬁcation changes. (2) Longevity: Ensure

identity preservation. (3) Auditability: record every

change. (4) Decentralization: align with decentral-

ized identiﬁer concept, avoiding central data control.

(5) Single source of truth: A subject should be in a

single ledger for data accuracy and non-repudiation.

Blockchains address needs one to four but not the

ﬁfth. Blockchain innate properties, addressing points

one to four, are not contingent on external data checks

prior to processing and storage. Addressing point ﬁve

forms part of our research focus here.

WEBIST 2023 - 19th International Conference on Web Information Systems and Technologies

536

3.2 Components

The DID-based identiﬁcation consists of three main

interacting components: the controller, the document

and the veriﬁable credentials.

DID Controller. To avoid confusion, the data struc-

ture DID will be named DID controller here. The DID

is a self-sovereign, portable, veriﬁable, decentralized

identity that lasts a lifetime and is implemented in the

form of a string that must follow the following syntax:

URI scheme identifier: identifier for the

DID method: DID method-specific identifier.

The URI scheme identiﬁer is always a “did”. The

method is a W3C-jargon for the different materializa-

tions of the veriﬁable data storage, which might be a

generic one or custom-made. In this veriﬁable data

storage, the DID document can be found. Btcr means

the bitcoin blockchain, for example. The two ﬁrst

components of the DID string (uri+method) are ﬁxed,

the third part might be redeﬁned by the method to

adapt the string for the local information necessities.

The sequential structure of the third part might be

even changed for a sequence of strings that meet one

given standard. Cosmos, for example, developed the

DID further in four different versions to adapt it to

its interoperable reality; a DID string that carries the

zone would be adequate, e.g., for Cosmos:

cosmos:version:chainspace(test,mainnet):

namespace:unique-id.

The following DID corresponds to a DID doc-

ument stored in the ”regen” testnet in the NFT

“ecocredit” namespace (Andrieu et al., 2022):

did:cosmos:1:regentest:ecocredit:

1Kpg3KJPOIarthPWf8HHyy

DID Document. The document retrieved from the

data registry via DID key is a DID document which

contains data related to the DID subject, including

cryptographic materials (keys) and possible external

references, such as a reference to an alternative

identiﬁcation method, a service reference, amongst

others. It is usually created/issued in one standard

format (JSON or JSON-LD). The controller creates

the DID document and could change it (if it is not

stored in an immutable storage), whilst the subject

is identiﬁed by it. In some cases, the subject and

controller might be the same. Whether the DID

standard allows changes to be made it is not clear

(W3C, 2021). A sample DID document (Serto Suite

Documentation, 2023) is:

"@context": "https://www.w3.org/ns/did/v1",

"id": "did:example:123456789abcdefghi",

"authentication": [

"id": "did:example:123456789abcdefghi#keys-1",

"type": "Ed25519VerificationKey2018",

"controller": "did:example:123456789abcdefghi",

"publicKeyBase58": "H3C2AVvLMv6gmMNam3u

VAjZpfkcJCwDwnZn6z3wXmqPV" ],

"service": [

// used to retrieve Verifiable Credentials

associated with the DID

"id":"did:example:123456789abcdefghi#vcs",

"type": "VerifiableCredentialService",

"serviceEndpoint": "https://example.com/vc/"]

Veriﬁable Credentials. The DID string is a mecha-

nism for indexing a user or issuer public key in the

blockchain, while the VC is a claim or attestation

related to the DID subject. The DID is the means

and the VC is the ﬁnality of the process: a crypto-

graphically signed claim, whose legitimacy can be

proven by a reverse cryptographic process using a

public key stored in the blockchain. A VC can be

a diploma, a birth certiﬁcate, the identiﬁcation name

of a user or any piece of information related to one

digital/physical subject.

3.3 Drawbacks of the W3C Standard

According to our analysis, the most signiﬁcant prob-

lem of the DID mechanism as designed by the W3C

is the fact that it is not interoperable. The reasons for

this mechanism design can be assumed as follows:

1. It was designed in 2020/2021 for the then hetero-

geneous and fragmented state of blockchains.

2. Interoperability was not a focus during the devel-

opment, especially because the year before the re-

lease (2020) saw an explosion in market capital-

ization of tokens, and it seemed back then there

would be enough users for the biggest networks.

3. The developers visualized the interoperability in

DIDs would or should be better implemented

through another mechanism in the blockchain

software stack, for example with an API, a local

logic of each application or a layer 2 or 3 solution.

3.4 W3C Standard and Blockchain

The DID standard as deﬁned by the W3C can be im-

plemented on the Web 2.0. The W3C documentation

does not afﬁrm that the key storage must be made in

the blockchain. Nonetheless, it the DID implemen-

tation and expansion in number of protocols can be

expected in a Web 3.0 iteration because:

1. Storing the keys outside an immutable ledger

(blockchain) would threaten the non-repudiation

of the communication that happens in name of

that DID (alias the VCs).

Decentralized Identiﬁcation and Information Exchange in Distributed, Blockchain-Based Internet Architectures: A Technology Review

537

Figure 1: An E-commerce example.

2. According to our research, there is no implemen-

tation of the DID in the Web 2.0 currently in use.

3.5 Process for the User

Fig. 1 illustrates the on-boarding and checkout proce-

dures implementing the DID and the VC. Firstly, the

customer logs into the platform with the DID stored

on the wallet. The customer proceeds to checkout and

the website sends a request for the wallet of personal

data such as name, age, and the payment gateway au-

thorisation. The wallet formulates the request as a

push-up notiﬁcation for the customer who must ac-

cept or deny it. After the customer approval, the hash

of the customer’s personal data is sent in the form of

VC together with the issuer’s (the state’s) DID string.

With help of the DID string, the e-commerce applica-

tion locates the issuer’s public key in the blockchain

and uses it to decrypt the hash of the customer’s per-

sonal data, conﬁrming his or her identity.

3.6 Process for Business/Software Actor

Fig. 2 shows a generic business process that imple-

ments the DID and the VC. Firstly, it is necessary to

clarify some concepts implemented in the diagram.

The process is triggered with an identiﬁcation re-

quest sent to the DID protocol. The DID protocol –

most likely the wallet part – will formulate two re-

quests: one for the login with password and another

one for the authorization to transfer the data. If the

user types the password wrongly, the password re-

quest is repeated, and if the user denies the transfer-

ring of data, the process is aborted at the application

level. If both password and data transferring requests

are successful, the process continues with the encrypt-

ing of the user’s data in the level of the DID protocol

with the private key of the issuer. In this same task,

the data is encapsulated with the DID of the issuer,

and after that it is sent to the application layer. The

application layer receives this package with encrypted

data and DID and searches in the blockchain for the

key-value pair DID:public key. If the key-pair is

not identiﬁed, the process terminates instantaneously,

else the decryption of the data is executed next (the

decryption is included in the sub process App Busi-

ness Process). With the decrypted data, the decen-

tralized application business process can be executed,

and the process terminates in its successful path.

4 DECISION FRAMEWORK

A objective is the development of a decision frame-

work, helping developers to select a protocol and

blockchain platform for an identity management so-

lution. This is based on a review and classiﬁcation

of protocols. After an initial state-of-the-art assess-

ment, 17 protocols implementing the DID system as

standardized by the W3C were found. We used a two-

phased procedure for creating the decision framework

together with a group of criteria and of questions for

the ﬁrst and the second phase, respectively. Fur-

thermore, a systematic review of the ofﬁcial docu-

mentation and white papers related to each protocol

was made in order to answer the questions and as-

certain the previously established criteria. The de-

cision framework contains a pre-deﬁned number of

steps that can assist the choice of one protocol when-

ever the business and identiﬁcation requirements of

the decentralized application are clearly deﬁned. It

is visually represented by the decision tree. Further-

more, for validation and illustration, a decentralized

application with a prototypical identiﬁcation need is

WEBIST 2023 - 19th International Conference on Web Information Systems and Technologies

538

Figure 2: A decentralized identiﬁcation in a generic business process.

Table 1: An excerpt from the original decision matrix.

Protocol/Criterion Updated GitHub Updated Website Part Conferences Wallet works

Serto no no no n.a.

civic.com yes yes yes no

dock.io yes yes no yes

speciﬁed, used as input for the decision framework

and as a result one protocol is chosen.

4.1 DID-Implementing Protocol

A DID-implementing protocol consists of an API

containing classes, objects and methods for pro-

cedures related to the DID identiﬁcation and PII-

exchanging mechanism, such as:

• Creating the DID string and the set of public and

private keys.

• Storing the key-pair value DIDstring:public key in

the blockchain in an indexed way.

• Indexing the same key-pair value at user wallet.

• Signing one VC and passing the combo [ DID-

string of the issuer + hash/VC + claimed message

] to another user

• Receiving the combo [ DIDstring of the issuer +

hash/VC + claimed message ] and verifying the

authenticity of the message

The latter two might be executed at application

level, but the DID protocol must at least pass the

combo [ DIDstring of the issuer + hash/VC

+ claimed message ] to the application, where it

will be transmitted and/or received and decrypted.

4.2 Methodology and Construction

After an initial review of the selected projects’ doc-

umentation, it became evident that some protocols

needed exclusion due to obsolescence or other rea-

sons. This led us to a two-phase approach: exclu-

sion and inclusion. In phase one, unsuitable protocols

were eliminated, while phase two categorized remain-

ing ones based on their characteristics and relevance.

Both phases involved systematic reviews of the avail-

able protocol materials, including white papers and

ofﬁcial communications. Phase one aimed to address

questions as follows: (i) criteria for a protocol’s in-

eligibility in (D)app integration and (ii) ideal fea-

tures when choosing a DID-implementing protocol.

These questions yielded yes-no criteria, such as as-

sessing wallet-based protocols’ ease of DID creation

and obsolescence. Phase two focused on protocol dis-

tinctiveness and relevance to business needs, using

the following questions: (i) blockchain platform and

Decentralized Identiﬁcation and Information Exchange in Distributed, Blockchain-Based Internet Architectures: A Technology Review

539

its position in the scalability-security-decentralization

trilemma and (ii) protocol interoperability.

The inclusion criteria were deﬁned after phase

one, taking into account the protocols left. Phase two

aimed to align each protocol with speciﬁc business

process needs or (D)app requirements, often necessi-

tating sub-criteria for differentiation. Ultimately, this

process facilitated the mapping of each protocol to

unique business necessities or (D)app requirements.

The construction of the decision framework fol-

lows the two phases deﬁned above.

4.3 Selection Criteria

We consider three exclusion criteria:

1. The Obsolescence of the Project: Given the recent

W3C DID standard publication and the dynamic

nature of the darea, constant protocol evolution is

imperative. Software maintenance must consider

factors like security enhancements and blockchain

ecosystem adaptations. Project activity indicators

include factors such as GitHub activity, roadmaps,

team engagement in workshops, and social me-

dia updates. Ongoing observation clariﬁed which

protocols met this criterion.

2. Proprietary Software: Integrating proprietary so-

lutions into open-source platforms poses licensing

challenges. To avoid compliance issues, both app

and DID framework should be from the same ven-

dor. Framework integration assumes license com-

patibility (often lacking in proprietary software).

3. Testing of Wallet-Based Protocols: Some pro-

tocols integrate at the app layer, while others

closely collaborate with wallets, acting as iden-

tity/password managers. Wallet-based protocols

underwent guided tests for creating DIDs.

A ﬁrst protocol division based on Ethereum compati-

bilty as one of the key platforms resulted in two exclu-

sive groups: (1) Ethereum and Ethereum Virtual Ma-

chine (EVM) compatible; (2) interoperable and ag-

gregating protocols.

Ethereum or EVM Compatible: Running on EVM-

compatible blockchains widens user reach due to

Ethereum’s market share. EVM executes smart con-

tracts, and Ethereum’s popularity promises greater

user interaction. Arguments for EVM-based proto-

cols: (1) Dapp users engage with Ethereum’s ecosys-

tem. (2) Potential network effect favors protocols on

widely-used blockchains. However, Ethereum lacks

interoperability and faces scalability and price issues.

Subdivision criteria for the Ethereum category are

the following: (1) Protocol is Ethereum-based. (2)

Protocol is EVM-compatible with higher scalability:

Binance Smart Chain-based protocol.

Interoperable and Aggregating Protocols: Origi-

nal DID and blockchain designs lacked interoperabil-

ity, causing issues like identity fragmentation. To ad-

dress this, two imperfect approaches emerged: inter-

operability and aggregation. Interoperable protocols

operate within an interoperable ecosystem, while ag-

gregation handles data communication between non-

compatible networks.

• Interoperable protocols solve logic transforma-

tion across networks, but they’re limited to spe-

ciﬁc ecosystems like Polkadot and Cosmos. Here,

there are no sub-criteria for interoperability proto-

cols due to their ecosystem similarity.

• Aggregation protocols bridge data communica-

tion gaps between non-compatible networks but

require manual logic translation. Sub-criteria for

aggregation protocols are as follows: (1) Protocol

has a blockchain of its own. (2) Protocol doesn’t

have its own blockchain.

4.4 Application of the Decision Criteria

In this part, the above deﬁned decision process with

a series of steps will be applied. For the ﬁrst part,

the exclusion criteria, it is not necessary to deﬁne a

speciﬁc context. On the other hand, the second part

with inclusion criteria requires the deﬁnition of a spe-

ciﬁc context, more concretely said, a contextualized

decentralized application.

The initial list of DID-implementing protocols

found was: Litentry, civic.com, kilt.io, ontology,

selfkey, XSL, veramo.io, metadium, dock.io, Ce-

ramic, Microsoft ION, blockpass, remme.io, valid-

ity.tec, synaps, IBM Blockchain Identity, serto

4.4.1 Exclusion Criteria

Obsoleteness and proprietary software were decided

based on the documentation and resources available.

The wallet decison required testing, which had the

following results. Kilt.io successfully passed, offer-

ing clear instructions and easy DID access. Selfkey,

however, caused problems as exhaustive research and

app exploration failed to yield DID creation.

Thus, the initial protocol list was reduced by ap-

plying the exclusion criteria one-by-one:

1. After excluding the obsolete projects, the list

reduces to: Litentry, civic.com, kilt.io, self-

key, XSL, metadium, dock.io, ceramic, IBM

Blockchain Identity.

WEBIST 2023 - 19th International Conference on Web Information Systems and Technologies

540

2. After excluding the proprietary software-based:

Litentry, civic.com, kilt.io, selfkey, XSL, meta-

dium, dock.io, Ceramic.

3. After excluding the non-functioning wallet-based

tested protocols: Litentry, kilt.io, XSL, metadium,

dock.io, Ceramic.

4.4.2 Inclusion Criteria

The classiﬁcation of protocols following the inter-

operability criteria is presented in Table 2. Table 3

shows a discussion of interoperability concerns.

To allow a technical comparison, we also provide

an analysis of the blockchain throughput in Table 4.

We already said, that the for second phase, the

application context plays a role (Dodevski and Tra-

jkovik, 2018; Guggenberger et al., 2020). In this

phase, application requirements guide our choice of

an e-voting Dapp, serving as an example of a web

3.0 service needing an identiﬁcation system. Such

criteria extend to other web 3.0 services reliant on au-

thentication, including decentralized exchanges, DeFi

lending, DAOs, and voting systems. The DID utility

extends to future DeFi services like credit rating cre-

ation for borrowers. The e-voting app targets speciﬁc

contexts, such as city council representative elections.

Interoperability and aggregation concerns for the

chosen app context are: (1) Ethereum + EVM com-

patibility or Aggregation + Interoperability: Interop-

erability (2) Interoperability or Aggregation: Given

Polkadot-centric interoperability, aggregation is pre-

ferred. (3) Aggregation Protocol with or without its

own blockchain: Litentry’s own blockchain suits ex-

clusive DID management or Dapp hosting.

In the e-voting context, the DID serves a utili-

tarian role, authenticating users and validating votes.

The selected protocol should interact with diverse

blockchains for adaptable e-voting implementations,

making an aggregation protocol without a dedicated

blockchain, like Ceramic, a ﬁtting choice.

The integrity of the decision can be validated ei-

ther by proving the quality of the decision procedure

or through illustration by implementing the chosen

protocol (Ceramic for the given context) as a baseline

identiﬁcation architecture in one production-case of

the exemplary business process (e-voting) and testing.

Given that a creation, implementation, and testing of

do not lie within the scope of this project, greater dili-

gence will be put into the evaluation of the correct-

ness and completion of the decision protocol. Never-

theless, the implementation of one illustrative DID as

identiﬁcation baseline is provided later with the aim

of clarifying the achievability of this implementation.

4.5 Decision Tree

A decision tree is a representation of the steps of the

decision process. It acts here as a summary of the

framework created after the deﬁnition of the decision

criteria. The aim was to differentiate the protocols

as much as possible, such that the decision frame-

work would ﬁt the largest spectrum of decentralized

projects (and their requirements). The consequence of

this work is the fact that the tree has leaf nodes with

only one protocol, except for kilt.io and dock.io. A

visualization of the tree can be found in Fig. 3.

5 DECISION PROCEDURE

EVALUATION

The protocol’s feasibility was assessed in the ﬁrst half

of 2023, considering digital identiﬁcation systems,

business processes, and current DID-implementing

protocols. Characteristics were evaluated uniformly,

without arbitrary prioritization due to undeﬁned ap-

plication domains. A speciﬁc concern is the up-to-

dateness and extensibility of the decision framework.

The extensible decision framework, representing ac-

cumulated knowledge, suits any cognitive identiﬁca-

tion process requiring PII exchange in digital busi-

ness. The protocol remains viable unless: (1) new

DID protocol enters production; (2) a listed protocol

exits the market; (3) major disruptions affect base el-

ements; (4) the blockchain coins’ market capitaliza-

tion is disrupted; (5) key digital economy actors im-

plement protocols. Adapting the framework for item

1 or 2 is simple, while other scenarios demand a full

decision procedure reformulation.

Currently, a few functional DID-implementing

protocols exist after the 2022 Crypto crisis, which is

reﬂected in the current list. Larger ecosystems like

Polygon and Cosmos lack DID protocols. Ceramic

stands out, sharing DID across blockchains as an ap-

plication layer solution.

6 DID SYSTEM

IMPLEMENTATION

The scope of this implementation consists of creat-

ing a functional decentralized application for the cre-

ation of a DID, which string ought to be posted in

the blockchain as an index to the public key. The

objective is providing an implementation and deploy-

ment in order to investigate viability, feasibility and

ease of integration into any digital business process.

Decentralized Identiﬁcation and Information Exchange in Distributed, Blockchain-Based Internet Architectures: A Technology Review

541

Table 2: Protocols divided following deﬁned interoperability criteria and sub-criteria.

Interoperable or Aggregating Interoperable or Aggregating

Ethereum + EVM Compatible Interoperable Aggregating

Ethereum: Metadium more scal-

able: XSL (Binance smart chain)

Polkadot: kilt.io, dock.io With a blockchain of its own: Litentry

Without a blockchain of its own: Ceramic API

Table 3: Pros and Cons of Interoperability-based and Aggregation-based protocols.

Interoperability Aggregation

pros Prefabricated logic, one DID enough Network effect, increase scalability

cons

Protocols are incipient, no real interoperability

within big chains

Protocols are middlemen APIs. No token of its own

(exception Litentry). Potential translation issues

Table 4: The Throughput of the blockchains that have active DID protocols, measured in TPS (transactions per second).

Blockchain Maximum TPS Average TPS

Ethereum

20 (Blockchair Blockchain Services,

2023)

13-15 (Blockchair Blockchain Services,

2023)

Binance Smart Chain

300 (BSC Binance Smart Chain News,

2023)

40 (BNB Smart Chain Explorer, )

Polkadot 1,000 (Coinbase Documentation, 2023) Information not found

The initial intention was to provide an interoperable

implementation with Ceramic, based on the decision

process and documented experience with a previous

implementation provided on GitHub (Dabit, 2023).

Nevertheless, due to continuously changing APIs, an

Ethereum-based implementation was provided to an-

swer these questions: (1) What is the feasibility of

the implementation of protocol for managing DIDs?

(2) What are the drawbacks of the DID-implementing

protocols? (How) Could they be improved? We report

on problems that arose during the implementation that

would limit feasibility and/or ease of implementation.

6.1 Ceramic Protocol

The Ceramic Network is a group of open-source APIs

for storing, updating and retrieving data from de-

centralized networks (Ceramic, 2023), that has three

main usability branches, amongst which is the sup-

port to the creation of apps with interoperable DID

storage and communication. The way in which in-

teroperability is implemented and operated in Ce-

ramic can be seen in Fig. 4. One of Ceramic’s

products is named Decentralized Identiﬁer and pro-

vides the client with methods for creating and retriev-

ing DIDs, which is interoperable with seven differ-

ent blockchains, amongst which Cosmos, Ethereum,

Filecoin and Polkadot (DID Toolkit, 2023). This in-

teroperability can be easily implemented in code with

a switch-case structure at the moment of creating a

data proﬁle that accumulates the DID data and inter-

acts with the blockchain.

Furthermore, Ceramic can interact with already

existing wallets – of which most importantly Meta-

mask – which avoids the situation in which the user

must download a wallet and manage its credentials

for each DID created (Ceramic Developers, 2023).

Another relevant reason for implementing APIs from

Ceramic is that the JavaScript DID is coded in Type-

Script, which makes its implementation and integra-

tion into other code structures less challenging com-

pared to other blockchain-related APIs, where inter-

action happens mostly in Rust, a recently developed

and not so largely diffused language.

6.2 Initial Implementation

The objective is to build an interface for Ceramic for

interacting with Ethereum to read or create a DID

reference. Using TypeScript, the main Ceramic pro-

tocol functions like 3id-did-resolver (Ceramic Net-

work, 2023) inﬂuenced a React app design. The

app is divided into front-end (React App, JavaScript)

and back-end (Ceramic APIs, blockchain). Ini-

tially, code was based on a tutorial, but libraries 3ID

and IDX were replaced by ’@didtools/pkh-ethereum’

and ’composeDB’ (ComposeDB on Ceramic, 2023).

ComposeDBonly works in Linux IDEs. Issues arose

with the DID class of the ’dids’ package, preventing

successful implementation. This class creates a skele-

ton DID structure, authenticates sessions, and con-

nects to Ceramic’s endpoint client. The skeleton can

be replaced with actual data from the IDX library.

6.3 Second Implementation

The aim is creating an application that writes a

DID on the blockchain. Given that the data con-

WEBIST 2023 - 19th International Conference on Web Information Systems and Technologies

542

Figure 3: The Decision Tree for Protocol Selection for E-Voting.

Figure 4: Example of Interoperability in Ceramic.

Figure 5: The Libraries Implemented for the DID-Dapp.

cept of DID is not provided by any JavaScript

Ethereum library, it must be created within the

application. Fig. 5 shows the libraries used for this

implementation. The DID is a mechanism for the

indexing of the public key in the blockchain, and

that the DID string is this index. The most efﬁ-

cient option for indexing information on Ethereum

lies in the transaction hash, which will concate-

nated with the method to create a DID string such as

did:ethr:0x988d147855e7d02081631d0c0416e96

0d8139b4e6a657c45822a1a5718bec36d. The pub-

lic key stored in the blockchain is the wallet address.

The React Native baseline was maintained, be-

cause the JavaScript library ’ethers’ (Ethers Ethereum

Library, 2023) allows interaction with Ethereum

mainchain and testchain (Goerli). Fig. 6 displays the

smart contract with which method the application in-

teracted. Whether the interaction is made with the

mainchain or in the testchain depends on the user’s

conﬁguration of the wallet and on the location of the

smart contract to interact with. Two functioning Ce-

ramic libraries are implemented (’did-session’ and

’@didtools/pkh-ethereum’) to collect the user’s

authorization for the session and for the access to wal-

let funds in the form of a wallet pop-up.

Figure 6: The Smart Contract in Solidity.

A React Native application is created, followed

by a smart contract in Solidity (here in the Remix

online IDE) to receive a string input (public key)

and write it to the blockchain. This contract must

be deployed only once, and must be copied into the

JavaScript code. Based on the ABI and contract

address, the JavaScript code can access the method

storePubKey() for posting the public key and passed

the previously collected wallet address as parameter.

7 CONCLUSIONS

The feasibility of decentralized data exchange archi-

tectures raises concerns beyond technological issues.

While this research focused primarily on the technical

aspects, several crucial factors require attention.

In evaluating the potential for decentralized iden-

tiﬁcation to consolidate, factors beyond privacy com-

pliance need an analysis. Economic, legal, and so-

Decentralized Identiﬁcation and Information Exchange in Distributed, Blockchain-Based Internet Architectures: A Technology Review

543

ciological inﬂuences hold considerable sway. The

combination of high entry costs and network effects

creates a capital risk that could discourage participa-

tion from both identity providers and business actors,

potentially leading to an oligopolistic market lacking

user choice. This underscores the necessity of well-

designed technical elements to prevent data misuse.

Market-driven forces further complicate matters.

Sustainable business models for providers and incen-

tives for user adoption remain currently unanswered.

The transition from centralized routines to decentral-

ized ones relies on user willingness to migrate from

familiar systems. Moreover, third-party actors need

compelling reasons to embrace these changes.

Human behavior and perceptions play a vital role.

Encouraging users to trust information to decentral-

ized identiﬁers, while motivating them to transition

from established systems, presents challenges (Le

et al., 2022). Additionally, addressing user awareness

and engagement remains vital for success of the DID

concept.

REFERENCES

Andrieu, J., Spies, L., and Conway, S. (2022).

did:cosmos method speciﬁcation. https://github.com/

EarthProgram/did-cosmos/blob/main/README.md.

Blockchair Blockchain Services (2023). Ethereum trans-

actions per second chart. https://blockchair.com/

ethereum/charts/transactions-per-second. [accessed

Sept 05, 2023].

BNB Smart Chain Explorer. Binance smart chain log and

statistics (average tps). https://bscscan.com/. [ac-

cessed Sept 05, 2023].

Bowers, D. M. (1988). Principles of access control and per-

sonal identiﬁcation systems. In Bowers, D. M., editor,

Access Control and Personal Identiﬁcation Systems.

Butterworth-Heinemann.

BSC Binance Smart Chain News (2023). Bi-

nance, bnb chain transaction rates (tps).

https://bsc.news/post/bnb-chain-is-the-go-to-

blockchain-for-developers-why-is-it-special. [ac-

cessed Sept 05, 2023].

Ceramic (2023). Ceramic – the composable data network.

https://ceramic.network/. [accessed Sept 05, 2023].

Ceramic Developers (2023). Why ceramic? https:

//developers.ceramic.network/learn/features/. [ac-

cessed Sept 05, 2023].

Ceramic Network (2023). Ceramic github project.

https://github.com/ceramicnetwork/js-ceramic/blob/

develop/packages/3id-did-resolver/src/index.ts.

[accessed Sept 05, 2023].

Coinbase Documentation (2023). What is polka-

dot. https://www.coinbase.com/learn/crypto-basics/

what-is-polkadot. [accessed Sept 05, 2023].

ComposeDB on Ceramic (2023). Composedb docs. https:

//composedb.js.org/docs/0.4.x/introduction. [accessed

Sept 05, 2023].

Dabit, N. (2023). Sign in with ethereum & decen-

tralized identity with ceramic, idx, react, and 3id

connect, github repository. https://gist.github.com/

dabit3/ba326e47e4882073bd6342dc1998fd16. [ac-

cessed Sept 05, 2023].

DID Toolkit (2023). Add support for a new blockchain.

https://did.js.org/docs/guides/add-chain-support/.

[accessed Sept 05, 2023].

Dodevski, Z. and Trajkovik, V. (2018). Decentralizing

the health information exchange systems-a blockchain

based approach. In 15th Intl Conf on Informatics and

Information Technologies, pages 43–49.

Ethers Ethereum Library (2023). Ethers v6.7.1 documen-

tation. https://docs.ethers.org/v6/. [accessed Sept 05,

2023].

Fukami, Y., Shimizu, T., and Matsushima, H. (2021). The

impact of decentralized identity architecture on data

exchange. In Big Data, pages 3461–3465.

Guggenberger, T., Schweizer, A., and Urbach, N. (2020).

Improving interorganizational information sharing for

vendor managed inventory: Toward a decentralized

information hub using blockchain technology. IEEE

Trans on Engineering Mgnt, 67(4):1074–1085.

Le, V. T., Ioini, N. E., Barzegar, H. R., and Pahl, C.

(2022). Trust management for service migration in

multi-access edge computing environments. Comput.

Commun., 194:167–179.

Pahl, C., Ioini, N. E., and Helmer, S. (2018). A decision

framework for blockchain platforms for iot and edge

computing. In 3rd Intl Conf on Internet of Things, Big

Data and Security, IoTBDS, pages 105–113.

Serto Suite Documentation (2023). What is a did? https:

//docs.serto.id/docs/main-concepts/dids/. [accessed

Sept 05, 2023].

Shilina, S. (2022). What is decentralized identity in

blockchain? Coin Telegraph. [accessed Sept 05,

2023].

W3C (2023). World wide web consortium: Decentral-

ized identiﬁers (dids) v1.0 - core architecture, data

model, and representations. https://www.w3.org/TR/

did-core/. [accessed Sept 05, 2023].

W3C (2021). World wide web consortium - meeting min-

utes 2021-03-30. https://www.w3.org/2019/did-wg/

Meetings/Minutes/2021-03-30-did#section5-8. [ac-

cessed Sept 05, 2023].

Werth, J., Berenjestanaki, M. H., Barzegar, H. R., Ioini,

N. E., and Pahl, C. (2023a). A review of blockchain

platforms based on the scalability, security and decen-

tralization trilemma. In 25th Intl Conf on Enterprise

Information Systems, ICEIS, pages 146–155.

Werth, J., Ioini, N. E., Berenjestanaki, M. H., Barzegar,

H. R., and Pahl, C. (2023b). A platform selec-

tion framework for blockchain-based software sys-

tems based on the blockchain trilemma. In 18th Intl

Conf on Evaluation of Novel Approaches to Software

Engineering, ENASE, pages 362–371.

WEBIST 2023 - 19th International Conference on Web Information Systems and Technologies

544