Towards an identity management solution on Arweave

Andreea Elena Dragnoiu; Ruxandra F. Olimid

REVIEW 4 major objections 5 minor 74 references

Towards an identity management solution on Arweave

T0 review · 4 major / 5 minor · reviewed 2026-08-11 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read The paper proposes the first identity-management system built on Arweave, using DIDs, verifiable credentials, and BBS(+) proofs for selective disclosure.

desk verdict A clear Arweave SSI design proposal that overclaims novelty and GDPR compliance; useful as a tutorial, not as a verified system. read the letter →

arxiv 2412.13865 v3 pith:QBHPBUUG submitted 2024-12-18 cs.CR cs.ET

Andreea Elena Dragnoiu , Ruxandra F. Olimid This is my paper · ORCID

classification cs.CRcs.ET

keywords Arweaveidentitymanagementself-sovereigndecentralizedidentifiersverifiablecredentialsBBS+signaturesselectivedisclosureGDPR

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper argues that Arweave's permanent storage can host a self-sovereign identity management solution. It proposes storing DID documents on Arweave, resolving them through ArNS, issuing verifiable credentials with BBS(+) signatures, and using BBS(+) zero-knowledge proofs for selective disclosure. The authors claim to be the first to investigate identity management on Arweave and present sample JavaScript code for setup, credential issuance, and verification. They further argue that the design supports GDPR compliance by keeping sensitive data out of DID documents, and that the security of the solution reduces to the security of BBS(+).

What carries the argument

The load-bearing mechanism is the BBS(+) signature scheme combined with Arweave's permanent storage. BBS(+) signs multiple identity claims into a single credential, and its zero-knowledge proofs let a holder disclose a chosen subset while proving that the disclosed values were part of the originally signed set. Arweave stores the DID document permanently, and ArNS resolves human-readable names to the transaction ID, so a verifier can retrieve the public key and check a proof without a central registry.

What would settle it

A concrete test would be to store a DID document containing a public key linked to a named natural person, then invoke the GDPR right to erasure by attempting to delete or update that transaction; if the original bytes remain retrievable on Arweave, the proposed architecture has no erasure mechanism, which would falsify the GDPR-by-design claim as stated.

Watch

Extended reading notes

Core claim

The central claim is that Arweave's permanent, immutable storage can serve as the resolution layer for a self-sovereign identity system. Concretely, each entity stores a DID document containing only public keys and service endpoints as an Arweave transaction, maps an ArNS name to that transaction ID, and receives verifiable credentials signed by a trusted issuer using BBS(+). A holder later presents an ArNS name and a BBS(+) zero-knowledge proof that reveals only the claims needed for a given interaction. Because DID documents contain no sensitive data and BBS(+) hides undisclosed claims, the paper concludes that data protection is achieved by construction and that the scheme's security reduces to the security of BBS(+), assuming a trusted issuer and secure channels.

Load-bearing premise

The load-bearing assumption is that storing identity data on Arweave's permanent, immutable ledger can still satisfy GDPR's data minimization, rectification, and erasure requirements, even though the regulation grants individuals the right to have personal data deleted.

Editorial extensions

If this is right

If the proposal holds, identity verification can run without a central identity provider: issuers certify claims, holders store credentials locally, and verifiers check proofs against DID documents fetched from Arweave.
Selective disclosure becomes a property of the credential itself, because BBS(+) proofs reveal only the chosen claims and hide all others.
The claim that security reduces to BBS(+) means that breaking the scheme requires breaking the underlying signing assumptions, assuming a trusted issuer and secure issuance channels.
Unlinkability is not automatic: the public key in the DID document can be used to track a user, so the design leaves a privacy-versus-efficiency trade-off for key refreshment.
The two minimal-disclosure variants show that finer-grained privacy is possible, but only at the cost of issuer-side flexibility or a full zk-SNARK setup.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

Editorial inference: the permanence that makes Arweave attractive for identity records is in direct tension with GDPR erasure; a workable solution would likely need off-ledger pointers, time-limited DID documents, or a legal deletion layer that the paper does not specify.
Editorial inference: per-verification key refresh, suggested to restore unlinkability, would multiply Arweave transactions and re-issuance events, so a cost model based on bundling and storage fees could determine whether the design is practical.
Editorial inference: the paper's second minimal-disclosure variant replaces BBS(+) with a general zk-SNARK, adding a trusted setup and a new proof system to the trusted base; one could test this variant on Arweave's smart-contract execution layers and compare proof-generation costs.
Editorial inference: a natural next step is to benchmark the proposed flow against the other Arweave-based naming and identity protocols the paper cites, since those are the closest competitors rather than the non-Arweave solutions used for comparison.

Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

Best read as a tutorial-style design proposal, not as a verified identity system. The paper walks through Arweave's ecosystem clearly and shows how W3C DIDs/VCs, BBS(+) selective disclosure, and ArNS can be assembled into an SSI framework, with sample JavaScript. As an introduction to Arweave for identity researchers, it is genuinely useful.

The problems are in the claims attached to that assembly. The "first IdM on Arweave" novelty does not survive contact with the paper's own §2, which describes Ark Protocol as a decentralized IdM framework on Arweave and Namespace.gg as a naming service designed to combine with it. That is an IdM solution on Arweave, even if the authors didn't build it. Second, the GDPR-by-design claim is unsupported and internally contradicted in §6.1: the paper says DID documents on Arweave "cannot be altered or deleted," then in the same section says users can ask for corrections and deletion through a trusted authority, and that this complies with EU regulations. No mechanism for erasure or irreversible invalidation is given, and the paper itself admits the DID public key uniquely identifies the user and permits tracking. The claim that DID documents contain no sensitive data doesn't help; non-sensitive but identifying data is still personal data under GDPR. This is load-bearing, not cosmetic, because GDPR compliance is part of the central contribution.

The security claim is also overstated: "reduces to the security of BBS(+)" skips the DID document storage, ArNS resolution, key management, and the admitted linkability problem. The sample code is illustrative, and the paper itself says a full implementation is future work. That is all acceptable for a position paper, but not for a paper claiming a working, compliant solution.

Who is this for? Anyone wanting a concise overview of Arweave and a concrete SSI design pattern to critique. It would make a good reading-group discussion piece on blockchain immutability vs GDPR. It deserves a serious referee, but only with honest scoping: drop or soften the "first" claim, either give a concrete erasure/invalidation strategy or revise the GDPR claim, and label it a position paper rather than a complete solution. The architecture is reasonable and the writing is clear, so the raw material is there; the claims just need to match what is actually delivered.

Referee Report

4 major / 5 minor

Summary. The paper proposes a Self-Sovereign Identity (SSI) framework on the Arweave permanent-storage network, combining W3C Decentralized Identifiers (DIDs), Verifiable Credentials (VCs), the Arweave Name System (ArNS), and BBS(+) signatures to enable selective disclosure. It gives a phase-wise design (DID creation, VC issuance, identity verification) with illustrative JavaScript, discusses two minimal-disclosure variants using zk-proofs, and compares the proposal with Sovrin, Veramo, Civic, ION, and SelfKey. The paper claims to be the first IdM solution on Arweave and asserts both GDPR compliance by design and that the security of the proposal reduces to the security of BBS(+).

Significance. If the design were rigorously supported, this would be a useful early contribution to identity management on decentralized permanent storage, and the tutorial material on Arweave is informative. The paper is transparent about many design choices (e.g., the trade-off between unlinkability and efficiency, the minimal-disclosure variants, the reliance on trusted issuers). However, the central regulatory claim, GDPR compliance by design, is not established and is in tension with the paper's own description of Arweave immutability; the security reduction to BBS(+) is asserted without proof; and the novelty claim is questioned by the paper's own related-work discussion. These issues affect the paper's core contributions and need to be resolved.

major comments (4)

[§6.1, 'Self-sovereignty' paragraph; §4.5] The claim that the proposal achieves 'compliance with the GDPR by design' is not supported and is internally inconsistent. Section 6.1 states that 'the DID documents persist and cannot be altered or deleted,' and Section 4.5 says data on the Permaweb 'cannot be deleted or modified,' yet the same subsection claims that users can ask for corrections and deletion of their identities and that 'data update and identity removal are performed by a trusted, certified authority. This complies with EU regulations.' No mechanism is described that would allow a certified authority to alter or erase a DID document once written to Arweave; removing an ArNS pointer or rotating keys would leave the original transaction and the public-key-to-user association permanently retrievable. Since Section 6.1 also concedes that 'the public key maintained in the DID uniquely identifies the user and permits tracking of his/her actions,' the DID document contains personal data under the GDPR, and GDPR Articles 16 and 17 require rectification and erasure that the described architecture cannot provide. The footnote that 'the DID document contains no sensitive data' does not resolve the issue, because non-sensitive but identifying data still falls within the scope of the GDPR.
[§6.1, 'Privacy and security' paragraph; §6.5] The statement that 'the data security in our proposal, as described in Subsection 5.4, reduces to the security of the BBS(+) scheme' is an unproven assertion. The construction includes components outside BBS(+): Arweave storage and ArNS resolution, DID document creation and public-key management, VC issuance with JWT-based signing and secure transmission, key management via ArConnect/ArDrive, and, for Variant 2, an additional zk-SNARK with a fresh proving/verification key pair. No adversary model, security game, or reduction argument is given for the full protocol; the phrase 'holds directly from the construction' does not constitute a proof. This is especially problematic because Section 6.5 defers 'a more in-depth analysis of the security and privacy of such a solution' to future work. Either provide a formal security statement and proof sketch for the whole design, or revise the claim to describe the precise trust assumptions for each component.
[§2 and §6.4] The novelty claim, stated in the Introduction as 'we are the first to look into IdM solutions on Arweave' and echoed in Section 6.4 as 'We did not identify any other IdM solution built on Arweave except our current proposal,' is in tension with the paper's own description of the Ark Protocol in Section 2 as 'a decentralized IdM framework, designed to facilitate the creation, management, and verification of digital identities, which integrates with the broader blockchain and Web3 ecosystems' and as providing 'standards and frameworks for DIDs, verifiable credentials, and interoperability.' If Ark Protocol qualifies as an IdM solution on Arweave, the novelty claim should be qualified or clarified; if it does not, the paper should state the distinguishing criteria explicitly.
[§5.2 vs §6.1] The requirements list in Section 5.2 includes 'Anonymization' and 'Unlinkability' as privacy and security requirements, but Section 6.1 acknowledges that 'the public key maintained in the DID uniquely identifies the user and permits tracking of his/her actions,' and the only proposed remedy is refreshing the holder's keys after each verification, described as a considerable complexity trade-off. As written, the proposal does not meet its own stated requirements, and the analysis does not present a concrete mechanism to achieve unlinkability. The paper should either revise the requirements analysis to acknowledge partial fulfillment or add a mechanism (e.g., ephemeral DIDs or per-verifier DIDs) that actually provides unlinkability.

minor comments (5)

[§3.4; §6.1] There are typographical errors: 'back-and-four' should be 'back-and-forth' in Section 3.4, and 'discard the necessary claims only' should be 'disclose the necessary claims only' in Section 6.1.
[Table 1] The acronym table lists 'GRPD' instead of 'GDPR'; please correct the spelling.
[§6.2] The text refers to 'Figure 6.2 illustrates these changes,' but the figure is labeled 'Figure 4' in the manuscript.
[§5.4] The JavaScript snippets are presented in a confusing order and contain undefined functions (e.g., `createVerifiableCredential`) and duplicate declarations of `signedVC`; the code should be cleaned, completed, and referenced consistently so that the phases are reproducible.
[References [32] and [68]] Reference [32] and the duplicate entry [68] both contain the title misspelling 'Dillemma' (should be 'Dilemma'), and [68] appears incomplete without a venue or URL.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: the paper is a design proposal whose security and privacy claims reduce to external primitives, not to its own inputs.

full rationale

The manuscript is an architectural proposal rather than a derivation, so the circularity patterns (fitted parameters, definitions that presume the target, load-bearing self-citation chains) do not apply. The central claim that the security of the construction reduces to BBS(+) is a compositional reduction: BBS(+) is an externally analyzed signature scheme, and the paper explicitly states the assumptions (trusted issuer, secure channels) under which the reduction holds (§6.1). The GDPR-related assertions are internally inconsistent — §4.5 and §6.1 state on-chain data 'cannot be altered or deleted' while §6.1 also claims deletion by a trusted authority — but that is a correctness/design tension, not circularity, because the claim does not reduce to its own inputs by construction. The self-citations ([16], [34], [72]) are background surveys, a prior uPort analysis, and an optional implementation pointer for the zk-SNARK variant in §6.2; none is invoked as the sole justification of a core result. The 'first to look into IdM on Arweave' claim is an assertion and is in tension with the paper's own discussion of Ark Protocol and Namespace.gg, but a novelty dispute is not a circular-reasoning defect.

Assumptions & free parameters 0 free parameters · 4 assumptions · 1 invented entities

The proposal contains no fitted parameters. Its load-bearing assumptions are: Arweave's permanence is compatible with GDPR erasure rights (ad_hoc, asserted but unresolved); trusted issuers and secure channels exist (ad_hoc, stated in §6.1); BBS(+) security as a background building block (standard_math); and a workable 'did:arweave' DID method (domain_assumption, not specified). The only invented entity is the 'did:arweave' method placeholder, which has no independent evidence.

assumptions (4)

domain assumption Arweave provides permanent, immutable, available storage for DID documents.
The design stores DID documents on Arweave and relies on their permanence; invoked throughout §4 and §5.4, but the GDPR compatibility of that permanence is not shown.
ad hoc to paper A trusted VC issuer exists that does not disclose sensitive information, and secure channels exist between issuer and holder.
Stated in §6.1 as the assumptions under which 'data security reduces to the security of BBS(+)'.
ad hoc to paper DID documents containing public keys and service endpoints are not sensitive personal data under GDPR.
The paper asserts 'the DID document contains no sensitive data' (§6.1) while admitting public keys uniquely identify the user; this unproven premise underlies the GDPR-by-design claim.
standard math BBS(+) signatures are secure under DDH and q-SDH and support selective disclosure.
Background from [10]; used as the core privacy primitive in Phase 2.

invented entities (1)

did:arweave DID method
purpose: To make DIDs resolvable via Arweave transactions and ArNS names.
The paper gives an example DID document with 'did:arweave:...' IDs (§5.4) but never specifies the DID method, its resolution rules, privacy properties, or governance; no implementation is provided.

how reviews work

0 comments

Cite this review

Pith. "Pith review of Towards an identity management solution on Arweave." pith.science (2026). https://pith.science/paper/QBHPBUUG

@misc{pith2026241213865,
  author       = {Pith},
  title        = {Pith review of: Towards an identity management solution on Arweave},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/QBHPBUUG}},
  note         = {Machine review of arXiv:2412.13865}
}

read the original abstract

Traditional identity management systems, often centralized, face challenges around privacy, data security, and user control, leaving users vulnerable to data breaches and misuse. This paper explores the potential of using the Arweave network to develop an identity management solution. By harnessing Arweave's permanent storage, our solution offers the users a Self-Sovereign Identity (SSI) framework, that uses Decentralized Identifiers (DIDs) and Verifiable Credentials (VCs) to allow individuals and other entities to create, own, and manage their digital identities. Further, the solution integrates privacy-preserving technologies, including zero-knowledge proofs and the BBS(+) signature scheme, enabling selective disclosure. This approach ultimately enhances user privacy and supports compliance with European Union legislation and regulatory standards like the General Data Protection Regulation (GDPR) by design.

Figures

Figures reproduced from arXiv: 2412.13865 by the authors.

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

74 extracted references · 72 canonical work pages

[1]

Last Accessed: August 2024

Arweave, Meet Arweave: Permanent information storage, https://arweave.org. Last Accessed: August 2024

work page 2024
[2]

URL https://ec.europa.eu/digital -building-blocks/ sites/display/EUDIGITALIDENTITYWAL LET/The+Digital+Identity+ Regulation+Enters+into+Force

European Commission, The EU Digital Identity Framework Regulation Enters into Force (2024). URL https://ec.europa.eu/digital -building-blocks/ sites/display/EUDIGITALIDENTITYWAL LET/The+Digital+Identity+ Regulation+Enters+into+Force. Last Accessed: November 2024

work page 2024
[3]

Last Accessed: August 2024 (2023)

eIDAS Technical Sub-group, eIDAS Cryptographic Requirements for the Interoperability Framework, https://ec.europa.eu/digital-building-blocks/sites/display /DIGITAL/eIDAS+eID+Profile. Last Accessed: August 2024 (2023)

work page 2023
[4]

Last Accessed: September 2024 (2023)

European Union, Regulations of the European Parliament and of the Council amending Regulation (EU) No.910/2014 as re- gards establishing the European Digital Identity Framework, https://data.consilium.europa.eu/doc/document/ PE-68-2023-REV-1/en/pdf. Last Accessed: September 2024 (2023)

work page 2023
[5]

Last Accessed: October 2024

Regulation (EU) 2016/679, General Data Protection Regulation GDPR, https://gdpr-info.eu/. Last Accessed: October 2024

work page 2016
[6]

Last Accessed: November 2024

Christopher Allen, The Path to Self-Sovereign Identity, https://www.lifewithalacrity.com/article/the-path-to-self -soverereign -identity. Last Accessed: November 2024

work page 2024
[7]

Last Accessed: Novem - ber 2024

W3C, Verifiable Credentials Data Model v2, https://www.w3.org/TR/vc -data-model-2.0. Last Accessed: Novem - ber 2024

work page 2024
[8]

Core architecture, data model, and representations, 32 https://www.w3.org/TR/did -core

W3C Recommendation, Decentralized Identifiers (DIDs) v1.0. Core architecture, data model, and representations, 32 https://www.w3.org/TR/did -core. Last Accessed: August 2024 (2022)

work page 2022

Show all 74 references

[9]

Last Accessed: August 2024

ar.io Docs, Arweave Name System (ArNS), https://docs.ar.io/arns. Last Accessed: August 2024

2024
[10]

Tessaro, C

S. Tessaro, C. Zhu, Revisiting bbs signatures, in: Annual International Conference on the Theory and Applications of Cryptographic Tech - niques, Springer, 2023, pp. 691–721

2023
[11]

URL https://sovrin.org

Sovrin Foundation, Global public registry for DIDs, Trust anchor for Verifiable Credentials (2024). URL https://sovrin.org. Last Accessed: November 2024

2024
[12]

URL https://veramo.io

Sovrin Foundation, Performant and modular APIs for Verifiable Data and SSI (2024). URL https://veramo.io. Last Accessed: November 2024

2024
[13]

URL https://www.civic.com

Control Safety Trust for Digital Identities, Civic Technologies (2024). URL https://www.civic.com. Last Accessed: November 2024

2024
[14]

URL https://identity.foundation/ion

DIF Organization, ION (2024). URL https://identity.foundation/ion. Last Accessed: November 2024

2024
[15]

URL https://selfkey.org

SelfKey, Community Vote Proposed Merger With SingularityDAO and Cogito Finance to form Singularity Finance(SFI) AI Fi Layer 2 (2024). URL https://selfkey.org. Last Accessed: November 2024

2024
[16]

Panait, R

A.-E. Panait, R. F. Olimid, A. Stefanescu, Identity management on blockchain – privacy and security aspects (2020). arXiv:2004.13107. URL https://arxiv.org/abs/2004.13107

2020 arXiv
[17]

Nokhbeh Zaeem, K

R. Nokhbeh Zaeem, K. C. Chang, T.-C. Huang, D. Liau, W. Song, A. Tyagi, M. Khalil, M. Lamison, S. Pandey, K. S. Barber, Blockchain - based self-sovereign identity: Survey, requirements, use-cases, and com- parative study, in: IEEE/WIC/ACM International Conference on Web Intell...

2022
[18]

M. R. Ahmed, A. K. M. M. Islam, S. Shatabda, S. Islam, Blockchain - based identity management system and self -sovereign identity ecosys - tem: A comprehensive survey, IEEE Access 10 (2022) 113436 –113481. doi:10.1109/ACCESS.2022.3216643

2022
[19]

M. M. Merlec, H. P. In, Blockchain-based decentralized storage systems for sustainable data self-sovereignty: A comparative study, Sustainabil- ity 16 (17) (2024). doi:10.3390/su16177671. URL https://www.mdpi.com/2071-1050/16/17/7671

2024 doi
[20]

Last Accessed: August 2024

decent.land, Ark Protocol, https:/arkprotocol.xyz. Last Accessed: August 2024

2024
[21]

Last Accessed: August 2024

decent.land, namespace.gg, https://www.namespace.gg. Last Accessed: August 2024

2024
[22]

Last Accessed: August 2024

decent.land, decent.land, https://www.decent.land. Last Accessed: August 2024

2024
[23]

Last Accessed: August 2024 (2023)

European Commission, electronic IDentification (eID), https://ec.europa.eu/digital -building-blocks/sites/display /DIGITAL/What+is+eID. Last Accessed: August 2024 (2023)

2023
[24]

Last Accessed: October 2024

European Commission, A digital ID and personal dig- ital wallet for EU citizens, residents and businesses, https://ec.europa.eu/digital-building-blocks/sites/display/ EUDIGITALIDENTITYWALLET/EU+Digital+Identity+Wallet+Home. Last Accessed: October 2024

2024
[25]

Last Accessed: November 2024 (2024)

European Commission, EU Digital Identity Wallet Technical specifica- tions, https://ec.europa.eu/digit al-building-blocks/sites/ display/EUDIGITALIDENTITYWALLET/Technical+Specifications. Last Accessed: November 2024 (2024)

2024
[26]

et al., Cryptographers’ Feedback on the EU Digital Identity’s ARF, https://github.com/eu -digital-identity-wallet/ eudi-doc-architecture -and-reference-framework/discussions /211

Baum, C. et al., Cryptographers’ Feedback on the EU Digital Identity’s ARF, https://github.com/eu -digital-identity-wallet/ eudi-doc-architecture -and-reference-framework/discussions /211. Last Accessed: November 2024

2024
[27]

URL https://www.euaiact.com

European Parliament, The EU AI Act (2024). URL https://www.euaiact.com. Last Accessed: November 2024 34

2024
[28]

Last Accessed: August 2024

Arweave community, Arweave Permaweb Cookbook, https://cookbook.arweave.dev. Last Accessed: August 2024

2024
[29]

Boneh, X

D. Boneh, X. Boyen, H. Shacham, Short group signatures, in: Annual international cryptology conference, Springer, 2004, pp. 41 –55

2004
[30]

M. H. Au, W. Susilo, Y. Mu, Constant -size dynamic k -taa, in: Security and Cryptography for Networks: 5th International Conference, SCN 2006, Maiori, Italy, September 6-8, 2006. Proceedings 5, Springer, 2006, pp. 111–125

2006
[31]

Camenisch, M

J. Camenisch, M. Drijvers, A. Lehmann, Anonymous attestation using the strong diffie hellman assumption revisited, in: Trust and Trustwor - thy Computing: 9th International Conference, TRUST 2016, Vienna, Austria, August 29-30, 2016, Proceedings 9, Springer, 2016, pp. 1–20

2016
[32]

Søren Eller Thomsen, On the eu digital identity wallets dillemma: Un - linkability or loa high?
[33]

Looker, V

T. Looker, V. Kalos, A. Whitehead, M. Lodder, The BBS Signature Scheme (2024). URL https://identity.foundation/bbs-signature/draft-irtf- cfrg-bbs-signatures.htmlname-generators-calculation. Last Accessed: December 2024

2024
[34]

Panait, R

A.-E. Panait, R. F. Olimid, On using zk -snarks and zk -starks in blockchain-based identity management, in: D. Maimut, A.-G. Oprina, D. Sauveron (Eds.), Innovative Security Solutions for Information Tech - nology and Communication s, Springer International Publishing, Cham, 20...

2021
[35]

Last Accessed: August 2024

Ryan Sproule, A Developer’s Guide to the zkGalaxy, https://www.blockchaincapital.com/blog/a -developers -guide-to -the-zkgalaxy. Last Accessed: August 2024

2024
[36]

Last Accessed: September 2024

Manta Network, Manta Network, https://github.com/Manta-Network. Last Accessed: September 2024

2024
[37]

Last Accessed: September 2024

Ethereum Foundation, What is Semaphore, https://docs.semaphore.pse.dev. Last Accessed: September 2024. 35

2024
[38]

Last Accessed: August 2024

ident3, Circom 2 Documentation, https://docs.circom.io/ getting-started/proving -circuits. Last Accessed: August 2024

2024
[39]

Last Accessed: September 2024

Aztec Labs, Noir - The universal language of zero-knowledge, https://aztec.network/noir. Last Accessed: September 2024

2024
[40]

Last Accessed: September 2024

Starkware, Cairo, https://starkware.co/cairo. Last Accessed: September 2024

2024
[41]

Last Accessed: December 2024

Jacob Eberhardt, Zokrates GitHub, https://github.com/Zokrates /ZoKrates. Last Accessed: December 2024

2024
[42]

Last Accessed: September 2024

Aleo, Leo, https://www.leo -lang.org. Last Accessed: September 2024

2024
[43]

Last Accessed: August 2024

ident3, snarkjs GitHub, https://github.com/iden3/snarkjs. Last Accessed: August 2024

2024
[44]

Last Accessed: August 2024

Electric Coin Company (ECC), halo2 GitHub, https://zcash.github.io/halo2. Last Accessed: August 2024

2024
[45]

URL https://arkworks.rs

arkworks contributors, arkworks zksnark ecosystem (2022). URL https://arkworks.rs

2022
[46]

Last Accessed: August 2024

NilFoundation, Zero -Knowledge Proof Systems Circuit Compiler, https://github.com/NilFoundation/zkllvm. Last Accessed: August 2024

2024
[47]

Last Accessed: September 2024

ZKsync, ZKsync, https://zksync.io. Last Accessed: September 2024

2024
[48]

Last Accessed: September 2024

Polygon, Polygon zkEVM, https://polygon.technology/ polygon-zkevm. Last Accessed: September 2024

2024
[49]

Last Ac - cessed: September 2024

Scroll Ltd, Scroll - Ethereum, Extended., https://scroll.io. Last Ac - cessed: September 2024

2024
[50]

Last Accessed: September 2024

Starknet Community, Starknet Docs, https://docs.starknet.io. Last Accessed: September 2024

2024
[51]

Last Accessed: November 2024

RiscZero, Universal Zero Knowledge, https://risczero.com. Last Accessed: November 2024. 36

2024
[52]

S. Gao, G. Li, H. Fu, Zkwasm: A zksnark wasm emulator, IEEE Trans- actions on Services Computing (2024)

2024
[53]

Last Accessed: September 2024

Community Labs, Incubate Elevate on Arweave and AO, https://www.communitylabs.com. Last Accessed: September 2024

2024
[54]

URL https://www.arweave.org/yellow -paper.pdf

Sam Williams, Viktor Diordiiev, Lev Berman, India Raybould, Ivan Uemlianin, Arweave: The Permanent Information Storage Protocol (2024). URL https://www.arweave.org/yellow -paper.pdf

2024
[55]

URL https://www.arweave.org/files/arweave -lightpaper.pdf

Sam Williams, Abhav Kedia, Lev Berman, Sebastian Campos -Groth, Arweave: The Permanent Information Storage Protocol (2024). URL https://www.arweave.org/files/arweave -lightpaper.pdf

2024
[56]

Last Accessed: October 2024

Sam Williams, Lev Berman, ANS- 103: Succinct Proofs of Random Access, https://github.com/ArweaveTeam/arweave -standards/blob/master /ans/ANS-103.md. Last Accessed: October 2024

2024
[57]

Last Accessed: August 2024

Arweave community, SmartWeave, https://cookbook.arweave.dev/ concepts/smartweave.html. Last Accessed: August 2024

2024
[58]

Last Accessed: August 2024

Warp by RedStone, Smart contracts on Arweave, https://warp.cc. Last Accessed: August 2024

2024
[59]

Last Accessed: August 2024

Decent Land Labs, MEM: Lightning-fast serverless functions for web3, https://www.mem.tech. Last Accessed: August 2024

2024
[60]

Last Accessed: October 2024

Arweave, WeaveVM, https://docs.wvm.dev. Last Accessed: October 2024

2024
[61]

WeaveVM, Read and write to arweave from solidity smart contracts: Introducing weavevm precompiles
[62]

Last Accessed: October 2024

decent.land, ANS, https://github.com/decentldotland/ANS. Last Accessed: October 2024

2024
[63]

Last Accessed: Au- gust 2024

AR.IO, AR.IO is a network of decentralized gateways and permanent domains that power the permaweb, https://ar.io. Last Accessed: Au- gust 2024. 37

2024
[64]

Last Accessed: August 2024

Arweave community, ArNS, https://cookbook.arweave.dev/concepts /arns.html. Last Accessed: August 2024

2024
[65]

Last Ac- cessed: November 2024

Maurice E Mu¨ller, Robert Schneider, Hans Willenegger, Martin Allg o¨wer, and Walter Bandi, The AO Protocol: A Decentral - ized Open-Access Supercomputer, https://ao.ar.io//read. Last Ac- cessed: November 2024

2024
[66]

Last Accessed: September 2024

Partisia, Partisia Decentralised Identity, https://www.partisia.com/docs/partisia -decentralised -identity. Last Accessed: September 2024

2024
[67]

Standard, Personal identification — ISO-compliant driving licence (2024)

I. Standard, Personal identification — ISO-compliant driving licence (2024). URL https://www.iso.org/standard/69084.html. Last Accessed: November 2024

2024
[68]

Søren Eller Thomsen, On the EU Digital Identity Wallets Dillemma: Unlinkability or LoA High?,
[69]

URL https://digital -strategy.ec.europa.eu/en/policies /data-act

European Commission, Data Act (2024). URL https://digital -strategy.ec.europa.eu/en/policies /data-act. Last Accessed: November 2024

2024
[70]

Last Accessed: October 2024

ArConnect, ArConnect, https://www.arconnect.io. Last Accessed: October 2024

2024
[71]

Last Accessed: Octo - ber 2024

ArDrive, ArDrive, https://ardrive.io/mobile. Last Accessed: Octo - ber 2024

2024
[72]

Panait, R

A.-E. Panait, R. F. Olimid, A. Stefanescu, Analysis of uPort Open, an Identity Management Blockchain-Based Solution, in: S. Gritzalis, E. R. Weippl, G. Kotsis, A. M. Tjoa, I. Khalil (Eds.), Trust, Privacy and Security in Digital Business, Springer International Publishing, Cha...

2020
[73]

Vlasov, K

A. Vlasov, K. Kelly Olson, A. Stokes, A. Sanso, EIP-2537: Precompile for BLS12-381 curve operations (2024). URL https://eips.ethereum.org/EIPS/eip -2537. Last Accessed: December 2024 38

2024
[74]

Last Accessed: November 2024 (2024)

ArweaveTeam, ANS-104: Bundled Data v2.0 - Binary Serialization, https://github.com/ArweaveTeam/arweave-standards/blob/master/ ans/ANS-104.md. Last Accessed: November 2024 (2024)

2024

Pith tools

Reviewed August 11, 2026 · model on record in the stance chip above.

[1] [1]

Last Accessed: August 2024

Arweave, Meet Arweave: Permanent information storage, https://arweave.org. Last Accessed: August 2024

work page 2024

[2] [2]

URL https://ec.europa.eu/digital -building-blocks/ sites/display/EUDIGITALIDENTITYWAL LET/The+Digital+Identity+ Regulation+Enters+into+Force

European Commission, The EU Digital Identity Framework Regulation Enters into Force (2024). URL https://ec.europa.eu/digital -building-blocks/ sites/display/EUDIGITALIDENTITYWAL LET/The+Digital+Identity+ Regulation+Enters+into+Force. Last Accessed: November 2024

work page 2024

[3] [3]

Last Accessed: August 2024 (2023)

eIDAS Technical Sub-group, eIDAS Cryptographic Requirements for the Interoperability Framework, https://ec.europa.eu/digital-building-blocks/sites/display /DIGITAL/eIDAS+eID+Profile. Last Accessed: August 2024 (2023)

work page 2023

[4] [4]

Last Accessed: September 2024 (2023)

European Union, Regulations of the European Parliament and of the Council amending Regulation (EU) No.910/2014 as re- gards establishing the European Digital Identity Framework, https://data.consilium.europa.eu/doc/document/ PE-68-2023-REV-1/en/pdf. Last Accessed: September 2024 (2023)

work page 2023

[5] [5]

Last Accessed: October 2024

Regulation (EU) 2016/679, General Data Protection Regulation GDPR, https://gdpr-info.eu/. Last Accessed: October 2024

work page 2016

[6] [6]

Last Accessed: November 2024

Christopher Allen, The Path to Self-Sovereign Identity, https://www.lifewithalacrity.com/article/the-path-to-self -soverereign -identity. Last Accessed: November 2024

work page 2024

[7] [7]

Last Accessed: Novem - ber 2024

W3C, Verifiable Credentials Data Model v2, https://www.w3.org/TR/vc -data-model-2.0. Last Accessed: Novem - ber 2024

work page 2024

[8] [8]

Core architecture, data model, and representations, 32 https://www.w3.org/TR/did -core

W3C Recommendation, Decentralized Identifiers (DIDs) v1.0. Core architecture, data model, and representations, 32 https://www.w3.org/TR/did -core. Last Accessed: August 2024 (2022)

work page 2022