A Comprehensive Approach to User Delegation and Anonymity within Decentralized Identifiers for IoT

Abstract

Decentralized Identifiers have recently expanded into Internet of Things devices and are crucial in securing users’ digital identities and data. However, Decentralized Identifiers face challenges in scenarios necessitating authority delegation and anonymity, such as when dealing with legal guardianship for minors, device loss or damage, and specific medical contexts involving patient information. This paper aims to strengthen data sovereignty within the Decentralized Identifier system by implementing a secure authority delegation and anonymity scheme. It suggests optimizing verifiable presentations by utilizing a sequential aggregate signature, a Non-Interactive Zero-Knowledge Proof, and a Merkle tree to prevent against linkage and Sybil attacks while facilitating delegation. This strategy mitigates security risks related to delegation and anonymity, efficiently reduces the computational and verification efforts for signatures, and reduces the size of verifiable presentations by about 1.2 to 2 times.

1. Introduction

In the era rapidly evolving into a data economy, propelled by the Fourth Industrial Revolution and the ensuing interconnectedness of objects and the internet, the significance of data has become increasingly pronounced. Within this context, the vast amount of data generated by devices has necessitated advancing security and privacy measures, thus propelling the development of IdM (identity management) technologies and methodologies. Traditionally, IdM was processed within centralized systems, where a handful of central institutions or large corporations collectively managed users’ data. However, such centralized systems have become prime targets for hackers, continuously facing security threats and data breaches [1,2,3].

To address these challenges, DIDs (Decentralized Identifiers) offer a novel approach [4,5,6]. DIDs and other decentralized technologies present a new paradigm for securing personal data and protecting privacy in the data economy era [7,8,9,10,11]. It is anticipated that DIDs will transcend the limitations of traditional centralized systems by enabling user-centric data management, selective disclosure, and sovereign security. Various products, including Microsoft’s ION, Korea’s Pass, the Sovrin Foundation’s Sovrin, and ConsenSys’s uPort, have been launched, indicating widespread research and development of DIDs globally. The application of DIDs signifies a shift in personal activities, extending beyond mere individual actions to encompass various legal, economic, and social interactions, offering numerous benefits in the data economy era.

The application of DIDs in the IoT (Internet of Things) environment is particularly noteworthy. IoT devices, such as mobile devices, PCs (Personal Computers), and sensor devices, play an increasingly vital role in everyday life. These devices are key in managing and protecting users’ digital identities and personal data. The integration of DIDs in the IoT allows users to manage their identity information securely across various devices and platforms, enhancing privacy protection. This capability provides users with the autonomy to control their digital identities in the digital environment freely, enabling a secure and more personalized user experience.

Despite its advancements, DIDs encounter limitations in scenarios such as the legal guardianship of minors and the loss and damage of devices, as well as scenarios where immobile patients require guardians to obtain prescriptions on their behalf, providing patients’ EHRs (Electronic Health Records) to other medical institutions or companies, and generating power of attorney for the delegation of access rights and task execution. While traditional centralized IdM systems facilitated such delegation of authority relatively easily, DIDs must undergo further evolution to replace or integrate these functionalities to be effectively applied in various real-world service environments. Currently, DIDs struggle to support scenarios where a representative is tasked with temporarily or permanently delegating authority or identity information. This limitation underscores the need for continued development in the field of DIDs, aiming to bridge these gaps and extend the applicability of DIDs across a broader spectrum of use cases. Such improvements are crucial for ensuring that DIDs can meet the complex requirements of modern service environments, encompassing legal, healthcare, and personal data management contexts [12,13,14,15].

To address this, an approach to DIDs is exploring schemes for Holders to delegate authority to a Delegatee in a controlled manner by adding relevant information about the Delegatee to a VC (verifiable credential) and requesting its issuance from the Issuer. Furthermore, it is proposed that the delegated authority data be recorded in the VDR (Verifiable Data Registry), enabling transparent and verifiable management. However, the current scheme faces complexities in VC management when issuing new VCs or changing the authority level of a Delegatee [16,17,18].

Additionally, one of the core objectives of DIDs is to secure user privacy amidst the identifier-based relational risks that emerge from interactions across various services. The accumulation and submission of multiple VPs (verifiable presentations) bearing unique user DIDs (both Holder and Delegatee) allows attackers to link and analyze these identifiers, inferring additional personal information, thus potentially leading to privacy breaches. For instance, service providers in online shopping, social media, and healthcare sectors could correlate and track user identities, exposing details of online activities, health information, and purchase histories. Consequently, linkage attacks impinge upon the tenets of privacy and self-sovereignty [19,20,21,22,23].

Moreover, DIDs are confronted with persistent security threats within the Web 3.0 ecosystem, notably the risk of Sybil attacks. Unresolved challenges include the increasing storage demands due to the enlargement of VPs and the Delegatee’s problematic revocation of delegated authority. These challenges present critical tasks requiring resolution to uphold the system’s integrity and the users’ trust.

Therefore, this paper proposes a study on a scheme to ensure delegation and anonymity in DIDs. This paper makes the following contributions:

• Delegation and revocation by the Holder: In this paper, the Holder can delegate their authority to the delegate using a VC and an SAS (sequential aggregate signature) for delegation, and the Delegatee can prove to the Verifier that the delegation has been approved by the Holder. Additionally, this delegation uses a revocation list that allows delegates to revoke delegated authority at any time if they need it.
• Prevention of linkage and Sybil attacks: This paper generates anonymous DIDs using NIZK (Non-Interactive Zero-Knowledge) Proofs and Merkle trees. It provides user anonymity and prevents fake identities, thereby enhancing trustworthiness.
• VC management optimization and minimization of VP size: By utilizing an SAS and a reconstructed approach to VPs, this paper optimizes VC management for Holders and reduces the size of VPs by up to two times.

Section 2 explores and analyzes existing studies on the authority delegation of DIDs and the user anonymity scheme, clearly outlining the current research status and limitations. Section 3 details the various security requirements that may arise during the implementation of authority delegation and anonymity in DIDs, deriving considerations for these schemes from a security perspective. Section 4 details the proposed phases for authority delegation and anonymity, presenting their implementation and application strategies. Section 5 thoroughly analyzes and evaluates the security of the proposed scheme based on the derived security requirements. Finally, Section 6 summarizes the main contents of this paper and presents conclusions for future research directions.

2. Background

In this section, we delve deeply into DIDs and their significance, elaborating on the necessity and importance of authority delegation and anonymity within DIDs. Furthermore, we thoroughly analyze various schemes currently employed in the DID environment for user authority delegation and anonymity, comparing their advantages and disadvantages. Subsequently, we provide a fundamental understanding and detailed analysis of SAS and NIZK Proof schemes. Through this analysis, we clearly comprehend the current research trends and limitations of authority delegation and anonymity schemes related to DIDs, setting the stage for the necessity and distinctiveness of this proposed scheme in subsequent sections.

2.1. DID (Decentralized Identifier)

DIDs enable users to manage their identity information independently, without relying on central authorities or third parties, based on SSI (self-sovereign identity) principles, which emphasize personal data sovereignty.

The key characteristics of DIDs include persistence, resolvability, cryptographic verifiability, and decentralization. These features play a crucial role in ensuring the reliability and security of identity management in DIDs. In DIDs, the Holder receives a VC from the Issuer and submits it to the Verifier. The Verifier then authenticates the Holder using the verification value stored in a decentralized VDR, such as a blockchain. A critical aspect of this process is that all information exchanges occur with the user’s consent.

These DIDs are used in IoT devices such as mobile devices, PCs, and sensor devices. The application of DIDs in IoT devices is playing an increasingly important role in our daily lives, and these devices are becoming key elements in managing and protecting users’ digital identities and personal data.

The scenario for DIDs is illustrated in Figure 1.

• Step 1: The Holder generates a DID based on their public key and creates a DDO (DID document), incorporating their public key and DID. Subsequently, the Holder submits the DDO to the VDR for recording. Afterward, the VDR creates a Merkle tree using transactions containing the DDO and other users’ DDO transactions as input and records them on the blockchain.
• Step 2: The Holder sends its own DID and claims to the Issuer and requests a VC. Upon receiving the request, the Issuer performs DID Resolve [24] to obtain the Holder’s DDO from the VDR. The Issuer then verifies the signature in the received request message for the Holder’s VC.
• Step 3: The Issuer creates a VC comprising the Issuer and Holder’s DIDs, the Holder’s claims, and the value signed with the Issuer’s private key and then sends it to the Holder. The Holder securely stores the received VC.
• Step 4: The Holder and the Verifier perform DID Auth (DID Authentication) [25]. Upon successful verification, the Holder combines multiple VCs to create a VP and sends the generated VP to the Verifier.
• Step 5: The Verifier sends the DIDs of the Holder and Issuer to the VDR and receives the DDOs from the VDR. The Verifier then extracts the public keys and verifies the VP.

2.2. SAS (Sequential Aggregate Signature)

An SAS is a scheme that combines multiple digital signatures into a single signature following a specific order [26,27,28]. The primary goal of SASs is to reduce the size of signatures, yet they incorporate an additional sequential structure. This approach enables the integration of individual signatures from each user into one aggregated signature, saving storage space and transmission time. It is particularly well suited for systems where data are generated sequentially, such as blockchains, and proves beneficial in environments like auditing and logging, collaborative work, and delegation.

• ${\sigma }_i\leftarrow Sign(s{k}_i,m_i)$: Each user $u_i$ generates an individual signature ${\sigma }_i$ for the message $m_i$ using their private key $s{k}_i$.
• ${\sigma }_{i+1}\leftarrow AggSign({\sigma }_i,s{k}_j)$: User $u_j$, upon receiving the previously signed ${\sigma }_i$, uses this signature and their own private key $s{k}_j$ to create the sequential aggregate signature ${\sigma }_{i+1}$.
• $1/0\leftarrow Verify({\sigma }_{i+1},PK)$: The Verifier performs verification using the final sequentially aggregated signature ${\sigma }_{i+1}$ and the public key set $PK={\left\{p{k}_i,\dots ,p{k}_j\right\}}_{i,j\in \left[1,n\right]}$. If the verification is correct, it returns 1; otherwise, it returns 0.

2.3. NIZK (Non-Interactive Zero-Knowledge) Proof

An NIZK Proof is a cryptographic scheme that enables the owner of information to prove the possession of specific information without revealing the actual information. Unlike traditional Zero-Knowledge Proofs, an NIZK Proof does not require interaction between the prover and the verifier. Instead, the prover can demonstrate possession of the information with a single message transmission.

• $crs\leftarrow Setup\left(1^{\lambda }\right)$: The prover generates a common reference string $crs$ needed for the cryptographic protocol, given a security parameter. The $crs$ serves as public information accessible to all participants of the protocol, containing parameters required for proof and verification.
• $\pi \leftarrow Prove(crs,x,w)$: The prover generates a proof value $\pi$, indicating their knowledge of a specific problem. The inputs for this proof are the proposition $x$ to be proved, a related secret witness $w$ known only to the prover, and $crs$.
• $1/0\leftarrow Verify(crs,x,\pi )$: Upon receiving $x$ and $\pi$ from the prover, the verifier performs verification using these along with $crs$. If the verification is correct, it returns 1; otherwise, it returns 0.

2.4. Related Work

2.4.1. Scheme of Delegation in DID

In digital identity verification, DIDs leverage the IoT to ensure user authentication and self-sovereign identity. This integration, while innovative, has its challenges. As depicted in Figure 2, certain issues arise in the operational environment of DIDs when interfaced with IoT devices. To this end, schemes that can provide delegation in DIDs are being studied [16,17,18].

Chadwick et al. proposed FIDO (Fast Identity Online) and DIDs as schemes to overcome issues in traditional ID management systems, proposing a concept model, architecture, and protocols extending FIDO’s UAF (Universal Authentication Framework), thereby providing robust authentication and powerful authorization [29]. They also developed FIDO and DIDs for UK NHS (United Kingdom National Health Service) patients, providing authority delegation and revocation. This scheme ensures privacy in authority delegation for the Holder and Delegatee by separating the public key pairs between Issuers and Verifiers.

Abdelgalil et al. proposed a framework named Health-Block for jointly sharing EHRs and personal privacy [30]. Utilizing Hyperledger Indy and IPFS (InterPlanetary File System), this framework stores and shares patient EHRs in a distributed off-chain repository, ensuring record immutability and granting patients complete control over their EHRs. It involves the Holder hashing the proof of delegating authority to the Delegatee and recording it as a transaction on the blockchain. Recording the DID as a certificate linking a series of attributes and public keys provides proof of authority delegation for the Delegatee. Additionally, Hyperledger Fabric stores access control policies (roles and actions) and delegations for patient EHRs. Roles are divided into patients, EHR providers, and EHR consumers, and actions are classified as creation, encryption, upload, access, delegate permission, and modify. However, the inclusion of Holder and Delegatee information in the VP exposes their privacy.

Dursun et al. proposed a new on-chain governance model utilizing both policy-based management and DIDs [31]. The design and implementation focused on creating a simple, fair, robust, scalable, user-friendly, and flexible framework. However, the inclusion of Holder and Delegatee information in the VC compromises their privacy.

These three schemes commonly involve the Holder sending their claims and specific Delegatee information to the Issuer when intending to delegate authority. The Holder then receives an appropriate VC from the Issuer, signs it with their private key to create a VP, and transmits the VP to the Delegatee for authority delegation. However, this process requires reissuing a VC from the Issuer when delegating to another Delegatee or changing the authority level of an existing Delegatee, causing communication and computation overhead for the Holder and Issuer. Furthermore, this approach results in complexities in VC management and overhead in VP storage capacity for the Holder. Additionally, using a unique DID singularly exposes them to linkage attacks and privacy breaches.

Except for Dursun et al.’s scheme, the other two do not provide time-stamped authority delegation or revocation within a specified period, posing a problem for Holders who wish to revoke the authority delegation to a Delegatee at a desired time. This paper analyzes these schemes and based on them, reconstructs the SAS and VPs in DIDs to provide minimal authority delegation and disconnects the DID-based linkages using NIZK Proofs to ensure users’ anonymity. Additionally, it aims to optimize VC management and minimize overhead in VP storage capacity, providing the revocation of a delegated authority.

2.4.2. Scheme of Anonymity in DID

Kim’s scheme applies a blockchain-based DID to vehicles, recording vehicle modifications and maintenance history and considering security in credential authentication systems like a car birth certificate. Using a unique DID singularly could expose vehicle identifiers, driver information, driving data, and location and compromise privacy. To protect these securely, they proposed a vehicular DID ensuring anonymity using 16 bytes of multiple X.509 certificate public keys in WAVE (Wireless Access in Vehicular Environment) as an sDID (short-term DID) [32]. However, using 16 bytes for a DID is not secure from collision possibilities. Until replaced with another sDID after a certain period, the used DID remains the same, and is not completely secure from linkage attacks. Also, recording a DDO in the VDR for each sDID is inefficient.

Song’s scheme highlights that while DIDs strive to grant users complete sovereignty over digital assets within the Web3 ecosystem, this risks privacy breaches concerning user credentials and identity information, posing problems with the longstanding nemesis of Sybil attacks in Web 3.0 [21]. To solve this, they use Commitment and NIZK to prove legitimate users while hiding the DID and protecting against Sybil attacks using the Merkle tree.

Bosk et al. identifies the problem that a traditional DID exposes the Issuer’s identity to all participants, leading to data breaches. They propose a new anonymous credential using NIZK, a modified PS (Pointcheval Sanders) Signature, and Aggregate, allowing the Holder to hide the Issuer of credentials while ensuring trust in a trustless setting [33]. However, it is not secure when it comes to Sybil attacks, as attackers can create multiple fake identities and exert undue influence within the DID.

This paper analyzes these schemes and based on them, uses NIZK in a DID for authority delegation to hide the DID of the Holder and Delegatee, ensuring users’ anonymity by disconnecting DID-based linkages. Additionally, it prevents against Sybil attacks using the Merkle tree.

3. Security Requirements

This section details the essential security requirements and additional requirements for a comprehensive approach to user delegation and anonymity within a DID for the IoT. These requirements play a crucial role in guaranteeing the security of user delegation and anonymity in DIDs.

3.1. Primary Security Requirements

3.1.1. Delegation

• Authentication of Delegation

With a DID, a Holder must be able to delegate their authority temporarily or permanently to another entity (Delegatee). To ensure the legitimacy of such authority delegation, the Delegatee must clearly prove that they have indeed been delegated the authority by the Holder. However, if the Verifier fails to verify or incorrectly verifies the Delegatee’s authority delegation, the attacker risks misusing or abusing the Holder’s authority. This can lead to personal information leakage and improper data access and manipulation. Therefore, it is essential for the Delegatee to prove their identity and clearly confirm the Holder’s intention of authority delegation.

• Revocation of Delegatee

The Holder should be able to revoke the delegated authority of the Delegatee at any time if necessary. In such cases, a function to verify and process legitimate requests for revocation of authority delegation is needed. If revocation measures are not properly implemented, a Delegatee whose authority has been revoked could misuse or abuse such authority. To prevent this, when an unauthorized Delegatee attempts access using their credentials, the Verifier should cryptographically verify these credentials to block unauthorized access. Additionally, it is vital to prevent illegitimate user authentication requests and ensure secure authority management.

3.1.2. Anonymity

• Prevention of Linkage Attack (Unlinkability)

Linkage attacks are considered a significant threat to user privacy. With DIDs, although users can generate unique identifiers for each interaction, these identifiers can be traced and inferred, connecting multiple identifiers across various services to track a user’s online activities and identity. Thus, a third party collecting and analyzing multiple VPs should not be able to trace the unique DIDs of the Holder and Delegatee or infer additional personal information.

• Prevention of Sybil Attack

Sybil attacks are a serious problem in decentralized networks, where an individual or group can fill multiple nodes with fake or duplicated identities, disrupting or manipulating the network’s operation. Attackers can create multiple fake identities and exert abnormal influence within the network, using these identities to manipulate network decisions, voting, and resource allocation. With DIDs, it must be impossible for an individual or group to create fake or duplicated identities and disrupt or manipulate the network.

3.2. Additional Requirements

• Optimization of VC Management

For a Holder to delegate authority to a Delegatee, the VC or VP must include information proving the delegation from the Holder and about the Delegatee. Additionally, the Delegatee should submit the delegated VC or VP to the Verifier for verification. Therefore, it is crucial for the Holder and Delegatee to issue new VCs for authority delegation and manage and store the delegated VCs. However, due to varying authority levels for each Delegatee, the Holder faces inconvenience in issuing new VCs for each Delegatee. Also, Delegatees find it challenging to store and manage VCs when delegated authority from multiple Holders. Thus, the issuance of new VCs for authority delegation and the management of the delegated VCs or VPs must be optimized.

• Minimization of VP Storage Capacity

With DIDs, the basic structure of a VP comprises selected VCs issued by the Issuer and the Holder’s signature as input. Additionally, for delegating authority to a Delegatee, the Delegatee’s DID and signature must be included. However, if a Delegatee receives authority delegation from multiple Holders or multiple authority levels, the size and number of VCs or VPs increase, along with the burden of storage capacity. Thus, this needs to be minimized.

• Minimization of DDO Records in VDR

When a Holder creates a DID, it generates a DDO by binding it with the corresponding public key. The created DDO is then recorded in the VDR for future verification. However, if a new DID and DDO are created to ensure the anonymity of the Holder or Delegatee, the number of DDOs to be recorded in the VDR increases, leading to an increased burden on the VDR. Therefore, this needs to be minimized.

4. DID-Based Delegated Scheme with User Anonymity in IoT

This section proposes a comprehensive approach to user delegation and anonymity within DIDs for the IoT. The existing DID operational process utilizes an SAS to facilitate user authority delegation and verification, with the Delegatee receiving authentication services from the Verifier on behalf of the Holder. Additionally, NIZK and Merkle trees are employed to hide the identities of the Holder and Delegatee while enabling verification by the Verifier. This paper is structured into six phases, as illustrated in Figure 3: the setup phase, the registration phase, the VC issuance phase, the authority delegation phase, the VP verification phase, and the revocation phase.

4.1. System Entities

The roles of system entities are as follows:

• Holder (Delegator): The Holder, as a trustworthy entity of data sovereignty, receives verifiable credentials from the Issuer, providing authentication services to the Verifier through these credentials. The Holder is also an entity capable of temporarily or permanently delegating their authority to a Delegatee.
• Issuer: The Issuer, a government agency that acts as a trusted certification center, verifies the Holder’s credentials when a Holder requests VC issuance. If the Holder’s credentials are correct, the Issuer creates a digital signature that guarantees the Holder’s credentials can be trusted when the Holder later authenticates with a Verifier. The Issuer then issues a VC to the Holder, and the Issuer’s digital signature is attached.
• Verifier: As a service provider, the Verifier receives the Holder’s VP from the Holder when requesting authentication and verifies it. To determine if the authentication is valid, the Verifier verifies the Holder’s digital signature included in the VP to see if the owner of the VP is the Holder, and the Verifier verifies the issuer’s digital signature to see if a trusted issuer issued the VC included in the VP. If the authentication is correct, the Verifier provides the service to the Holder.
• Delegatee: The Delegatee, an entity that receives delegation from the Holder, requests authority delegation from the Holder and, upon approval, assumes the delegated authority, receiving authentication services from the Verifier on behalf of the Holder.
• VDR (Verifiable Data Registry): A VDR is a verifiable data repository that stores and manages credentials of all entities and related data, as well as a revocation list, for authentication purposes.

4.2. System Parameters

The system parameters used in this paper are as presented in

Table 1. System parameters.

Symbol	Definition
*	Participant entities mean the Holder, Issuer, and Verifier collectively
$H,I,V,D,VDR$	Holder, Issuer, Verifier, Delegatee, and Verifiable Data Registry
$p,q$	Large prime numbers
$P$	Elliptic curve base point
$H\left(\right)$	Hash function, $H:{\left\{\mathrm{0,1}\right\}}^{*}\to Z_p^{*}$
$G_1,G_2$	Addition group and multiple group
$G_T$	Groups in bilinear mapping
$g_1,g_2$	Generator of $G_1,G_2$
$e$	Bilinear map, $e:G_1\times G_2⟶G_T$
$crs$	Common reference string
$PP$	Public parameters
$s{k}_{*},p{k}_{*}$	Participant’s private key and public key pair
$ts$	Timestamp
$DI{D}_{*},DD{O}_{*}$	Participant’s DID and DID document
$DT{x}_{*}$	Transaction that contains participant’s DDO
$Add{r}_{*}$	Participant’s blockchain network address
${\sigma }_{{*}_{input}}$	Signed value of the participant’s input message
$M{T}_{*}$	Binary tree structure with hash values generated including $DT{x}_{*}$ as the upper nodes.
$roo{t}_{*}$	Top Merkle root value of a Merkle tree
$Prove\left(\right)$	Function that generates a proof value based on NIZK Proof
$AI{D}_{*}$	Participant’s anonymous DID
$clai{m}_H$	Holder’s claim (s)
$V{C}_{H\to D}$	Holder’s verifiable credential for Delegatee
$V{P}_H$	Holder’s verifiable presentation
$DV{C}_{H\to D}$	Holder’s verifiable credential for Delegatee
$\varsigma$	Signature using sequential aggregate signature
$RV{P}_D$	Delegatee’s re-structure verifiable presentation
$CT$	ECC (Elliptic-Curve Cryptography)-based public key ciphertext for message $m$ for secure communication
$date$	Current date and time
$RL$	Revocation list

, and they are denoted as follows.

4.3. Assumption

The assumptions for the comprehensive approach to user delegation and anonymity within DIDs for the IoT are as follows:

• As a trusted entity, the Issuer generates and manages public parameters, and all channels communicating with the Issuer are assumed to be secure [34].
• The VDR, capable of blockchain computations, stores publicly available credentials and can issue DID certificates. Additionally, the VDR maintains and publicly discloses a revocation list, accessible for verification by anyone.
• The structure of transactions stored in the VDR is composed of {sender address, data, recipient address, sender’s signature, and sender’s public key}.
• For delegation, the Holder utilizes a TLS (Transport Layer Security) handshake [35] for mutual authentication with the Delegatee.
• The structure of the revocation list stored in the VDR comprises {Holder’s anonymous DID, revoked anonymous Delegatee’s DID, VC to be revoked, and revoked date}.
• For secure cryptography in this paper, detailed cryptographic functions, hash functions, and signatures are based on large primes $p,q$, an arbitrary elliptic curve reference point $P$ using the ECDSA (Elliptic Curve Digital Signature Algorithm) [36], and a hash function $H\left(\right)$, all of which are publicly disclosed to all entities.
• The Pedersen Commitment [37] and NIZK are used to create anonymous DIDs to provide user anonymity in this paper.
• An additive group $G_1$ and a multiplicative group $G_2$, both with the same prime $q$, are generated; $g_1$ is defined as the generator of $G_1$, and $g_2$ as the generator of $G_2$. Moreover, it satisfies $e:G_1\times G_2⟶G_T$.

4.4. Proposed Scheme

The proposed scheme is divided into six phases, which is detailed as follows.

4.4.1. Setup

In the setup phase, the Issuer generates and publishes public parameters for all DID participants (Holder, Issuer, and Delegatee). An initial empty revocation list is also created and recorded in the VDR.

• Step 1: The issuer generates the following public parameters using security parameter $\lambda$:

  $$PP=\{p,q,g_1,g_2,G_1,G_2,G_T,e,H,P,crs\}$$

  (1)
• Step 2: The issuer initializes and creates the revocation list $HL$.

4.4.2. Registration

In the registration phase, DID participants create their public key pairs and DIDs, requesting their recording in the VDR. The VDR then registers and publishes these participants. Anonymous DIDs are also created to ensure the anonymity of Holders and Delegatees.

• Step 1: The participants (Holder, Issuer, and Delegatee) select a prime $x_{*}$ in $Z_p$, use it as their private key $s{k}_{*}$, generate their public key $p{k}_{*}$ as follows, and publish $p{k}_{*}$ to all participants, including the VDR.

  $$s{k}_{*}=x_{*},p{k}_{*}={sk}_{*}·P$$

  (2)
• Step 2: The participants create $DI{D}_{*}$ using their generated public key $p{k}_{*}$ and a timestamp $ts$, then map $p{k}_{*}$, $DI{D}_{*}$ to create a DID document $DD{O}_{*}$ and sign it based on the ECDSA.

  $$DI{D}_{*}=H(p{k}_{*},ts),DD{O}_{*}=\{DI{D}_{*}, p{k}_{*}\}$$

  (3)

  $$d\in \left[1,n-1\right]\left(\mathrm{where}n\mathrm{is}\mathrm{the}\mathrm{value}\mathrm{defined}\mathrm{in}\mathrm{secp256k1}\right)$$

  (4)

  $$\left(x_1,y_1\right)=d·P$$

  (5)

  $$r=x_{1}modn$$

  (6)

  if $r\ne 0:$

  $$s=d^{-1}\left(H\left(DD{O}_{*}\right)+s{k}_{*}r\right)modn$$

  (7)

  otherwise, repeat from (4)

  $${\sigma }_{{*}_{DDO}}=si{g}_{s{k}_{*}}\left(DD{O}_{*}\right)=(r,s)$$

  (8)
• Step 3: The participants create a transaction $DT{x}_{*}$ using their address $Add{r}_{*}$, $DD{O}_{*}$, the VDR’s address $Add{r}_{VDR}$, ${\sigma }_{DDO}$, $p{k}_{*}$ and send $DD{O}_{*}$ to the VDR.

  $$DT{x}_{*}=\left\{Add{r}_{*}, DD{O}_{*}, Add{r}_{VDR}, {\sigma }_{{*}_{DDO}}, p{k}_{*}\right\}$$

  (9)
• Step 4: For verification, the VDR extracts the signature ${\sigma }_{{*}_{DDO}}$ from $DT{x}_{*}$ and, if valid, generates a Merkle tree $M{T}_{*}$ with $DT{x}_{*}$ and other transactions ${\left\{DT{x}_1,\dots ,DT{x}_k\right\}}_{k\in [1,n]}$ as input. And the VDR records $M{T}_{*}$.
  The participant registration verification process is as follows.
  If $0<r,s\le n-1:$

  $$w=s^{-1}modn$$

  (10)

  $$u_1=H\left(DD{O}_{*}\right)wmodn$$

  (11)

  $$u_2=rwmodn$$

  (12)

  $$\left(x_1,y_1\right)=\left(u_1·P+u_2·p{k}_{*}\right)modn$$

  (13)
  If $\left(x_1,y_1\right)=O$: error message $\perp$ (where $O$ is the point of infinity)

  $$v=x_{1}modn$$

  (14)

  $$r\stackrel{?}{=}v$$

  (15)

  $$roo{t}_{*}=H{\left(...\left(H\left(H\left(H\left(DT{x}_{*}\right)\parallel H\left({DTx}_1\right)\right)\parallel ...\right)\parallel H\left({DTx}_{k-1}\right)\right)\parallel H\left({DTx}_k\right)\right)}_{k\in [1,n]}$$

  (16)
• Step 5: The Holder and Delegatee input their $DI{D}_{*}$, random number $r{c}_{*}\in Z_p$ to generate a Commitment value $co{m}_{*}$ based on the Pedersen Commitment.

  $$co{m}_{*}=r{c}_{*}·g_1+DI{D}_{*}·g_2$$

  (17)
• Step 6: The Holders and Delegatees send $DI{D}_{*}$, $r{c}_{*}$, $co{m}_{*}$ to the Issuer, requesting the creation of an anonymous DID, $AI{D}_{*}$.
• Step 7: The Issuer verifies $co{m}_{*}$ and responds with an error message $\perp$ if not valid.
  The Holder and Delegatee’s Commitment verification process is as follows:

  $${{com}_{*}}^{\prime }=r{c}_{*}·g_1+DI{D}_{*}·g_2$$

  (18)

  $$co{m}_{*}\stackrel{?}{=}{{com}_{*}}^{\prime }$$

  (19)

  if $co{m}_{*}\ne {{com}_{*}}^{\prime }$: error message $\perp$
• Step 8: The Issuer sends $DI{D}_{*}$ to the VDR, requesting the Merkle root value ${root}_{*}$ of the transaction containing the DID. The VDR then sends $roo{t}_{*}$ if the corresponding $M{T}_{*}$ contains $DI{D}_{*}$ as a transaction $DT{x}_{*}$.
  The Merkle tree registration verification process is as follows:
  If $H\left(DT{x}_{*}\right)\in M{T}_{*}=valid:$ send $roo{t}_{*}$.
  Otherwise, error message $\perp$.
• Step 9: The Issuer inputs the received ${root}_{*}$, $co{m}_{*}$, $pp$ into NIZK to generate $AI{D}_{*}$.

  $${AID}_{*}=Prove({root}_{*},co{m}_{*},crs)$$

  (20)
• Step 10: The Issuer transmits the generated $AI{D}_{*}$ to both the Holder and Delegatee.

4.4.3. VC Issuance

The VC Issuance phase involves the Holder sending their anonymous DID and claims to the Issuer and requesting the issuance of a VC. Upon receiving the request, the Issuer verifies the authenticity of the claims received from the Holder and creates a VC if they are valid. The Issuer then issues the generated VC to the Holder.

• Step 1: The Holder sends their $AI{D}_H$, $clai{m}_i,\dots ,clai{m}_j$ to the Issuer and requests the issuance of a VC.
• Step 2: The Issuer verifies the authenticity of $clai{m}_i$ and, if valid, creates the VC as follows.
  If $clai{m}_i=valid$:

  $$h_{claim}=H\left(AI{D}_H,clai{m}_i,\dots ,clai{m}_j\right)$$

  (21)

  $${\sigma }_{I_{claim}}=si{g}_{s{k}_I}\left(h_{claim}\right)$$

  (22)

  $$V{C}_k={\left\{DI{D}_I,AI{D}_H,clai{m}_i,\dots ,clai{m}_j,{\sigma }_{I_{claim}}\right\}}_{(k,i,j\in [1,n\left]\right)}$$

  (23)

  otherwise, error message $\perp$.
• Step 3: The Issuer sends the generated $V{C}_k$ to the Holder.
• Step 4: The Holder verifies ${\sigma }_{I_{claim}}$ in the received $V{C}_k$ using the Issuer’s public key $p{k}_I$. If the verification is correct, the Holder securely stores $V{C}_k$; otherwise, they repeat Step 1 of the VC Issuance.
  If ${\sigma }_{I_{claim}}=valid$: store $V{C}_k$.
  Otherwise, repeat Step 1 of the VC Issuance.

4.4.4. Delegation

The Delegation phase involves mutual authentication between the Holder and Delegatee, with the Delegatee sending their anonymous DID to the Holder. The Holder then sends their VC and the Delegatee’s anonymous DID to the Issuer, requesting the issuance of a VC for delegation. Subsequently, the Holder combines various VCs and VCs for delegation to create a VP and delegates it to the Delegatee.

• Step 1: The Holder and Delegatee mutually authenticate their $DI{D}_{*}$ via a TLS handshake, and upon successful authentication, the Delegatee securely transmits their $ADI{D}_D$ to the Holder.
• Step 2: The Holder sends their $AI{D}_H$ and the Delegatee’s $AI{D}_D$ to the Issuer, requesting the issuance of a VC for delegation, $DV{C}_{H\to D}$.
• Step 3: Upon request, the Issuer verifies the authenticity of $AI{D}_H$ and $AI{D}_D$ and, if valid, creates $DV{C}_{H\to D}$. The Issuer then issues $DV{C}_{H\to D}$ to the Holder.

  $$h_{AID}=H\left(AI{D}_H,AI{D}_D\right)$$

  (24)

  $${\sigma }_{I_{AID}}=si{g}_{s{k}_I}\left(h_{AID}\right)$$

  (25)

  $$DV{C}_{H\to D}=\{DI{D}_I,AI{D}_H,AI{D}_D,{\sigma }_{I_{AID}}\}$$

  (26)
• Step 4: The Holder, having received the VC for delegation, uses their $V{C}_k$ and $DV{C}_{H\to D}$ to create $V{P}_{H\to D}$ and securely delegates it to the Delegatee.

  $$V{P}_{H\to D}={\left\{V{C}_k,DV{C}_{H\to D}\right\}}_{(k\in [1,n\left]\right)}$$

  (27)

4.4.5. VP Verification

In the VP Verification phase, the Delegatee undergoes authentication verification by the Verifier on behalf of the Holder. For this purpose, the Delegatee creates an RVP (Reconstructed VP) based on sequential aggregate signatures and submits it to the Verifier, who then verifies the RVP and, if valid, provides services to the Delegatee.

• Step 1: The Delegatee requests authentication from the Verifier on behalf of the Holder.
• Step 2: The Verifier requests the necessary credentials to provide the service.
• Step 3: Upon request, the Delegatee combines the appropriate credentials and generates $RV{P}_D$ based on sequential aggregate signatures as follows.

  $$sr\in Z_p^{*}$$

  (28)

  $$A=r^{-1}·P,B=\mathrm{s}r·s{k}_D\left({\prod }_{i=1}^{k}V{C}_{i}DV{C}_{H\to D}p{k}_i\right)$$

  (29)

  $${\varsigma }_D=(A,B)$$

  (30)

  $$RV{P}_D=\{V{P}_{H\to D},{\varsigma }_D\}$$

  (31)
• Step 4: The Delegatee creates an encrypted ciphertext $CT$ using $RV{P}_D$, ${com}_D$, ${DID}_D$, $r{c}_D$, and the Verifier’s public key, and sends it to the Verifier.

  $$CT=E_{p{k}_V}(RV{P}_D,{com}_D,{DID}_D,{rc}_D)$$

  (32)
• Step 5: The receiving Verifier decrypts the ciphertext $CT$ using their private key.

  $$RV{P}_D=D_{s{k}_V}\left(CT\right)$$

  (33)
• Step 6: The Verifier verifies $co{m}_D$ and responds with an error message $\perp$ if invalid.
  The Verifier’s commitment verification process is as follows:

  $${{com}_D}^{\prime }=r{c}_D·g_1+DI{D}_D·g_2$$

  (34)

  $$co{m}_D\stackrel{?}{=}{{com}_D}^{\prime }$$

  (35)

  if ${com}_D\ne {{com}_D}^{\prime }$: error message $\perp$.
• Step 7: The Verifier extracts $DI{D}_I$ from $RV{P}_D$ and sends $DI{D}_I$, $DI{D}_D$ to the VDR, requesting $DD{O}_I$, $DD{O}_D$.
• Step 8: The VDR uses DID Resolve to find $DD{O}_I$,$DD{O}_D$ mapped to $DI{D}_I$, $DI{D}_D$ and sends them to the Verifier if a match is found.
• Step 9: The Verifier extracts $p{k}_I$, $p{k}_D$ from $DD{O}_I$, $DD{O}_D$ and verifies $RV{P}_D$ as follows.

  $$C={\prod }_{i=1}^{k}V{C}_{i}DV{C}_{H\to D}p{k}_i$$

  (36)

  $$e(A,B)\stackrel{?}{=}e(C,p{k}_D)$$

  (37)

4.4.6. Revocation

In the Revocation phase, if the Holder wishes to revoke a credential previously delegated to the Delegatee, the Holder sends anonymous DIDs and VCs for delegation to the Issuer. The Issuer verifies VCs for delegation and decides on the delegation status. If valid, the Issuer adds this information to the revocation list and updates the list in the VDR.

• Step 1: The Holder sends $AI{D}_H$, $AI{D}_D$, $DV{C}_{H\to D}$ to the Issuer, requesting revocation of the delegated credential.
• Step 2: The Issuer verifies if $DV{C}_{H\to D}$ was issued by them.
• Step 3: If valid, the Issuer adds $AI{D}_H$, $ADI{D}_D$, $DV{C}_{H\to D}$, and the revoked date to the revocation list.

  $${RL}^{\prime }=\{AI{D}_H,AI{D}_D,DV{C}_{H\to D},date\}$$

  (38)
• Step 4: The Issuer sends the updated revocation list to the VDR for recording.
• Step 5: The VDR records ${RL}^{\prime }$.

5. Analysis of Proposed Scheme

In this section, the security requirements and additional requirements presented in Section 3 are analyzed, as shown in

Table 2. Analysis table of proposed scheme for delegation.

Requirements	Sabadello et al. [25]	Boneh et al. [26]	Lysyanskaya et al. [27]	Proposed Scheme
Authentication of Delegation	Delegatee’s DID in VC	Delegatee’s DID in VC	Delegatee’s DID in DDO	Delegatee’s DID in VC and SAS
Prevention of Impersonation Attack	PKI	PKI	PKI	PKI, Commitment, NIZK
Revocation of Delegatee	X	Δ (Timestamp)	Δ (Timestamp)	Revocation List
Prevention of Linkage Attack	X	X	X	NIZK, Merkle Tree

Δ: Some provided, X: not provided.

,

Table 3. Analysis table of proposed scheme for anonymity.

Requirements	Song [21]	Yin et al. [22]	Kim [32]	Bosk et al. [33]	Proposed Scheme
Unforgeability	DSA	DSA and sign the digest of the claims	DSA	PS Signature	ECDSA, SAS
Unlinkability (DID)	Commitment and NIZK Proof	X	sDID	NIZK, Aggregate, and PS Signature	Commitment and NIZK Proof
Privacy	Commitment, NIZK, and Merkle tree	Δ (Commitment, AND, OR, and Range Proof)	Δ	NIZK, Aggregate, PS Signature	Commitment, NIZK, and Merkle tree
Prevention of Sybil Attack	Commitment, NIZK Proof, Merkle tree	Registration through Issuer	X	X	Commitment, NIZK Proof, and Merkle tree
Minimization of DDO Records in VDR	Low	-	High	Low	Low

Δ: Some provided, X: not provided.

,

Table 4. Analysis table of proposed scheme for efficiency comparison.

Requirements	Sabadello et al. [25]	Boneh et al. [26]	Lysyanskaya et al. [27]	Proposed Scheme
Sign	$3nmEM$	$3nmEM$	$3nmEM$	$(n+2m)EM$
Verify	$3nm(EA+2EM)$	$3nm(EA+2EM)$	$3nm(EA+2EM)$	$nmP$

n: Number of VCs for delegation, m: number of Delegatees, EA: elliptic curve addition, EM: elliptic curve multiplication, P: pairing.

and

Table 5. Computational amount parameters.

Symbol	Definition	Calculation Amount
$t_m$	Time of modular multiplication	$t_m$
$E$	Exponentiation	$\approx 240t_m$
$EM$	Elliptic curve point multiplication	$\approx 29t_m$
$P$	Bilinear pairing	$\approx 87t_m$

and Figure 4.

5.1. Primary Security Analysis

5.1.1. Delegation

• Authentication of Delegation

With DIDs, the Holder must be able to delegate temporarily or permanently some or all of their authority to another entity and confirm that the Holder intended to delegate this authority. To this end, this paper proposed issuing $DV{C}_{H\to D}$, which includes the Holder’s $AI{D}_H$ and Delegatee’s $AI{D}_D$, from the Issuer to create $V{P}_{H\to D}$, as shown in Equations (39)–(42). By delegating the created $V{P}_{H\to D}$ to the Delegatee, proof of authority delegation can be presented, as shown in Equations (43)–(47).

$$h_{AID}=H\left(AI{D}_H,AI{D}_D\right)$$

(39)

$${\sigma }_{I_{AID}}=si{g}_{s{k}_I}\left(h_{AID}\right)$$

(40)

$$DV{C}_{H\to D}=\{DI{D}_I,AI{D}_H,AI{D}_D,{\sigma }_{I_{AID}}\}$$

(41)

$$V{P}_{H\to D}={\left\{V{C}_k,DV{C}_{H\to D}\right\}}_{(k\in [1,n\left]\right)}$$

(42)

$$A=r^{-1}·P,B=\mathrm{s}r·s{k}_D({\prod }_{i=1}^{k}V{C}_{i}DV{C}_{H\to D}p{k}_i)$$

(43)

$${\varsigma }_D=(A,B)$$

(44)

$$RV{P}_D=\{V{P}_{H\to D},{\varsigma }_D\}$$

(45)

$$C={\prod }_{i=1}^{k}V{C}_{i}DV{C}_{H\to D}p{k}_i$$

(46)

$$e(A,B)\stackrel{?}{=}e(C,p{k}_D)$$

(47)

• Revocation of Delegatee

The Holder may want to revoke some of the delegated authority to the Delegatee at any time and must be able to cancel such authority delegation. Additionally, if an unauthorized Delegatee makes a request, the Verifier should be able to cryptographically verify the Delegatee’s credentials. Subsequently, the Verifier should provide verification services for illegal authentication requests and be able to block them. To facilitate this, the proposed scheme adds information about $AI{D}_D$ and the $V{P}_{H\to D}$ delegated to the Delegatee to the revocation list ${RL}^{\prime }$ and updates it in the VDR, as shown in Equations (48) and (49).

$${RL}^{\prime }=\{AI{D}_H,AI{D}_D,DV{C}_{H\to D},date\}$$

(48)

$$RT{X}_I=\left\{Add{r}_I, {RL}^{\prime }, Add{r}_{VDR}, {\sigma }_{I_{RL\mathrm{’}}},p{k}_I\right\}$$

(49)

5.1.2. Anonymity

• Prevention of Linkage Attack (Unlinkability)

The proposed scheme is based on the Pedersen Commitment and NIZK, and the Holder or Delegate receives $AI{D}_H$ or $AI{D}_D$ from the Issuer and includes it in the VC for delegation $DV{C}_{H\to D}$ to prevent linkage attacks. In other words, each time the Holder provides delegation according to the level of authority to the Delegatee, a VC for delegation containing different $AI{D}_H$ and $AI{D}_D$ is issued from the Issuer. Afterward, the Holder uses this as input to create a VP and delegates it to the Delegatee. Then, the Delegatee creates an RVP using the received VP and later transmits it to the verifier to perform authentication on its behalf. Through this, even if an attacker obtains various RVPs through illegal routes, the $AI{D}_H$ and $AI{D}_D$ contained in the RVPs are different, so the attacker can break the connection, which guarantees the anonymity of the Holder and Delegatee.

• Prevention of Sybil Attack

The proposed scheme involves the Holder or Delegatee collaborating with the Issuer and the VDR and prevents Sybil attacks based on the Pedersen Commitment, NIZK Proof, and Merkle tree. In the proposed scheme, the Issuer requests the VDR to verify that the actual Holder or Delegatee’s DID is included in the Merkle tree. The requested VDR checks whether the transaction $DT{x}_{*}$ containing the received Holder or Delegatee’s DID is included in the Merkle tree, as shown in Equations (50) and (51). The VDR then responds to the results $roo{t}_{*}$ to the Issuer, and if included, the Issuer generates an $AI{D}_{*}$ with $DI{D}_{*}$, $roo{t}_{*}$, and other data as input, as shown in Equations (52)–(55). Afterward, the Holder or Delegatee requests service from the Verifier, and the Verifier performs authentication. However, if the Holder or Delegatee is in doubt, the Verifier may require the Holder to prove their $DT{x}_{*}$, $AI{D}_{*}$, and the Verifier can cooperate with the VDR to generate $DT{x}_{*}$, $AI{D}_{*}$ to verify. If the $DT{x}_{*}$, $AI{D}_{*}$ for this are incorrect, the Verifier may determine that the Holder has a fake identity and refuse service, as shown in Equation (56). Therefore, the proposed scheme can prevent Sybil attacks.

$$H\left({{DTx}_{*}}^{\prime }\right)\in M{T}_{*}\stackrel{?}{=}valid$$

(50)

$${{root}_{*}}^{\prime }=H{\left(...\left(H\left(H\left(H\left(DT{x}_{*}\right)\parallel H\left({DTx}_1\right)\right)\parallel ...\right)\parallel H\left({DTx}_{k-1}\right)\right)\parallel H\left({DTx}_k\right)\right)}_{k\in [1,n]}$$

(51)

$${{root}_{*}}^{\prime }\in M{T}_{*}\stackrel{?}{=}valid$$

(52)

$${{com}_{*}}^{\prime }={{rc}_{*}}^{\prime }·g_1+{{DID}_{*}}^{\prime }·g_2$$

(53)

$$co{m}_{*}\stackrel{?}{=}{{com}_{*}}^{\prime }$$

(54)

$${{AID}_{*}}^{\prime }=Prove({{root}_{*}}^{\prime },{{com}_{*}}^{\prime },crs)$$

(55)

$${AID}_{*}\stackrel{?}{=}{{AID}_{*}}^{\prime }\mathrm{}$$

(56)

5.2. Efficiency

For the efficiency analysis in this paper, we compare existing related schemes with the proposed scheme as follows. The paper considers computational complexity as provided in Table 4 and Table 5 [38,39], and analyzes optimization in VC management and minimization in VP storage capacity for the Issuer, Holder, Delegatee, and Verifier.

• Optimization of VC Management

This paper assumes a context length of 120 bytes, a DID length of 50 bytes, a claim length of 250 bytes, a signature length of 64 bytes, a proof length of 320 bytes, a VC length of 804 bytes, and a length of 854 bytes for a VC for a delegation intended for delegation.

When creating a single VP based on $n$ VCs for a delegation to provide delegation to $m$ Delegatees, the existing schemes [21,22,32,33] generate with the size being the number of VC for delegation ($n$) * the number of Delegatee ($m$) + $n\ast m\ast$ VC for delegation. The existing scheme requires $m$ separate original VCs rather than VCs for delegation. As an exception, in [32], the DID length is 16 bytes.

To optimize VP storage capacity, this paper generates a size of ((($n$ + 1) + $m$) ∗ VC for delegation) + VC. Additionally, the proposed scheme requires at least two VCs when creating a VP for delegation. However, compared to the existing and reconstructed schemes, the former is small when there is only one VC for delegation, but the latter is efficient when there are many VCs for delegation, or the number of delegates is large.

• Minimization of VP Storage Capacity

Existing schemes are identical to creating a VP from a regular DID. In the existing proposed scheme, the Delegatee selects a VC for delegation and generates the Delegatee’s ECDSA-based digital signature as input to create a VP. Existing schemes include at least three signatures (Issuer, Holder, and Delegatee) in the VP, and as the number of VCs included in the VP increases, the digital signature increases by more than two times.

This proposed scheme performs sequential aggregate signatures by inputting the Issuer included in the VP received by the Delegatee from the Holder, the Holder’s digital signature, and the Delegatee’s private key. Afterward, the generated signature and VP are combined to create a Reconstructed VP. Here, by using sequential aggregate signatures, the digital signatures of the Issuer and Holder can be reduced to one. This proposed scheme minimizes the VP storage capacity.

However, when the Holder delegates to a single Delegatee, existing schemes are more efficient than this proposed scheme, but when there are multiple Delegatees, this proposed scheme is more efficient.

• Minimization of DDO Records in VDR

This proposed scheme initially creates a DDO when the Holder and Delegatee generate their DID, binding it with the corresponding public key. However, to reduce the burden on the VDR and ensure the anonymity of the Holder or Delegatee, the proposed scheme uses the Pedersen Commitment and NIZK to generate $AI{D}_H$, and $AI{D}_D$ through the Issuer and includes them in the VP. This allows for verification by the Verifier, minimizing the storage capacity in the VDR.

6. Conclusions

This paper presented an innovative approach to reconstructing VPs for a minimally secure delegation of authority using schemes such as SAS, NIZK Proof, and Merkle tree to maintain anonymity and prevent Sybil attacks in DIDs. These measures ensure that users’ identities remain protected even when multiple VPs are analyzed, addressing the crucial challenge of preserving self-sovereignty in the digital era.

Additionally, the proposed scheme proposed optimizations to manage VCs and minimize VP storage requirements to address the efficiency and security issues of the delegation process. This strategy mitigates security risks related to delegation and anonymity, efficiently reduces the computational and verification efforts for signatures, and reduces the size of the VP by about 1.2 to 2 times. In other words, this enhances privacy protection and respects individuals’ autonomy over their digital identities, reinforcing the right to self-determination.

Future works will refine and evaluate the proposed scheme’s performance to meet evolving security needs and offer a robust and reliable framework for digital identity management in the DID ecosystem.