Based on Evaluation Framework for SSI Solutions
✅ Fulfils Criteria
🟠 Dependency / Questionable
❌ Does not fulfil criteria
❓ Unclear
| High-Level Criteria | Sub Goals | Privado | Credebl | Quark | MATTR |
|---|---|---|---|---|---|
| Foundational Property | Existence | ✅ | ✅ Credebl supports digital encoding of user characteristics through DIDs and VCs | ✅Proof of existence /Proof of humanity | 🟠 |
| Autonomy | ✅ | 🟠 Functions are managed by a SSI wallet (organisations may integrate their own wallet, Adeya, a wallet created by the same company is also available) | 🟠 Dependency on trust assumptions and settlement of zksync.Core base protocol is technically agnostic of the blockchain layer for settlements. During initial testing it was deployed on Polygon, BNB Chain and Starknet and even Rootstock (Bitcoin L2). Current implementation is preferring ZKsync due to their technical support and partnership to scale in this initial state. Long term vision is to be a Protol independent of any chain. | 🟠 | |
| Ownership | ✅ | 🟠 Organisations can setup their own SSI Web Wallet based on a multi-tenant shared Aries agent. | ✅ non-custodial | ❓ Unclear | |
| Access | ✅ | 🟠 User registration process through email-based verification. FIDO Passkey for phishing-resistent user verification. | ✅ | ✅ | |
| Single Source | ✅ There is no direct communication between issuer and verifiers. | ✅ inherited from the protocol and the trust assumptions on the credential | ✅ inherited from the protocol and the trust assumptions on the credential | 🟠 | |
| Security Property | Protection | ✅ | ✅ (See technical evaluation below) | ❓ Unclear | ✅ |
| Availability | ✅ supports bulk issuance of claims with a highly efficient on-chain storage | 🟠Ledger agnostic. Dependent on liveness of ledger used/ chain deployment . (see below on decentraliazation) | 🟠 In the Lepton version, all private information of individuals is stored in the Secure Storage of their mobile device and is not synchronized with other devices or with the DWN. The Decentralized Web Node (DWN) currently only serves the messaging function as defined by the DIF specification and does not yet implement the storage function outlined in the specification. In the Fermion version, the DWN will incorporate cloud storage and synchronization across different devices controlled by the user as defined by the DIF specification | ✅ | |
| Persistence | 🟠Ledger agnostic. Dependent on the ledger used/ chain deployment . | 🟠Ledger agnostic. Dependent on the ledger used/ chain deployment . (see below on decentralization) | 🟠 As above | ❓ Unclear | |
| Controllability Property | Choosability | ✅ | ✅ You can choose what info to share using zero-knowledge proofs | ✅ The user has full control over when and to whom their private information is released. | |
| In the Fermion version, an upgrade to the DWN will implement the capability to store encrypted information in the DWN | ✅ | ||||
| Disclosure | ✅ | ✅ Supports selective disclosure features | 🟠 Fermion version, selective disclosure capabilities are limited to the level of entire credentials; it is not possible, using the standard QuarkID wallet, to select only certain attributes from each credential or to generate zero-knowledge proofs based on one or more credentials. This limitation exists because, although credentials are currently issued using the BBS Signature Scheme, and verifiers could verify presentations utilizing selective disclosure capabilities derived from using BBS as a signing scheme, the standard QuarkID wallet does not yet support the BBS Signature Scheme due to an incompatibility between the cryptographic library we use and React Native. | ✅ | |
| Consent | ✅ | ✅ See data privacy in table below | ✅ all private information resides on devices controlled by the users themselves, and the wallet always notifies the user of any request for credential presentation—requiring their authorization before proceeding and informing them of the specific information being requested | ||
| Flexibility Property | Portability | ✅ | ✅ Uses VCs and adheres to various standards (see below) | ✅ Decentralized identity is system and network independent. This allows entities to use their digital identifiers with any system that adheres to the standards. | ✅ |
| Interoperability | ✅ | ✅ .Designed for interoperability with W3C specifications such as Decentralized Identifiers (DID) and Verifiable Credentials (VC), along with contributions from the Decentralized Identity Foundation (DIF), Trust over IP Foundation (ToIP), as well as the collaborative efforts of the Hyperledger Indy and Aries open-source initiatives. | ✅W3C specifications (DID/VC), the ToIP model, and implementing JSON-LD credentials, QuarkID is also fully aligned with DIF specifications | ✅ | |
| Minimisation | ✅ Client-side verifications (revocation, expiration, ownership) | ✅ Agent creates a separate wallet database for each organization wallet in order to keep the data isolated. Platform uses NATS for message-driven data exchange between CREDEBL microservices. | 🟠Disclosure of identity data will be achieved in the upcoming releases. Protocol will provide tools for selective disclosure in the Boson version. | ✅ | |
| Sustainability Property | Transparency | ✅ | ✅ Credebl is open-source | 🟠 some code Open source but seems some parts are being built in private | ✅ |
| Standard | ✅ w3c standards , DIF, DID, JSON-LD and JSON | ✅ Based on open standards DID, VC, DIF, ToIP, W3C* see above | ✅ Uses w3C DID, based on ToIP model, VCs,JSON-LD | ✅Compliant with ISO/IEC 18013-5, 18013-7. |
Compliant with OIDF OpenID4VCI, OpenID4VP |
| Criteria | Privado | Credebl | Quark | MATTR |
|---|---|---|---|---|
| Performance of ZK Stack | new circuits in beta - СredentialAtomicQueryV3 and CredentialAtomicQueryV3Onchain | Credbl is currently using Credo in the background, from Credo’s documentation it seems that their way to implement zk-credentials is through BBS+ signatures and anoncreds. BBS+ signatures are efficient on both proof generation (mostly server side) and verification (verification requires 2 EC pairings). For anoncreds it seems that ZKPs are based on CL Signatures. | 🟠 Not clear if they are actually using BBS+ signatures (‣).successfully implemented BBS+ signatures at the backend level, which ensures efficient proof generation and verification. However, this functionality has not yet been integrated into our wallet. | ✅ Performances of BBS+ |
| Mattr is leading the standardisation effort for the BBS+ algorithm, and they plan to implement it in their solution, but at the moment it is not part of their suit, even if they have the most optimised integration of it. | ||||
| Mobile Compatibility | ✅ | ✅ It seems mobile friendly and they are working on a React Native lib. | ✅ It should be mobile-friendly. They’ve worked on a mobile application built with React Native: ‣. | ✅ |
| On-chain Deployment Requirements | ✅ EVM compatible | Signatures verification | ||
| If using BBS+, depending on the curve implemented, it should be possible to implement the verification logic for the EVM, though I didn’t see any on-chain verifier at the moment, could lead to research and implementation on our side. | ||||
| For CL signatures it should also be possible but again no verifier implementation found for the EVM. |
Data storage The protocol is currently using Polygon PoS, to post unique user identifiers (DID identifiers) in a decentralised registry, as well as the schemas for VCs (optional). | They’re using ZK-Sync Era, which is EVM-compatible (https://docs.zksync.io/build#main-features). | ❌ The current implementation uses the BLS12-381 curve, that doesn’t have precompile for the EVM | | Selective Disclosure | ✅ | 🟠 For BBS+, yes For CL Signatures, yes the doc (unclear if implemented yet) | 🟠 ****It is based on VCs and VPs, so it should support it: https://docs.quarkid.org/en/Docs/componentes/vc#verifiable-presentations. There’s no confirmation tho, as the code is not available. Packages dependencies (@extrimian/kms-suite-bbsbls2020) lead to ‣. If they’re using it, selective disclosure should be supported. | ✅ | | W3C compatible | ✅ | ✅ | ✅ Yes, it uses DIDs in the first layer and VCs in the third one. The entire system is based on the ToIP (trusted over ip) model. | ✅ | | Opportunities for ZKP development | ✅ | ✅ | ✅ There is no mention of it, but since the entire stack is based on DIDs and VCs, zk-proofs should be compatible and integrable into layers 3 and 4 of the ToIP model. | - | | Credential exchange format | JSON-LD Context. Non-merklized credentials are used for on-chain issuers, because smart contracts built on Solidity can't fetch JSON-LD schemas directly via HTTP or IPFS. | openid4vc W3C DID AnonCreds, JSON-LD, JWT, etc. | ✅ Credentials are based on WACI (DIF): https://identity.foundation/waci-didcomm/#format-property. The whitepaper mentions JSON-LD, JWT, ZKP-CL. | Full list here https://learn.mattr.global/docs/standards/supported | | ZK verifications | The Atomic Query Signature V2 Circuit and Atomic Query MTP V2 Circuit circuits have been designed as generic circuits to do the ZK verification based on users' claims.
The Query Language sits on top of these circuits to provide a simple way for developers to design customized authentication requirements for someone's credentials. | If we want to verify zk proof in the contract, we have to consider the compatibility of precompiles. AnonCreds use BN254 for CL signatures, which is compatible with Ethereum's precompile. | 🟠 ****ZK verifications will be implemented in version Fermion of the technical roadmap | - API call
| Sub Goal | Privado | Credebl | QuarkID | EUID ARF | MATTR |
|---|---|---|---|---|---|
| Relevance to SDGs | ✅ SDG8: Decent Work and Economic Growth,SDG9: Industry¸ Innovation and Infrastructure,SDG10: Reduced Inequalities,SDG17: Partnerships for the Goals | ✅ SDG8: Decent Work and Economic Growth,SDG9: Industry¸ Innovation and Infrastructure,SDG10: Reduced Inequalities,SDG17: Partnerships for the Goals | ✅ SDG8: Decent Work and Economic Growth,SDG9: Industry¸ Innovation and Infrastructure,SDG10: Reduced Inequalities,SDG17: Partnerships for the Goals | ✅ SDG8: Decent Work and Economic Growth,SDG9: Industry¸ Innovation and Infrastructure,SDG10: Reduced Inequalities,SDG17: Partnerships for the Goals | ✅ |
| Use of Approved Open Licenses | ✅ Apache-2.0, MIT, GPL 3.0 licenses found | ✅ Apache-2.0 | 🟠Apache-2.0 license on some repositories | ✅ The European Digital Identity Wallet Architecture and Reference | |
| Framework © 2023 by European Commission is licensed under Attribution | |||||
| 4.0 International. To view a copy of this license, visit | |||||
| http://creativecommons.org/licenses/by/4.0/ | ✅ | ||||
| Clear Ownership | ✅ https://docs.privado.id/privacy-policy.pdf | ✅ Blockster Labs Private Limited https://docs.credebl.id/en/license/copyright-and-license | ❓ Unclear | ✅ European Comission https://digital-strategy.ec.europa.eu/en/policies/eudi-wallet-implementation | ❓ Unclear |
| Platform Independence | 🟠 Iden3 (mostly run by privado but also jordi ) | ✅ Solution does not use any closed components that create proprietary dependency | ❓ Unclear | 🟠 list of dependency analysis needs to be conducted on sub services and compensating controls . i,e. cloud services | ❓ Unclear |
| Documentation | ✅ https://docs.privado.id/ | ✅ https://github.com/credebl/docs https://docs.credebl.id | ❌ Poor documentation (in english language) | ✅ Very Comprehensive | ✅ |
| Mechanism for Extracting Data | ✅ not distributed, not collected | 🟠The CREDEBL platform collects PII data for platform users which is essential for the access to the platform but is NOT distributed. However, CREDEBL also enables the collection/use of non-PII data which holds system-wide importance. For example, information related to statistics and reporting of organisations and users, which is made available through relevant REST APIs. The data is available in JSON (non-proprietary) format. This data can be consumed by the platform users or external systems to provide analytics and reporting functions. |
| ❓ Unclear | 🟠 Varied but controlled by wallet functionality. “The EUDI Wallet should incorporate clear information and visual indicators or badges e.g. Trust Mark could be utilised to indicate whether the Relying Party is considered trusted, based on the underpinning trust framework established. Providing users with this data helps them make informed decisions about which parties they trust and are comfortable sharing their data with. Further information must be provided upon clicking on the badge regarding what it means to be a trusted party and how you become one.” | ✅ | | | ✅ not collected | 🟠 CREDEBL collects following PII during the onboarding of organisations and individual users - Email (Mandatory) - Name (Optional) | ✅ Decentralised Web Nodes | ✅ Under EU commission eIDAS regulation https://digital-strategy.ec.europa.eu/en/pages/legal-notice#ecl-inpage-km0gfb8o | ✅ | | Adherence to Privacy Laws | ❓ https://docs.privado.id/privacy-policy.pdf. mostly gdpr compliant ( from otto) | ✅ Complies with privacy laws and standards in accordance with GDPR. Privacy Policy - https://credebl.id/privacy-policy , Terms of Use - https://credebl.id/terms-of-use | ✅ Largely built for the purpose of the Argentinian government ID requirements | ✅Under the Electronic Identification, Authentication and Trust Services (eIDAS) Regulation | ✅ | | | ✅ | ✅ CREDEBL platform provides standard secured transport mechanisms such as HTTPS/SSL to protect the data in transit. CREDEBL provides row-level encryption of data at rest on the back-end services so that the data is only accessed by authorised entity. CREDEBL does not distribute this data. https://docs.credebl.id/en/intro/platform-features/ | ✅ | 🟠 Varied but controlled by wallet functionality by the user. The EU Digital Identity Wallets will enable people to choose and keep track of their identity, data and certificates which they share with third parties. Anything which is not necessary to share will not be shared. | ✅ | | | ✅ | ✅ Content is NOT collected NOT stored and NOT distributed. | 🟠 Decentralised Web Nodes mentioned but unclear if implemented | 🟠 Varied and determine by the data sharing scenario. EUDI Wallet should include clear and concise explanations about the purpose of each data request, the relying party's identity, and how the data will be used, highlighting data storage and ‘intent to store’ aspects to the user. | ❓ Unclear | | Adherence to Standards | ✅ | ✅ Decentralised Identifiers: https://www.w3.org/TR/did-core/ DID Method Registry: https://github.com/decentralised-dataexchange/automated-data-agreements/blob/main/docs/did-spec.md https://www.w3.org/TR/did-spec-registries/ Selected RFCs from the following list of RFCs: https://github.com/hyperledger/aries-rfcs/tree/main/features | ✅ Adheres to widely used standards, DID, VC, ToIP | ✅ Standards used: ISO/IEC 18013-5 defines an attribute schema, data format and proof mechanisms for mDL-s, which can be used also with other attribute schemas, see [ISO/IEC 18013-5].
Selective Disclosure for JWTs (SD-JWT) defines a proof mechanism similar to [ISO/IEC 18013-5], but for a different data format, see [SD-JWT].
W3C Verifiable Credentials Data Model v1.1 [W3C VC DM v1.1] defines a generic attribute schema agnostic to data formats and proof mechanisms, while v 2.0 introduces requirements on format and recommendations on proof mechanisms, see [W3C VC DM v2.0].
SD-JWT-based Verifiable Credentials (SD-JWT VC) define a generic attribute schema and establish requirements on data format and proof mechanisms, see [SD-JWT-VC]. | ✅ | | Do No Harm by Design | ✅ | ✅ Designed to prevent harm by ensuring privacy, security, and content moderation. | ✅ | ✅ | ✅ | | | | | | ✅ | |
References: