{"id":"1128ab13-e0fa-4861-9a41-46193cb4f49a","arxiv_id":"2411.16987","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":4.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"SoverClaim integrates Hyperledger Indy with Storj to issue, present, and delete document-based claims; measured issuance under 750 ms and presentation under 600 ms.","lead":"This paper introduces SoverClaim, a prototype that combines a blockchain-based identity system with peer-to-peer document storage, letting users present and delete claim documents without a central provider. It offers a concrete benchmark for how fast decentralized identity and document handling can work in practice.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Storj's deletion mechanism is described but not independently verified; if shards remain recoverable after 'uplink rm', SoverClaim's GDPR/right-to-be-forgotten claim fails.","rationale":"I considered alternative concerns: the latency evaluation lacks error bars and public artifacts, and the private VON ledger is not a public decentralized network. These weaken evaluation but do not directly falsify the demonstrated integration. The deletion issue is more load-bearing because it targets a stated contribution: decentralized storage with deletion supporting right-to-be-forgotten. The paper itself acknowledges the difficulty in Section 2.3 yet makes the claim in Section 3 and the abstract. Since the prototype evaluation does not test erasure, the conditional acceptance should be kept; the authors should either verify deletion or soften the privacy claim.","tokens_in":10157,"tokens_out":4607,"duration_ms":43300,"concrete_test":"Deploy SoverClaim against a private Storj test network (e.g., storj-sim), upload a known test file, capture the shared URL, execute the delete operation through SoverClaim, then attempt to retrieve the object via the shared URL and via 'uplink cat' at 0h, 24h, and 7 days after deletion, and inspect the storage nodes' local data directories for remaining shards. If the file remains retrievable or shards remain on disk after the delete call returns success, the deletion guarantee fails.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The paper's privacy contribution rests on the claim that documents are 'securely stored and can be... deleted to comply with data protection laws' (Section 3, step viii). Section 4.5 states that Uplink rm obtains signed confirmations from storage nodes and removes segment pointers; however, signed acknowledgements are not proof of physical erasure. Section 2.3 explicitly concedes that 'the distributed nature of these systems makes it impractical to guarantee complete data eradication.' The prototype evaluation (Section 5) measures latency of delete but never checks whether the object is actually unrecoverable after deletion, nor whether fragments persist on storage nodes. The paper therefore overstates the right-to-erasure guarantee, which is one of SoverClaim's distinguishing features. This is not an internal inconsistency in the integration itself, but it means the central privacy objective is not established.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper presents SoverClaim, a decentralized application prototype that combines Hyperledger Indy/Aries-based self-sovereign identity (SSI) with Storj decentralized storage for document-based claim processes. The system lets a user upload identity documents to Storj, receive a verifiable credential from an issuer who validates the document, present the credential to a service provider, and manage audit logs on an Indy ledger. The paper describes the architecture and protocols, then reports measurements from a Google Cloud deployment: credential issuance and presentation are said to complete in under 750 ms and 600 ms respectively, supporting the claim that the system is suitable for interactive use. The paper also reports CPU, memory, and cost estimates.","tokens_in":10275,"tokens_out":4723,"duration_ms":46234,"significance":"If the results hold, this is a useful integration case study: it demonstrates that existing standards-based SSI components (Hyperledger Indy, Aries, Ursa) can be combined with a decentralized storage service (Storj) to support document-based claims with reasonable latency. The paper does not introduce new cryptographic mechanisms, formal models, or fitted parameters; its contribution is the working prototype and the measurement of its behavior. The latency numbers are direct measurements, which is a strength compared to purely architectural proposals. However, the two load-bearing claims—that documents can be deleted to satisfy right-to-erasure obligations, and that the measured latencies are statistically reliable evidence of interactive suitability—are not adequately supported. These issues are addressable and do not invalidate the integration itself, but they need substantial revision before the paper can be recommended for publication.","major_comments":[{"comment":"The paper's central privacy claim—that documents are 'deleted to comply with data protection laws'—is not supported by the evidence. Section 4.5 describes the Storj delete flow as obtaining signed acknowledgements from storage nodes and removing segment pointers, but signed acknowledgements do not prove physical erasure. Section 2.3 explicitly concedes that decentralized storage makes 'complete data eradication' impractical to guarantee. The evaluation in Section 5.2 / Figure 6 measures the latency of the delete operation but never checks whether the file is actually unrecoverable after 'uplink rm', nor whether shards persist on storage nodes. The paper should either empirically verify deletion (e.g., attempt to re-download the object or inspect node garbage collection) or scope the claim to access revocation and pointer removal rather than right-to-erasure. As written, the GDPR compliance objective is overstated.","section":"Section 5.2 / Figure 6; Section 6"},{"comment":"The feasibility conclusion that SoverClaim is 'suitable for timely human interactions' rests solely on point estimates in Figure 6. The figure reports single latency values with no error bars, no repetition count, and no statistical analysis, and Section 5.1 does not describe the Locust workload (number of concurrent users, request rate, request duration, or how many repetitions produced the plotted values), despite Q1 asking about performance when 'used by multiple users'. The 750 ms threshold used in the conclusion is introduced without justification. Please report distributions, confidence intervals, or at least repeated-run statistics, and either justify the threshold or soften the claim to a demonstration that the integration works rather than a quantitative usability guarantee.","section":"Section 5.2 / Figure 6"}],"minor_comments":[{"comment":"The abstract contains typos: 'may online services' should be 'many online services', and 'andStorj' should be 'and Storj'.","section":"Abstract"},{"comment":"The discussion of Zero-Knowledge Proof concepts contains an informal first-person aside ('in my opinion, it is important to include') and a mention of a 'Compound Proof' mechanism that is not implemented. This is out of place in a formal paper and should be rewritten in a neutral style.","section":"Section 2.1"},{"comment":"The sentence about VON Network says it 'simplifies deployment and deployment'—the word 'deployment' is duplicated.","section":"Section 4.1"},{"comment":"Figure 6 is difficult to read: the bars for subprocesses are not clearly distinguished from the totals for each operation, and no numerical values are provided. A table with means and variances for each operation would substantially improve the evaluation.","section":"Figure 6"},{"comment":"The cost section uses 'C' as a currency symbol (e.g., '50 C'), which is ambiguous; it should be '€' or 'EUR'. Also, the sentence 'with an additional 50 C per entity' is unclear about whether this is a one-time or monthly cost.","section":"Section 5.3"},{"comment":"The paper does not provide a link to the prototype repository or an artifact availability statement. Given that the main contribution is a working prototype, a public artifact link would improve reproducibility and allow reviewers to verify the claims.","section":"Section 4"}],"recommendation":"major_revision","confidential_remarks":"The manuscript is a prototype demonstration rather than a foundational systems contribution. Its main value is as an integration case study, and the two major concerns (unverified deletion semantics and insufficient statistical support for the latency claims) are addressable with additional experiments and revised wording. The paper would also benefit from an explicit artifact link and raw measurement data. If the journal publishes demonstration papers, major revision is the appropriate outcome."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Colleague,\n\nThe paper is exactly what it looks like: a working prototype that stitches Hyperledger Indy/Aries to Storj for document-based claims, with measured latencies suggesting the flow is interactive. That combination is real—Sovrin lacks decentralized storage, uPort uses IPFS/Ethereum, ShoCard and Civic don't combine the pieces. So the prototype has a place as a reference architecture for SSI document workflows. The authors use standard protocols (DIDComm, Aries RFC 0454) and are clear about what is implemented and what isn't (the ZKP compound proof is future work). Credit for honest scoping.\n\nThe main soft spot is the deletion/privacy claim, and the stress-test note is on target. Section 4.5 says Uplink rm gets signed confirmations from storage nodes and removes segment pointers. That's a management-layer deletion, not proof of physical erasure. The paper itself concedes in Section 2.3 that complete eradication is impractical. Yet Section 3 step viii says documents 'are deleted to comply with data protection laws.' That overstates the right-to-erasure guarantee. The evaluation measures delete latency, not recoverability. This doesn't break the integration, but it means SoverClaim's distinguishing privacy feature is not actually demonstrated.\n\nThe evaluation is otherwise thin: Figure 6 shows single latency values with no error bars or repetition count, and the 750 ms usability threshold is arbitrary. For a prototype feasibility demo that's tolerable, but it should be labeled as such, not presented as a performance result. The resource usage and cost numbers are fine as ballpark estimates.\n\nThere's also an editorial stumble in Section 2.1: a first-person aside ('in my opinion, it is important to include the descriptions') that reads like a draft note, not published prose. That should be cleaned up.\n\nBottom line: this is a serious engineering study, not a conceptual advance. The math and the main system description are coherent, the citations to related systems are appropriate, and the prototype appears to work as described. The deletion overstatement is the one load-bearing weakness, and it can be fixed by soft-pedaling the GDPR claim and adding a discussion of what deletion does and doesn't guarantee. I'd send it to peer review as an engineering paper, conditional on revisions. If the authors also tighten the evaluation presentation, it would be a useful contribution for practitioners in SSI and decentralized storage.","headline":"Solid integration prototype of SSI + decentralized storage, but the deletion guarantee is overstated and the evaluation is thin.","tokens_in":10798,"tokens_out":2217,"would_cite":false,"duration_ms":19898,"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":"SoverClaim integrates self-sovereign identity with decentralized storage so users can present document-based claims privately, with sub-second latency for issuing and presenting credentials.","keywords":["self-sovereign identity","decentralized storage","verifiable credentials","Hyperledger Indy","Storj","document-based claims","GDPR right to be forgotten","decentralized application"],"falsifier":"Go through the SoverClaim flow with a test file, run `uplink rm` on it, then retain or regain the segment pointers from the satellite or a node's signed deletion response and attempt to fetch and decrypt the shards from the storage nodes that held them. If any shard remains retrievable, or if the signed deletion confirmations do not correspond to actual erasure, the right-to-be-forgotten claim collapses even though credential issuance and presentation may still work.","tokens_in":90,"feed_emoji":"🪪","tokens_out":5370,"duration_ms":99546,"temperature":0.7,"pith_summary":"The paper's central claim is that a working prototype can combine self-sovereign identity with decentralized storage to support document-based claims without a central identity provider holding the data. The system, SoverClaim, lets a user upload an encrypted document to Storj, receive a verifiable credential after the document is validated, and later present a zero-knowledge proof of that credential to a service provider, with audit logs written to an Indy ledger and decryptable only by the user. Measured end-to-end latencies are below 750 ms for issuing a credential and below 600 ms for presenting one, which the authors argue makes the flow practical for interactive use. The reason to care: if the claim holds, users gain transparency and control over their identity and documents, and the right to be forgotten can be addressed through document deletion in decentralized storage.","feed_headline":"Credential issue and presentation finish in under 750 ms","feed_subtitle":"SoverClaim pairs Hyperledger Indy with Storj so users hold identity and documents, and deletion is built in.","key_machinery":"The load-bearing object is the SoverClaim prototype itself: a Flask-based orchestrator that coordinates three Aries cloud agents (user, issuer, and service provider), a VON/Hyperledger Indy ledger for DIDs and encrypted audit logs, and the Storj Uplink CLI for bucket and file operations. The glue is DIDComm for peer-to-peer connections and Aries RFC 0454, Present Proof 2.0, for credential issuance and presentation, with Hyperledger Ursa providing zero-knowledge credentials so that a presentation can selectively disclose attributes. Storj's deletion flow—upload, share URL, and `uplink rm` with signed per-segment deletion confirmations from storage nodes—is the mechanism that gives the system its GDPR story.","core_discovery":"On its own terms, the paper establishes that self-sovereign identity and decentralized storage compose cleanly: Hyperledger Indy provides decentralized identifiers, verifiable credentials, and an auditable ledger; Hyperledger Aries and Aca-py handle DIDComm connections and the Present Proof 2.0 protocol; and Storj provides encrypted, sharded document storage with a deletion flow. The prototype demonstrates the full loop—upload document, receive URL, propose credential, validate document, issue credential, present credential, verify, delete, and audit—in geographically distributed cloud virtual machines, and reports that all interactive operations complete in well under a second. The authors also report modest resource use, roughly 16 KB of ledger and log data per credential request, about 40 percent CPU on the four ledger nodes and 36 percent on the Aries agent, and a per-entity monthly cloud cost around 50 euros, which they take as evidence that the approach is deployable in practice.","pith_inferences":["A natural next experiment is to instrument Storj storage nodes after `uplink rm` and verify that shards are actually unrecoverable; if they are, the same architecture could claim a stronger erasure guarantee than most decentralized storage offers.","The pattern could generalize beyond insurance documents to any sensitive artifact—medical images, diplomas, rental agreements—where selective disclosure of a credential could be paired with a shareable document URL.","Sub-second latencies suggest the flow could be embedded in ordinary web sign-up or onboarding journeys without users noticing the decentralized identity layer."],"forward_implications":["Issuers and service providers can validate documents and credentials without operating a central identity database, shifting trust from a single party to a transparent ledger.","Because document storage is encrypted and fragmented across Storj nodes, a compromise of one node does not reveal a complete document.","Credential issuance and presentation complete in 750 ms and 600 ms respectively, so the overhead is small enough for interactive user sessions.","Audit logs stored on the ledger are encrypted with a session key that only the user can decrypt, giving users verifiable records of their own activity without public exposure.","Deleting a document from Storj removes segment pointers and stops payments, giving users a concrete deletion mechanism aligned with GDPR's right to erasure."],"supporting_citations":[{"why":"Defines Storj's architecture (uplinks, satellites, storage nodes, sharding) that SoverClaim uses for encrypted document storage and deletion.","marker":"[21]"},{"why":"Security analysis of the Storj network that supports the choice of Storj as the decentralized document store.","marker":"[24]"},{"why":"Hyperledger Indy ledger that provides DIDs, verifiable credential records, and the transparent audit-log substrate.","marker":"[26]"},{"why":"Aca-py, the Aries Cloud Agent for Python, which implements the agents that handle connections and credential flows.","marker":"[29]"},{"why":"DIDComm protocol used for secure peer-to-peer communication between user, issuer, and service provider.","marker":"[33]"},{"why":"Aries RFC 0454 Present Proof 2.0, the standard protocol the prototype follows for issuing and presenting credentials.","marker":"[35]"}],"fun_headline_variants":["Decentralized identity and storage: claims in under 750 ms","SoverClaim: self-sovereign identity meets document storage","User-controlled identity and documents with built-in deletion","Fast claims: SSI and decentralized storage in one prototype","Putting users in charge of identity and document claims"],"cache_read_input_tokens":13056,"weakest_assumption_plain":"The privacy and GDPR claims depend on Storj's delete operation actually erasing the encrypted document shards from storage nodes, not merely removing pointers and stopping payments; the paper does not independently verify that erasure.","fun_headline_variants_meta":{"raw":{"variants":["Decentralized identity and storage: claims in under 750 ms","SoverClaim: self-sovereign identity meets document storage","User-controlled identity and documents with built-in deletion","Fast claims: SSI and decentralized storage in one prototype","Putting users in charge of identity and document claims"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000155,"raw_usage":{"total_tokens":1199,"prompt_tokens":915,"completion_tokens":284,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":531,"completion_tokens_details":{"reasoning_tokens":203}},"tokens_in":531,"tokens_out":284,"duration_ms":2937,"temperature":1.0,"reasoning_tokens":203,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-12T12:39:09.760810+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Go through the SoverClaim flow with a test file, run `uplink rm` on it, then retain or regain the segment pointers from the satellite or a node's signed deletion response and attempt to fetch and decrypt the shards from the storage nodes that held them. If any shard remains retrievable, or if the signed deletion confirmations do not correspond to actual erasure, the right-to-be-forgotten claim collapses even though credential issuance and presentation may still work.","supporting_citations":[{"cited_title":"Storj: A decentralized cloud storage network framework","cited_arxiv_id":null,"evidence_quote":"Defines Storj's architecture (uplinks, satellites, storage nodes, sharding) that SoverClaim uses for encrypted document storage and deletion."},{"cited_title":"Exploring the storj network: A security analysis","cited_arxiv_id":null,"evidence_quote":"Security analysis of the Storj network that supports the choice of Storj as the decentralized document store."},{"cited_title":"Hyperledger Indy 1.0 documentation","cited_arxiv_id":null,"evidence_quote":"Hyperledger Indy ledger that provides DIDs, verifiable credential records, and the transparent audit-log substrate."},{"cited_title":"Aca-py: A python implementation of the Aries Cloud Agent","cited_arxiv_id":null,"evidence_quote":"Aca-py, the Aries Cloud Agent for Python, which implements the agents that handle connections and credential flows."},{"cited_title":"Didcomm v2","cited_arxiv_id":null,"evidence_quote":"DIDComm protocol used for secure peer-to-peer communication between user, issuer, and service provider."},{"cited_title":"Present proof v2","cited_arxiv_id":null,"evidence_quote":"Aries RFC 0454 Present Proof 2.0, the standard protocol the prototype follows for issuing and presenting credentials."}],"review_version":1}