Decentralized Storage And Self-Sovereign Identity For Document-Based Claims

Bruno Gomes; David R. Matos; Miguel L. Pardal; Samih Eisa

REVIEW 2 major objections 6 minor 36 references

Decentralized Storage And Self-Sovereign Identity For Document-Based Claims

T0 review · 2 major / 6 minor · reviewed 2026-08-12 · deepseek-v4-flash

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

Pith's one-line read 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.

desk verdict Solid integration prototype of SSI + decentralized storage, but the deletion guarantee is overstated and the evaluation is thin. read the letter →

arxiv 2411.16987 v1 pith:VM22M4W6 submitted 2024-11-25 cs.CR cs.ET

Bruno Gomes , Samih Eisa , David R. Matos , Miguel L. Pardal This is my paper · ORCID

classification cs.CRcs.ET

keywords self-sovereignidentitydecentralizedstorageverifiablecredentialsHyperledgerIndyStorjdocument-basedclaimsGDPRrighttobeforgottenapplication

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

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.

What carries the argument

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.

What would settle it

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.

Watch

Extended reading notes

Core claim

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.

Load-bearing premise

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.

Editorial extensions

If this is right

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.

Reading between the lines

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

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.

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

Colleague,

The 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.

The 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.

The 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.

There'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.

Bottom 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.

Referee Report

2 major / 6 minor

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.

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 (2)

[Section 5.2 / Figure 6; Section 6] 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 5.2 / Figure 6] 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.

minor comments (6)

[Abstract] The abstract contains typos: 'may online services' should be 'many online services', and 'andStorj' should be 'and Storj'.
[Section 2.1] 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 4.1] The sentence about VON Network says it 'simplifies deployment and deployment'—the word 'deployment' is duplicated.
[Figure 6] 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 5.3] 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 4] 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.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: SoverClaim is an integration prototype whose claims rest on direct measurements and standard protocols, not on self-referential derivations.

full rationale

The paper does not derive any predictive result from fitted parameters, nor does it invoke a load-bearing self-citation chain. SoverClaim is presented as a prototype integrating Hyperledger Indy/Aries for self-sovereign identity and Storj for decentralized document storage. The central quantitative claims—credential issuance and presentation in less than 750 ms and 600 ms respectively (Section 6)—are direct latency measurements from the deployment described in Section 5.1, with a geographically distributed Google Cloud setup and Locust load generation. The suitability conclusion is an interpretation of those measurements, not a circular derivation. The privacy/GDPR contribution does depend on Storj's deletion mechanism (Section 4.5), and Section 2.3 concedes that decentralized storage makes complete data eradication impractical to guarantee; this is a correctness or validation gap about whether signed deletion acknowledgements imply physical erasure, not a circularity in the paper's evidence chain. No fitted value is renamed as a prediction, no uniqueness theorem from prior author work is imported, and no ansatz is smuggled via citation. The unusual editorial note in Section 2.1 ('it might be reasonable to omit their descriptions. However, in my opinion...') is stylistic and does not carry load-bearing argumentative weight. Therefore the appropriate circularity score is 0.

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

No free parameters are fitted in this engineering paper, and no new theoretical entities are proposed. The central claims rest on the documented behavior of third-party components (Storj, Hyperledger Indy/Aries) and on the representativeness of the measurement setup.

assumptions (4)

domain assumption Storj's deletion protocol (signed deletion agreements plus garbage collection) achieves actual erasure of document shards.
The privacy and GDPR case for SoverClaim depends on documents being deletable after claims processing. Section 4.5 describes the Storj delete flow, but the paper does not independently verify erasure, and Section 2.3 itself notes complete data eradication is impractical to guarantee in decentralized storage.
domain assumption Hyperledger Indy/Aries and Ursa provide the claimed SSI capabilities, including DIDs, verifiable credentials, and selective disclosure, as documented.
The prototype builds on these libraries without auditing their security or correctness; the assumption is invoked in Sections 4.1, 4.3, and 4.6.
domain assumption Latency measured on the described five-node Google Cloud deployment generalizes to real-world use.
Evaluation in Section 5.1 uses a private VON ledger and specific VM sizes, with no error bars or repetition counts reported, so representativeness is assumed rather than demonstrated.
ad hoc to paper A 750 ms response threshold is appropriate for 'timely human interactions'.
The conclusion in Section 6 applies this threshold without citing a usability benchmark or user study; the value is chosen by the authors.

how reviews work

0 comments

Cite this review

Pith. "Pith review of Decentralized Storage And Self-Sovereign Identity For Document-Based Claims." pith.science (2026). https://pith.science/paper/VM22M4W6

@misc{pith2026241116987,
  author       = {Pith},
  title        = {Pith review of: Decentralized Storage And Self-Sovereign Identity For Document-Based Claims},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/VM22M4W6}},
  note         = {Machine review of arXiv:2411.16987}
}

read the original abstract

Users increasingly rely on identity providers for accessing online services and resources. However, centralized identity systems often compromise user privacy due to online activity tracking or data breaches. At the same time, many online services require digital copies of physical documents for validation in claims processes, such as providing proof of residence for opening a bank account or verifying medical images for health insurance claims. With centralized solutions, privacy depends entirely on the trusted party, but there are emerging decentralized approaches that offer greater transparency. This article introduces SoverClaim, a decentralized application prototype that empowers users to control their identity and also allows them to present digital documents with privacy. SoverClaim leverages Hyperledger Indy, a blockchain for issuing and presenting self-sovereign digital identities with transparent audit logs, and Storj, a decentralized peer-to-peer service, for secure and decentralized document storage and subsequent deletion. The prototype demonstrates the seamless integration of self-sovereign identities and document-based claims, achieving response times of under 750 ms, making it suitable for timely human interactions.

Figures

Figures reproduced from arXiv: 2411.16987 by the authors.

**Figure 1.** illustrates the general architecture of an SSI management system: Issuer, User, and Service Provider. Issuer User Service provider Trust Relationship Issues claims Share proofs [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗

**Figure 2.** provides a collaboration diagram of SoverClaim in action along with their corresponding operation names. User issuer:Server serviceProvider:Server STORJ requestCredential(data + url) uploadDoc() deleteDoc() validateIdentity(url) issueCred() status() createCredential() Indy Ledger createDID() verifyCredential() presentCredential() shareDoc() urlDoc() auditLogs() auditLogs() createBucket() listDocs() resolveDID() reso… view at source ↗

**Figure 3.** SoverClaim deployment diagram. 4.1 Self-Sovereign Identity Blockchain The SSI blockchain chosen was Indy Ledger [26] due to its ability to create and use decentralized identities, compatible with W3C DID and VC standards. Indy operates as a permissioned blockchain and can securely record and validate transactions related to decentralized identities and provides transparent audit logs. There are several Hyperledger l… view at source ↗

Figures from the paper (5 more)

**Figure 4.** Figure 4: Issue credential protocol process. This process involves resolving the DIDs of both the user and the issuer to confirm their ownership and to validate the signatures of the verifiable credential. The verification result is then provided to the user, determining their a…

**Figure 5.** Figure 5: Present Credential protocol. 5 Evaluation For the evaluation, we set up a cloud infrastructure to conduct experiments aimed at answering the following questions: • Q1: How does SoverClaim perform when each component and entity of the system is geographically distribute…

**Figure 6.** Figure 6: Latency evaluation of different functionalities. [PITH_FULL_IMAGE:figures/full_fig_p010_6.png]

**Figure 7.** Figure 7: Processes by CPU percentage. In [PITH_FULL_IMAGE:figures/full_fig_p010_7.png]

**Figure 8.** Figure 8: Memory used by Issuer agent. 10 [PITH_FULL_IMAGE:figures/full_fig_p010_8.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

36 extracted references · 35 canonical work pages

[1]

An incident impacting some accounts and private information on twitter

Twitter. An incident impacting some accounts and private information on twitter. Twitter, 2022

work page 2022
[2]

Ireland fines facebook owner C265 million over data breach

Deutsche Welle. Ireland fines facebook owner C265 million over data breach. DW.com, 2022

work page 2022
[3]

Satybaldy, M

A. Satybaldy, M. Nowostawski, and J. Ellingsen. Self-sovereign identity systems: Evaluation framework. In M. Friedewald, M. Önen, E. Lievens, S. Krenn, and S. Fricker, editors, Privacy and Identity Management - Data for Better Living, pages 447–461. Springer, 2020

work page 2020
[4]

A survey on essential components of a self-sovereign identity

Alexander Mühle, Andreas Grüner, Tatiana Gayvoronskaya, and Christoph Meinel. A survey on essential components of a self-sovereign identity. Comput. Sci. Rev., 30:80–86, 2018

work page 2018
[5]

R. N. Zaeem, K. C. Chang, T. Huang, D. Liau, W. Song, A. Tyagi, M. Khalil, M. Lamison, S. Pandey, and K. S. Barber. Blockchain-based self-sovereign identity: Survey, requirements, use-cases, and comparative study. In IEEE/WIC/ACM International Conference on Web Intelligence, pages 128–135. ACM, 2021. 11 A PREPRINT - NOVEMBER 27, 2024

work page 2021
[6]

Article 17 - right to erasure (’right to be forgotten’)

GDPR Info. Article 17 - right to erasure (’right to be forgotten’). GDPR Info Website

work page
[7]

Ipfs and friends: A qualitative comparison of next generation peer-to-peer data networks

Erik Daniel and Florian Tschorsch. Ipfs and friends: A qualitative comparison of next generation peer-to-peer data networks. IEEE Communications Surveys & Tutorials, 24(1):31–52, 2022

work page 2022
[8]

Design aspects of decentralized identifiers and self-sovereign identity systems

Cristian Nicolae But,incu and Adrian Alexandrescu. Design aspects of decentralized identifiers and self-sovereign identity systems. IEEE Access, 12:60928–60942, 2024

work page 2024

Show all 36 references

[9]

Decentralized identifiers

W3C. Decentralized identifiers. https://w3c.github.io/did-core/
[10]

Verifiable credentials data model v1.1

W3C. Verifiable credentials data model v1.1. Available at: https://www.w3.org/TR/vc-data-model/
[11]

Zero knowledge proofs of identity

Uriel Fiege, Amos Fiat, and Adi Shamir. Zero knowledge proofs of identity. In Proceedings of the 19th Annual ACM Symposium on Theory of Computing, pages 210–217, 1987

1987
[12]

Singhal, G

B. Singhal, G. Dhameja, and P.S. Panda. Beginning Blockchain. Apress, Berkeley, CA, 2018

2018
[13]

Aponte-Novoa, A.L.S

F.A. Aponte-Novoa, A.L.S. Orozco, R. Villanueva-Polanco, and P. Wightman. The 51% attack on blockchains: A mining behavior study. IEEE Access, 9:140549–140564, 2021

2021
[14]

D. Reed, J. Law, and D. Hardman. The technical foundations of sovrin. Technical report, Sovrin Foundation, 2016

2016
[15]

Lundkvist, R

C. Lundkvist, R. Heck, J. Torstensson, Z. Mitton, and M. Sena. uport: A platform for self-sovereign identity. Technical report, Uport, 2016

2016
[16]

Dunphy and F.A.P

P. Dunphy and F.A.P. Petitcolas. A first look at identity management schemes on the blockchain. IEEE Security and Privacy, 16(4):20–29, 2018

2018
[17]

Civic token sale whitepaper

Civic. Civic token sale whitepaper. Retrieved from https://tokensale.civic.com/ CivicTokenSaleWhitePaper.pdf
[18]

A review on scalability of blockchain

Di Yang, Chengnian Long, Han Xu, and Shaoliang Peng. A review on scalability of blockchain. In Proceedings of the 2020 2nd International Conference on Blockchain Technology, pages 1–6, 2020

2020
[19]

IPFS - Content Addressed, Versioned, P2P File System

Juan Benet. IPFS - Content Addressed, Versioned, P2P File System. arXiv, 2014. arXiv:1407.3561 [cs]

2014 arXiv
[20]

Filecoin: A decentralized storage network

Protocol Labs. Filecoin: A decentralized storage network. Available at:https://filecoin.io/filecoin.pdf, 2017

2017
[21]

Storj: A decentralized cloud storage network framework

Storj Labs, Inc. Storj: A decentralized cloud storage network framework. Technical report, Storj, 2018

2018
[22]

Kapusta and G

K. Kapusta and G. Memmi. Data protection by means of fragmentation in various different distributed storage systems - a survey. Technical report, Télécom ParisTech Université Paris-Saclay, LTCI, 2017

2017
[23]

Reardon, D

J. Reardon, D. Basin, and S. Capkun. On secure data deletion. IEEE Security and Privacy, 12(3):37–44, 2014

2014
[24]

Exploring the storj network: A security analysis

Sammy de Figueiredo, Akash Madhusudan, Vincent Reniers, Svetla Nikova, and Bart Preneel. Exploring the storj network: A security analysis. In Proceedings of the 36th Annual ACM Symposium on Applied Computing, pages 257–264, 2021

2021
[25]

A survey on blockchain-based self-sovereign patient identity in healthcare

Bahar Houtan, Abdelhakim Senhaji Hafid, and Dimitrios Makrakis. A survey on blockchain-based self-sovereign patient identity in healthcare. IEEE Access, 8:90478–90494, 2020

2020
[26]

Hyperledger Indy 1.0 documentation

Hyperledger Indy. Hyperledger Indy 1.0 documentation. Available at: https://indy.readthedocs.io/en/ latest/
[27]

VON Network

BC Government. VON Network. https://github.com/bcgov/von-network
[28]

Python: A programming language

Python. Python: A programming language. Available at: https://www.python.org/
[29]

Aca-py: A python implementation of the Aries Cloud Agent

ACA-Py. Aca-py: A python implementation of the Aries Cloud Agent. Available at: https://github.com/ hyperledger/aries-cloudagent-python
[30]

Flask: A python web framework

Flask. Flask: A python web framework. Available at: https://flask.palletsprojects.com/
[31]

Sovrin foundation did method specification

Sovrin Foundation. Sovrin foundation did method specification. Available at: https://sovrin-foundation. github.io/sovrin/spec/did-method-spec-template.html
[32]

Did method: Key

W3C Credentials Community Group. Did method: Key. Available at: https://w3c-ccg.github.io/ did-method-key/
[33]

Didcomm v2

Hyperledger Aries RFCs. Didcomm v2. Available at: https://github.com/hyperledger/aries-rfcs/ blob/main/concepts/0005-didcomm/README.md
[34]

Prerequisites for using uplink cli, 2023

Storj. Prerequisites for using uplink cli, 2023

2023
[35]

Present proof v2

Hyperledger Aries RFCs. Present proof v2. Available at: https://github.com/hyperledger/aries-rfcs/ blob/main/features/0454-present-proof-v2/README.md
[36]

Locust: Scalable load testing framework

Locust Development Team. Locust: Scalable load testing framework. https://locust.io/. 12

Pith tools

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

[1] [1]

An incident impacting some accounts and private information on twitter

Twitter. An incident impacting some accounts and private information on twitter. Twitter, 2022

work page 2022

[2] [2]

Ireland fines facebook owner C265 million over data breach

Deutsche Welle. Ireland fines facebook owner C265 million over data breach. DW.com, 2022

work page 2022

[3] [3]

Satybaldy, M

A. Satybaldy, M. Nowostawski, and J. Ellingsen. Self-sovereign identity systems: Evaluation framework. In M. Friedewald, M. Önen, E. Lievens, S. Krenn, and S. Fricker, editors, Privacy and Identity Management - Data for Better Living, pages 447–461. Springer, 2020

work page 2020

[4] [4]

A survey on essential components of a self-sovereign identity

Alexander Mühle, Andreas Grüner, Tatiana Gayvoronskaya, and Christoph Meinel. A survey on essential components of a self-sovereign identity. Comput. Sci. Rev., 30:80–86, 2018

work page 2018

[5] [5]

R. N. Zaeem, K. C. Chang, T. Huang, D. Liau, W. Song, A. Tyagi, M. Khalil, M. Lamison, S. Pandey, and K. S. Barber. Blockchain-based self-sovereign identity: Survey, requirements, use-cases, and comparative study. In IEEE/WIC/ACM International Conference on Web Intelligence, pages 128–135. ACM, 2021. 11 A PREPRINT - NOVEMBER 27, 2024

work page 2021

[6] [6]

Article 17 - right to erasure (’right to be forgotten’)

GDPR Info. Article 17 - right to erasure (’right to be forgotten’). GDPR Info Website

work page

[7] [7]

Ipfs and friends: A qualitative comparison of next generation peer-to-peer data networks

Erik Daniel and Florian Tschorsch. Ipfs and friends: A qualitative comparison of next generation peer-to-peer data networks. IEEE Communications Surveys & Tutorials, 24(1):31–52, 2022

work page 2022

[8] [8]

Design aspects of decentralized identifiers and self-sovereign identity systems

Cristian Nicolae But,incu and Adrian Alexandrescu. Design aspects of decentralized identifiers and self-sovereign identity systems. IEEE Access, 12:60928–60942, 2024

work page 2024