Pith. sign in

REVIEW 4 major objections 5 minor 68 references

A Systematic Review and Layered Framework for Privacy-by-Design in Self-Sovereign Identity Systems

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

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

Pith's one-line read A four-layer framework maps self-sovereign identity components to privacy classes, giving architects a way to predict a stack's privacy before building it.

desk verdict A genuinely useful SSI survey with a dashboard that can't yet do what it promises: the component reviews are solid, but the privacy classes have no composition rule and the worked examples contradict the paper's own weakest-link principle. read the letter →

arxiv 2502.02520 v2 pith:O5AZ6KFO submitted 2025-02-04 cs.ET cs.CYcs.SE

Montassar Naghmouchi , Maryline Laurent This is my paper · ORCID
classification cs.ETcs.CYcs.SE
keywords self-sovereignidentityprivacybydesignfour-layerframeworkassistancedashboardverifiablecredentialsdecentralizedidentifierswalletclasses
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 tries to establish that the privacy of a self-sovereign identity (SSI) system can be analyzed and engineered by mapping its components onto four functional layers—infrastructure, identifiers and cryptographic material, credentials and presentations, and wallet applications—and by rating each component's privacy contribution as low, medium, or good. The authors argue that because privacy is compositional across these layers, a designer can use the accompanying Design Assistance Dashboard (DAD) to trace dependencies between components, spot privacy conflicts, and assemble a component stack with a predictable overall privacy level. If this is right, architects of SSI systems—who today face many competing choices for identifiers, credentials, and wallet designs—gain a practical tool for privacy-by-design before any code is written.

What carries the argument

The load-bearing mechanism is the four-layer privacy model plus the compositionality assumption attached to it. The layers are infrastructure (blockchain or web-based registries), identifiers and cryptographic material (DID methods, link secrets, resolvers), credentials and presentations (JSON/JWT, CL-based anonymous credentials, JSON-LD with BBS+ signatures, and revocation schemes), and wallet applications (edge and cloud agents, DID-Comm and DID-Auth protocols). Privacy requirements are mapped to each layer, and the framework asserts that privacy leaks in any one layer compromise the whole, while a privacy property satisfied in one layer is inherited by the layers above. DAD operationalizes this by linking components across layers into a design graph and colour-coding each component's privacy class, so a designer can see at a glance whether a proposed stack is consistent and how private it is likely to be.

What would settle it

Build two SSI architectures that DAD rates equally (say, all green components) but differ in one cross-layer interaction, such as a public DID used by the issuer combined with an anonymous holder credential, and run a formal privacy analysis (e.g., an unlinkability game or correlation attack) on both; if the two stacks have measurably different privacy despite identical DAD ratings, the privacy classes do not predict composite privacy.

Watch

Extended reading notes

Core claim

The central claim is that SSI privacy can be treated as a layered design problem rather than a property of any single technology. The paper reviews the main SSI building blocks—decentralized identifiers and their resolution methods, credential formats and signature schemes, revocation mechanisms, and wallet architectures—and organizes them into a four-layer model. For each component it derives a set of privacy considerations from regulation, standards, and community practice, and then assigns a simplified privacy class (low, medium, or good) indicating how well the component satisfies the privacy requirements mapped to its layer. The Design Assistance Dashboard (DAD) combines these ratings with a design graph that shows which components depend on which, so that selecting a component in one layer forces compatible choices in other layers. The paper demonstrates the framework on two use cases—a public university diploma system and a health credential system—and claims the resulting paths provide a quick assessment of the privacy of a proposed SSI architecture.

Load-bearing premise

The load-bearing premise is that privacy is compositional: each component can be assigned a privacy class on its own, and stacking components preserves the weakest layer's privacy—an assumption the paper states but does not test.

Editorial extensions

If this is right

  • An SSI architect can compare competing component stacks for privacy before implementation, rather than after deployment.
  • DAD can flag cross-layer conflicts, such as a public blockchain identifier that undermines the pseudonymity an anonymous credential scheme is supposed to provide.
  • The framework gives regulators and wallet providers a checklist for privacy-by-design, since privacy requirements are enumerated layer by layer.
  • The low/medium/good ratings can serve as a rough cost–benefit guide: components that provide good privacy (e.g., selective-disclosure credential schemes) are often the ones with higher computational cost.
  • The dashboard can be extended to automatically calculate an overall privacy score once more detailed metrics are defined, as the authors state is their next step.

Reading between the lines

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

  • The compositionality assumption is empirically testable: one could build several SSI stacks that DAD rates identically and run formal unlinkability or correlation attacks on them; if the measured privacy diverges from the ratings, the privacy classes need recalibration.
  • If the privacy classes are not validated across independent raters, two designers may read the same dashboard differently; a structured inter-rater reliability study would show whether the ratings are reproducible.
  • The layer separation suggests a modular certification scheme: each component could be certified for privacy at its layer, and the compositionality claim could underpin a system-level guarantee—an idea the paper leaves implicit.
  • DAD's decomposition into infrastructure, identifiers, credentials, and applications is not SSI-specific and could be carried over to federated or user-centric identity systems as a privacy analysis template.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

4 major / 5 minor

Summary. The paper presents a layered privacy framework for self-sovereign identity (SSI) systems, organizing SSI components into four layers: Infrastructure, Identifiers & Cryptographic Material, Credentials & Presentations, and Wallet Applications. It reviews standards, open-source implementations, and industry data, then introduces a Design Assistance Dashboard (DAD) that maps components across layers, shows dependencies, and assigns each component a simple privacy class (low/medium/good). Two worked examples (a public university diploma system and a verifiable health credential system) illustrate the intended step-by-step design process. The authors position the contribution as a systematic mapping and review that supports privacy-aware architectural choices in SSI design.

Significance. If the framework and DAD are reliable, the paper would fill a real gap: existing SSI layered models (ToIP, DIF mappings, Yildiz) focus on interoperability and governance rather than a component-level privacy analysis. The survey itself is broad and grounded in primary sources: W3C DID/VC specifications, Hyperledger Indy/Aries/AnonCreds, the CheckD vendor survey, and several wallet implementations. The paper also gives useful qualitative comparisons (e.g., JSON vs. JSON-LD credentials, revocation methods, DID resolution privacy) and explicitly flags trade-offs such as the scalability limitations of AnonCreds. In addition, the authors are transparent about the limitations of DAD, stating in Section 10 that an overall privacy score with better-defined metrics is future work. However, the central design-aid claim rests on the validity of the privacy classes and on a composition rule for combining them across layers; neither is established in the manuscript.

major comments (4)
  1. [Section 3.2 and Section 9.2] The paper states two compositionality principles that are in tension: 'the slightest lack of privacy in one layer calls into question the privacy of the whole' (weakest-link reading) and 'a privacy requirement satisfied in one given layer becomes an inherited feature for other layers' (upward propagation). No aggregation rule is provided that reconciles these, and Section 9.1 explicitly assigns only component-level classes. The worked examples expose the missing rule: in Case B, the selected components include 'Blockchain with medium privacy' and 'did:indy with medium privacy,' yet step 7 concludes the path 'creates a system that prioritizes the privacy, control and unlinkability of the holder' with 'a high level of privacy.' Under the stated weakest-link principle, the system-level class should be at most medium. Without an explicit composition function, the claimed ability to choose a stack with a predictable privacy level is not demonstrated.
  2. [Section 9.1 and Methodology (Section 2)] The low/medium/good privacy classes are assigned to each component without a scoring rubric, inter-rater validation, or sensitivity analysis. The methodology describes a multi-source review, but the mapping from qualitative evidence to a three-level class is not protocolized; the reader cannot reproduce the ratings or assess their robustness. This matters because the DAD's usefulness depends on these classes being meaningful and stable. The paper should either provide a transparent rubric (which privacy requirements are weighted, how conflicting evidence is resolved) or reframe DAD as an illustrative visualization rather than a decision-support tool.
  3. [Section 2 and Section 9.1] The paper claims a 'systematic mapping and review,' but the component selection criteria are not fully protocolized. The methodology lists sources (standards, open-source implementations, industry data) but does not specify inclusion/exclusion rules, search terms, or a repeatable selection process. The DAD dependencies between components are similarly presented as expert judgment without a documented derivation. For a paper whose contribution is explicitly a systematic review, the absence of a reproducible protocol weakens the central claim; at minimum, the authors should state that the review is systematic in the sense of a structured expert survey, not a formal systematic literature review.
  4. [Section 10] The authors themselves concede the main limitation: 'potentially calculating an overall privacy score with better-defined metrics, rather than using three classes (good, medium, bad)' is future work. This is consistent with my reading that the current DAD does not yet deliver a computable privacy assessment. The claim in the abstract that the DAD 'maps these components to different privacy requirements and considerations' is fair, but the stronger claim that it enables a designer to 'make an informed choice for a SSI solution that satisfies the need for privacy' needs a composition rule and validation to be substantiated.
minor comments (5)
  1. [References] The citation 'cited in checkD-survey' in Section 2 does not correspond to a numbered reference; the CheckD survey is later cited as [35], so the in-text citation should be updated for consistency.
  2. [Section 7.1.2] There is a typo in 'credentia1ls' (Section 7.1.2) that should be corrected to 'credentials.'
  3. [Section 3 and Figure 1] Figure 1 and Figure 2 are referenced but not described in the text in enough detail for a reader to interpret the layered model without flipping back and forth; consider adding a short caption-level explanation of the color coding and arrows.
  4. [Section 9.2, Case A] Case A step 5 states that the cloud agent stores credentials and performs key generation, but Section 8.2 notes that such a design reduces user control; the trade-off is acknowledged but not linked to the privacy class of the 'cloud agent' component, which would help illustrate how DAD handles wallet architecture choices.
  5. [Appendix B] The table in Appendix B is informative but dense; aligning the columns (e.g., for did:ethr and did:key) would improve readability.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the DAD is an explicit synthesis of the paper's own qualitative review; there are no fitted values, no self-citation chain, and no derivation that reduces to its inputs.

full rationale

The paper is a systematic mapping and review (Section 2, Phase 1) whose DAD is explicitly a visualization of that review. Section 9.1 says the privacy indicator is 'a simplified privacy rating based on our analysis and review provided for each component in Phase 1', and Section 2 says 'DAD builds on the previous layered model' and is 'a graphical representation of our SSI review process'. No quantity is fitted to data, no prediction is tested against a held-out set, and no load-bearing argument rests on a self-citation; the reference list contains no prior papers by the same authors. The Section 3.2 compositionality statements are ambiguous and the Section 9.2 worked examples do not follow a defined aggregation rule, but those are validity and utility limitations, not circularity: the paper makes no formal claim to compute a system-level privacy score and explicitly defers 'an overall privacy score with better-defined metrics' to future work. The DAD classes are the authors' qualitative judgments, which is a reproducibility limitation, not a derivation equivalent to its own inputs.

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

The central framework has no numerical free parameters or invented physical entities. It rests on the analytical taxonomy, the assumption that privacy properties compose across layers, the validity of the authors' qualitative privacy classes, and the accuracy of the cited standards and implementations. These are domain assumptions, not standard mathematical axioms.

assumptions (4)
  • domain assumption SSI components can be cleanly separated into four layers plus an identifier-resolution sub-layer.
    The entire framework depends on this taxonomy, introduced in Section 3.1 and contrasted with ToIP/Yildiz in Section 4; the boundaries are analytical choices, not formal necessity.
  • domain assumption Privacy is compositional across layers and components.
    Section 3.2 states that lack of privacy in one layer calls into question privacy of the whole and that layer-level privacy becomes inherited; the DAD relies on this inheritance assumption.
  • ad hoc to paper The low/medium/good privacy classes assigned to components are valid and useful.
    Section 9.1 defines these levels based on the authors' review, without inter-rater reliability, independent validation, or a scoring rubric.
  • domain assumption The surveyed standards and implementations (W3C DID/VC, AnonCreds, BBS+, Hyperledger stacks) are accurately represented.
    The review's factual comparisons in Sections 5 through 8 rest on these external sources, which are cited but not independently re-derived.

how reviews work

0 comments
Cite this review

Pith. "Pith review of A Systematic Review and Layered Framework for Privacy-by-Design in Self-Sovereign Identity Systems." pith.science (2026). https://pith.science/paper/O5AZ6KFO

@misc{pith2026250202520,
  author       = {Pith},
  title        = {Pith review of: A Systematic Review and Layered Framework for Privacy-by-Design in Self-Sovereign Identity Systems},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/O5AZ6KFO}},
  note         = {Machine review of arXiv:2502.02520}
}
read the original abstract

The use of Self-Sovereign Identity (SSI) systems for digital identity management is gaining traction and interest. Countries such as Bhutan have already implemented an SSI infrastructure to manage the identity of their citizens. The EU, thanks to the revised eIDAS regulation, is opening the door for SSI vendors to develop SSI systems for the planned EU digital identity wallet. These developments, which fall within the sovereign domain, raise questions about individual privacy. The design of SSI systems is complex, often characterized by a large number of components and architectural choices because the current SSI communities differ on how to create identifiers, how to build and present credentials, and even how to design a user wallet. SSI stacks developed by different organizations provide different privacy features for different privacy needs. This paper performs a systematic mapping and review of SSI components and technologies into a novel four-layer privacy framework to address the design complexity of SSI systems. Based on this review, we provide an accompanying Design Assistance Dashboard (DAD). The DAD shows the interdependencies between SSI components in different layers, and maps these components to different privacy requirements and considerations, even providing a simple privacy class for each component.

Figures

Figures reproduced from arXiv: 2502.02520 by the authors.

Figure 1
Figure 1. The SSI system model and architecture. 3.1 SSI Systems As shown in [PITH_FULL_IMAGE:figures/full_fig_p004_1.png] view at source ↗
Figure 2
Figure 2. Mapping privacy properties to each SSI layer. [PITH_FULL_IMAGE:figures/full_fig_p007_2.png] view at source ↗
Figure 3
Figure 3. Responses from 37 SSI vendors on DID methods supported by their products [source: CheckD survey [ [PITH_FULL_IMAGE:figures/full_fig_p012_3.png] view at source ↗
Figures from the paper (6 more)
Figure 4
Figure 4. Figure 4: Most used Verifiable Credential schemes [source: CheckD survey [ [PITH_FULL_IMAGE:figures/full_fig_p014_4.png]
Figure 5
Figure 5. Figure 5: A cold wallet with an online component re [PITH_FULL_IMAGE:figures/full_fig_p021_5.png]
Figure 7
Figure 7. Figure 7: Spectral representation of wallet applications, from fully cold wallets to fully hot wallets. [PITH_FULL_IMAGE:figures/full_fig_p022_7.png]
Figure 8
Figure 8. Figure 8: Overview of DID-Comm flow, with highlighted security and privacy crucial points for the protocol. [PITH_FULL_IMAGE:figures/full_fig_p025_8.png]
Figure 9
Figure 9. Figure 9: SSI design assistance dashboard with two example design paths (in blue and green). [PITH_FULL_IMAGE:figures/full_fig_p026_9.png]
Figure 10
Figure 10. Figure 10: A step-by-step flowchart for applying DAD to SSI design. [PITH_FULL_IMAGE:figures/full_fig_p027_10.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

68 extracted references · 67 canonical work pages

  1. [1]

    A Taxonomic Approach to Understanding Emerging Blockchain Identity Management Systems

    Lesavre, L., Varin, P., Mell, P., Davidson, M. & Shook, J. A Taxonomic Approach to Understanding Emerging Blockchain Identity Management Systems. CoRR. abs/1908.00929 (2019), http://arxiv.org/abs/1908.00929

    work page Pith review arXiv 2019

  2. [2]

    Submission Request to W3C: FIDO 2.0 Platform Specifications 1.0

    “Submission Request to W3C: FIDO 2.0 Platform Specifications 1.0..” https://www.w3.org/submissions /2015/02/, November 2015

    work page 2015

  3. [3]

    W3C World Wide Web Consortium

    “W3C World Wide Web Consortium..” https://www.w3.org/. [Accessed 27-01-2025]

    work page 2025

  4. [4]

    DIF Decentralized Identity Foundation

    “DIF Decentralized Identity Foundation..” https://identity.foundation/. [Accessed 27-01-2025]

    work page 2025

  5. [5]

    Bhutan to be the first country in the world to use self-sovereign identity (SSI) and blockchain technol- ogy

    M. Rai, “Bhutan to be the first country in the world to use self-sovereign identity (SSI) and blockchain technol- ogy..” https://thebhutanese.bt/bhutan-to-be-the-first-country-in-the-world-to-use-sel f-sovereign-identity-ssi-and-block-chain-technology/ . [Accessed 23-01-2025]

    work page 2025

  6. [6]

    Korean DID Alliance, consortium to create an SSI system for Korea

    “Korean DID Alliance, consortium to create an SSI system for Korea..” https://www.didalliance.org/ . [Accessed 23-01-2025]

    work page 2025

  7. [7]

    [Accessed 23-01- 2025]

    “Regulation (eu) no 910/2014 of the european parliament and of the council of 23 july 2014 on electronic iden- tification and trust services for electronic transactions in the internal market and repealing directive 1999/93/ec.” https://digital-strategy.ec.europa.eu/en/policies/eidas-regulation . [Accessed 23-01- 2025]

    work page 2014

  8. [8]

    EUROPEAN SELF-SOVEREIGN IDENTITY FRAMEWORK LAB

    “EUROPEAN SELF-SOVEREIGN IDENTITY FRAMEWORK LAB..” https://essif-lab.eu/ . [Ac- cessed 23-01-2025]

    work page 2025

Show all 68 references
  1. [9]

    European Blockchain Services Infrastructure

    “European Blockchain Services Infrastructure..” https://ec.europa.eu/digital-building-blocks/si tes/display/EBSI/Home. [Accessed 23-01-2025]

    2025

  2. [10]

    DID res- olution algorithm

    Manu Sporny, Dave Longley, Markus Sabadello, Drummond Reed, Orie Steele, Christopher Allen., “DID res- olution algorithm.” https://www.w3.org/TR/did-core/#resolution. [Accessed 23-01-2025]

    2025

  3. [11]

    Pairwise DID or the did:peer method

    O. Deventer et al., “Pairwise DID or the did:peer method..” https://identity.foundation/peer-did-m ethod-spec/#term:pairwise. [Accessed 23-01-2025]

    2025

  4. [12]

    A signature scheme with efficient protocols,

    J. Camenisch and A. Lysyanskaya, “A signature scheme with efficient protocols,” inSecurity in Communication Networks (S. Cimato, G. Persiano, and C. Galdi, eds.), (Berlin, Heidelberg), pp. 268–289, Springer Berlin Heidelberg, 2003

    2003

  5. [13]

    Decentralized Identity Foundation (DIF) - BBS+ Signatures scheme on Github

    Greg Bernstein and Manu Sporny, “Decentralized Identity Foundation (DIF) - BBS+ Signatures scheme on Github..” https://github.com/decentralized-identity/bbs-signature. [Accessed 23-01-2025]

    2025

  6. [14]

    Zero knowledge proofs of identity,

    U. Fiege, A. Fiat, and A. Shamir, “Zero knowledge proofs of identity,” STOC ’87, (New York, NY , USA), p. 210–217, Association for Computing Machinery, 1987

    1987

  7. [15]

    The European Digital Identity Wallet Architecture and Reference Framework, version Draft 0.0 October 2022

    “The European Digital Identity Wallet Architecture and Reference Framework, version Draft 0.0 October 2022..” https://digital-strategy.ec.europa.eu/en/library/european-digital-identit y-wallet-architecture-and-reference-framework . [Accessed 27-01-2025]

    2022

  8. [16]

    Specification of the Identity Mixer Cryptographic Library

    S. T. IBM Research Zurich, “Specification of the Identity Mixer Cryptographic Library..” https://dominowe b.draco.res.ibm.com/reports/rz3730_revised.pdf, 2010. [Accessed 27-01-2025]

    2010

  9. [17]

    Trust over IP (ToIP) model

    “Trust over IP (ToIP) model..” https://trustoverip.org/wp- content/toip- model/ . [Accessed 23-01-2025]

    2025

  10. [18]

    Self-Sovereign Identity: A Systematic Review, Mapping and Taxonomy,

    F. Schardong and R. Cust ´odio, “Self-Sovereign Identity: A Systematic Review, Mapping and Taxonomy,” Sensors, vol. 22, no. 15, 2022

    2022

  11. [19]

    SSI mapping by the Decentralized Identity Foundation interoperability project

    “SSI mapping by the Decentralized Identity Foundation interoperability project..” https://github.com/dec entralized-identity/interoperability/blob/master/assets/interoperability-mapping-exe rcise-10-12-20.pdf . [Accessed 23-01-2025]

    2025

  12. [20]

    Toward interoperable self-sovereign identities,

    H. Yildiz, A. K ¨upper, D. Thatmann, S. G¨ond¨or, and P. Herbke, “Toward interoperable self-sovereign identities,” IEEE Access, vol. PP, pp. 1–1, 01 2023

    2023

  13. [21]

    Schematic SSI layers

    Hakan Yildizm, “Schematic SSI layers..” https://identity.foundation/faq/#how-is-this-faq-str uctured. [Accessed 23-01-2025]. 29 NAGHMOUCHI AND LAURENT - S EPTEMBER 24, 2025

    2025

  14. [22]

    Enhancing the security and privacy of self-sovereign identities on hyperledger indy blockchain,

    M. P. Bhattacharya, P. Zavarsky, and S. Butakov, “Enhancing the security and privacy of self-sovereign identities on hyperledger indy blockchain,” in 2020 International Symposium on Networks, Computers and Communica- tions (ISNCC), pp. 1–7, 2020

    2020

  15. [23]

    W3C Recommendation for the DID identifiers, Privacy Considerations

    Manu Sporny, Dave Longley, Markus Sabadello, Drummond Reed, Orie Steele, Christopher Allen., “W3C Recommendation for the DID identifiers, Privacy Considerations..” https://www.w3.org/TR/did-core/ #privacy-considerations. [Accessed 27-01-2025]

    2025

  16. [24]

    Verifiable Credentials Data Model v1.1, Privacy Con- siderations

    Manu Sporny, Dave Longley and David Chadwick., “Verifiable Credentials Data Model v1.1, Privacy Con- siderations.” https://www.w3.org/TR/vc- data- model/#privacy- considerations . [Accessed 23-01-2025]

    2025

  17. [25]

    W3C Reccomendation for VC data model 2.0, Privacy Considerations

    Manu Sporny, Dave Longley, David Chadwick and Ivan Herman., “W3C Reccomendation for VC data model 2.0, Privacy Considerations..” https://www.w3.org/TR/vc-data-model-2.0/#privacy-considerati ons. [Accessed 27-01-2025]

    2025

  18. [26]

    Privacy-preserving eid derivation for self-sovereign identity systems,

    A. Abraham, F. H ¨orandner, O. Omolola, and S. Ramacher, “Privacy-preserving eid derivation for self-sovereign identity systems,” in Information and Communications Security (J. Zhou, X. Luo, Q. Shen, and Z. Xu, eds.), (Cham), pp. 307–323, Springer International Publishing, 2020

    2020

  19. [27]

    Blockchain-based self-sovereign identity: Survey, requirements, use-cases, and comparative study,

    R. Nokhbeh Zaeem, K. C. Chang, T.-C. 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 Intel...

    2022

  20. [28]

    Self-Sovereign Identity Solutions: The Necessity of Blockchain Technology,

    D. van Bokkem, R. Hageman, G. Koning, L. Nguyen, and N. Zarin, “Self-Sovereign Identity Solutions: The Necessity of Blockchain Technology,”CoRR, vol. abs/1904.12816, 2019

    1904 arXiv

  21. [29]

    Dock wallet

    “Dock wallet.” https://www.dock.io/. [Accessed 23-01-2025]

    2025

  22. [30]

    Ethereum claim registry and smart contract events

    “Ethereum claim registry and smart contract events..” https://github.com/uport-project/ethereum-c laims-registry and https://etherscan.io/address/0xaca1bcd8d0f5a9bfc95aff331da4c250cd9 ac2da#events. [Accessed 23-01-2025]

    2025

  23. [31]

    Ingo M.Weber and X.Xu Architecture for Blockchain Applications

    M.S. Ingo M.Weber and X.Xu Architecture for Blockchain Applications . Springer Cham, March 5, 2019, https://doi.org/10.1007/978-3-030-03035-3

    2019 doi

  24. [32]

    Future financial services regulatory regime for cryptoassets response to the consultation and call for evidence

    HM Treasury, “Future financial services regulatory regime for cryptoassets response to the consultation and call for evidence.” https://assets.publishing.service.gov.uk/media/653bd1a180884d0013f71 cca/Future_financial_services_regulatory_regime_for_cryptoassets_RESPONSE.pdf , ...

    2023

  25. [33]

    An internal auditor’s guide to auditing blockchain, part 3: Auditing blockchain environments

    Deloitte, “An internal auditor’s guide to auditing blockchain, part 3: Auditing blockchain environments.” http s://www2.deloitte.com/us/en/pages/risk/articles/internal-auditing-guide-to-blockchai n.html, 2021. [Accessed 27-01-2025]

    2021

  26. [34]

    DID methods registry

    The Decentralized Identifier Working Group (W3C)., “DID methods registry.” https://www.w3.org/TR/di d-spec-registries/#did-methods . [Accessed 23-01-2025]

    2025

  27. [35]

    Understanding the SSI stack through 5 trends and chal- lenges

    Alex Tweeddale, Ross Power and Ankur Banerjee, “Understanding the SSI stack through 5 trends and chal- lenges.” https://blog.cheqd.io/understanding-the-ssi-stack-through-5-trends-and-chall enges-b15e911b4989, 2022. [Accessed 23-01-2025]

    2022

  28. [36]

    Ethereum did registry contract events

    “Ethereum did registry contract events.” https://etherscan.io/address/0xdca7ef03e98e0dc2b855b e647c39abe984fcf21b#code. [Accessed 23-01-2025]

    2025

  29. [37]

    Talao wallet

    “Talao wallet.” https://talao.io/. [Accessed 23-01-2025]

    2025

  30. [38]

    Zero-knowledge proofs do not solve the privacy-trust problem of attribute-based credentials: What if alice is evil?,

    R. Arnold and D. Longley, “Zero-knowledge proofs do not solve the privacy-trust problem of attribute-based credentials: What if alice is evil?,” IEEE Communications Standards Magazine, vol. 3, no. 4, pp. 26–31, 2019

    2019

  31. [39]

    Being “Real

    K. Young, “Being “Real” about Hyperledger Indy & Aries / Anoncreds..” https://identitywoman.net/be ing-real-about-hyperledger-indy-aries-anoncreds/ , 2022. [Accessed 27-01-2025]

    2022

  32. [40]

    Verifiable credentials flavors explained

    K. Young, “Verifiable credentials flavors explained.” Linux Foundation Public Health (LFPH), https://ww w.lfph.io/wp-content/uploads/2021/02/Verifiable-Credentials-Flavors-Explained.pdf ,

    2021

  33. [41]

    Hyperledger Anoncreds

    “Hyperledger Anoncreds.” https://www.hyperledger.org/use/anoncreds. [Accessed 27-01-2025]

    2025

  34. [42]

    Hyperledger Fabric MSP Implementation with Identity Mixer

    “Hyperledger Fabric MSP Implementation with Identity Mixer.” https://hyperledger-fabric.readthed ocs.io/en/release-2.2/idemix.html. [Accessed 23-01-2025]. 30 NAGHMOUCHI AND LAURENT - S EPTEMBER 24, 2025

    2025

  35. [43]

    Benefits of JSON-LD and LD-Proofs, in Verifiable Credentials Implementation Guidelines 1.0 Implementation guidance for Verifiable Credentials, W3C Editor’s Draft 03 February 2023

    D. Chadwick et al., “Benefits of JSON-LD and LD-Proofs, in Verifiable Credentials Implementation Guidelines 1.0 Implementation guidance for Verifiable Credentials, W3C Editor’s Draft 03 February 2023..” https://w3 c.github.io/vc-imp-guide/#benefits-of-json-ld-and-ld-proofs . [...

    2023

  36. [44]

    Javascript Object Signing and Encryption (JOSE) framework

    “Javascript Object Signing and Encryption (JOSE) framework..” https://jose.readthedocs.io/en/lat est/. [Accessed 23-01-2025]

    2025

  37. [45]

    An efficient system for non-transferable anonymous credentials with op- tional anonymity revocation,

    J. Camenisch and A. Lysyanskaya, “An efficient system for non-transferable anonymous credentials with op- tional anonymity revocation,” in Advances in Cryptology — EUROCRYPT 2001 (B. Pfitzmann, ed.), (Berlin, Heidelberg), pp. 93–118, Springer Berlin Heidelberg, 2001

    2001

  38. [46]

    Blind signatures for untraceable payments,

    D. Chaum, “Blind signatures for untraceable payments,” in Advances in Cryptology (D. Chaum, R. L. Rivest, and A. T. Sherman, eds.), (Boston, MA), pp. 199–203, Springer US, 1983

    1983

  39. [47]

    Response to kaliya’s “being real

    D. Hardman, “Response to kaliya’s “being real” post.” https://daniel-hardman.medium.com/response -to-kaliyas-being-real-post-13fddb9410f0 , 2022

    2022

  40. [48]

    Acapy test results

    P. Wenzel, “Acapy test results.” https://github.com/lissi-id/acapy-load-test-results/blob/ma in/AcaPy_0-7-4/Endurance_Test/04-0_7_3_indy-200rpm/report-test-results-0-END.pdf , note = ”[Accessed 27-01-2025]”, 2022

    2025

  41. [49]

    Aries Askar

    “Aries Askar.” https://credo.js.org/guides/getting-started/set-up/aries-askar and https: //github.com/openwallet-foundation/askar. [Accessed 27-01-2025]

    2025

  42. [50]

    Verifiable credential data integrity 1.0

    D. Longley and M. Sporny, “Verifiable credential data integrity 1.0.” https://w3c.github.io/vc-data-i ntegrity/, 2024

    2024

  43. [51]

    BBS Cryptosuite v2023: Securing Verifiable Credentials with Selective Disclosure using BBS Signatures

    “BBS Cryptosuite v2023: Securing Verifiable Credentials with Selective Disclosure using BBS Signatures..” https://www.w3.org/TR/vc-di-bbs/

  44. [52]

    The bbs signature scheme, draft draft-irtf-cfrg-bbs-signatures- latest

    A. W. T. Looker, V . Kalos and M. Lodder, “The bbs signature scheme, draft draft-irtf-cfrg-bbs-signatures- latest.” https://identity.foundation/bbs-signature/draft-irtf-cfrg-bbs-signatures.html , 09 December 2024. [Accessed 23-01-2025]

    2024

  45. [53]

    Pairing-friendly elliptic curves: Revisited taxonomy, attacks and security concern,

    M. Kumar and S. Chand, “Pairing-friendly elliptic curves: Revisited taxonomy, attacks and security concern,” 12 2022

    2022

  46. [54]

    Anonymous credentials 2.0,

    D. K. Michael Lodder, “Anonymous credentials 2.0,” 26 February 2019, version 0.2

    2019

  47. [55]

    ALLOSAUR: Accumulator with low-latency oblivious sublinear anonymous credential updates with revocations

    S. Jaques, M. Lodder, and H. Montgomery, “ALLOSAUR: Accumulator with low-latency oblivious sublinear anonymous credential updates with revocations.” Cryptology ePrint Archive, Paper 2022/1362, 2022. [Accessed 23-01-2025]

    2022

  48. [56]

    Trezor hardware wallet

    “Trezor hardware wallet.” https://trezor.io/. [Accessed 23-01-2025]

    2025

  49. [57]

    Ledger nano s plus hardware wallet

    “Ledger nano s plus hardware wallet.” https://shop.ledger.com/products/ledger-nano-s-plus . [Accessed 23-01-2025]

    2025

  50. [58]

    Foundation devices, passport hardware and envoy mobile application

    “Foundation devices, passport hardware and envoy mobile application.” https://foundationdevices.co m/. [Accessed 23-01-2025]

    2025

  51. [59]

    Metamask wallet

    “Metamask wallet.” https://metamask.io/. [Accessed 23-01-2025]

    2025

  52. [60]

    Exodus wallet

    “Exodus wallet.” https://www.exodus.com/. [Accessed 23-01-2025]

    2025

  53. [61]

    Coinbase wallet

    “Coinbase wallet.” https://www.coinbase.com. [Accessed 23-01-2025]

    2025

  54. [62]

    Hyperledger Aries

    “Hyperledger Aries.” https://github.com/hyperledger/aries. [Accessed 27-01-2025]

    2025

  55. [63]

    Veramo SDK

    “Veramo SDK..” https://github.com/decentralized-identity/veramo?ref=blog.identity.fou ndation. [Accessed 27-01-2025]

    2025

  56. [64]

    [Accessed 27-01-2025]

    “Infura.” https://www.infura.io/. [Accessed 27-01-2025]

    2025

  57. [65]

    Aries RFC 0005: DID Communication

    Daniel Hardman, “Aries RFC 0005: DID Communication..” https://github.com/hyperledger/aries-r fcs/tree/main/concepts/0005-didcomm. [Accessed 27-01-2025]

    2025

  58. [66]

    DIDComm Messaging v2.0

    Sam Curren, Tobias Looker and Oliver Terbu, “DIDComm Messaging v2.0..” https://identity.foundat ion/didcomm-messaging/spec/v2.0/. [Accessed 27-01-2025]

    2025

  59. [67]

    Differences between DID-Comm V1 and DID-Comm V2

    Daniel Hardman and Kyle Den Hartog, “Differences between DID-Comm V1 and DID-Comm V2..” https: //github.com/hyperledger/aries-rfcs/blob/main/features/0044-didcomm-file-and-mime-t ypes/README.md#detecting-didcomm-versions. [Accessed 23-01-2025]. 31 Appendix A: SSI breakdown by ...

    2025

  60. [2021]

    [Accessed 27-01-2025]

    2025

Pith tools

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