Double-Blind Proof of Existence for Decentralized Identities

Decentralized identities return control of identities to the identity owners. Although current work enhances the privacy of these publicly stored identities using encryption and zero-knowledge proofs, decentralized identities can still be abused due to the following problems: • identity holders, e.g., blockchain peers, can profile identity owners by looking at “who is reading which identity data”, and • identity verifiers, e.g., applications and websites, learn private data about owners, like their monetary values and previous transactions during the identity linking. In the worst case scenario, the identity holders and verifiers collaboratively profile users to learn more information. As a practical solution, we introduce the notion of Double Blind Proofs of Existence (DBPoE), which shows that an opened DID is committed in one of the constant-sized multi-generator Pedersen commitments (33 Bytes at 128-bit security), and nothing else. Hence, our DBPoE double-blinds identity holders and identity verifiers to mitigate private information leakage. Equally importantly, our multi-generator commitment-based DBPoE is more resistant to graph analysis than other one-of-many proofs, e.g., ring signatures, which we show mathematically using the maximal flow problem. Our DBPoE protocol has a size complexity of <inline-formula> <tex-math notation="LaTeX">$O(\log _{2}(N) + m)$ </tex-math></inline-formula> when the real commitment is hidden in <inline-formula> <tex-math notation="LaTeX">$N$ </tex-math></inline-formula> commitments and <inline-formula> <tex-math notation="LaTeX">$m$ </tex-math></inline-formula> generators are used, e.g., when <inline-formula> <tex-math notation="LaTeX">$m=4$ </tex-math></inline-formula>, a DBPoE of 1000 commitments is only 3 KB.


I. INTRODUCTION
Many privacy policies state that users' data will be shared with ''our affiliates and other trusted businesses or persons'' but do not explicitly state with whom.This simple statement takes away users' privacy entirely and creates a legal loophole in what data holders can do with their users' data.Unfortunately, these types of data sharing have become a common practice, not only in social media platforms but also in sensitive applications like banking and healthcare systems.
Many examples show that buyers can deanonymize them [1], [2] even though the aggregated or anonymous data were shared.It is noteworthy that these cases [1], [2] were only identified because the datasets were public.There is no way to verify whether so-called anonymization is sufficient or not when the data selling happens in private.
The associate editor coordinating the review of this manuscript and approving it for publication was Wei Huang .
Many privacy enthusiasts promote user-controlled data management as a countermeasure since users take action and try to protect their data without relying on central authorities.

Decentralized Identity Management (DIM):
The first step to the user-controlled data management is decentralized identity management [3], [4], [5], [6], [7], [8] where users control their identity information, and these identities are stored in decentralized storage rather than a centralized authority, e.g., blockchain network.A decentralized identity has an identifier called DID (Decentralized Identifier) and an identity document containing more details about the identity.We separate participants in DIM according to their roles.
• Identity Owner -The identity belongs to the owner.
An identity owner can be an individual, an organization, or even a physical object.
• Identity Vendor (Issuer) -While some DID details could be self-issued, other details may be issued by an external party, e.g., a social media platform that issues usernames or a vehicle department that issues licenses.Sometimes, a DID document can combine multiple attributes issued by different vendors.
• Identity Holder -The entity who holds identities and/or identities' proofs of existence, e.g., an identity registry or a blockchain network.
• Identity Verifier -The entity who verifies the following: (1) the existence (2) the ownership, e.g., a website that verifies identities for log-in.Traditional Decentralized Identity Management: In DIM, the protocol works as follows.First, identity owners • decide what to include in their DID document, • secure the DID documents, e.g., using encryption or zero-knowledge proofs for sensitive information, and • send the secured identity or its short proof to the holder.Since this immutable storage is expensive, owners may store short proofs of the secured identity like certificates, hashes, or commitments and keep the secured identity with them.Later, the owners can use these identities for other applications by simply showing the identity and its existence records on blockchains or registries to identity verifiers.Therefore, the identity owner can decide what information to reveal, to whom, and when.For example, as shown in Figure 1, Bob registers his DID in a commitment Com 2 .Later, he can use DID to create an account on a website.For that, Bob sends a proof of existence PoE along with Com 2 and DID.Then the website checks if 1) Com 2 is in the blockchain, 2) DID is in Com 2 via PoE (existence), and 3) Bob owns DID via PoE (ownership).Many DID proposals rely on blockchain networks as their identity holders due to their availability and trustless immutability.However, this transparency creates new ways to profile and gain private information about identity owners.In this paper, we address the following two privacy issues by introducing Double Blind Proof of Existence.1) Identity Holders like blockchain peers gain information from who reads which data.For example, when the website reads Bob's DID, the blockchain peer could derive that Bob is a user of the website (Figure 1).This unintended information gain is an issue for blockchains as well since many users do not maintain their blockchain copy but rely on resourceful peers [9], [10], [11] via application interfaces.Those peers gain a significant amount of private data about users and their activities.Similar to centralized identity holders, these user data are also shared with third parties, e.g., ''we process and collect may be transferred between companies, Services, and employees affiliated with us as a normal part of conducting business''.Even though these resourceful peers use anonymizing techniques, deanonymization could be possible [1], [2].2) Identity verifiers, e.g., websites, individuals' applications, or organizations' clients, learn more information about individuals and organizations when DID are directly published on the blockchain or linked to the blockchain, e.g., previous transactions, monetary values, or relations to others [12], [13], [14], [15], [16], [17], [18].From Figure 1, the website learns that Bob owns 200 coins.In short, encrypting data, zero-knowledge proofs, or private information retrieval cannot solve the above-mentioned privacy issues.Also, these two problems must be solved simultaneously since both roles (blockchain peer/database and identity verifier) may be played by the same entity or they share data.
More importantly, these solutions must be affordable and should not overload the database or the blockchain; otherwise, solutions become impractical due to the cost (storing data on blockchains is expensive), and may not be affordable to identity owners, eventually forcing them to use cheap yet no-privacy solutions which turn owners into their products.

A. OUR CONTRIBUTION
We propose the notion of Double Blind Proofs of Existence (DBPoE) to prove the existence of a hidden DID in hiding commitments without directly showing where it is to mitigate private information leakage.Our DBPoE implementation on SECP256k1 Elliptic Curve Library is public on https://github.com/DData-core/secp256k1-did.
More formally, our special DID commitments with Double Blind PoEs provide the following properties.
• Hiding Succinct Decentralized Identifiers: Our constant-sized commitments can hold many DIDs while hiding them with a secret key.More precisely, we use m-generator Pedersen commitments, e.g., when m = 3, ∈ G is a Pedersen commitment of two DID documents when the secret key k ∈ Z q , and g, h 1 , h 2 are nothing-up-my-sleeve generators of multiplicative group G of prime order q.Here, f () turns a DID document into an element of Z q .
• Double Blinding Proof of Existence (from the Zero-Knowledge Argument): DBPoE only shows that the disclosed DID document is committed in one of the given commitments without revealing in which commitment it is residing, which generator was used to commit, and other DID documents of the same commitment.Hence, DBPoEs mitigate the discovery of the corresponding commitment in the long term, even if verifiers share/sell DBPoE data with each other.We discuss the graph analysis and why our system is more resistant to them than other one-of-many proofs due to the multi-generator commitments in Section V.
Our DBPoE is built from modifying Groth-Kohlweiss Protocol [19] for multi-generator commitments.The asymptotic size complexity of our DBPoE is only O(log 2 (N ) + m) when N is the number of commitments and m is the number of generators.
• Unforgeable Ownership with PoE: A valid PoE can be only created if the creator knows the corresponding secret key of the commitment.Hence, PoEs cannot be forged even if the attacker knows all hidden DIDs.Thus, the applications can verify the authenticity of the owner by including a time-based or random challenge message, and the same DID can be used many times with fresh challenge messages.

B. PRACTICAL USE OF DBPoE
DIM has a wide range of architectures to fit into different applications.Here, we narrow them down to two types: identities for organizations and individuals.Organizations or public figures publish identities for their clients or audiences, while individuals only want to share their identities with necessary parties like websites or applications.Due to these different objectives, we propose two DBPoE-based DIM solutions and explain them with two case studies.As a solution to our third case study, we show how these two DBPoE-based DIM solutions can coexist to build a DIM suitable for many applications.[20], [21] was introduced to make identity management easy for users by allowing them to reuse an identity issued by a reputable vendor, e.g., reusing a social media profile or email.However, this simplicity comes at the cost of privacy since the vendor can trace user activities across multiple applications.
Why blockchain-based DIM?Many free account applications like shopping websites or social media require users to have some form of legitimacy, like an email address or a phone number, to prevent attackers from overloading the system with fake accounts.DIDs can replace these federated identities since blockchains add a monetary-based legitimacy to self-issued identities with immutability.Note that this kind of monetary legitimacy can only be bought with decentralized systems since if the user pays someone or some organization for identities, users' applications will contact the centralized entity, and all user activities are again visible to that centralized entity.Hence, blockchain-based DID is a better option to reduce the number of fake accounts while giving control to the identity owners, not to a centralized vendor as explained in [22], [23], and [24].
Issues with blockchain-based DIM.While this setup solves the centralized tracing, it creates the previously mentioned problems.
• Many users (e.g., mobile applications) do not keep their own blockchain copy but rely on resourceful peers via application interfaces.Hence, peers learn identity owners' activities when applications or DID verifiers request DIDs from those peers.
• A blockchain includes other data like monetary values or relations to other identities.The application or DID verifiers learn the user's data on the blockchain when a user shares DID directly.DBPoE-based Solution.We propose off-chain DBPoEbased DIM for individuals where multiple DIDs of the same identity owner are hidden in a multi-generator Pedersen commitment.Later, the identity owner can open one of the DIDs to an identity verifier by sending multiple commitments with an offline DBPoE to prove that the opened DID is in one of the commitments.We modify the previous example in Figure 1 with our DBPoE solution (see Figure 2).Here, Bob stores two DIDs with no linkable information in com 2 .Then, he sends DIDs and their double-blind DBPoEs with commitment sets, including com 2 , to websites to create accounts.Once the websites receive DBPoEs, they verify the existence and ownership using these shared commitment sets.However, unlike traditional DIM, they can not identify the exact commitment even if the websites share information.Thus, Bob can hide how many coins he has.Also, a website's blockchain peer(s) only sees that the website is reading multiple commitments and cannot exactly identify which commitment's owner is a user of that website. 1hese multi-generator Pedersen commitments are only 33 bytes, and our DBPoE has logarithmic size complexity.Hence, the identity owners can use large commitment sets at an affordable price to gain more privacy, e.g., storing a 33byte commitment only costs ≈ 0.01 USD in Ethereum, and an offline DBPoE of 1000 commitments is only 3 KB.
2) CASE STUDY: DBPoE-BASED DECENTRALIZED IDENTITY FOR SOFTWARE INTEGRITY Software companies issue certificates to prevent malicious changes to the software during communication.These certificates' signatures can be used as legal evidence against the company in case of malicious activity.
Why Blockchain-based DIM? Providing software integrity is one of the exhaustively discussed use cases of blockchains [25], [26].Once the company self-issues an identity or obtains an identity from traditional PKI (Public Key Infrastructure), they share the certificate on a public website or individually with clients.However, unlike traditional PKI, publishing their identities on immutable blockchains makes double identities visible to everyone.Hence, users can see if the company is trying to be malicious to a target, e.g., the company targets Alice with malicious software but shares proper software with others.Also, the company can identify if someone tries to pretend to be them with similar information.These features are difficult to achieve in traditional PKI but easy with blockchain-based PKI due to the immutability and transparency.
Issues with blockchain-based DIM.However, directly publishing certificates creates the following problem.
• Software buyers learn the company's previous transactions, monetary values, or relations to others through the blockchain history [12], [13], [14], [15], [16], [17], [18].DBPoE-based Solution.We propose a layer 3 decentralized registry DBPoE-based DIM where the blockchain(s) holds hiding commitments, but the registry dedicated to identities holds certificates through DBPoE.As a result, the certificates are public, but they are not linked to any blockchain account.For organizations, publishing DBPoE is more expensive than for individuals' offline communication; however, it also gives them visibility with more privacy and security.

3) CASE STUDY: DBPoE-BASED METAVERSE IDENTITIES TO SOLVE INTEROPERABILITY
Metaverses [27] interconnect many different Internet applications and websites.The biggest issue of metaverses is interoperability since it is not secure or private to share everything with a centralized vendor.Still, we want to connect all metaverse builders to give the best user experience.For example, users can build their own 3D homes and workplaces, shop at a digital shopping mall, and play video games using the same account.These applications, i.e., 3D homes, shopping websites, and video games, may be from different vendors, but the user's identity information, like the username and the avatar, has to be shared.
Why Blockchain-based DIM? Blockchains provide the transparency and immutability we need for self-issued identities with monetary-based legitimacy.Hence, Blockchainbased DIM can bring different entities together without a centralized authority.Many metaverse projects are currently building DIM solutions for identities and also for NFT (Non-Faungible Tokens) to connect with content creators (prefer [27], [28] for more details).
Issues with blockchain-based DIM.However, directly publishing identities creates the following privacy issues.
• Blockchain peers who sell APIs to applications or websites learn user activities by looking at who is reading which identities.
• Also, those applications and websites learn users' monetary values and previous activities on the blockchain when the user links the DID.DBPoE-based Solution.Metaverse identities can belong to individuals or organizations (or public figures).Individuals do not need publicity, while organizations must publish their identities.Hence, we propose a layer 3 decentralized registry where identities can be confidential or public.All public identities with DBPoEs are published on the layer 3 decentralized registry, and owners share confidential identities with a DBPoE directly with applications, as shown in Figure 3.

a: ROAD-MAP
We discuss preliminaries, including multi-generator commitments and argument of zero-knowledge, in Section II.DID documents, DID cores, and what to commit from DID documents are explained in Section III.Then, we show how to create a double-blind PoE for commitments without directly opening DIDs in Section IV.Why DBPoE is stronger than other one-of-many proofs against graph analysis is explained in Section V.Then, we evaluate the performance of DBPoE implementation in Section VI.Finally, we discuss DBPoE solutions, related work, and future work in Section VII.

II. PRELIMINARIES A. NOTATION
We use '':='' and ''=:'' for assigning, e.g., a := b means that a was assigned to b.For a cyclic group G = ⟨g⟩, g denotes a generator of G. Z q = Z/qZ is a ring of modular integers in the range [0, q − 1] for modulus q.Bold letters like a denote vectors of n elements such that a ) is a negligible function ∀c ∈ N. We use pp, λ, and A for public parameters, security level, and p.p.t.adversaries, respectively.
Definition 1 (Discrete Log Problem): For G = ⟨g⟩ of prime order q, Adv DL G for an adversary A is defined as, .

B. PEDERSEN COMMITMENTS
The original Pedersen commitments [29] and their security properties are explained here.Let COM be the Pedersen commitment scheme [29], defined as follows, • COM.set(λ) : return pp = (G, g, h, q) ▶ where G = ⟨g⟩ = ⟨h⟩ is a group of prime order q ∈ {0, 1} λ , and the discrete logarithms of g and h relative to each other are unknown -they are ''nothing-up-my-sleeve'' (NUMS) group generators.
COM have the following security properties.Here, we use V pp for the value space.

Definition 4 (Hiding and Binding): For any p.p.t. adversary A, COM is hiding and binding if,
We recollect the security theorem of [29] here.Theorem 1: 2-generator Pedersen commitments are complete, perfectly hiding, and computationally binding if the DL problem and DDH problems are hard.

C. MULTI-GENERATOR PEDERSEN COMMITMENTS
Instead of original Pedersen commitments, we use m-generator commitments where m could be larger than 2. When m = 2, this protocol is equivalent to the original Pedersen commitments.This m contributes to the privacy against graph analysis in our DBPoEs.Hence, how to select m and its impact will be explained in Section V. Let COM be a m-generator Pedersen commitment scheme.
Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.
Theorem 2: Multi-generator Pedersen commitments are complete, perfectly hiding, and computationally binding of the DL and DDH problems are hard for each generator.

D. ZERO-KNOWLEDGE ARGUMENT
Our DBPoEs are arguments of zero-knowledge.An argument of zero-knowledge can cryptographically prove some statement without revealing any other information.In our case, the statement proves that an identity exists in the given commitments without revealing other identities, the index of the commitment, the index of the generator, etc.In general, the interactive version of our protocol contains three algorithms: the setup set which produces a Common Reference String (CRS) pp, the interactive prover P, and the interactive verifier V.Each interaction between P and V of inputs s and t is denoted as tr = ⟨P(s), V(t)⟩, which can be 1 if V accepts; otherwise, 0. We call a relation R is a polynomial-time-decidable ternary relation of pp ∈ {0, 1} * , a witness w ∈ {0, 1} * of a statement u ∈ {0, 1} * such that (pp, u, w) ∈ R. From this, we can define a CRS-dependent language L = {x|∃w : (pp, x, w) ∈ R} to be the set of statements that have a witness in R. We formally define the Argument of Knowledge below.
for an Oracle O = ⟨P ′ (pp, u, s), V(pp, u)⟩, and allows to rewind the protocol to any point and continue with new random coin tosses for the verifier.
Definition 10 (n-Special Soundness): Let there be an efficient extraction algorithm X that can compute the witness from n ''valid'' transcripts, [(x i , s i )] n i=1 such that ∀x i ̸ = x j when i ̸ = j with the same initial message a of the prover.Then (set, P, V) is n-special sound if X outputs a valid witness for R such that Adv KS DK,A is, Pr (pp, u, w) when pp := set(1 λ ) and for any p.p.t.adversary A. This special-soundness guarantees that a transcript can be only created by a prover who knows the witness.
In this paper, we are more interested in non-interactive protocols where only the last transcript is exchanged between the prover and the verifier.To simulate them cryptographically, we turn into the public coin argument of special honest verifiers where all messages from verifiers are chosen from a public uniformly random tape independently from the prover's messages.In other words, there is a simulator that can simulate the whole argument if the verifier knows random challenges in advance.We define the public coin zero-knowledge argument below.
for non-uniform p.p.t.adversaries A 1 and A 2 .
In real-life, applications are secured from these arbitrary verifiers in the CRS model using standard techniques like [30] with a small overhead.

E. GROTH-KOHLWEISS PROTOCOL
Our DBPoE protocol is an improvement of Groth-Kohlweiss proofs [19] that allows proving that one-out-of-many commitments have a value of ''0'' with a logarithmic sized complexity, i.e., the communication cost is O(log N ) when there are N commitments.We explain the interactive Groth-Kohlweiss protocol in Figure 4. Let δ i,j be 1 if i = j; otherwise, 0. Also, i l presents the lth bit of i < 2 n such that i 0 is the least significant bit of i.Let n be ⌈log 2 (N )⌉.For any j ∈ [0, N − 1] and [a l ] n l=0 , we can precompute the following polynomial coefficients The core of the protocol is that polynomials' X n coefficient will be non-zero if and only if i = j.Using this, Groth-Kohlweiss protocol proves that there is a ''0'' value commitment without revealing its index j.DBPoE should be unmalleable, i.e., they have the quasi-unique response property, that is, given an accepting proof, an adversary cannot find a new valid response for the same initial message a and challenge x as follows.
Definition 12: (Quasi-Unique Response) The protocol of (set, P, V) has quasi unique responses if for any p.p.t.
Theorem 4: Non-interactive Groth-Kohlweiss protocol that replaces verifier's challenges with random-oracle challenges is complete, has quasi unique responses, and provides public coin zero-knowledge argument.

III. DID CORES AND INTERNET PERSONAS
This section explains what to include in a DID commitment and why an identity owner may need to maintain separate DID documents.
First, we have to identify what should be embedded in commitments.A decentralized identity is associated with a DID document, e.g., the following is an example of W3C DID standardization version 1 [31].
{ " @ c o n t e x t " : [ ' ' h t t p s : / / www.w3 .o r g / n s / d i d / v1 ' ' , \ l d o t s ] ' ' i d " : " d i d : e x a m p l e : 1 2 3 4 5 6 7 8 9 a b c d e f g h i ' ' , " v e r i f i c a t i o n M e t h o d " : [ { " i d " : " d i d : e x a m p l e : 1 2 3 # _Qq0UL2Fq651Q0Fj \ l d o t s " , ' ' t y p e " : " JsonWebKey2020 ' ' , ' ' c o n t r o l l e r " : " d i d : e x a m p l e : 1 2 3 ' ' , " p u b l i c K e y J w k " : { ' ' c r v " : " Ed25519 ' ' , " x " : " VCpo2LMLhn6iWku8MKvSLg \ l d o t s " , ' ' k t y " : "OKP' ' , " k i d " : " _Qq0UL2Fq651Q0Fjd6TvnY \ l d o t s " } } , { ' ' i d " : " d i d : e x a m p l e : 1 2 3 4 5 6 7 8 9 a b c d e f g h i # keys −1 ' ' , ' ' t y p e " : " E d 2 5 5 1 9 V e r i f i c a t i o n K e y 2 0 2 0 ' ' , " c o n t r o l l e r " : " d i d : e x a m p l e : p q r s t u v w x y z \ l d o t s " , " p u b l i c K e y M u l t i b a s e " : " \ l d o t s " } ] , } Each DID document contains a Decentralized Identifier (DID), a cryptographically generated self-issued identifier that does not require centralized authority.For example, did:example:123456789abcdefghi and did:web:example.comare two DIDs that use a static identifier and a website name for unique identification, respectively.
In general, DID documents contain essential data like associated public keys, personal claims, and assertions of verifiable credentials.However, not all data are required to commit to the commitment.For example, some personal claims may not be required for all identity verifiers.Still, if we directly commit the entire DID document, it must be presented when we open the commitment.Also, knowing some associated public keys, but not all, may be sufficient to authenticate the users and their verifiable claims through a time-stamped signature.Hence, the DID document's data required for a particular identity verifier is called DIDcore, e.g., the previous DID document could also be the DID core of did:example:123456789abcdefghi#keys-1 for a website.Therefore, we commit hashes of DID cores in Pedersen commitments, which we call DID commitments.Since we use m-generator Pedersen commitments, a single DID commitment can hold at most (m − 1) DID cores.
132186 VOLUME 11, 2023 Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.

A. INTERNET PERSONAS AND ANONYMITY
A DID document holds personal information about a person, especially with verifiable credentials.For example, the following is a verifiable credential (verifiable university certificate) issued for did:example:123456789abcdefghi.
{ " @ c o n t e x t " : [ ' ' h t t p s : / / www.w3 .o r g / 2 0 1 8 / c r e d e n t i a l s / v1 ' ' , \ l d o t s ] , ' ' i d " : " h t t p : / / u n i .edu / c r e d e n t i a l s / 3 7 3 2 ' ' , " t y p e " : [ ' ' V e r i f i a b l e C r e d e n t i a l ' ' , ' ' U n i v e r s i t y D e g r e e C r e d e n t i a l ' ' ] , ' ' i s s u e r " : " h t t p s : / / u n i .edu / i s s u e r s / ' ' , ' ' i s s u a n c e D a t e " : "2010−01−01T19 : 2 3 : 2 4 Z ' ' , " c r e d e n t i a l S u b j e c t " : { ' ' i d " : " d i d : e x a m p l e : 1 2 3 4 5 6 7 8 9 a b c d e f g h i ' ' , " d e g r e e " : { ' ' t y p e " : " B a c h e l o r D e g r e e ' ' , ' ' name " : " B a c h e l o r _ o f _ S c i e n c e _ a n d _ A r t s ' ' } } , " p r o o f " : { ' ' t y p e " : " E d 2 5 5 1 9 S i g n a t u r e 2 0 2 0 ' ' , ' ' c r e a t e d " : "2022−02−25T14 : 5 8 : 4 3 Z ' ' , ' ' v e r i f i c a t i o n M e t h o d " : " h t t p s : / / u n i .edu / i s s u e r s / # key −1 ' ' , ' ' p r o o f P u r p o s e " : " a s s e r t i o n M e t h o d ' ' , " p r o o f V a l u e " : " \ l d o t s " } } While these types of verifiable credentials may link digital identities to the real world, many DIDs may represent an online persona without any links to the physical world.In fact, due to the excessive information selling between applications, one may use multiple internet personas to create boundaries and limit tracing.For example, an individual may use different internet personas for work, personal browsing, or different social media platforms.Hence, it is common to have multiple DID documents with different DID identifiers with no unique identifiers.
Recall that multi-generator DID commitments with DBPoE give the same privacy as a commitment of a single DID core.In other words, a verifier cannot link two DID cores together even if they are committed in the same DID commitment if there are no unique identifiers between DID cores.Hence, this property is cost-effective for identity owners and promotes privacy-enhancing techniques for individuals rather than cheap yet no-privacy solutions.

IV. DOUBLE BLIND PROOFS OF EXISTENCE
In this section, we explain how to commit DID cores in a way that one DID core can be opened without revealing anything other than the statement, ''the opened DID core is committed in the commitments'', which hides the secret key, other DID cores of the owner's commitment, the index of the particular DID commitment, or even the index of the DID core.We call this zero-knowledge opening, Double Blind Proofs of Existence (DBPoE) of a decentralized identity.
The protocol works as follows (see Figure 5).First, the identity owner publishes the DID commitment, e.g., as a blockchain transaction or registers the commitment in the DID registry.When the identity owner decides to use one of the DID cores in the commitment, he/she sends the commitment to the identity verifier V, mixed with other commitments.Then, V sends a challenge message w to the identity owner.After that, the owner sends a DBPoE of DID core DC to V, which V verifies against the challenge message w.This challenge may contain application names or timestamps to recognize the identity owner and prevent reusing the DBPoE of other applications or old DBPoEs (see Figure 5).
The owner does not need the openings of other commitments to create a DBPoE; hence, the real DID commitment can be hidden in others' DID commitments.In that way, 1) commitment holders, i.e., blockchain peers and database owners, can not directly identify identity owners' applications or services, and 2) identity verifiers, i.e., applications or services, are unable to trace identity owners' activities on the blockchain.Note: These types of one-out-of-many proofs are susceptible to graph analysis in the long run, especially when many DIDs use the same applications or the applications exchange/sell DBPoE data with each other.In the next section, we explain how our DBPoE counter-protects against graph analysis for long-term use with m-generator Pedersen commitments even when identity verifiers collaboratively try to discover the real DID commitment.
Let DBPoE be the DBPoE protocol.
• DBPoE.prove(pp, or not.The DBPoE protocol between the prover P (identity owner) and the verifier V is explain in Figure 5.
Expected Security Properties: We expect DBPoE to be complete, Existentially Unforgeable against Chosen Challenges (EUF), and to have the argument of zero-knowledge.
Definition 13 (Completeness): DBPoE is complete for some N ∈ N and m ∈ N if, equation ( 2) as shown at the bottom of the next page.
We expect PoEs to be unforgeable such that even though the adversary knows the DID core, they should not be able to forge another proof for a fresh challenge.We focus on the strong unforgeability where the adversary can request many challenges for the same DID commitment set from the Oracle .The adversary's goal is to generate a fresh pair of proof and a challenge that the oracle has not returned.Otherwise, PoE is unforgeable, or applications can check the existence of DID cores soundly with fresh challenges.The complete definition is stated below.[Hash(DC

Definition 14 (Existential Unforgeability Against Chosen Challenge Attacks (EUF) :) DBPoE is unforgeable against chosen challenges if Adv
We expect the argument of zero-knowledge in Definition 7 to achieve ''double blind'' property for our DBPoE such that the statement only says that ''the opened DID core is committed in one of the given commitments''.Hence, the adversary can not figure out the real commitment and the generator more than the probability of 1/N and 1/(m − 1), respectively, when the DID commitment set size is N , and m generators are used.

A. OUR PROPOSAL
Our PoE proposal allows to commit multiple DID cores within the same DID commitment and only reveals the following zero-knowledge argument, ''The opened DID core exists in the DID commitment set, and nothing else''.Our interactive protocol is stated in Figure 6, and the non-interactive protocol used for GitHub Implementation is stated below. 11: J l = COM.cmt(jl , r l )

22:
A l = COM.cmt(al , s l ) 23: 31: ▶ Verify a proof for the DID core DC 32: DBPoE.verify(pp,w, c, d)∈Z q 43: Return 1 if the followings are equal, otherwise, return 0. 44: For l = [0, n) : 132188 VOLUME 11, 2023 Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.

SECURITY PROOFS
Theorem 5: The interactive DBPoE protocol is complete and provides the argument of knowledge, including special soundness and computational witness-extended emulation.
Theorem 6: The non-interactive DBPoE protocol is complete, Existential Unforgeable against Chosen Challenge Attacks (EUF), and provides the public coin argument of knowledge of special honest verifiers, including special soundness and computational witness-extended emulation.

1) COMPLETENESS
Here, we show that the arrange commitment set includes a zero value commitment in the (j N * m + j m )th index.

Lemma 1: DBPoE has public coin argument of knowledge when solving DDH problem is intractable, and Groth-Kohlweiss protocol has public coin argument of knowledge (see Appendix A).
Lemma 2: Let Oracle be separated into three oracles Y for computing Y t values, H 0 for x 0 values, and G for Groth-Kohlweiss protocol.Assume that a p.p.t.adversary makes q y queries to Y, q g queries to G, q x 0 queries to the random oracle H 0 .The adversary's advantage is at most + O q y q + q y (q y + q x 0 ) q 2

C. BEST PRACTICE 3: LARGE M AND N AGAINST GRAPH ANALYSIS
We can mitigate graph analysis by increasing the m and N altogether, i.e., the number of possible DID cores in a N commitments is N × (m − 1).Also, as we saw in the graph analysis example, the edge between the drain to each commitment increases to (m − 1).Hence, increasing m and N mitigates these graph analyses.In other words, verifiers need more information and more processing time for these attacks [37], [38], [39], [40], [41].Since the size complexity of our DBPoE is O(log 2 N + m), computing DBPoE for large N and m is efficient and private.
In the next section, we show how DBPoE size, generation time, and verification time change with N and m.

VI. PERFORMANCE EVALUATION
We implement the DBPoE protocol using SECP256k1 Elliptic Curve Library (public on https://github.com/DDatacore/secp256k1-did).This section evaluates DBPoE sizes, generation times, and verification times for different N and m values.Note that all are measured on i7-1065G7 CPU at 1.30GHz as single thread programs.Our DBPoE's asymptotic time complexity is O(Nm) for DBPoE generation and verification.Figure 9

VII. DISCUSSION AND RELATED WORK
The need for decentralized identities or user-controlled identities [6], [44], [45], [46] became essential with misuses of identities like selling them to third-parties and the incidents of de-anonymization of anonymous data set [1], [2].As it appears, the first problem of decentralized identity management is standardization.The World Wide Web Consortium (W3C), with the collaboration of an international community group, released the first version of DID v.1 [31].The released draft contains methods of primitive identity management and the standards for advanced features like selective disclosable identities based on BBS+ signatures [47].In selective disclosable identities [48], the users can decide what to disclose from a DID Document and to whom; hence, disclosed data and their proofs can be seen as an advanced form of DID cores.Therefore, identity owners can use DBPoE for selective disclosable identities by updating DID cores with relevant proofs, which gives more privacy with double-blinding.
Note: There are many advanced zero-knowledge protocols [43], [49] that are not standardized by [31] but can be used to improve the privacy of decentralized identities other than the protocols based on BBS+ signatures [47].DBPoE is also generally compatible with those protocols since the DID core can be modified according to their proofs.Blockchain-based decentralized identity platforms like [10], [50], [51], [52], [53], [54], [55], [56], [57], [58], and [59] were introduced to bring decentralization and immutability of blockchains to identity management.While some of them rely on Public blockchains like Ethereum [60], others build special identity blockchains like Hyperledger Indy [50].However, they still need to address the privacy issues we address in this paper, that is, how to protect privacy from identity holders and identity verifiers, especially when they collaborate to profile users.Hence, these current implementations can benefit from our efficient DBPoEs to improve user privacy at a little cost.In Table 6, we state current DIM solutions and whether they are compatible with DBPoE or not.Here, ''✓ * '' means that the native blockchain is only suitable for storing multi-generator commitments due to the cost of storing data, and the DBPoE should be shared offline.For example, according to the current prices, storing a 33-byte commitment roughly costs 0.01 USD on Ethereum.Hence, we believe that the affordability of our DBPoE solutions can improve Decentralized Identity Management for day-to-day use.
One-of-many proofs like ring signatures [37], [38], [39], [40], [41] or confidential digital asset protocols [42], [43] are common protocols that provide double-blinding properties for different applications, e.g., [61] and [62].In general, they are allowed to hide something within a set.However, unlike these protocols, the DBPoE protocol is built to resist the graph analysis of malicious collaborating verifiers who share data, similar to what happens to decentralized identities.DBPoE protocol overcomes these attacks by using multi-generator commitments, as explained in Section V. We state the related work of DBPoE protocols and their complexities in Table 7.As shown in the table, the DBPoE protocol can commit many DIDs in a single commitment yet be more resistant to graph analysis than any other one-of-many proofs.Our DBPoE-based DID solutions are more affordable and private for regular use.

VIII. CONCLUSION
This work proposes the notion of Double Blind Proofs of Existence (DBPoE) for decentralized identity solutions to improve the privacy of decentralized identities against identity holders and identity verifiers since blockchain peers or applications that share data with others can profile users, learn private information, and deanonymize the pseudonyms of blockchain users.Due to the complexity of logarithmic size, current decentralized identity solution platforms can benefit from this double-blind PoE protocol to give their users more affordable privacy.Our main objective is to improve decentralized identities for regular use.Technical improvements like DBPoE with logarithmic size complexity can motivate researchers and application developers to use Decentralized Identity solutions for regular use, e.g., to replace federated identities or use as interoperable metaverse identities that connect identity holders in a trustless manner.

APPENDIX A PROOFS OF PUBLIC COIN ARGUMENT OF KNOWLEDGE
We prove Lemma 1 in this section.We separate our DBPoE protocol into two sections: arranging the new commitment set and using Groth-Kohlweiss protocol that shows that there is a ''0'' value commitment.Since we have proven the completeness in Section IV, we directly move to the soundness of DBPoE.Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.first section, let the initial message be a = ([DC] m−1 t=0 , ) and the adversary has access to • (x 0 , [e t ] m−1 t=0 ) and (x ′ 0 , [e t ] m−1 t=0 ) such that e t = x 0 Hash(DC t )+y t and e ′ t = x ′ 0 Hash(DC t ) + y t .The adversary can compute the simulated hashes of DID cores since for each t, d t ← (e t − e ′ t )/(x 0 − x ′ 0 ) ∈ Z q or the adversary has to break DL problem of the generators to find another d t set that returns Y t .
For the second section, we refer to [19] (pages 9-10), which shows that (n + 1) queries are sufficient to extract a valid witness.Altogether, we claim DBPoE provides (n + 2)-Special Soundness from Definition 10.

B. SPECIAL HONEST VERIFIER ZERO-KNOWLEDGE
We start with the first section where the adversary gets challenge x 0 in advance for known (  ) and saves them in ), π).In other words, for each query, Oracle runs calls Y, H 0 , and G once.
Let there be a p.p.t.adversary who makes q y number of queries to Oracle Y, q g number of queries to Oracle G, and q x 0 queries to the random oracle H 0 .

A. CASE 1
In the initial case, A makes at most q y queries to Y.The game terminates with 1 if output [Y t ] m−1 t=0 was queried for a different input previously such that [y t ] m−1 t=0 ̸ = [y ′ t ] m−1 t=0 and Here, the probability of A winning the game is Pr 1 ≤ q y /q since A can be simulated to solve DL problem between the generators.

B. CASE 2
In this case, we assume that A makes at most q x 0 queries to H 0 with inputs it received from Y.The game returns 1 if output x ′ 0 = x 0 was queried previously for a different input or Y terminates with 1.At this stage, each input is no longer uniformly random because A can modify inputs.However, there will be at least one almost uniformly random string in [C i ] N i=0 , [Y t ] m−1 t=0 due to DDH problem.The probability of A winning the game is Pr 2 ≤ Adv DDH G,A + q y (q y + q x 0 )/q 2 .

C. CASE 3
Now, we let the adversary to make q q queries to G.Each of these queries triggers a query to Y and H 0 .The game returns 1 if the output was queried for different inputs or any of the oracles returns 1.The probability of G terminating is Pr 3 ≤ Adv  Hence, we see that Adv EUF DBPoE ≤ Adv quasi−u DK,A + Adv DDH G,A + O(q y /q + q y (q y + q x 0 )/q 2 ), and conclude that Lemma 2 is valid.

FIGURE 1 .
FIGURE 1.An example of traditional DIM.

FIGURE 2 .
FIGURE 2.Cost-effective and double-blind Decentralized Identities from multi-generator commitments.Here, DID 1 and DID 2 cannot be linked together or to the commitment com 2 when they do not have any linkable information even if Website 1 and Website 2 collaborate with each other.

FIGURE 3 .
FIGURE 3. Solving interoperability of metaverses when public DIDs and confidential DIDs coexist.
Definition 11 (Public Coin Argument of Zero-Knowledge): Public coin argument of zero-knowledge of (set, P, V) is a special honest verifier zero-knowledge argument if there exists a p.p.t.simulator S such that Pr

FIGURE 5 .
FIGURE 5. Double blind proof of existence protocol.

1 :
▶ Creates a PoE for the j m th DID core of C j N = COM.cmt(pp,k, [DC t ] m−1 t=1 ) when the verifier's challenge is w and DID commitment set is [

FIGURE 6 .
FIGURE 6. Interactive protocol of double blind proofs of existence.
and Figure 10 show DBPoE generation time and verification times for different N and m values, respectively.The asymptotic size complexity is O(log 2 (N ) + m), and the sizes are shown in Figure 11 for different N and m values.Due to these short sizes, e.g., a DBPoE of 1024 commitments (m = 4) is only 3KB, DBPoE can be efficiently transferred to verifiers.

FIGURE
FIGURE Generation time vs. N and m.

FIGURE 10 .
FIGURE 10.Verification time vs. N and m.
A. (N + 2)-SPECIAL SOUNDNESSFor the first section, witness is the simulated [y t , d t = Hash(DC t )] m−1 t=0 .To prove the special soundness of the 132192VOLUME 11, 2023

FIGURE 12 .
FIGURE 12. Graph analysis of other One-of-Many proof data from maximal-flow problem.

FIGURE 13 .
FIGURE 13.Graph analysis of our DBPoE data from maximal-flow problem.
Let A 1 and A 2 be interactive non-uniform p.p.t.adversaries.The protocol (set, P, V) has computational witness-extended emulation if there is an p.p.t.emulator E for all deterministic polynomial time prover P ′ such that the following holds Definition 7 (Argument of Knowledge): A protocol (set, P, V) is called argument of knowledge for relation R if it is complete (Definition 8), sound (Definition 10), and has computational witness-extended emulation (Definition 9).Definition 8 (Completeness): (set, P, V) is complete if Pr (pp, u, w) ∈ R∨ ⟨P(pp, u, w), V(pp, u)⟩ ?=1 (u, w)←A(pp) = 1 when pp := set(1 λ ) and for any p.p.t.adversary A. Definition 9 (Computational Witness-Extended Emulation):
[19][C i ] N i=1).The adversary first picks j m Now, the adversary has witnesses([DC t ] m−1 t=1)) for the first section of the protocol.Hence, the adversary can move to proof of Groth-Kohlweiss protocol (see page 10 in[19]) for the new commitment set[C ′ l ]Therefore, we can claim DBPoE protocol has Special Honest Verifier Zero-Knowledge (from Definition 11).Finally, we claim that Lemma 1 is correct due to DBPoE being complete, (2(m − 1) + (n + 1))−special sound, and special honest verifier zero-Knowledge.