Self-Sovereign Identity (SSI) represents a paradigm of identity management which resolves issues of current Identity Management System (IMS) by providing to users full control over their personal data without relying on third-party providers. Decentralized Identifiers (DIDs) are essential components of SSI as they provide a new type of identifier enabling to uniquely and globally identify an entity without having to rely on a central authority. In this paper, we investigate the anonimity of DIDs used in SSI by using diferent sources of information to assess if these systems expose sensitive information that can be exploited to infer personal information about users. We leverage the proposed framework to evaluate the anonymity properties of a real-world DID implementation based on the Ethereum blockchain, highlighting the system's strengths and weaknesses in terms of privacy and de-anonymization risks.
In today’s interconnected world, the concept of digital identity has become a fundamental part of how individuals interact online, including personal, social and professional aspects. Digital identity can be defined, therefore, as the collection of a person’s attributes or characteristics that are exhibited in online interactions.
A traditional digital identity uniquely represents an individual or entity in the context of a specific digital service and it consists of two main components: i) the identifier that an entity uses to uniquely recognize and diferentiate themselves from other entities, and ii) the personal information associated to the identifiers, such as personal profile information, driver’s licenses, and university degrees. Typical examples of identifiers we use every day include email addresses, social network usernames, ID numbers, and product identifiers. Identity Management Systems (IMS) are responsible for managing diferent aspects of digital identities, including how identifiers are created, stored, accessed, and authenticated within a system. The majority of IMSs are based on a centralized or federated architecture consisting of two diferent types of actors: i) the identity providers, which act as IMS by providing identity creation, storage and authentication, and ii) the service providers, which request authentication decisions from identity providers in order to assert the identity of a user and retrieve their attributes. Both centralized and federated identity models sufer from significant vulnerabilities, such as single points of failure, privacy concerns related to the control of identifiers to a central authority, and dependency on third-party providers.
Self-Sovereign Identity (SSI) [
Despite the privacy-preserving promises of SSI, DIDs can still expose users to identification and
deanonymization risks if they are not managed properly by identity owners [
The goal of this paper is to investigate the anonimity of DIDs used in SSI by using diferent sources
of information to assess whether these systems expose sensitive information that can be exploited
to infer personal information about users. To achieve this, the paper proposes a framework that is
responsible for the acquisition of information related to DIDs, the modeling, and the analysis of the
extracted information. The framework is designed and specialized to operate on blockhain-based DIDs
[
The outline of the paper is as follows. The foundational concepts related to SSI are described in Section 2 while the related works regarding de-anonymization and security of DIDs are presented in Section 3. The analysis and identification of the risks for anonymity in DIDs is described in 4. The architecture and functionalities of the proposed framework are described in Section 5, while Section 6 presents the results of the proposed framework on an Ethereum-based DID implementation. Finally, Section 7 draws conclusions and future improvements.
SSI represents an innovative paradigm in identity management, where users have full control over their
personal data without having to rely on a central authority. Unlike centralized or federated systems,
where identities are managed by third parties, the SSI architecture enables individuals to create, manage,
and share their credentials in a secure and transparent manner. The foundation of SSI is based on 10
principles firstly defined in [
In order to guarantee these principles, the SSI relies on three fundamental pillars: Decentralized Identifiers (DID) to represents users’ identities, Verifiable Credentials (VC) and Verifiable Presentation (VP) to represents identities information, and Verifiable Data Registry to support credential/identity management and verification.
Decentralized Identifiers (DIDs) provide a new type of identifier which enables to uniquely and globally
identifies an entity. Unlike traditional identifiers, DIDs are cryptographically verifiable and controlled
by the entity (individual or organization) that owns them. Unlike traditional identifiers like e-mail,
phone number, or username, which are managed and owned by centralized authorities, DIDs remain
under the control of their owners as long as they possess the corresponding criptographic material. A
DID, as described in W3C documentation [
As for example, the DID method did:ethr is a library providing DIDs under the Ethereum domain
[
Listing 1: DID document example. { ’ @context ’ : [ ’ h t t p s : / / www. w3 . o r g / ns / d i d / v1 ’ , ’ h t t p s : / / w3id . o r g / s e c u r i t y / s u i t e s / s e c p 2 5 6 k 1 r e c o v e r y − 2 0 2 0 / v2 ’ ] , i d : ’ d i d : e t h r : 0 x 1 2 3 4 5 6 7 8 9 . . . ’ , v e r i f i c a t i o n M e t h o d : [ { i d : ’ d i d : e t h r : 0 x 1 2 3 4 5 6 7 8 9 . . . # c o n t r o l l e r ’ , t y p e : ’ E c d s a S e c p 2 5 6 k 1 R e c o v e r y M e t h o d 2 0 2 0 ’ , c o n t r o l l e r : ’ d i d : e t h r : 0 x 1 2 3 4 5 6 7 8 9 . . . ’ , b l o c k c h a i n A c c o u n t I d : ’ e i p 1 5 5 : 1 : 0 x 1 2 3 4 5 6 7 8 9 . . . ’ } ] , a s s e r t i o n M e t h o d : [
’ d i d : e t h r : 0 x 1 2 3 4 5 6 7 8 9 . . . # c o n t r o l l e r ’ ] , a u t h e n t i c a t i o n : [
’ d i d : e t h r : 0 x 1 2 3 4 5 6 7 8 9 . . . # c o n t r o l l e r ’ }
A Verifiable Credential, as described in W3C documentation [
Users can generate Verifiable Presentations from VC and then share them with a verifier to prove that they possess VCs with certain characteristics. A Verifiable Presentation (VP) is the sharing of a subset of data regarding a user, and they can express data from multiple VCs. VPs are created by the VC’s owner (the user itself) and they may contain metadata that describes contextual information for proper verification (e.g., creation time, and validity) and selective disclosure information regarding the credential. Selective disclosure approaches can be used to limit the exposure of data to a verifier and to select the data of the credential to be revealed to the verifier. The VP and the corresponding metadata are cryphographically signed by the user in order to ensure its authenticity and integrity. Both VCs and VPs can be transmitted directly to the verifier, who being able to verify them without the intervention of third parties.
Several properties of the blockchain, such as decentralization, the tamper-evident and verifiable nature
of the data stored on the blockchain, align with SSI principles and make the blockchain one of the leading
solutions for supporting the creation, management, and verification of DIDs. Several DID methods
exploit the blockchain solution as a verifiable data registry where DIDs can be easily discovered and
resolved [
The did:ethr is a practical example of a DID method that uses the Ethereum blockchain as a verifiable
data registry to manage DID documents [
This section provides an overview of the existing scientific contributions relevant to user deanonymization focusing on SSI systems.
De-anonymization in SSI systems presents significant risk of threats to the privacy and security of
personal information. Such vulnerabilities, if breached by malicious parties, can lead to track, profile,
or impersonate a user. Authors of [
The initial security and privacy considerations for DID were provided in the DID W3C specification
[
The analisys proposed in [
Naik, Grace et al. [
Krul, Paik et al. [
The SPDID system proposed in [
The authors of [
Despite the privacy-preserving promises of SSI, certain elements within Decentralized Identifiers (DIDs) can expose users to re-identification and de-anonymisation risks if not properly managed. The metadata and the information of a DID document could potentially be exploited by malicious actors to compromise their anonymity, inferring also sensitive information from Verifiable Credentials (VCs) and Verifiable Presentations (VP).
For this reason, it becomes crucial to analyze these elements in SSI systems to identify and mitigate potential vulnerabilities. By understanding the ways in which anonymity could be compromised, it is possible to develop strategies to reinforce privacy protections within SSI ecosystems.
SSI achieves anonymity by providing the users with control and management of digital identities without relying on central authorities. This is accomplished through the use of DIDs and VCs to enable secure and private interactions. A DID is a pseudonym created and owned by the users and does not reveal any sensitive information of the entity. The DIDs are cryptographically generated by the user and stored in decentralized fashion, without being controlled by any central authority. This decentralized nature helps to protect the user’s privacy and ensures that control over the identifier remains entirely with the user. In SSI systems, DIDs are used in combination with VCs, allowing users to create context-specific credentials. With the help of the selective disclosure, the user can select which data to disclose; thus, this ensures that only the minimum necessary data are exposed for a given transaction. Also, through the use of zero-knowledge proofs protocol, it allows users to verify the validity of credentials or claims without necessarily showing the actual data. The interplay of user control, selective disclosure, and cryptography techniques ensures that users can interact with other parties maintaining their privacy and anonymity, while still meeting the necessary requirements for identity verification and trust within the SSI ecosystem.
The degree of anonymity provided by DIDs can be compromised if they are not properly implemented and used. For instance, repeated use of the same DID across multiple contexts can lead to linkability, where diferent interactions can be correlated, compromising user anonymity. Similarly, although VCs enable selective disclosure, improper implementation or the inclusion of excessive personal information within a credential can expose users to privacy risks. In the following sections, an attacker model is developed and a deep analysis of DID, VC and VP vulnerable fields is made.
Let denote a user in an SSI system and PID represent a pseudonymous identifier used by (e.g., a DID). An adversary denoted by aims to deanonymize by successfully establishing a mapping from PID to , that is, : PID → . This mapping is achieved by exploiting vulnerabilities in SSI mechanisms, and public information about interactions, transactions, or metadata, such that can, with non-negligible probability, correctly associate PID with the real-world identity .
In this section, the properties of DIDs are analyzed to identify potential vulnerabilities that could be
exploited for de-anonymization attacks. By understanding the structure and data contained within these
entities, it is possible to assess the risks associated with their use and develop strategies to mitigate them.
The level of anonymity of a DIDs impacts also VC and VP, where issuers and subjects of credentials are
typically represented by DIDs. In order to discover the vulnerabilities, we analyzed the fields contained
within DID to understand which of them are vulnerable to de-anonymization attacks. This allowed to
Source of attack Description Countermeasures
ServiceEndpoint If DID1 and DID2 have the same serviceEndpoint property, it Encryption - Hashing
is likely that DID1 = DID2. Also, if a serviceEndpoint shows a
website link, it can be attackable
publicKeyPem/ publicK- If DID2 and DID2 use the same key, it implies that both identi- Use DIDs associated with
eyHex fiers are controlled by the same entity diferent keys for each
interaction
AlsoKnowAs If DID1 and DID2 have the same alsoKnowAs property, it is Encryption - Hashing
likely that DID1 = DID2
equivalentID/ canoni- If DID1 and DID2 have the same equivalentID property, it is Encryption - Hashing
calID likely that DID1 = DID2
capabilityDelegation If DID1 and DID2 have the same capabilityDelegation property, Pay attention to the entities
it is likely that DID1 = DID2 to which delegate
verificationMethod If DID1 and DID2 have the same verificationMethod property, Unique methods for each
it is possible that DID1 = DID2 DID - Encryption - Hashing
History of a DID Having access to the history of DID document referring to the Try to provide as little
usesame DID can be a form of user trafic analysis (derived from ful information as possible
the public and standardised nature of DID) in DID documents
identify the fields to be considered as sources of attack, the type of attacks, and the countermeasures
used to mitigate the vulnerability examined.
4.2.1. Decentralized Identifiers Vulnerabilities
This section provides a detailed description of the vulnerable fields in DID documents that could be
exploited by attackers to perform de-anonymization of an entity. Table 1 summarizes the vulnerability
and the countermeasure identified for each field.
serviceEndpoint The field is used in DID documents to express ways of communicating with the
DID subject or associated entities. In particular, the serviceEndpoint property within a DID document
specifies a URL or other resource location that the DID holder wants to associate with their identifier.
This could be an API endpoint, a contact method, or any other type of service. If two diferent DIDs
share the same serviceEndpoint, it could indicate that the same entity controls both identifiers. This
weakens the anonymity of the DID holder because an attacker can compare and correlate diferent
identities based on this shared service endpoint. To mitigate this vulnerability, it is possible to encrypt
or hash with nonce the value of the serviceEndpoint, so that the information becomes unintelligible to
unauthorized parties. When the DID owner receives an interaction request, it can decide whether or
not to reveal this data to the other party.
publicKeyPem/publicKeyHex This field of a DID document contains the public key in PEM (Privacy
Enhanced Mail) or Hex format. This key is used in various cryptographic operations like verifying
signatures and ensuring the integrity of messages or transactions associated with the DID. Since the
public key itself is not secret, the usage of the same public key on diferent DIDs can lead to serious
security issues. An attacker can compare the public key used by diferent DIDs and collects the DIDs
controlled by the same public key in order to link identities. To mitigate this vulnerability, the DID
specification [
History of a DID When a blockchain-based DID used, its history is typically recorded as a series of transactions or updates on the blockchain. Access to the complete history of a DID can be a significant privacy risk: an attacker performing trafic analysis might deduce patterns or behaviors based on transactions. Limiting the use of a DID to a specific activity can efectively reduce the risk of user trafic analysis and de-anonymisation attacks by using public blockchain data.
De-anonymization attacks in Ethereum DID ecosystem are possible through a systematic approach starting from analyzing DID documents, transactions and interactions, to create a DID profile. Figure 1 shows the workflow used to analyze the anonymity of DID by the proposed framework. The main phases of the framework are the data acquisition, in which all the necessary data are taken, the DID analysis, in which the DID documents and their fields are analysed based on the vunerabilities identified in Section 4, and the graph analysis, in which the data enriched with graph formalism to perform diferent tasks, such as the community analysis.
Firstly, the address of smart contracts responsible for managing DIDs within the Ethereum blockchain are identified. As for example, the ethr-did-registry smart contract provided by the did:ethr DID method operates at the address 0xdCa7EF03e98e0DC2B855bE647C39ABe984fcF21B. The access to the Ethereum blockchain is performed in order to read all transactions which invoked the ethr-did-registry smart contract. These transactions are directly linked to DIDs because Etherum addresses are used as DID identifiers and only the DID owner can perform transactions on the ethr-did-registry smart contract. For this reason, we retrieved values of the sender address specified by the from field of each transaction. Based on the specification of the did:ethr method, the Ethereum address of the sender serves as unique DID identifier, allowing the framework resolve each DID into the corresponding DID document. Another source of information that is important to understand the behavior and interactions of blockchain-based DIDs are transactions initiated by DIDs using the same blockchain address specified in the DID document. For this reason, for every DID identified in the ethr-did-registry, all the transactions in which DIDs are involved are retrieved from the Ethereum blockchain.
In addition to internal blockchain data, the data acquisition component extracts information related to
a DID identifier from external sources (such as block explorer and analytics platform [
The collected data are transformed by the framework into a graph model to enable de-anonymization analysis. Each unique Ethereum address collected during data acquisition is represented as a node in the graph, and an edge is created between two nodes whenever a transaction occurs between the corresponding addresses. The edges are directed, reflecting the direction of the transaction from the source DID to the target DID, and the weight of each edge is determined by the number of times a particular operation occurred between the source and target DIDs. If multiple transactions of the same operation occur between the same pair of addresses, the counts are aggregated to reflect the total frequency, indicating how often interactions happened between two specific users. Each node in the graph is enriched with a set of attributes derived from both blockchain data and
external services. These attributes include the DID document, DID nametag, DID funder, and other relevant information related to a DID.
The data analysis component conducts vulnerability detection and graph analysis on the model to identify potential risks and patterns of de-anonymization. It examines how these DIDs interact within diferent communities and the types of operations performed by each.
DID Vulnerabilities Detection This component indicates vulnerable fields from a DID document based on the analysis presented in Section 4, such as serviceEndpoint, alsoKnownAs or other metadata informations that might link a DID to a real-world identity or a recognizable entity. In addition to identify vulnerabilities in the DID document, the component is able to evaluate the distribution of the operations made by DIDs on the DID document by analyzing the transactions on the ethr-did-registry smart contract.
Graph Analysis Graph analysis is chosen because it serves as a powerful tool for understanding the unique attributes and behaviors associated with each DID. By constructing and analyzing a graph representing the interactions and relationships of DIDs, it becomes possible to uncover specific patterns and characteristics that are distinctive to each DID. These insights enable the creation of detailed profiles, facilitating the process of de-anonymization by associating behaviors, operations, and connections to potential real-world entities or contexts.
For this reason, the framework is able to compute general graph metrics: such as measures the number of nodes and edges, how closely the nodes in a graph are connected (density), assesses the degree to which nodes in a graph tend to cluster together (Clustering coeficient), quantifies the strength of division of a graph into communities (Modularity), measures the uniformity of a graph’s connections within communities (Homogeneity), examines the tendency of nodes to connect with similar nodes (Assortativity).
Another important technique provided by the framework for the analysis of the DIDs is based on centrality. Centrality measures allow to identify key entities or operations, and their role within the system. For this reason, the framework includes various measures, such as degree, betweenness, and closeness centrality that indicate the importance or influence of a node within the graph.
The proposed framework also integrates a community detection algorithm based Louvain method which is able to group the DIDs into distinct communities. The community analysis of DIDs can provide important information about the intractions and behavior of DIDs and can be used to extract informations the entities with which a DID has frequently interacted and belongs to the same community. In addition, community detection allows to identify the type of activities a DID is involved in and the platforms or entities it interacts with. For example, if a DID is involved in particular tokens, it is possible to infer some behavioural information. Similarly, investments in niche tokens or markets could reveal personal interests or financial positions.
By combining the blockchain data (transactions, token), external data (such as nametage and funders), and potential vulnerabilities in the DID document, it is possible to build a detailed profile of a DID. Such profile can be enriched by using information related to the behavior, associations, and metadata.
This section presents the results of the analysis conducted on Ethereum DIDs ecosystem by exploiting an implementation of the proposed framework3. 3Available at https://github.com/Breian/DLT2025---Assessing-the-Anonymity-of-DIDs-in-Self-Sovereing-Identity.git. (a) DID’s operations
(b) Targets of DID’s operations (c) DIDs verification methods
We present the results of the DID Vulnerabilities analysis by analyzing the distribution of the vulnerable ifelds in DID document and operation obtained by a total of 31714 transactions performed on the ethr-did-registry smart contract by DID owners. 6.1.1. DID documents The transactions list allow the resolution of 3613 distinct DID documents. The results reveal that attributes versionId and updated of a DID document occur very frequently (3259 DID documents specify these attributes), suggesting that most of the DID owners have versioned their DID document and have updated them at least once since their creation. The DID vulnerabilities analysis also reveals the presence of the attributes serviceEndpoint, publicKeyBase58 and publicKeyHex, that could potentially expose sensitive information of 10 diferent DID documents over 3613. The distribution of these fields within the collected dataset is shown in Figure 2c.
The public key fields publicKeyBase58 or publicKeyHex are used by few DID documents in order to
specify a diferent authentication key based on either EdDSA algorithm [
The vulnerabilities of the verification method across the DID documents are identified by examining the verificationMethod ifeld of each DID and checking if one method is similar or identical to other DID documents. The verification methods used in DID documents are EcdsaSecp256k1RecoveryMethod2020, X25519KeyAgreementKey2019, and EcdsaSecp256k1VerificationKey2019 . The EcdsaSecp256k1RecoveryMethod2020 verification method is used by 99% of the analysed DIDs and it is an ECDSA algorithm based on the Secp256k1 curve. The method X25519KeyAgreementKey2019 is used by only one DID to specify a elliptic curve key agreement algorithm while EcdsaSecp256k1VerificationKey2019 is used by 2 DIDs to specify another ECDSA method using based on secp256k1 curve. The analysis of the verificationMethod reveals that the majority of DID documents do not introduce any vulnerabilities and do not share other relevant information. 6.1.2. DID operations Another information provided by the DID vulnerability analysis is the type of transactions executed by DID owner on the Ethereum Blockchain and the entity to which this transaction is intended. Figure 2a shows the top 10 most executed operations by DID owners. The approve operation is the most frequently performed across all DIDs, allowing the DID to manage tokens by granting permission for another entity (contract or individual) to transfer a specified amount of tokens on their behalf. The transfer operation represents asset movement and refers to the direct transfer of tokens or assets from a DID. The Swap Exact Tokens For Tokens and Swap Exact Tokens For ETH are used to manage liquidity by exchanging one type of token for another or for Ether. The Set Approval For All is used by a DID to authorize an operator to manage all of their assets while the Set Obo Approval For All operation is used to set approval for all actions on behalf of another party. Operations like Withdraw, Execute and Claim are less frequent for DIDs and they are used for the execution of transactions or functions in smart contracts, for claiming rewards, tokens, or assets that may have been locked or earned through a DeFi protocol. The mint operation involves creating new tokens or assets and it suggests that some DIDs have responsibility in token creation.
Figure 2b shows the 10 most frequent targets of the operations made by DIDs. In general, trading platforms and Exchangers (such as Uniswap) are the targets of the most part of the transaction performed by DIDs. The most frequent target of transactions is Router 2 smart contract, which is used to facilitate liquidity management within the Uniswap V2 protocol. Another traiding platform that is frequently used by DIDs is the EtherDelta platform. The MKT Token smart contract indicates a considerable amount of activity related to token or operations associated with the MakersPlace platform. Similarly, the BAE Token and the Wyvern Exchange are exchangers related to the blockchain crypto-art ecosystem and they refer to BlockchainArtExchange and OpenSea (two of the most important NFT marketplace platforms). Stablecoins (sush as USDT, USDC, and DAI) represent another main target for several DID owners, which use them as a liquidity, trading, and exchange medium. The Ethereum Name Service (ENS) is a distributed naming system which allows to map human-readable names to machine-readable identifiers to Ethereum entities (e.g., addresses or cryptocurrency). Finally, another important target for DID activities is the TRB Token smart contract provided by Tellor, which is focused on providing oracle-related token. The presence of OpenSea and TRB Token suggests that NFT marketplaces and oracle services are an important part of the observed transactions.
The graph-based analysis considers the graph of transactions performed by each DID towards other DIDs or Ethereum addresses and consists of 31714 nodes and 74654 edges. Table 2 shows the number of nodes, the number of edges, the density, the assortativity, and the clustering coeficient (Clust. Coef.) of each community. The metrics suggest that the graph is disassortative and sparse with moderate strong community structures, where most interactions occur within distinct groups, and a few highly connected nodes serve as hubs interacting with many smaller, less connected entities. In particular, the low density value means that the network is sparsely connected,and the low value of the clustering coeficient indicates that most DIDs interact individually with other entities without forming interconnected groups, while homogeneity indicates that most connections are internal to communities.
The most central DIDs in terms of degree, betweenness, and closeness centrality are also evaluated in the graph, showing the diferent roles in the Ethereum blockchain ecosystem. The most central DIDs belong to key participants or infrastructure entities enabling important functions, such as liquidity management, governance operations, token transfer, and asset control. Several of the top DIDs, particularly those with high closeness and betweenness centrality, are essential to the DeFi ecosystem, like Uniswap V2: Router 2, Circle: USDC Token, Maker: Dai Stablecoin and CH DAO: Deployer, which helps to manage governance tokens, liquidity, and the decision-making processes of DAOs. Instead, DIDs with high degree centrality demonstrate high engagement in NFT minting and token management, like MakersPlace: MKT Token, which is a significant actor in the NFT marketplace, and coopahtroopa.eth, that is another active participant in the DeFi and NFT space. 6.2.1. Communities Analysis The results of the community detection performed with the Louvain algorithm identified a total number of 30 communities (1, . . . , 30) in the graph. For each community, we computed the density, assortativity, and clustering coeficient to better understand the structural characteristics of each community. Table 3 summarizes the structure of the communities based on the evaluated metrics. The majority of communities (12, 15, 17, 19, 20, 23, 24, 25, 27, 28, 30) consist of few participants and interactions (at most 100 nodes and 100 edges), have sparse connections and hierarchical structure resulting from both a very low densitity value between 0 and 0.0073, a high nevative assortativity value between -1 and -0.7, and a zero cluestering coeficient. Some of these very small communities are centered around specific assets, such as the community 19 which is centered around the Falcon Project: Voucher and community 25, which is centered on the minting of NFTs and other digital assets. Communities 21, 26, 29, and 18 have a small number of participants and interactions (i.e., the number of nodes and edges of each community is included between 100 and 500) and expose a low value of density. In particular, the high negative value of assortativity and the zero clustering coeficient suggest that the communities 21, 26, and 29 are hierarchically structured. In contrast, community 18 exposes a negative value (between -0.7 and -0.3) of assortativity and a low cluestering coeficient (between 0.001 and 0.01).
Another large group of communities with significant participants and interactions are 2, 5, 6, 7, 8, 9, 14, and 16. The number of nodes in such communities ranges from 500 to 2000 while the number of edges ranges from 1000 to 5000. All these communities expose a very low value of density and a hierarchical structure, while only half of them (2, 8, 9, 14) expose a very low value of clustering (below 0.001) suggesting sparse local interconnectedness and rare formation of triangles. Most of these communities demonstrate centralized patterns, in which one or a few dominant DIDs are the central hub of most operations. In general, these DIDs execute central operations, such as transfer, approval, and governance actions, often against DeFi platforms, NFT markets, or other DApps. The communities 1, 4, 11, 13, and 22 consist of a large number of participants and interactions (the number of nodes is greater than 2000 and the number of nodes is greater than 5000). The low density value and the positive value of the clustering coeficient indicate the presence of some cohesive subgroups in each community. In particular, the cluestering coeficient of the community 22 ranges between 0.001 and 0.1, where a central DID exposes the role in governance management by performing the majority of transfers and confirm/exec transactions.
The analysis of structural metrics (such as centrality) combined with the underlying community structure, provides valuable insights into the behavioral patterns and functional roles of entities within the network. These metrics help uncover how entities interact, whether they act as central coordinators, peripheral participants, or bridges between subgroups, and it is particularly useful in contexts of de-anonymization.
In this paper, a framework for analyzing the anonymity of DIDs has been proposed. The approach focused on blockchain-based DIDs and leverages transaction data, DID document analysis, and graphbased analysis to reveal hidden correlations between user activities and personal attributes. The proposed framework was used to assess the anonymity properties of a DID implementation based on Ethereum, allowing to successfully derive information related to a real identities of 30 DIDs.
In several cases, DIDs are immediately de-anonymised through explicit information obtained from the blockchain or from external sources of information (e.g., block explorer platform). Collectively, these results illustrate that while SSI in Ethereum is designed to provide users with complete control over their identities, the transparency of blockchain transaction data, when combined with graph analytics and community detection methods, can reveal information of the entity behind a DID. As a direction for future research, it is essential to refine the proposed methodology by enhancing its analytical capabilities through the integration of AI approach for inferring information from DIDs and explore the application of a framework to cross-chain schenario where DIDs belong to diferent blockchains.
This work was partially supported by project SERICS (PE00000014) under the MUR National Recovery and Resilience Plan funded by the European Union - NextGenerationEU.