{"id":"73e113e3-4942-4a56-a798-987a8cc25189","arxiv_id":"2412.13865","paper_version":3,"verdict":"CONDITIONAL","confidence":"HIGH","novelty_score":3.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"A design proposal for storing self-sovereign identities on Arweave using DIDs, verifiable credentials, and BBS(+) selective disclosure, with a claim of GDPR-by-design that is not fully supported.","lead":"The paper proposes a design for a self-sovereign identity system that stores decentralized identifiers on the Arweave permanent-storage blockchain, using verifiable credentials and BBS(+) signatures so users can reveal only selected identity claims. It is a blueprint rather than a working system, aimed at anyone assessing whether Arweave can host GDPR-oriented digital identity management.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"GDPR-by-design claim is internally inconsistent: §6.1 says DID documents 'cannot be altered or deleted' on Arweave yet asserts deletion by a trusted authority; the admitted linkability of DID public keys makes this a personal-data erasure problem, not a scoping caveat.","rationale":"The most load-bearing concern is the GDPR-by-design claim, because it is part of the paper's stated motivation and abstract-level contribution. The reader's weakest assumption identified the same issue: storing DID documents on immutable Arweave storage conflicts with GDPR's erasure and rectification rights, and the paper does not reconcile this. I agree with that assessment and with the recommendation of conditional acceptance: the issue is fixable by either adding a concrete erasure/invalidation mechanism or narrowing the claim to 'GDPR-aligned for disclosed attributes' and removing 'by design.' The other concerns—the novelty overclaim regarding Ark Protocol and the imprecise 'security reduces to BBS(+)' statement—are real but less damaging: the first affects only the contribution framing, and the second is explicitly qualified by assumptions in §6.1. The GDPR issue, by contrast, undermines the paper's central regulatory promise and is internally inconsistent with the authors' own description of Arweave in §4.5 and §6.1. A single concrete retrieval test after a simulated 'identity removal' would settle whether the proposed architecture can meet Article 17; absent that, the paper should not be accepted as a GDPR-by-design solution.","tokens_in":19554,"tokens_out":6448,"duration_ms":62654,"concrete_test":"Run a revocation scenario on Arweave testnet: publish a DID document containing a public key and an ArNS mapping, execute the paper's proposed 'identity removal' by having the trusted authority remove or update the ArNS pointer, then fetch the original transaction directly via https://arweave.net/<txid> and via any cached ArNS URL. If the original DID document remains retrievable and still contains the identifying public key, GDPR Article 17 erasure is not achieved. To settle the concern, the authors must either provide a concrete invalidation or key-rotation mechanism that makes the old DID document unlinkable and unrecoverable, or revise the claim from 'GDPR compliance by design' to a narrower, accurate statement about selective disclosure of VC attributes.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The paper's central regulatory claim is that the proposal supports 'compliance with the GDPR by design.' That claim is not supported by the construction and is contradicted by the paper's own statements. Arweave storage is permanent and immutable: §4.5 says data 'cannot be deleted or modified,' and §6.1 concedes that 'the DID documents persist and cannot be altered or deleted.' In the same subsection, however, the authors claim that users can 'ask for corrections ... and deletion of their identities,' that 'data update and identity removal are performed by a trusted, certified authority,' and that this 'complies with EU regulations.' No mechanism is given for a trusted authority to delete or irreversibly invalidate a DID document on Arweave; at most the ArNS pointer could be removed, leaving the original transaction permanently retrievable by its txid. This matters because the paper itself admits in §6.1 that 'the public key maintained in the DID uniquely identifies the user and permits tracking of his/her actions,' so the DID document is personal data, not a neutral public record. GDPR Articles 16 and 17 require rectification and erasure of personal data; the proposed architecture provides no way to satisfy those rights for data permanently recorded on an immutable ledger. The assertion in §6.1 that the DID document 'contains no sensitive data' does not resolve the issue, because non-sensitive but identifying data still falls within GDPR's scope. The claim of GDPR compliance by design is therefore not established by the paper's arguments, and the internal contradiction is directly load-bearing for the central contribution.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","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(+).","tokens_in":19809,"tokens_out":5741,"duration_ms":47488,"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":[{"comment":"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.","section":"§6.1, 'Self-sovereignty' paragraph; §4.5"},{"comment":"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.","section":"§6.1, 'Privacy and security' paragraph; §6.5"},{"comment":"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.","section":"§2 and §6.4"},{"comment":"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.","section":"§5.2 vs §6.1"}],"minor_comments":[{"comment":"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.","section":"§3.4; §6.1"},{"comment":"The acronym table lists 'GRPD' instead of 'GDPR'; please correct the spelling.","section":"Table 1"},{"comment":"The text refers to 'Figure 6.2 illustrates these changes,' but the figure is labeled 'Figure 4' in the manuscript.","section":"§6.2"},{"comment":"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.","section":"§5.4"},{"comment":"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.","section":"References [32] and [68]"}],"recommendation":"major_revision","confidential_remarks":"This is a design/position paper rather than a fully formalized system, and its main contributions are the Arweave IdM architecture, the BBS(+)-based selective disclosure approach, and the comparison table. The major revision should focus on either providing mechanisms for erasure/rectification or removing the 'GDPR by design' claim, and on either proving or precisely qualifying the security-reduction statement. The novelty claim regarding Ark Protocol also needs to be reconciled with the related-work section, since the current text is internally inconsistent. These are fixable within the manuscript's scope, so rejection is not warranted, but the revisions are substantive rather than merely editorial."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","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.\n\nThe 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.\n\nThe 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.\n\nWho 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.","headline":"A clear Arweave SSI design proposal that overclaims novelty and GDPR compliance; useful as a tutorial, not as a verified system.","tokens_in":20412,"tokens_out":2860,"would_cite":false,"duration_ms":23103,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"The paper proposes the first identity-management system built on Arweave, using DIDs, verifiable credentials, and BBS(+) proofs for selective disclosure.","keywords":["Arweave","identity management","self-sovereign identity","decentralized identifiers","verifiable credentials","BBS+ signatures","selective disclosure","GDPR"],"falsifier":"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.","tokens_in":19284,"feed_emoji":"🪪","tokens_out":7131,"duration_ms":62230,"temperature":0.7,"pith_summary":"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(+).","feed_headline":"Arweave gets first self-sovereign identity proposal","feed_subtitle":"DIDs and verifiable credentials with BBS+ selective disclosure aim for GDPR compliance by design.","key_machinery":"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.","core_discovery":"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.","pith_inferences":["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."],"forward_implications":["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."],"supporting_citations":[{"why":"Supplies the BBS(+) signature scheme, which the design relies on for selective disclosure and zero-knowledge proofs.","marker":"[10]"},{"why":"Defines DID documents, controllers, and resolution, the identity record that gets stored on Arweave.","marker":"[8]"},{"why":"Defines the verifiable credential data model and the issuer-holder-verifier roles used in the design.","marker":"[7]"},{"why":"Describes ArNS, the naming layer that maps human-readable names to the Arweave transactions holding DID documents.","marker":"[9]"},{"why":"Describes Arweave's permanent storage, the substrate whose immutability and availability motivate the whole proposal.","marker":"[1]"},{"why":"Defines GDPR rights and principles that the solution claims to satisfy by design.","marker":"[5]"},{"why":"Provides the eIDAS attribute profile that fixes which identity attributes the solution manages.","marker":"[3]"},{"why":"Defines eIDAS, the EU legal framework for electronic identification that shapes mandatory identity attributes.","marker":"[23]"},{"why":"Supplies the zk-SNARK and zk-STARK line that Variant 2 uses for minimal disclosure beyond BBS(+).","marker":"[34]"}],"fun_headline_variants":["Arweave SSI: BBS+ proofs for GDPR-friendly selective disclosure","Self-sovereign identity on Arweave with BBS+ zero-knowledge","Arweave DIDs: permanent storage, BBS+ selective disclosure","Permanent Arweave DIDs meet BBS+ for private identity sharing"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"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.","fun_headline_variants_meta":{"raw":{"variants":["Arweave SSI: BBS+ proofs for GDPR-friendly selective disclosure","Self-sovereign identity on Arweave with BBS+ zero-knowledge","Arweave DIDs: permanent storage, BBS+ selective disclosure","Permanent Arweave DIDs meet BBS+ for private identity sharing"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000291,"raw_usage":{"total_tokens":1638,"prompt_tokens":824,"completion_tokens":814,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":440,"completion_tokens_details":{"reasoning_tokens":731}},"tokens_in":440,"tokens_out":814,"duration_ms":7429,"temperature":1.0,"reasoning_tokens":731,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-11T12:42:51.427570+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"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.","supporting_citations":[{"cited_title":"Tessaro, C","cited_arxiv_id":null,"evidence_quote":"Supplies the BBS(+) signature scheme, which the design relies on for selective disclosure and zero-knowledge proofs."},{"cited_title":"Core architecture, data model, and representations, 32 https://www.w3.org/TR/did -core","cited_arxiv_id":null,"evidence_quote":"Defines DID documents, controllers, and resolution, the identity record that gets stored on Arweave."},{"cited_title":"Last Accessed: Novem - ber 2024","cited_arxiv_id":null,"evidence_quote":"Defines the verifiable credential data model and the issuer-holder-verifier roles used in the design."},{"cited_title":"Last Accessed: August 2024","cited_arxiv_id":null,"evidence_quote":"Describes ArNS, the naming layer that maps human-readable names to the Arweave transactions holding DID documents."},{"cited_title":"Last Accessed: August 2024","cited_arxiv_id":null,"evidence_quote":"Describes Arweave's permanent storage, the substrate whose immutability and availability motivate the whole proposal."},{"cited_title":"Last Accessed: October 2024","cited_arxiv_id":null,"evidence_quote":"Defines GDPR rights and principles that the solution claims to satisfy by design."},{"cited_title":"Last Accessed: August 2024 (2023)","cited_arxiv_id":null,"evidence_quote":"Provides the eIDAS attribute profile that fixes which identity attributes the solution manages."},{"cited_title":"Last Accessed: August 2024 (2023)","cited_arxiv_id":null,"evidence_quote":"Defines eIDAS, the EU legal framework for electronic identification that shapes mandatory identity attributes."},{"cited_title":"Panait, R","cited_arxiv_id":null,"evidence_quote":"Supplies the zk-SNARK and zk-STARK line that Variant 2 uses for minimal disclosure beyond BBS(+)."}],"review_version":1}