Self-Sovereign Identity (SSI) Attribute-Based Web Authentication

Biagio Boi

, Marco De Santis

and Christian Esposito

University of Salerno, Fisciano, Italy

Keywords:

Self-Sovereign Identity, Hyperledger Aries, Attribute-Based Authentication.

Abstract:

Web authentication is primarily based on password usage, representing the weakest link in the entire security

chain. The number of services offered over the web is continuously increasing, and with them also the number

of required passwords that users need to create and securely store. Despite various standards for password-less

or multi-factor authentication, another issue is that most web authentication means use an identity provider

(or a federation of providers) advocated to create, manage and check digital identity claims; able to proﬁle

user habits related to web navigation and violate rights in terms of privacy. Recently, we are witnessing a

radical change of perspective, where identity checks and enforcement are moved away from the providers

and more focused on users. Within such user-centric approaches, Self-Sovereign Identity (SSI) has faced

progressive popularity, and some authentication mechanisms based on SSI have been proposed. This paper

aims to describe a solution based on Hyperledger Aries which is capable to achieve zero-knowledge proof

to make an attribute-based authentication and authorization for the web able to cope with the recent legal

obligations in terms of privacy.

1 INTRODUCTION

User authentication is among those solutions needed

by processors to protect personally identiﬁable infor-

mation, as required by the General Data Protection

Regulation (GDPR) (Tamburri, 2020), and the cur-

rent legislation and the recent changes at the national

and European level w.r.t. data protection are promot-

ing a considerable evolution of the authentication and

authorization solutions. In fact, over the past few

years, these mechanisms have undergone signiﬁcant

changes due to technological advances, user behavior

changes, and an increase in cyber threats.

Password-less authentication has emerged as an

alternative to traditional username and password au-

thentication, which moreover aims at solving prob-

lems related to centralized authentication providers.

It uses methods such as biometric authentication,

hardware-based security keys, or one-time codes to

verify the identity of a user without requiring them to

enter a password. Some of the notable changes in au-

thentication mechanisms over the last years concern

the usage of multi-factor authentication (MFA) (Ome-

tov et al., 2018), which aims at increasing the over-

https://orcid.org/0000-0003-3044-5345

https://orcid.org/0009-0004-6514-4168

https://orcid.org/0000-0002-0085-0748

all level of security of the authentication process.

While the improvement of the authentication schemes

is thought to aim for more robust and effective user

identiﬁcation, from the architectural point of view,

they are strongly centralized. Every time requests are

made, identity attributes and access claims must be

directly or indirectly processed by a provider, which

can record all the incoming requests. This represents

a serious concern as it has non-negligible privacy con-

sequences: the provider can proﬁle user habits in the

web navigation. There is a need to move away from

this provider-centric practice to decentralize the iden-

tity and claim management.

Self-Sovereign Identity (SSI) (M

uhle et al., 2018)

is a password-less and decentralized mechanism that

allows identity veriﬁcation without relying on a cen-

tralized authority. The concept of Veriﬁable Creden-

tials (VCs) completely matches such a schema, pro-

viding self-veriﬁable attributes using some crypto-

graphic property. In addition, certain VCs schemes

also introduce Zero-Knowledge Proof (ZKP) to solve

the above problems related to privacy.

In this work, we want to exploit existing Hy-

perledger solutions, such as Aries for proposing

attribute-based authentication based on SSI and ZKP

in the context of web authentication. The novelties

are not limited to the combination of SSI and ZKP

758

Boi, B., De Santis, M. and Esposito, C.

Self-Sovereign Identity (SSI) Attribute-Based Web Authentication.

DOI: 10.5220/0012121400003555

In Proceedings of the 20th International Conference on Security and Cryptography (SECRYPT 2023), pages 758-763

ISBN: 978-989-758-666-8; ISSN: 2184-7711

 2023 by SCITEPRESS – Science and Technology Publications, Lda. Under CC license (CC BY-NC-ND 4.0)

but we demonstrate how well-established session han-

dling mechanisms, such as JSON Web Token (JWT)

(Jones and Sakimura, 2015), can still be applied in

this context.

2 STATE OF ART

To solve problems related to user tracking on activ-

ities done with SSO credentials, the concept of giv-

ing users the possibility to store their credentials for

authentication over multiple platforms started to take

place. The ﬁrst provider moving in such a direction

is FIDO (Fast Identity Online), which aim is to cre-

ate a series of open standard authentication protocols

enough stronger, and able to cut out every kind of

password-based mechanism. The ﬁrst proposed pro-

tocol has been FIDO UAF (Universal Authentication

Framework Protocol), able to use a ﬁngerprint scan-

ner as an authentication mechanism. The real change

happened in 2019 when FIDO2 was presented. It is

an evolution of the ﬁrst version in terms of use cases

and security, such protocol is based on the paradigm

of public/private key pair for user authentication in a

secure way, without the need for a password.

A study on possible problems coming from the

adoption of FIDO2 has been conducted by (Ghor-

bani Lyastani et al., 2020), which highlights the prob-

lems in recovery at scale and authenticator revocation.

These two problems are related to the implementation

of FIDO2 which does not support a veriﬁable registry

containing the valid keys, making it impossible for

users to invalidate the authenticator device in case of

steal. Blockchain support may solve such problems,

by adopting a veriﬁable data registry in which stores

released and valid keys and revoke stolen identity au-

thentication data. A different implementation of SSI

is based on VCs and Blockchain, which aim is to pro-

vide a digital identity using such veriﬁable credentials

in conjunction with a revocation registry, able to be

updated when a data branch occurs.

(Ferdous et al., 2023) describe an identity man-

ager framework: SSI4Web, based on blockchain and

SSI for Web. It creates an immutable distributed reg-

ister of user transactions. In such a way, users hold

their VCs and can share them based on their volun-

teer, with a blockchain system that registers every op-

eration done over them. For example, a service may

ask the user to present his credentials to conclude a

transaction or access a service. A commercial service

exists, namely, Sovrin (Reed et al., 2016), which is

the ﬁrst public-permissioned blockchain designed to

support SSI and VCs using the architecture offered

by Hyperledger Aries and Indy. VCs and SSI are

taking the advent of the market of authentication sys-

tems; digital identity demands are increasing and with

them, the guarantee of privacy, which must agree with

GDPR, too.

Anyway, poor studies have been conducted on the

usage of such solutions as means for attribute-based

authentication and on the security of credentials ex-

change mechanisms, which could be the weakest link

if proper security methods are not implemented. The

proposed system aims at considering SSI for attribute-

based authentication in conjunction with ZKP; the

overall aim is to reduce the data shared by users using

a decentralized approach while guaranteeing access to

reserved resources.

3 DESIGN

The proposed architecture takes into consideration the

SSI paradigm to guarantee the users’ privacy and se-

curity; creating an ecosystem in which users are en-

couraged to use digital services thanks to more secure,

reliable, unique, and fast authentication. In what fol-

lows the architectural design is discussed, and we will

refer to the VC as that deﬁned by W3C (Sporny et al.,

2022).

3.1 Decentralized Trust Management

To realise decentralized trusted authorities, a veriﬁ-

able, always available, and tamper-proof registry is

needed. Two main approaches exist: Blockchain or

Distributed Public Key Infrastructure (DPKI).

Blockchain is an immediate alternative that jumps

to the eye when talking about decentralization, de-

spite it isn’t the only available one, it can be con-

sidered the best choice in comparison with an ap-

proach based on DPKI. As discussed in the study con-

ducted by (Li et al., 2020), the major solutions based

on DPKI which do not use Blockchain are log-based

PKI and Web of Trust, but problems exist for both

solutions. The ﬁrst one ignores data consistency in

the log server, while the second one does not provide

identity retention and is not friendly to new incoming

members.

In such a Blockchain, or a Key Infrastructure, a

public and veriﬁable registry, must always be avail-

able for the veriﬁcation of proofs presented by the

users. This register will contain information about the

validity of released Veriﬁable Credentials (VCs), and

more importantly, information about the identity of

issuing agents.

Optionally, based on the implementation choice

is possible that such a registry will also be used for

Self-Sovereign Identity (SSI) Attribute-Based Web Authentication

759

the users’ identiﬁcation, as explained in the following

subsection.

A Blockchain solution is preferred on DPKI.

A possible considered solution that follows the de-

scribed requirements is more generally known as

Public Permissioned Blockchain, where a Trusted Au-

thority (TA), for the security of the proposed sys-

tem, manages validation nodes by choosing only the

trusted nodes and admitting new nodes by checking

their trustworthiness. Validation nodes are those re-

sponsible for certifying an issuer’s identity and vali-

dating new credentials issuing. Notice that TA so de-

ﬁned must not be confused with a Certiﬁcate Author-

ity (CA) widely known within the context of Public

Key Infrastructure (PKI); TA is the node of the net-

work responsible for managing the Blockchain and

does not certify or validate any Credentials.

The public part consists of Public Ledger: a reg-

istry containing all the information needed from VCs

by providing a decentralized and tamper-proof way

to store and verify veriﬁable credentials, enabling or-

ganizations and individuals to establish trust and se-

curely share information without relying on a central

authority.

3.2 Decentralized Identiﬁcation

In order to deploy a decentralized authentication

mechanism, it’s necessary to deﬁne how to identify

users within the decentralized context. In a traditional

centralized system users are identiﬁed by a username,

an email, or a context-related identiﬁer released by a

central entity, which associates the released identiﬁer

with a key, which is the demonstration of being the

owner of such identity. In our context, there is no

central entity able to do this, but instead, there is a set

of issuers that release identity and related identiﬁers.

The World Wide Consortium (W3C) has deﬁned

the Decentralized Identiﬁers (DID) (Sporny et al.,

2021) completely compliant with the VC data model.

The DID Method is used for referring to a precise im-

plementation of DID speciﬁcation, often associated

with a particular veriﬁable data registry. Some meth-

ods make use of a Distributed Ledger Technology

(DLT), such as the case of SOV using the Sovrin Net-

work; while other ones use the cryptographic property

of the method, such as the case of key based on pub-

lic/private key pairs, to verify the ownership of a DID.

Since a veriﬁable data registry has been adopted

by architectural choice, a method based on such a

registry could be better in terms of security and per-

formance in the veriﬁcation of identity, but thanks to

the structure of the proposed architecture, also other

kinds of DID Methods are implementable.

3.3 Credentials Exchange &

Authentication

Following what is deﬁned in data model (Sporny

et al., 2022), a VC must include Credential Meta-

data, Claim(s) and Proof(s). The format used for the

proposed architecture is JSON-LD. VC data model

shows the main ﬂow, which can be adopted in our ar-

chitecture. A veriﬁable data registry is used for main-

taining identiﬁers and schemas; while Issuer, Holder,

and Veriﬁer will interact with such register at different

levels. Three main phases must be analyzed: Creden-

tials Issuing, Credentials Presentation, and Creden-

tials Veriﬁcation.

The issuing phase is responsible for the creation of

VCs and related claim(s) and proof(s). An authorized

Issuer can release such credentials by referring to a

created schema, or by reusing an existing one, which

location depends on the implementation of Decentral-

ized Trust Management. VC Data Model agrees on

multiple possible representations of such credentials,

their description is out of the scope of this paper; we

will consider only the case of JSON representation,

which is also the most common. A credential al-

ways refers to a context, which contains the ﬁeld that

must be ﬁlled for the release of valid credentials. It

can be found in a vocabulary way, not blinded to any

Blockchain or registry, which is the case of JSON-

LD credentials, or in a schema, which is the case of

Indy credentials. The currently considered architec-

ture, which is based on Blockchain, supports a veri-

ﬁable data registry, namely the Public Ledger. Such

a choice makes us move in the direction of Indy cre-

dentials which gives us the possibility to handle re-

vocation. To issue new credentials, the Issuer uses a

previously declared schema, available on the public

registry, by asking the Decentralized Trust Manage-

ment to validate this transaction. Once such a trans-

action has been validated it will be published in the

veriﬁable data registry, making it available for veri-

ﬁcation by Veriﬁer. The Holder receives a VC and

stores it in a secure space. It’s possible to consider

the Public Ledger as the veriﬁable data registry in the

case of the adoption of a Blockchain, where only au-

thorized agents can release credentials by interacting

with the registry under the supervision of trustable

nodes. More in detail, this paper is interested in ex-

ploiting ZKP for veriﬁable credentials, for this reason,

the Issuing phase must follow the algorithms deﬁned

in 5.2 (Lodder and Khovratovich, 2019), while the in-

formation included in a so-deﬁned credential can be

found at 3.2 (Sporny et al., 2022).

The presentation phase must be done transpar-

ently, and the Holder must be informed of the infor-

SECRYPT 2023 - 20th International Conference on Security and Cryptography

760

mation which is requested by the veriﬁer. The pro-

posed system takes into consideration also ZKP; this

means that a method able to prevent information dis-

closure must exist, this can be an added value in SSI

and more in general in attribute-based authentication.

In such a schema the Veriﬁer will send a proof request

to the Holder, which is able, by using a series of cryp-

tographic techniques, to create a ZKP of possession

for each attribute requested from the Veriﬁer, formal

algorithms can be found at 7.1, and 7.2 in (Lodder and

Khovratovich, 2019).

In the veriﬁcation phase the Veriﬁer veriﬁes the

quality of a presented credential. Veriﬁers do not in-

teract with Issuers during the credential veriﬁcation

process; this is because the proposed SSI system is

designed to enable individuals to control their digital

identities and personal data, including the credentials

that verify their attributes, without relying on central-

ized intermediaries. Some veriﬁcation methods re-

quire the usage of a decentralized registry - which

is the case of Indy credentials. Moreover, an exam-

ple of self-veriﬁable credentials is done by JSON-LD

credentials which use cryptographic properties for the

veriﬁcation of the validity of a credential. Indy cre-

dentials, instead, directly support a revocation registry

by making them authenticated also in terms of valid-

ity in a given time; for this reason the veriﬁcation step

will involve the Public Ledger.

The attribute that users will share with the Veri-

ﬁer can directly be an email or a role within an or-

ganization. As it’s possible to see in Figure 1, where

the Holder and Veriﬁer are substituted to Browser and

Server resp. - since we are considering the case of

web authentication - the server creates the JWT af-

ter checking the validity of veriﬁable credentials. Af-

ter receiving such a signed token, the client, namely

the browser will use this token for every request; this

is because the JWT is a self-contained token since

the payload contains all requested information about

users, preventing database interrogation at each itera-

tion. In our system, a JWT will contain the value of

veriﬁable credentials, or more properly, in the consid-

ered system, the assertion about a predicate.

4 IMPLEMENTATION

Hyperledger Aries will be considered for the im-

plementation of our proposed architecture. It pro-

vides a shared, reusable, interoperable tool kit de-

signed for initiatives and solutions focused on cre-

ating, transmitting, and storing veriﬁable digital cre-

dentials. Such a solution also includes direct support

for Indy wallet and ZKP thanks to the adoption of

Figure 1: JWT authentication and request schema.

AnonCreds. AnonCreds uses a combination of cryp-

tographic techniques, including ZKP, digital signa-

tures, and encryption, to enable users to prove cer-

tain claims about themselves without revealing their

actual identity. Hyperledger Aries, with the related

implementation named Aca-py, offer the possibility

to create and handle revocation using an HTTP API-

based communication. It also provides API for the

veriﬁcation of credentials using the Public Ledger and

for interacting with the Indy wallet in order to pro-

duce Predicative Proof Presentation (PPP). Since all

communications must be secured, the public key con-

tained in the DIDDoc is used to cipher the requests

coming from a new user.

Figure 2: Overall implementation, characterized by the

three credentials exchange phases.

Figure 2 represents the overall proposed imple-

mentation based on previously described technolo-

gies; three main phases exist, whose description can

be found in the Design section. Our focus will be on

Self-Sovereign Identity (SSI) Attribute-Based Web Authentication

761

phases 2 and 3, related to the Presentation and Ver-

iﬁcation, which are the phases needed for attribute-

based authentication. The Issuing phase can be con-

sidered as already implemented by Sovrin Network,

meaning that Holder already has its SSI, which can be

used to access to Veriﬁer server. Services that want to

use SSI mechanisms for authentication must imple-

ment a JWT mechanism within the server and expose

their API for the connection and for the exchanging

of credentials. The service detects the existence of an

extension and will ask the user to produce PPP about

one or more attributes.

The presentation begins with a Veriﬁer server that

checks if the Holder browser has a Firefox extension;

such an extension is able to communicate with the

server to transmit the Holder agent end-point needed

for using Hyperledger Aries. The extension is con-

ﬁgured for creating a listener on presentation requests

coming from a Veriﬁer; in such a way, each time a

Veriﬁer wants to access Holder VCs, the extension

will be informed and the request will be shown to

the user using the respective interface. At this point,

the Holder will interact with the extension in order

to check which ﬁelds are requested by the Veriﬁer,

and what is more important, the visibility of requested

attributes. To correctly deploy a ZKP of possession

is necessary that Holder does not share information

about the real value of requested attributes but only

assertion about a predicate, in a veriﬁable way. Once

the Holder agrees on producing the PPP, the Firefox

extension will call the local Aca-py end-point for ac-

cept the transmission of PPP. At this point, the Veriﬁer

server has the PPP sent by Holder and needs to verify

it before giving access to the reserved resources. This

veriﬁcation is simply done by using the end-point of-

fered by Aca-py, which consults the Veriﬁable Data

Registry assessing the validity both in terms of truth

and expiration. Once Veriﬁer has veriﬁed the VCs

can respond to the extension with a JWT; such a to-

ken can be used by extension for redirect operations

to reserved pages.

From the security perspective, the communication

between the Holder and the Veriﬁer is secured using

Aries, whose analysis will be considered in the next

section. The Firefox extension does not exchange any

packets with the Veriﬁer, except the communication

of the end-point needed for creating a secure commu-

nication using Aries. The extension can be seen as

a mediator or a means for improving the user expe-

rience. Once the service declares its end-point, the

Veriﬁer searches to such end-point for the DIDDoc,

which will be used by the Aca-Py client to encrypt

the communication and exchange the credentials fol-

lowing the deﬁned schema. The performance evalua-

tion of such an approach is out of the scope of current

work but depends on the performance of public per-

missioned Blockchain and Hyperledger Aries, whose

evaluation has been already conducted and reported

in (Pﬂanzner et al., 2022).

5 SECURITY

The implementation of the proposed architecture has

been explained by considering the Aca-Py agent,

which interacts with the Indy wallet by communicat-

ing over an HTTP channel in according with Hyper-

ledger Aries standards. In what follows, we refer to a

typical user as a Holder, which is a user with VCs that

uses the Aca-Py agent for interacting with the Veriﬁer.

Starting from the STRIDE model (Shostack, 2014)

we highlight all the possible threats, not only referring

to the single agent but considering the overall imple-

mentation. In addition, Forward Secrecy property and

resistance to Replay Attacks can increase the overall

security of communication, in particular referring to

the insecure communication channel.

Spooﬁng attacks are prevented by securing the

communication between agents. Hyperledger Aries

uses DIDComm v1 Encrypted Envelope - and is cur-

rently working on a second version of such a proto-

col. The DIDDoc deﬁnes the key-agreement mecha-

nisms used for the encryption. Tampering attacks are

mitigated thanks to the Blockchain and the messages

being digitally signed. An attacker cannot change

the value of an attribute since it is associated with a

public-facing proof, which is published on the veri-

ﬁed data registry. Such registry also contains infor-

mation on Issuers, namely their DIDs, which means

that if the attackers want to behave as an Issuer must

be able to gain access to their Indy wallet. Wallet ac-

cess is protected using a secret key, whose security

depends on the Issuer’s choice; elevation of privilege

is prevented depending on such choice. The only way

to obtain information for an attacker from a typical

user is by using the Presentation request, which in-

dicates the requested attributes. Information disclo-

sure is prevented thanks to the characteristics of such

a request signed by the Veriﬁer and consequential re-

signed by the Holder, making it impossible for an at-

tacker to steal information since the Holder can verify

the requesting party’s identity. Moreover, the infor-

mation in the veriﬁed data registry is not associable

with any attribute since it only contains data related to

the public-facing proof, not dependent on VCs. For-

ward Secrecy is guaranteed by adopting session keys;

at each session, before communication begins, the

parties share a sort of local DIDDoc, which present

SECRYPT 2023 - 20th International Conference on Security and Cryptography

762

a local public key, which is different from the public

key existing in DIDDoc and which is used for the en-

cryption of the current session communications. Re-

play and Repudiation Attacks are mitigated using the

mechanisms of the message signature, or more pre-

cisely, the DIDComm V1 Signed Envelopes. The cre-

dential presentation is signed by both parties, in such

a way the typical user is sure to answer to the Veri-

ﬁer server, which is unable to behave maliciously, by

re-using the proposed credentials since the presenta-

tion is signed in conjunction with a challenge. DoS

attacks depend on server implementation; a ﬁlter or

ﬁrewall on requests of such a server can be enough to

guarantee a good level of prevention.

6 CONCLUSIONS

A distributed approach based on Blockchain for han-

dling authentication in the context of attribute-based

authentication has been proposed, in conjunction with

a preliminary security analysis. We have planned to

use formal methods, such as ProVerif (Blanchet et al.,

2018), to verify the security of the used communi-

cation protocols. SSIs are increasingly widespread

and interoperable (Yildiz et al., 2022). A more spe-

ciﬁc use case can be found within the context of the

Solid project, which has been considered a promis-

ing solution for e-government services (Sambra et al.,

2016). A schema of ZKP it’s been taken into con-

sideration for increasing the overall level of privacy.

The main advantages in adopting a Blockchain-based

solution are related to the possibility to revoke and

update VCs when not still valid; on the counter limi-

tations of the proposed architecture are related to the

scalability of permissioned Blockchain, required for

secure implementation. Future works may include

these kinds of credentials also in other projects, like

Algorand (Gilad et al., 2017), which offer different

consensus mechanisms, able to guarantee both secu-

rity and scalability.

ACKNOWLEDGEMENTS

This work was partially supported by project SER-

ICS (PE00000014) under the NRRP MUR program

funded by the EU - NGEU.

REFERENCES

Blanchet, B., Smyth, B., Cheval, V., and Sylvestre, M.

(2018). Proverif 2.00: automatic cryptographic pro-

tocol veriﬁer, user manual and tutorial. Version from,

pages 05–16.

Ferdous, M. S., Ionita, A., and Prinz, W. (2023). Ssi4web:

A self-sovereign identity (ssi) framework for the web.

In Prieto, J., Ben

ıtez Mart

ınez, F. L., Ferretti, S., Ar-

royo Guarde

no, D., and Tom

as Nevado-Batalla, P., ed-

itors, Blockchain and Applications, 4th International

Congress, page 366–379, Cham. Springer Interna-

tional Publishing.

Ghorbani Lyastani, S., Schilling, M., Neumayr, M., Backes,

M., and Bugiel, S. (2020). Is ﬁdo2 the kingslayer of

user authentication? a comparative usability study of

ﬁdo2 passwordless authentication. In 2020 IEEE Sym-

posium on Security and Privacy (SP), pages 268–285.

Gilad, Y., Hemo, R., Micali, S., Vlachos, G., and Zeldovich,

N. (2017). Algorand: Scaling byzantine agreements

for cryptocurrencies. In Proceedings of the 26th sym-

posium on operating systems principles, pages 51–68.

Jones, M. and Sakimura, N. (2015). Json web key (jwk)

thumbprint. Technical report.

Li, Y., Yu, Y., Lou, C., Guizani, N., and Wang, L.

(2020). Decentralized public key infrastructures atop

blockchain. IEEE Network, 34(6):133–139.

Lodder, D. M. and Khovratovich, D. (2019). Anonymous

credentials 2.0.

uhle, A., Gr

uner, A., Gayvoronskaya, T., and Meinel, C.

(2018). A survey on essential components of a self-

sovereign identity. Computer Science Review, 30:80–

86.

Ometov, A., Bezzateev, S., M

akitalo, N., Andreev, S.,

Mikkonen, T., and Koucheryavy, Y. (2018). Multi-

factor authentication: A survey. Cryptography, 2(1):1.

Pﬂanzner, T., Baniata, H., and Kertesz, A. (2022). Latency

analysis of blockchain-based ssi applications. Future

Internet, 14(10):282.

Reed, D., Law, J., and Hardman, D. (2016). The technical

foundations of sovrin. The Technical Foundations of

Sovrin.

Sambra, A. V., Mansour, E., Hawke, S., Zereba, M., Greco,

N., Ghanem, A., Zagidulin, D., Aboulnaga, A., and

Berners-Lee, T. (2016). Solid: a platform for decen-

tralized social applications based on linked data. MIT

CSAIL & Qatar Computing Research Institute, Tech.

Rep.

Shostack, A. (2014). Threat modeling: Designing for secu-

rity. John Wiley & Sons.

Sporny, M., Longley, D., Sabadello, M., Reed, D., Steele,

O., and Allen, C. (2021). Decentralized identiﬁers

(dids) v1. 0. w3c.

Sporny, M., Noble, G., Longley, D., Burnett, D. C., Zundel,

B., and Hartog, K. D. (2022). Veriﬁable credentials

data model v1.1.

Tamburri, D. A. (2020). Design principles for the gen-

eral data protection regulation (gdpr): A formal con-

cept analysis and its evaluation. Information Systems,

91:101469.

Yildiz, H., K

upper, A., Thatmann, D., G

ond

or, S., and Her-

bke, P. (2022). A tutorial on the interoperability of

self-sovereign identities.

Self-Sovereign Identity (SSI) Attribute-Based Web Authentication

763