Introduction

On September 17, 2014, the regulation on identification and trust services for electronic transactions in the internal market (eIDAS) entered into force. The European Union adopted eIDAS to create a framework for secure and reliable electronic identification and trust services that ensure cross-border interoperability and provide citizens and businesses with secure and easy-to-use online interactions with public and private services. (European Commission, 2021). Since its implementation in 2017, eIDAS has established a foundation for digital identities in Europe and has been used as the basis for many e-government services (EUR-Lex, 2014). Despite promising secure and supposedly easy-to-use ways to provide electronic identification, only 14 of the 28 member states of the European Union have adopted an electronic identity (eID) in line with the regulation. Taking a closer look at the national level, the adoption of eID services provided by the government is very low. As the most notable example, only 7% of German Citizens have used the German eID so far (European Commission, 2021).

In 2020, the European Commission launched a study investigating why countries in Europe do not adopt digital identities (European Commission, 2020). The report concluded that the existing European identity network does not meet the changing demands for digital identities. It explicitly addresses the fact that the current technical implementation reveals weaknesses. First and foremost, the data set in the current implementation of eIDAS is severely limited and focuses only on the master data of private individuals. Such master data typically comprises core information, e.g., name, address, date of birth, and national identification number. Therefore, additional attributes (e.g., tax attributes, degree of education) and legal entities are currently not covered. In addition, the current system, designed primarily for e-government, limits its use for businesses, resulting in minimal integration of the public and private sectors (European Commission, 2020).

To overcome these limitations, the European Union is working towards a new, European-wide identity network called eIDAS 2.0. This system aims to improve upon the current identity management infrastructure by facilitating the exchange of identity data between public institutions and private companies (European Commission, 2021). One of the key concepts being considered as the foundation for eIDAS 2.0 is self-sovereign identity (SSI) (European Commission, 2021; Preukschat, 2021). SSI is an approach that utilizes blockchain technology to give individuals more control over their own identity data (Wang & Filippi, 2020). By using decentralized identifiers and modern cryptography, eIDAS 2.0 aims to improve privacy and security while making it easier for citizens and also businesses to access a wide range of digital services. This is a significant departure from the current eIDAS infrastructure, which was primarily designed for citizens and the public sector (European Commission, 2021). With SSI, any type of attestation can be represented, opening up new possibilities for the use of digital identities.

Despite its potential benefits, the high costs of implementation and operation of SSI present a challenge and hinder its widespread adoption by the public and private sectors. The initial setup of a new SSI-based pan-European IdM alone is estimated to cost more than 600 million euros, plus the operating costs for public and private organizations during the period of use (European Commission, 2021). Most of the very few research articles on SSI that could help make informed decisions in this area of tensions either focus on the hypothetical opportunities the paradigm has for society in general or on specific technical particularities (Liu et al., 2020). And even though research on blockchain-based IdM generally exists that could provide a first foundation (Dunphy & Petitcolas, 2018; Faber et al., 2019; Sullivan & Burger, 2017), they do not cover all particularities of modern SSI implementations, such as ZKP, accumulators, and the employed standards and how they manifest in business cases.

Due to its complexity, designing effective information systems based on SSI requires a deep understanding of the various use cases and the needs of different stakeholders (Nærland et al., 2017; Treiblmaier & Beck, 2019). Only then can we ensure that the system achieves the necessary privacy, security, interoperability, and scalability. Nevertheless, the theory of SSI system design is still largely undiscovered, resulting in difficulties for organizations, such as government institutions and companies, to fully leverage the potential benefits of SSI systems (Preukschat, 2021; Zhu & Badr, 2018). To bridge this gap in research, we ask the following question:

  • RQ: How can blockchain-based SSI be incorporated for decentralized identity management spanning multiple organizations?

To answer this question, we follow the design science research (DSR) paradigm to ensure rigor and generalizability throughout our research (Gregor & Hevner, 2013; Peffers et al., 2007). In particular, we present an SSI system that allows online retailers to retain multiple Verifiable Credentials (VC) to prove the proper registration as a taxpayer against an online platform (e.g., Amazon, eBay). We chose this use case as a perusing example because (1) existing solutions within this field face typical problems like counterfeiting, privacy issues, and inefficiencies, (2) the use case involves an identity holder that transacts with multiple certificate issuing authorities and verifiers spanning across various organizations, and (3) the incorporated parties involve public institutions as well as private companies demonstrating the ecosystem characteristics of SSI. Therefore, we aim to design and implement an SSI system that replaces the existing paper-based application.

Besides presenting and evaluating the final solution design, we derive four nascent design principles (Baskerville et al., 2018), which we present in the discussion section of this article. The principles are (1) Utilize the multiplicity of roles of actors for scaling the identity ecosystem: SSI provides means for actors to engage in different roles, which greatly improves scalability in comparison to eIDAS, where roles are strictly tied to entities. (2) Consider credentials for multiple applications to facilitate additional use cases: With SSI, credentials are not bound to specific use cases, demonstrating the multipurpose nature of the paradigm spanning both applications within the public and private industry. (3) Recognize the identity holder as the primary controller to ensure seamless processes: SSI is highly user-centric, which means that all processes have to involve the user and are mostly bilateral. Therefore, third parties cannot track the activities of the identity holder. Finally, (4) Use Public DIDs only for credential issuers to minimize privacy issues: SSI typically uses blockchain in contrast to eIDAS. To still provide privacy, identifiers should only be used by parties who intend to issue credentials.

This study contributes to the field of e-government systems and the broader field of identity management in several key ways. Firstly, it provides practical insights into the design and underlying decisions of SSI systems, giving guidance for organizations and institutions looking to implement similar systems. This includes both government institutions and private companies. Secondly, by evaluating the design and implementation of SSI, we shed light on the strengths and weaknesses of this approach. These findings provide valuable insights for any organization looking to adopt SSI and understand the potential benefits and challenges associated with the technology. For example, organizations considering use cases with a high demand for audits may face challenges in executing these with an SSI system. Thirdly, the study provides design principles as guidelines for SSI and blockchain-based identity management systems, contributing to the broader design theory beyond the specific use case. This aligns with the call for guidelines in previous studies (Carter & Ubacht, 2018; Nærland et al., 2017) and can help organizations and institutions to optimize their SSI systems and ensure they meet the needs of all stakeholders.

Related work

Centralized and federated identity management systems

The extensive use of digital identities characterizes our digital, interconnected society. Many digital services in our personal and professional life require identification and identity verification (Cao & Yang, 2010). For handling the identities of their customers and employees, organizations use IdMs. These systems are paramount for the administration of digital identities along the identity lifecycle, which includes the issuance, updating, and revocation of identities (Clauß & Köhntopp, 2001). Thus, they provide an often necessary foundation for trust in digital transaction relationships on electronic markets (Cao & Yang, 2010; Clauß & Köhntopp, 2001).

Various forms of IdMs have been developed, of which centralized and federated are the most used ones. In a centralized IdM, a user creates an identity in the system by registering an account with an application, typically providing a username and a password (Preukschat, 2021). While such systems are very simple to implement, they also show deficits, e.g., accounts are typically only valid for a single application. Thus, identity information is not transferable, resulting in additional efforts for the user and lacking interoperability between applications (Zhu & Badr, 2018).

Federated IdMs try to improve over centralized IdMs. Instead of creating an account directly with an application provider, the user registers at an identity provider. When the user accesses an application, the IDP relays a portion of their identity information to this application (Zhu & Badr, 2018). One of the largest federated IdMs is the European eID, governed under the eIDAS regulation, aiming to serve almost 500 million people. The system uses a network of eIDAS Nodes, which are run by national governments and act as identity providers for their citizens. Service providers, such as government websites, can then use these eIDAS Nodes to identify and authenticate users. This allows citizens to use their own national eID to access services in their own and other European countries (Carretero et al., 2018).

Despite their benefits, federated IdMs still come with their drawbacks (Jensen, 2012). One major concern is the presence of intermediaries between users and service providers, which can lead to privacy issues and the potential tracking of citizens and companies (Squicciarini et al., 2008). Because information passes through the identity provider, they could potentially use this as a means to (partially) track the activities of identity holders. Additionally, onboarding of new identity providers within a federation can be complex and costly, making it difficult for new entities to join the network or for existing entities to expand their participation (Jensen, 2012). To address these issues, decentralized approaches for IdM services are currently being researched and considered as an alternative solution.

Blockchain-based identity management systems

Due to the ever-growing digitalization, an increasing number of digital identities and systems must be managed (Caza et al., 2018). In conjunction with the rising interest in blockchain (Arnold et al., 2019), researchers started to rethink existing IdM paradigms. Blockchain’s characteristics, e.g., decentralization, interoperability, and high level of security (Guggenberger et al., 2020), promise to offer opportunities to improve existing IdM systems providing means to transition from centralized and federated IdMs to decentralized IdMs (Lesavre, 2020; Sourabh, 2019; Zambrano et al., 2018).

Several researchers have analyzed how blockchain-based IdMs can benefit institutions and users alike (Liu et al., 2020). Since typically public institutions issue trustworthy digital identities, an important research strand has emerged around corresponding e-government solutions. For example, Sullivan and Burger (2017) describe a technical implementation of a blockchain-based IdM to represent the Estonia e-ID. The authors point out that blockchain “could fundamentally change the way identity information is controlled and authenticated” (Sullivan & Burger, 2017). The system facilitates improved control of citizens over their identity by allowing them to use the blockchain to define which property is shared with whom granularly. Faber et al. (2019) followed a similar approach to incorporate blockchain to create a GDPR-compliant IdM system. The authors argue that blockchain provides high security, trust, and transparency. Ultimately, their system enables users to control their data, shifting the power to the end users. Besides master identity information, IdM systems can also provide evidence of more specific properties. The representation of diplomas is a well-analyzed use case for blockchain-based IdM, and even systems for the management of diplomas already exist (Marina et al., 2020). Table 1 illustrates our literature review and summarizes existing research in the context of IdM and e-government. For a more holistic overview of blockchain-based IdMs beyond the e-government sector, we would like to refer to the systematic literature review of Rathee and Singh (2021).

Table 1 Literature on blockchain-based identity management systems for e-government
Full size table

In summary, researchers present that blockchain offers opportunities to improve IdM in the e-government sector. Nevertheless, as our literature review shows, most designs still do not use interoperable standards, advanced cryptography, and certificates. Instead, previous research uses proprietary solutions that typically combine smart contracts and off-chain repositories (centralized servers or IPFS). Only Gao et al. (2018) provide insights into how certificates stored on user devices can be employed with blockchain.

Against this background, SSI has emerged as a new concept from the blockchain community. SSI combines several existing approaches of other decentralized IdM, such as ZKP, decentralized public key infrastructure, certificates, and blockchain, to provide a comprehensive framework to manage identities (Preukschat, 2021).

Conceptual foundations of self-sovereign identity

Preukschat (2021) describes SSI as a concept in which the identity of a user is “neither dependent on nor subject to any other power or state” (Preukschat, 2021). At the core of the SSI concept is the belief that the user should be the owner and have full control over their identity (Allen, 2016). Nevertheless, it is important to note that the field of SSI is diverse and dynamic, and there are multiple interpretations and conceptualizations of what exactly constitutes SSI. Despite this, the core principle of user control and ownership remains consistent across all interpretations (Der et al., 2017; Mühle et al., 2018; Wang & Filippi, 2020).

For the sake of this study, we primarily adhere to the conceptualization of Preukschat (2021) and the W3C (2021a). As depicted in Fig. 1, the typical building blocks of such an SSI system are Verifiable Credentials (VC) and Verifiable Presentations (VP), wallets, Decentralized Identifiers (DID), and a Verifiable Data Registry, commonly represented by a blockchain (Mühle et al., 2018).

Fig. 1
figure 1

Fundamental SSI components, based on Preukschat (2021)

Full size image

VCs build the operational component representing identity attributes. VCs are cryptographically signed digital objects which allow holders to make claims about themselves. VCs are similar to digitally signed certificates but are never meant to be shown directly to a verifier. Instead, the VC holder creates VPs, which are tamper-proof presentations of evidence that the user can derive from one or multiple VCs. Such evidence includes properties themselves, the issuer’s signature, and proof that the VC has not been revoked. VCs also support the use of cryptographic ZKP to minimize data disclosure. As such, it is possible, e.g., that a user can prove only some properties of a VC or that they are older than a certain age limit without revealing their exact age (Mühle et al., 2018).

Over time, identity holders accumulate a wide variety of different VCs. Therefore, it is necessary to provide secure and convenient means for users to manage all their VCs and interactions with other parties. Like a purse where we collect our official documents, SSI uses digital wallets to manage VCs, digital keys, VP creation, and connections to issuers and verifiers. Depending on the characteristics of an identity holder, they can use different forms of wallets. Most of the solutions found today build upon smartphone apps. However, wallets, also called agents in an enterprise context, are in development for more professional applications, letting companies use SSI appropriately (Preukschat, 2021).

To allow parties to identify each other within the SSI ecosystem, they use DIDs. DIDs are unique identifiers following a standardized scheme. However, in contrast to universally unique identifiers, DIDs are resolvable, similar to a URL. This feature allows DIDs to point to a DID Document, either stored publicly or interchanged peer-to-peer. A DID Document shows meta-data about an identifier, including public keys and gateways, to build up a connection to the respective identity controller (Rhie et al., 2021). As such, DIDs build the fundamental building block to establish a secure connection between parties and look up the public keys of VC issuers.

While most of the interaction of SSI is meant to be bilateral, there is information that should be globally accessible. Such information includes DID Documents of VC issuers, revocation registries for VCs, and standardized templates for VCs. Various solutions are currently developed to implement such a Verifiable Data Registry, reaching from web services, over data repositories, and distributed ledgers, i.e., blockchains. While a blockchain is technically unnecessary for SSI, it provides an important way of decentralizing the infrastructure of the Verifiable Data Registry (Nauta & Joosten, 2019; Preukschat, 2021), holding the only information that must be publicly accessible in an SSI system.

SSI is based on the perception that identity holders should actively provide all information. As such, SSI does not make use of hashes stored on the blockchain. Instead, many implementations use a Cryptographic Accumulator. For building such an Accumulator, the issuing party generates a huge amount of random numbers. Using modular arithmetic, these numbers will be calculated, forming the Accumulator (Camenisch & Lysyanskaya, 2002). Eventually, the Accumulator is written on the blockchain. When a VC gets issued, one of the randomly generated numbers is assigned to that VC. The user can now perform a proof of non-revocation, demonstrating that their number was used to generate the Accumulator. Accordingly, if a VC needs to be revoked, the issuing party can deduct the respective number from the Accumulator, and proof of non-revocation is not possible anymore (Nauta & Joosten, 2019).

Literature on SSI is scarce and either focuses on its potential (Der et al., 2017; Wang & Filippi, 2020) or its technical components (Ferdous et al., 2019; Mühle et al., 2018; van Bokkem et al., 2019). The way such systems should be designed and how they can effectively support business processes is mostly unexplored. Especially its implication for the e-government sector is currently missing.

Method

We followed the DSR paradigm (Gregor & Hevner, 2013; March & Smith, 1995; March & Storey, 2008; Nunamaker et al., 1990) to guide the research project and eventually design the artifact (March & Smith, 1995). In general, DSR aims to contribute to both practice and science. First, DSR aims to solve a practical problem by developing effective artifacts. Consequently, DSR is a natural fit for us as we aim to improve online retailers’ tax registration verification process by introducing SSI-based applications. Second, a rigorous research process and an appropriate level of abstraction should help produce design theory as a result of DSR. Depending on the maturity of the artifact, such a theory can be a (medium and grand) design theory, a construct, a method, or a (software) instantiation. With this study, we demonstrate a solution design built on SSI, a software instantiation, and propose four nascent design principles that contribute to the design theory of SSI.

In summary, we chose to employ DSR as it allows us to design an innovative solution to solve a problem with practical relevance. Furthermore, following DSR, we seek to expand the body of knowledge on designing SSI systems, as existing literature lacks in-depth knowledge in this area. In particular, research on real-world applications is missing (Wang & Filippi, 2020). Therefore, the findings from this study should help in making better decisions in designing future SSI-based IdM solutions.

Our study was contextually embedded within a research project initiated by the Bavarian tax authority, which lasted between February 2020 and August 2020. The project primarily served to gain experience with blockchain technology to increase efficiency in tax administration and e-government services. In this way, we were able to draw on eight experts (see Table 2 for more details), whom we involved in defining the objectives for the design solution and evaluating the artifact.

Table 2 Overview of the involved experts
Full size table

For the development of our design, we followed the approach of Peffers et al. (2007), consisting of the steps (1) problem identification and motivation, (2) definition of solution objectives, (3) design and development, (4) demonstration, (5) evaluation, and (6) communication. During the research, steps (3) to (5) were conducted highly iteratively (see Fig. 2). Table 3 presents further details on the supporting activities during the research process.

Fig. 2
figure 2

Design science research process, based on Peffers et al. (2007)

Full size image
Table 3 Supporting activities during the research process
Full size table

We structured the research project as follows: First, we conducted four initial meetings with the Bavarian tax authority. The meetings took between two and four hours and focused mainly on the processes and legal aspects of the existing approach. The Bavarian tax authority is one of the governing bodies in Germany responsible for issuing proofs of tax registration for online retailers, thus allowing us to better understand the existing solution and identify related problems. We took meeting notes during all workshops. Second, based on these problems, we derived solution objectives to guide our development process. Third, we applied the concept of SSI to the problem area and designed an innovative solution. To demonstrate the applicability and effectiveness of the artifact, an IT service provider eventually implemented a prototype. In weekly meetings, the prototype was continuously presented and discussed with consultants, managers, and potential system users at the tax authority. This approach allowed us to test the design continuously and provided ongoing guidance for further improvements. Once we perceived a sufficient level of maturity, we went over to the final evaluation of our design. To evaluate the developed artifact, we employ a mixed-methods approach. In particular, we used literature and insights from the artifact’s development to assess whether the artifact meets the predefined design objectives. To gain additional insights, we also conducted eight interviews. Prior to the interviews, each interview partner could extensively use the developed prototype, including the issuance and verification of VCs. The interviews took between 45 and 60 min. We started with general questions about the interviewee and later inquired about discussing whether the artifact meets their requirements and, in case there were still problems, what needs to be improved. To analyze the interviews, we used qualitative techniques, including transcribing and coding the interviews (Mayring, 2014). Finally, abstracting from the case-specific design, we used our insights to formulate four nascent design principles for SSI systems.

Problem identification

The growing dissemination of Internet marketplaces poses a significant challenge to tax authorities. Retailers offer their goods in Germany but may not meet their tax obligations, which results in considerable tax losses. The German legislator has reacted to this situation by introducing recording obligations for operators of electronic marketplaces. Marketplace operators will be required to obtain a tax registration certificate from their retailers. Retailers must apply for this certificate at their responsible tax office. At present, the application and issuance of the certificate are conducted in paper form. Figure 3 describes the current process as a business process diagramFootnote 1.

Fig. 3
figure 3

Description of the current paper-based process

Full size image

Manual activities characterize the entire process flow, leading to high expenses, especially concerning marketplaces since they must manually check the respective paper certificates. Besides, the document’s authenticity is difficult to verify as no further measures exist to protect the document against forgery apart from the tax authority’s official stamp and signature. Thus, certificates might be manipulated without significant hurdles in the paper-based process. Finally, the most significant drawback is that it is not possible to revoke the certificate. The tax registration also expires when a retailer unsubscribes from its tax office. This fact should consequently also affect the certificate. While the current solution would allow the tax authority to collect the issued paper certificates, this procedure is still impracticable as scans allow for further use of copies.

Design objectives

We aim to develop an improved solution that should support the particularities depicted in Fig. 4 The retailer must identify themselves to apply for a tax certificate. After the application, the respective tax authority issues a certificate with all the required characteristics. The retailer can then use this certificate to prove they are properly registered with the tax authority. The marketplace must be able to verify the information given by the retailer. It should no longer be possible to provide evidence of the tax registration if the taxpayer or market participant no longer meets the requirements. In this case, it should be possible to set the certificate’s status to “invalid”.

Fig. 4
figure 4

Simplified overview of the process

Full size image

We used workshops with two employees of the tax authority along with literature to derive eight design objectives (see Table 4).

Table 4 Design objectives for the SSI system
Full size table

Design and development

We started our design phase by discussing centralized solutions. However, a missing central authority and a high number of stakeholders led to the final solution design based on SSI, using blockchain as a Verifiable Data Registry. At first glance, using a blockchain in public administered use cases might look inappropriate, as typically, there should be no trust issues arising. However, political and legal barriers often prevent the centralization of competencies in many western countries, which makes blockchain a potential alternative. Rieger et al. (2019) provide detailed insights into the applicability of blockchain for the public sectors, especially within Europe. Thus, data protection of blockchain (in combination with modern cryptography) and promises regarding interoperability have strengthened our decision for blockchain and an SSI approach. Figure 5 depicts our study’s final design, incorporating the SSI building blocks and legacy database systems. While the tax authority is responsible for providing certification of tax registration, the citizens’ office issues an identity VC for the online retailer.

Fig. 5
figure 5

SSI-based tax verification system

Full size image

The system comprises five distinct process steps: preparation and initial setup, onboarding via an identity VC, issuance of the tax VC, presentation towards the marketplace, and revocation. We explain each step in more detail in the following.

Initial system setup

While SSI makes heavy use of peer-to-peer exchange of VCs, a Verifiable Data Registry has to be set up first. We decided on Hyperledger Indy as a permissioned public blockchain for the given case. This decision contrasts with other architectures for e-government solutions, such as Rieger et al. (2019) or Yavuz et al. (2018), who typically propose private permissioned or public permissionless blockchains. We differ from previous literature due to the following reasons. First, we wanted to ensure high reliability and level of assurance regarding the data provided by the system. The blockchain acts as a single point of truth, mainly for the decentralized PKI. Thus, parties must trust its data. This requirement calls for tight control over who can write data to the blockchain and use it to issue VCs later. Therefore, we opted for a permissioned system. Second, while we wanted to restrict who can write on the blockchain, potentially, any party should be able to query data written on the blockchain as its data is needed to verify the validity of VCs. This requirement led to the use of public accessible blockchain infrastructure.

We used the BCovrin Test network as a concrete implementation of Hyperledger Indy as infrastructure for our prototype.Footnote 2 In the future, a (partly) state-owned blockchain might be desirable, where the citizens’ office and the tax authority run their peers. Alternatively, projects such as European Blockchain Service Infrastructure even suggest that pan-European, cross-state operations would be possible in the future (Williams, 2020). Regardless of the physical nature of the blockchain system, both the citizens’ office and the tax authority have to be entitled as endorsers to publish relevant information. Once the authorities are registered as endorsers, they can publish their DID Documents, including their public DID (see Fig. 6 for exemplary JSON of the citizens’ office DID document), their Credential Definitions, and the respective Accumulator (see Fig. 7 for exemplary JSON of the identity VC definition) on the blockchain.

Fig. 6
figure 6

Citizens’ office DID Document

Full size image
Fig. 7
figure 7

Identity VC Credential Definition

Full size image

The DID Document contains all relevant information of a certain issuer that is required to establish a secure connection to it and, second, to later verify the signature of the VC. Therefore, the DID Document published on the blockchain consist of the keys used by the authority, the respective cryptographic algorithms, and the service gateways through which the authorities can be reached (Preukschat, 2021). The citizens’ office and the tax authority write a DID Document on the blockchain. To later provide this information, a party can use the DID of the respective authority to resolve the related DID Document.

Next, the authorities can create a Credential Definition and write it on the blockchain. The Credential Definition holds all meta-data for a VC. This data includes the mandatory data fields of a VC, the revocation method, if applicable, and the DIDs of the authorities acting as the controller of that definition. We would like to note that similar to the DIDs that can be used to resolve a DID Document, Credential Definitions also have identifiers that can later be used to resolve the Credential Definition. The verifier can, thus, include this Credential Definition identifier to ensure that it can only be answered with VCs that follow this exact Credential Definition. With the creation of the Credential Definition, also an Accumulator is written on the blockchain. The Credential Definition points to this Accumulator and allows parties to access the Credential Definition to resolve the Accumulator. In turn, the Accumulator represents the revocation registry of the respective VCs (Camenisch & Lysyanskaya, 2002; Nauta & Joosten, 2019).

Lastly, online websites were developed to facilitate the connection of the online retailer’s wallet with the respective enterprise wallets. We used HTML, Javascript, and Trinsic Agents with Trinsic StudioFootnote 3 to implement the web services and the enterprise agents. Figure 8 depicts one of the developed web interfaces used to set up a secure connection to an enterprise agent by scanning the QR code with the smartphone wallet. If a desktop wallet should be used, the online retailer might open a link instead of using the QR code.

Fig. 8
figure 8

Online web interface of the tax authority

Full size image

Onboarding the online retailer

In the first step, the IdM system has to onboard the online retailer. This procedure aims to provide a VC representing the retailer’s master identity that they can use for different processes within the system. Similar to the German citizen identity, the citizens’ office will issue the respective VC (see Fig. 9).

Fig. 9
figure 9

Issuance of the identity VC

Full size image

First, the online retailer applies (1) for their first VC at the citizens’ office’s website. As this VC does not yet represent their tax registration but rather the master identity data, we name it identity VC. To identify themselves, they might use their identity card and video ident. Once applied, an invitation link is generated by the responsible citizens’ office’s agent (2). The link will be provided in the form of a QR code, which allows it to be sent via paper to the retailer or online via a website or e-mail. The online retailer can open this link using their SSI wallet by scanning the QR code. The link establishes a secure connection between the retailer’s wallet and the citizens’ office’s SSI agent (3). This process step also includes the exchange of the DID Documents between the online retailer and the citizens’ office. All communication now runs over a secure and direct connection between the retailer’s wallet and the citizens’ office’s agent. Next, the citizens’ office’s agent sends a credential offer to the online retailer’s wallet (4). If the online retailer accepts the VC in the proposed form, it sends back a credential request (5). The citizens’ office’s SSI wallet finally sends the corresponding VC back to the online retailer (6). No transaction on the blockchain is required yet for the VC’s issuance. The revocation works similarly to a blocklist, meaning that all VCs are valid by default. We consider this an effective design decision because there was no need to issue invalid VCs, which allowed us to drastically reduce the number of transactions written to the blockchain. As the VCs are cryptographically signed, there is also no need to store the hash of the certificate upfront, unlike what has been suggested by other researchers (Haddouti & Ech-Cherif El Kettani, 2019).

Issuance of the tax verifiable credential

To confirm the tax registration, the tax authority will issue the tax VC to the retailer, representing the tax registration (see Fig. 10). For the second VC, the online retailer applies for the appropriate credential via the web portal of the tax authority. Steps (2) and (3) are analogous to issuing the identity VC and establishes a secure connection between the retailer’s wallet and the tax authority’s agent. The tax authority’s agent now expects the online retailer to prove the master data, such as name and address, from their identity VC (4). The online retailer retrieves the latest Accumulator status from the blockchain (5). With this data, the retailer creates proof of identity, including proof that the underlying identity VC is not revoked, and sends the VP to the tax authority’s agent (6). The tax authority’s agent now queries the Accumulator value of the identity VC and the DID Document of the citizens’ office from the Verifiable Data Registry (7). Both are used to verify the validity and signature of the VP. The tax authority then internally checks the proof’s contents and whether the proof of identity matches the identity for the requested tax registration (8). Suppose the online retailer could authenticate themself with their identity VC. In that case, the tax VC is issued using the same procedure as the issuance of the identity VC at the citizens’ office (9). The online retailer finally stores the tax VC in their wallet. Only read requests from the blockchain are required to obtain the current Accumulator, and again no write transactions are needed.

Fig. 10
figure 10

Issuance of the tax VC

Full size image

Proof of identity and tax registration

The retailer can now use both VCs to prove the underlying attributes (see Fig. 11). To do so, the online retailer first logs themself into their account on the marketplace’s web portal (1). Again, a secure connection is established by exchanging an invitation link and the DID Documents via (2) and (3). In the next step, the marketplace creates a proof request and sends it to the online retailer (5). The proof request contains a detailed list of the required attributes and who should certify these attributes. In the given case, the attributes must provide general identity information, proof of tax registration, and evidence that the citizens’ office and tax authority have issued the underlying VCs. Upon receiving the proof request, the online retailer processes the corresponding request, including retrieving the latest Accumulator value (6). The process is very similar to the presentation towards the tax authority. However, the retailer’s wallet now combines attributes from the two previously obtained VCs, i.e., the identity VC and the tax VC, into a single VP and sends it to the marketplace (7). The marketplace can now use the Verifiable Data Registry (i.e., the blockchain) to retrieve the DID Documents from the citizens’ office and the tax authority (including their public keys and signing method) as well as the Accumulator status of the VCs (8). Then the marketplace can use cryptographic methods to validate the proofs and confirm the online retailer’s identity and the validity of the tax registration (9).

Fig. 11
figure 11

Presentation toward the marketplace

Full size image

Revocation of a verifiable credential

It can happen in individual cases that tax registrations of individual retailers might no longer be valid or that an identity VC needs to be revoked due to changes in the retailer’s corporate information, such as the company address or discontinuance of business. This situation requires the possibility of marking individual VCs as invalid. For this purpose, the tax authority or the citizens’ office can adjust the data stored on the blockchain so that the factor representing the validity of the VC now returns “invalid”. From this moment on, the retailer can no longer create valid proof of non-revocation. If necessary, a VC with the new data can then be issued. The possibility of revocation also leads us not to integrate master identity data in the tax VC. As such, attributes can be revoked independently from each other, and no dependencies exist.

Demonstration and evaluation

An IT service provider prototypically implemented the proposed design with Hyperledger Indy (Hyperledger Indy, 2020) and Aries (Hyperledger Aries, 2020) at the Bavarian tax authority. We used these frameworks as they follow the W3C standards and have a growing community. The implementation includes all central components of the design, enterprise agents, graphical user interfaces, and the blockchain environment. Furthermore, we employed the Trinsic Wallet available on the Android and Apple App Markets. As a public blockchain, we used the BCovrin Test Network to allow for easier integration of different stakeholders. The prototype permitted us to evaluate the system beyond a conceptual level. We involved managers and potential users in workshops and presentations to demonstrate the prototype, checking whether it meets their expectations. In particular, the prototype allowed users to play along with the entire process, starting from the issuance of the first VC until the presentation of the tax registration.

The general feedback from the experts was positive. The interviewees largely approved that the system addresses the current problems. They especially highlighted that the system provides very good integrity and privacy characteristics. IP3 says that these traits are especially important in governmental applications, where citizens must rely on respective information. With this, IP4 positively noted the use of an Accumulator to store the validity of credentials and said: “that if hashes were used, it would be much more difficult to implement [such a blockchain-based system] from a data protection point of view.”

Asking about differences to a hypothetical centralized approach, IP1 stresses that the availability of the blockchain is an essential benefit. In the presented case, any downtime must be avoided since this could lead to retailers no longer being able to prove their registration. “A marketplace could even run its own node” (IP1), allowing a high level of redundancy. IP2 furthermore added that the decentralized infrastructure also allows “to shift the responsibility away (…) from the tax authority [to the marketplaces]”. As such, marketplaces can be involved in the accountability for the availability of the system. Finally, also addressing the comparison to centralized systems, IP5 said “that an individual solution would probably not bring as much benefit as a generic solution”. The interviewee emphasized that SSI could provide an “open and generic” platform for many future applications. For the given case, IP5 actually only sees marginal benefits of SSI over a conventional PKI. However, having the option to further expand the system in any direction with very flexible governance “is the real benefit compared to a normal PKI”.

We also inquired with the experts about the differences between the SSI system in comparison to other blockchain-based IdM systems. One of the most dominant answers from the interviewees was that the ecosystem built around SSI is to be considered a major advantage. IP5 states that “many solutions are based on the same technology and the same standards”, which is “the key that gives SSI the greatest potential” (IP5). Similarly, IP1 points out that other blockchain solutions are often proprietary or do not follow any standards, lacking common technical specifications as an important requirement for interoperability. As such, the expert positively remarked that we follow the W3C standards for DIDs and VCs and employ Hyperledger Aries and Indy as development frameworks. Accordingly, another expert expects that different SSI applications currently under development will be interoperable on a technological level due to these specifications (IP8). Nevertheless, the employed solution still requires all parties to be on the same blockchain, as cross-blockchain implementations of VCs are still in development in the given frameworks (IP6). As such, IP6 points out that “it is essential that the interoperability between different blockchains has to improve”, so that full portability can be established.

The interviewees also point out one major issue of the system. IP7 commented that it would be easier to just let the marketplace monitor the tax registration status. With SSI, the retailer must always arrange for the creation of a VP proving that he is still registered: “Now if you imagine a retailer who is constantly selling something [on different marketplaces], then it is difficult to implement a process if there always has to be an impulse from the retailer for every marketplace” (IP7). Even though IP8 generally agrees that the SSI application requires additional efforts, he still thinks that it is a better solution than giving marketplaces direct access to revocation information: “Of course, this would be a security risk, as access tokens might be stolen and then used by others” (IP8).

Table 5 shows the consolidated results of our evaluation with regard to the predefined design objectives. In general, the developed IdM system satisfies the functional requirements. It provides means for the issuance of credentials, derivation of proofs, and verification of proofs. Besides, all aspects of IT security showed very good results. While the blockchain ensures the availability of organization-spanning features (i.e., the validity registry), cryptographic signatures and proofs allow for integrity and privacy. However, especially features for auditing and usability still show further room for improvement.

Table 5 Evaluation of the artifact
Full size table

Discussion

Our evaluation shows that SSI can provide a solid infrastructure for a decentralized, cross-organizational IdM system. While organizations retain their legacy databases and systems, SSI provides an overarching identity layer to transfer identity information across different organizations, which would otherwise be characterized as data silos.

Description of the SSI artifacts

From an infrastructure perspective, two components are essential for the SSI system to function (see Table 6). First, Wallets and Agents provide a means of handling VCs, VPs, and connections between parties. Thus, they provide the main way of bilateral communication between a holder and the issuer or the verifier. We heavily discussed with the practitioners whether a custom wallet would bring benefits over existing offerings readily available on the market during the project. The discussion was also driven by whether a public authority should provide their own wallet to the citizens, also allowing for branding it as an official wallet developed by the authorities. Finally, we refrained from the idea, mainly due to the high expenses of developing a secure wallet from scratch. Rather, during the evaluation phase, we tested a wide variety of mobile apps and demonstrated the compatibility of the developed system with these apps. As such, citizens will be able to choose the app they like without any niceties to use a state-developed application, as long as these apps follow the W3C DID (W3C, 2021a) and W3C VC (W3C, 2021b) standards. Nevertheless, wallets provided by the authorities might still be viable in the future, for example, to allow for eIDAS compliance and a higher level of assurance.

Table 6 Description of used infrastructure and SSI artifacts
Full size table

Second, the Verifiable Data Registry provides a publicly available infrastructure. An SSI system stores public DIDs, respective DID Documents, revocation lists, and Credential Definitions in the Verifiable Data Registry. Currently, most SSI frameworks use blockchain for the Verifiable Data Registry (Preukschat, 2021). Nevertheless, during the development, we also discussed centralized ways of implementing the Verifiable Data Registry, where the tax authority and the citizens’ office each would have their own server, managing their respective data. Unfortunately, the Hyperledger Aries framework does not yet implement the option to combine VCs governed by two different Verifiable Data Registries. As a result, there would be two independent SSI systems, failing to provide a common ecosystem. In addition, taking the promises blockchain makes towards sophisticated decentralized governance in e-government applications (Rieger et al., 2019) and IT security, including availability, blockchain still offers some benefits over centralized systems. Nevertheless, once future iterations of SSI frameworks are available, potentially powered by projects such as a Universal Resolver for different registries (Decentralized Identity Foundation, 2021), hybrid-governed SSI ecosystems may potentially arise. In such a hybrid scenario, one SSI ecosystem might be supported by several Verifiable Data Registries. Depending on the use case, such registries might run on central servers, one or more blockchains, or a combination of these options. Research into how such hybrid systems for SSI can look and how they provide benefits offers scope for further research.

Comparison of SSI to alternative solutions

Throughout the research project, we compared the SSI system to other alternatives, i.e., the current paper-based process and the current implementation of eIDAS (see Table 7).

Table 7 Comparison of SSI to alternative solutions
Full size table

As our evaluation shows, it is evident that the paper-based process shows a wide range of challenges that SSI can address. From a function point of view, the process when using SSI is very similar to using actual paper-based certificates. There is still an issuer who hands out a document to a holder, and the holder still shows the properties of this document to a third party. However, while SSI follows very similar procedures, it allows the entire process to be completely digital. In addition, SSI enables a few more features, for example, the easy revocation of documents. While it is possible to physically collect issued documents in an analog process, it is associated with high costs or even completely impracticable if the document can be copied at will.

Since the study was strongly motivated by the shortcomings of the current eIDAS implementation, we also like to compare it to the presented SSI solution. Several factors speak to the advantages of SSI. First, SSI is not limited to private individuals. Currently, identities for legal entities are not provided for in eIDAS. Thus, a merchant who is not a natural person cannot prove his identity (European Commission, 2021). SSI is agnostic in this sense and provides a technical basis for both natural and legal persons. Second, eIDAS does not allow the representation of additional attributes besides the master data (EUR-Lex, 2014). This means that the tax registration information cannot be depicted at all with eIDAS. Again, SSI is potentially more flexible and allows any form of attribute evidence, requiring only a schema to be published in a common ledger. Third, integrating private companies into the eIDAS ecosystem is often seen as too expensive and too burdensome (European Commission, 2021). Here, SSI has the advantage that auditors can easily develop use cases based on SSI, especially when using public blockchains. Nevertheless, it is important to mention that eIDAS still has specific advantages over SSI in terms of security. In particular, SSI does not yet meet the highest requirements regarding level of assurance, especially the option to bind certificates to devices (EUR-Lex, 2014). Currently, there are no hardware tokens, e.g., smart cards, that enforce device binding for SSI. Following the opinion of the interviewees, this is not relevant in the case described in this article, as even a lower level of assurance suffices. However, for very sensitive applications, e.g., in the financial sector, the very high level of assurance that eIDAS implementations can provide might be necessary. Future research should therefore try to incorporate solutions that use trusted computing technology (Gao et al., 2018) with SSI.

Derivation of design principles

While the IdM system development was highly motivated by the use case, the general applicability of the developed system beyond this field was considered throughout the entire project. Therefore, we follow the general conception that SSI systems should be thought out in a broader context facilitating interoperability between different applications and use cases (Mühle et al., 2018; Wang & Filippi, 2020). Due to the design of the solution concept as a generic SSI system consisting of the issuer, holder, and verifier, the system might be transferred to numerous certification processes. Other documents issued by public and private organizations could use this system to digitalize the process. Therefore, based on the learnings during the development, implementation, and evaluation of the artifact, we propose the following nascent design principles. These principles aim to extend the body of knowledge regarding best practices in designing SSI applications (Wang & Filippi, 2020).

Design Principle 1: Use the multiplicity of roles of actors for scaling the identity ecosystem

SSI represents a peer-to-peer system for IdM (Preukschat, 2021). Therefore, there are no longer dedicated servers (certificate authorities) and clients (users) (Cao & Yang, 2010). This is where the design of SSI systems differs from centralized systems, where the roles typically are defined when the system is set up. Rather, in an SSI system, all actors can transact with each other either as an issuer, holder, or verifier, while the configuration might even change over time (Mühle et al., 2018). To take full advantage of SSI, such systems should be designed so that one party can take on each of the three named roles at any time.

In the present case, we encounter this phenomenon in the design of the tax authority system. The tax authority is an issuer of credentials and has to verify the retailer’s identity VC. This fact required several considerations. First, the tax authority’s system became more complex, as it must now cover the issuance process of the tax VC and the verification process of the identity VC. Second, additional governance guidelines had to be considered as we needed to define which identity VCs should be trusted. Thinking beyond the processes presented in this article, the tax authority could also be the holder of identity attributes, i.e., VCs. For example, other governmental institutions could issue credentials to the tax authority authorizing it to provide certain services. A citizen or company could then request proof of this certificate from the tax authority beforehand. This would, in turn, increase the technical effort and require even more multi-level governance measures. However, it would also allow making use of a web of trust, creating a decentralized fault-tolerant authentication for DIDs and public keys, very similar to the approach implemented by Pretty God Privacy, also known under its abbreviation PGP (Garfinkel, 1995).

Based on our findings, we suggest that regulators in the future make their identity frameworks more flexible. For example, eIDAS does not provide for overlapping roles but instead requires a rigorous audit process first before acting as an issuer or verifier. While this makes sense in highly regulated applications, it potentially hinders the growth of use cases and, thus, the entire ecosystem. Overly strict regulation of SSI and its roles would potentially prevent the promises of flexibility and interoperability from being delivered.

Design principle 2: Consider credentials for multiple applications to facilitate additional use cases

Like in the analog world, VCs can be issued without a specific application in mind but rather as a general-purpose document. For example, issued one time, the underlying identity information can be used in a wide range of different scenarios. Thanks to its portability, the same holds for SSI credentials (Mühle et al., 2018). As such, multiple uses of a credential for services reduce friction and improve user experience (Wang & Filippi, 2020).

We made use of this principle by allowing the retailer to apply for their master identity at the citizens’ office. Once they receive their identity VC, they use it for two different services. First, they use it for providing identity information and as a means of authentication towards the tax authority. Second, together with tax VC, they employ the identity VC to provide identifying information for the marketplace. The blockchain spans a decentralized, organization-overarching infrastructure for public DIDs and revocation lists. This property allows any organization, regardless of whether public or private, to validate and compute the respective identity information. In the future, additional services can make use of the VCs issued in the given case. E.g., a bank could join the SSI system. They could then use the identity and the tax VC to perform know-your-customer procedures, including the certainty that the retailer has a valid tax registration.

Once again, we would like to plead for a flexible design of future identity ecosystems. Only if these ecosystems are as open and interoperable as possible can new applications successively build on them. This also means that the development of new systems and the corresponding regulatory framework should not be based directly on fixed use cases but should also allow for organic developments. Therefore, VCs should not be designed from the outset only for specific applications but should be made usable in a context-independent manner.

Design principle 3: Recognize the identity holder as the primary controller to ensure seamless processes

What might sound rather obvious in a system where the user stands in the middle of any interaction drastically restricts the way processes can be planned. All processes either start with action from the identity holder or need their approval at a certain step. Therefore, applications using SSI must be designed to consider the identity holder an active part in almost all processes.

In the given case, the online retailer must be involved in many actions, resulting in numerous interactions. They must accept new connections, credential offers, and proof requests and actively manage presentations. We later realized that proof of non-revocation by design is an active process as well, always involving the retailer (Mühle et al., 2018). That means that when a retailer is no longer registered, the marketplace neither gets automatically informed about that fact nor can it perform periodic checks. Therefore, we later decided that we had to require the retailer to perform proof of non-revocation periodically. We also considered automation of this process after initial consent from the retailer. However, we dismissed this approach during our development phase as it might be questionable to what extent such a level of automation is in line with SSI’s basic philosophy (Preukschat, 2021). In his work about privacy self-management, Solove (2012) describes that users tend to give general consent to disclosing data out of convenience, neglecting the associated privacy risks. Therefore, automation could quickly lead to a situation in which the user no longer has an overview of the consent declarations and loses control over their or her identity. For business reasons, a retailer may prefer to cease operations, so the marketplace would never have to know about the revocation of its tax VC. Automatic retrieval of the revocation by the marketplace could lead to the retailer unwillingly disclosing this information. The decision not to automate the proofing process was also supported by the fact that the wallet implementations we considered do not allow automation of this process but always require active user participation.

SSI provides for the holder to be placed in the center of all activities. In addition to the aforementioned need for more flexible regulation, this means a heavy responsibility burden for the holder in the future. Government and regulators will therefore have to conduct a strong education of individuals as well as companies to ensure that they can use the new opportunities without risk.

Design principle 4: Use public DIDs only for credential issuers to minimize privacy issues

DIDs are an important measure within the SSI stack to support the communication and identification of parties within the identity ecosystem. Generally, DIDs can be made public (i.e., public DIDs) by publishing the respective DID Document on a Verifiable Data Registry or kept private by exchanging it and its DID Document bilateral. Following the general perception of using the blockchain only when and where necessary (Rieger et al., 2019), we propose to use public DIDs only for credential issuers. For all other parties, bilateral exchange of the required data is sufficient. Being able to freely decide whether to write an identifier on the blockchain or keep it private is a major differentiator compared to other blockchain-based IdMs, where all identifiers are stored on the blockchain (Dunphy & Petitcolas, 2018; Faber et al., 2019; Sullivan & Burger, 2017).

We applied this design principle by only publishing the DIDs and DID Documents of the two issuing parties, namely the tax authority and the citizens’ office. This allows any party later to look up their DID Documents on the blockchain, resolving the respective signing keys and, thus, verifying the signature of VCs. The online retailer and the marketplaces do not issue VCs. Therefore, we decided to exchange their DIDs and DID Documents only bilaterally. This approach has two major benefits. First, it reduces the number of transactions that need to be written on the blockchain. Reducing required transactions is considered a best practice for designing blockchain-based solutions (Rieger et al., 2019). Second, it also prevents the risk of publishing personally identifiable information on the blockchain, potentially infringing GDPR requirements. This is especially important if the online retailer acts as a private person and not as a natural person.

While this is a simplification for the holder and the verifier, issuers need to overlook their public closely DID. Accordingly, issuers should regularly check the accuracy and timeliness of their data on the blockchain. This is the only way to ensure that the relevant endpoints can be reached and that issued VCs can be verified.

Conclusion

This study comprises the conceptual design, prototypical implementation, and evaluation of a blockchain-based SSI system that incorporates a set of public and private organizations to verify the tax registration of online retailers. First, the existing processes were analyzed, and the potential for improvement was identified. The paper-based process currently shows significant inefficiencies due to media discontinuities and counterfeiting risks. Second, an SSI solution was proposed that integrates into the existing system landscape and issues VCs to online retailers. They can then use a digital wallet to present their registration and general identity information to the marketplaces. The validity can be checked via a registry on a public blockchain. Communication occurs mostly via a bilateral link between the parties involved (citizens’ office, tax authority, online retailers, and marketplaces) and in the form of VPs. Finally, we extensively evaluated the overall concept and proposed four design principles to develop SSI-based applications.

By presenting the artifact, giving insights into the design and development process, evaluating the artifact, and proposing design principles, this paper seeks to make the following contributions. First, we provide practical insights into our design for an improved IdM spanning across various organizations and highlight the underlying decisions that support similar efforts in e-government systems and the public sector. To our best knowledge, this is the first paper describing in detail an SSI system for supporting taxation-related processes in a business-to-business environment, thus demonstrating potential also beyond frequently discussed use cases like university diplomas or driver’s licenses. Abstracting from the given use case, we are convinced that the detailed insights into the processes and technical functionalities will also provide knowledge for the development of similar systems also beyond taxation applications. Second, our evaluation sheds light on the effectiveness of such a system in supporting inter-organizational processes. In particular, we demonstrate the benefits and hurdles of the use of SSI. Finally, we answer the call of Nærland et al. (2017) and Carter and Ubacht (2018) and provide general guidelines that contribute to the design theory of blockchain-based IdM, specifically SSI. We hope that our design principles will ultimately lead to more effective blockchain-based SSI applications.

This study has limitations. The design was carried out in the form of a proof of concept to evaluate the general feasibility. However, the scope of the implementation and the interviewees were limited to the tax authority. We propose involving various stakeholders, including online retailers and marketplaces, to analyze technical, socio-technical, and socio-economic aspects in real conditions, offering opportunities for additional evaluation in future research. Furthermore, our discussion of this study points out the benefits of opening the system to other use cases. However, this idea is only theoretically driven as of now. The combination of issued proofs of different parties and inter-organizational collaboration must be evaluated empirically to demonstrate its real value. This would also allow better use of ZKPs, including anonymous VCs and range proofs, which will be urgently needed to ensure privacy in many applications. Finally, future research should expand on the political, legal, and ethical implications of SSI and the impact of these non-technical factors on the success and adoption of SSI in organizations and institutions.

Despite the aforementioned limitations, this paper shows that blockchain and SSI can benefit public and private organizations alike. The research project demonstrates the applicability and effectiveness of such systems for inter-organizational IdM. Thus, we hope that the results of this paper contribute to an emerging SSI ecosystem.