{"id":"7d3d6a1a-efc1-4528-9e92-2dc3f5e8450b","arxiv_id":"2501.12229","paper_version":1,"verdict":"CONDITIONAL","confidence":"HIGH","novelty_score":4.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"A patient-centric health data framework using self-sovereign identity and blockchain, with backup, revocation and emergency functions, but only basic flows are implemented in the proof of concept.","lead":"This paper proposes an open-source framework that lets patients store and control their electronic health records on their own devices, using self-sovereign identity and blockchain. It adds recovery, revocation, and emergency-access functions that many earlier designs lack, and reports a proof-of-concept test between a patient and a doctor.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The feasibility claim rests on the unvalidated recovery/emergency functions, whose design gives the MSP both a key share and control of the audit trail; Section 7's acknowledgment does not repair the gap.","rationale":"The reader's verdict is CONDITIONAL, and my read does not move it. The paper is a plausible architecture description with a working basic exchange flow, so REJECT would be too harsh; but the complete-framework feasibility claim is not supported because the novel functions are not implemented and the one function most central to the paper's contribution—emergency access and recovery—depends on a single MSP that both holds a key share and writes the audit record. The reader's weakest assumption correctly identifies the CA/MSP root of trust; my concern sharpens it by noting that the undefined 'split in half' procedure and the absence of any independent audit verifier make the failure mode concrete rather than hypothetical. The authors explicitly acknowledge the CA/MSP limitation in Section 7, but an acknowledged limitation is still a limitation: for an SSI claim, a root of trust that can decrypt backups is material. The concrete test would settle whether the emergency loop can be abused undetected; until then, the verdict should remain CONDITIONAL with the condition being an implemented and independently audited recovery/emergency mechanism.","tokens_in":21344,"tokens_out":5535,"duration_ms":60572,"concrete_test":"Implement the §4.3.1/§4.3.4 recovery and emergency flows in the PoC with a concrete key-splitting scheme (e.g., Shamir 2-of-n), a cloud-agent backup, and a malicious MSP adversary. Run the emergency loop against a conscious, non-consenting patient; if the MSP can obtain the second share from a contact, decrypt the backup, and write or delete an audit entry without detection by any independent verifier, the emergency design fails its own security premise. If instead an independent observer (e.g., a patient-side notification plus an append-only log written by a different organization) detects the loop, the concern is answered.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The paper's central claim—that the PoC validates a complete, decentralized SSI framework (Sections 4–5)—is only supported for the basic identity/credential-exchange flow. Section 5.2 states that the implemented and tested functionality is registration, connection, and VC exchange; wallet recovery (§4.3.1), data-access revocation (§4.3.2), VC revocation (§4.3.3), and emergency access (§4.3.4) are specified but not implemented. The most load-bearing gap is the recovery/emergency design itself. In §4.3.1 the MSP receives half of the backup private key; in §4.3.4 the same MSP initiates the emergency loop that collects the other half from trusted contacts, decrypts the patient's cloud backup, and writes the audit record that is supposed to deter abuse. A malicious or compromised MSP can therefore request the second half for any patient whose contacts respond, decrypt the backup, and forge or omit the audit entry because no independent party is specified to verify the 'special security channel.' Section 7 acknowledges that a malicious CA or MSP compromises the whole framework, but that admission conflicts with the paper's stated goal of decentralization and 'no central authorities' (Section 1), and it does not mitigate the fact that the central feasibility claim depends on exactly this unvalidated trust anchor. In addition, the 'split in half' key-recovery protocol is unspecified, so the claimed threshold property cannot be checked. This is a support gap, not a consensus disagreement.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes a self-sovereign identity (SSI) framework for electronic health record access, with patient data stored on personal devices, a permissioned Hyperledger Fabric blockchain as a verifiable data registry, and Veramo/DIDComm-based wallets for authentication and credential exchange. Beyond the basic patient-practitioner-laboratory workflow, the design includes four additional functions: wallet recovery, health data access revocation, verifiable credential revocation, and an emergency access loop. A proof of concept (PoC) implements and tests the basic registration, pairwise connection, and verifiable credential exchange flow, and performance measurements of these baseline operations are reported. The authors claim that the PoC validates the feasibility of the overall framework and that the design is more complete than prior work.","tokens_in":21590,"tokens_out":3407,"duration_ms":36047,"significance":"If the design were fully implemented and its trust assumptions made explicit, the paper would make a useful contribution: it assembles relevant standards (W3C DIDs, VCs, DIDComm) into a coherent architecture, provides an open-source code repository [15], gives a structured comparison with related work (Table 1), and reports a reproducible 10,000-operation performance benchmark for the baseline flows. However, the significance as presented is limited because the four claimed novel functions—recovery, data-access revocation, VC revocation, and emergency access—are specified but not implemented or measured, and the security of the recovery/emergency mechanism hinges on a single trusted authority (the MSP) whose compromise is acknowledged in Section 7 to break the whole framework. The paper's central feasibility claim therefore goes beyond what the evidence supports.","major_comments":[{"comment":"The PoC implements only registration, pairwise connection, and VC exchange: Section 5.2 explicitly says \"These are all the design functionalities that we have implemented and tested,\" listing no implementation of wallet recovery (§4.3.1), health data access revocation (§4.3.2), VC revocation (§4.3.3), or the emergency loop (§4.3.4). The abstract and Section 8 nevertheless state that the design is validated and that a PoC was used to validate the proposed framework. The feasibility of the complete framework is therefore not established by the reported experiments. The authors should either implement and test the four additional functions or substantially narrow the claims to a design specification with an initial PoC covering only the baseline interaction.","section":"Sections 5.2 and 8"},{"comment":"The recovery and emergency design places the MSP in a position to defeat the stated security goal. In §4.3.1 the patient sends one half of the backup private key to the MSP; in §4.3.4 the same MSP initiates the emergency loop, collects the other half from trusted contacts, decrypts the cloud backup, and writes the audit record that is supposed to deter abuse. A malicious or compromised MSP can request the second half for any patient whose contacts respond, access the decrypted data, and forge or omit the audit entry, since no independent party is specified to verify the \"special security channel\" record. Section 7 acknowledges that a malicious CA or MSP compromises the whole framework, but this contradicts the Section 1 claim that the framework \"requires no central authorities,\" and it leaves the central feasibility claim dependent on exactly this unvalidated trust anchor. The authors should provide a concrete threat model, state the trust assumptions explicitly, and either redesign the protocol to avoid a single party controlling both a key share and the audit trail or justify why the centralized root of trust is acceptable for the claimed decentralized design.","section":"Sections 4.3.1, 4.3.4, and 7"},{"comment":"The VC revocation mechanism is described only at a high level: the revocation registry is said to be an accumulator, and the text promises \"In Section 5, we will explain the technology used to implement this non-revocation proof.\" Section 5 contains no such explanation and no implementation of a revocation registry. Since VC revocation is one of the four claimed novel functions and is central to the framework's access-control story, the paper should either provide the cryptographic construction and its implementation/test results or explicitly move this function to future work.","section":"Section 4.3.3"},{"comment":"The performance evaluation covers only the baseline operations (DID/VC creation, verification, DIDComm messaging, and the DID read/write chaincode). None of the four additional functions is benchmarked, so the concluding statement that the framework \"could be used with a high number of users\" is not supported for the complete design. In particular, the emergency loop and VC revocation update both involve additional blockchain writes and communication with third parties, which may have substantially different latency profiles than the measured \"Write DID\" operation. The authors should either benchmark these functions or restrict the scalability claim to the implemented subsystem.","section":"Section 6"}],"minor_comments":[{"comment":"The phrase \"as we will present in the following subsections\" appears twice; one occurrence is grammatically disconnected and should be revised.","section":"Section 4.1.1"},{"comment":"There is a typo in \"monitoring and auditing all actions perfoemd\" — it should read \"performed.\"","section":"Section 4.3.4"},{"comment":"The word \"imprative\" should be \"imperative.\"","section":"Section 7"},{"comment":"The paragraph beginning \"These are all the design functionalities that we have implemented and tested\" is in tension with the immediately preceding sentence that the PoC \"covers only certain aspects\" of the design. The authors should clarify which functionalities were implemented and which were only designed, without mixed wording.","section":"Section 5.2"},{"comment":"The figure reports average times without standard deviations or percentile information; adding these would make the performance claims more robust and reproducible.","section":"Figure 11"}],"recommendation":"major_revision","confidential_remarks":"The manuscript is better framed as a design proposal with an initial prototype than as a validated complete framework. If the authors implement and evaluate the four additional functions, or explicitly narrow the contribution to the baseline SSI healthcare flow and reposition the other functions as future work, the paper could become acceptable for a journal publication. The trust-model issue in Sections 4.3.1/4.3.4 is the most substantive technical gap and should be addressed before resubmission."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Read this one knowing two things. The contribution is an integrated SSI framework for EHR access that combines patient-held storage, social recovery, emergency override, data-access revocation, and VC revocation in a single design, using Hyperledger Fabric rather than Indy, with open-source PoC code. That combination is genuinely absent from prior work, and Table 1 supports it. The paper is clearly written and the architecture is coherent.\n\nThe problem is the gap between design and validation. The PoC implements and tests only registration, pairwise connection, and VC exchange. Wallet recovery, data-access revocation, VC revocation, and the emergency loop are specified but not built. Section 5.2 says so plainly. The strongest claim—that the framework's feasibility is validated—is therefore only true for the basic identity flow.\n\nThe emergency/recovery design is the softest spot. The MSP holds half the backup private key, initiates the emergency loop that collects the other half from contacts, decrypts the backup, and writes the audit record intended to deter abuse. A compromised MSP can request the second half, decrypt, and forge or omit the audit trail, since no independent verifier is specified. Section 7 admits a malicious CA/MSP compromises the whole framework, but that tension with the paper's 'no central authorities' framing is not resolved. The 'split in half' protocol is described without enough detail to check the claimed threshold property.\n\nPerformance numbers exist, but they are averages over 10,000 operations with no variance or confidence intervals, and the Fabric write test is a benchmark, not the actual chaincode under realistic load. The sub-100ms conclusions are plausible but not rigorously supported.\n\nThis is a support gap, not a fatal flaw. The authors are honest about limitations, the related work is well handled, and the open-source code gives future work a starting point. I'd send it to a serious referee, expecting major revision: re-scope the claims to what the PoC actually shows, specify the recovery protocol, and address the MSP trust anchor directly.","headline":"A clearly written integration of existing SSI building blocks for healthcare, but the novel functions are specified rather than validated, and the emergency/recovery loop leans on a centralized trust anchor.","tokens_in":22165,"tokens_out":2072,"would_cite":true,"duration_ms":19948,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":null,"created_at":"2026-08-10T17:21:55.452171+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":null,"supporting_citations":[],"review_version":1}