Mosaic DID: Blockchain-Agnostic Self-Sovereign Identity with Selective Disclosure

Blockchain-anchored decentralized identity systems are proliferating, yet each is locked to a specific ledger – did:ion to Bitcoin, did:ethr to Ethereum, did:sol to Solana – creating fragmented ecosystems with no portability. We present Mosaic DID, a blockchain-agnostic self-sovereign identity (SSI) architecture that decouples identity operations from any specific chain through an abstract journal interface. Mosaic DID introduces three architectural contributions: (1) a multicipher framework supporting Ed25519, secp256k1, and extensible cipher suites from a single hierarchical deterministic seed; (2) JSON Digest selective disclosure, enabling privacy-preserving credential presentation via canonical JSON hashing and Merkle-proof masking without BBS+ signatures or pairing curves; and (3) anti-censorship DID operations, where cryptographic authorization lives inside the signed operation rather than at the transaction submission layer – any blockchain account can submit operations for any DID without being its controller.

We provide a reference implementation as a Substrate pallet (pallet-mosaic-did) with materialized on-chain state, bounded collections for parachain compatibility, and six-right capability model. The implementation spans 18 Rust crates (~12,000 lines) with native, WebAssembly, and C FFI bindings. Security analysis provides proof sketches for selective disclosure soundness, operation authorization, and key binding. To our knowledge, Mosaic DID is the first SSI architecture to combine blockchain agnosticism, hash-based selective disclosure, and anti-censorship operations in a single framework with a production-ready on-chain registry.

Keywords: decentralized identity, blockchain-agnostic, selective disclosure, Substrate, verifiable credentials, self-sovereign identity

1. Introduction

1.1 Motivation

The W3C Decentralized Identifier (DID) specification [Sporny, 2022] defines a framework for self-sovereign identity but delegates cryptographic implementation and persistence to individual DID methods. In practice, most production DID methods are locked to a single blockchain: did:ion [Buchner, 2021] requires Bitcoin anchoring via the Sidetree protocol, did:ethr [Thorstensson, 2019] requires Ethereum’s ERC-1056 registry, and emerging methods like did:sol and did:algo create further fragmentation.

This chain-locking creates three problems. First, portability: identities cannot migrate between chains without losing their identifier and accumulated reputation. Second, availability: identity operations are subject to the availability, throughput, and fee economics of a single chain. Third, censorship: if the anchoring chain’s validators refuse to include DID operations, the identity is effectively frozen.

Meanwhile, off-chain alternatives like did:key [Sporny, 2022] provide decentralization but sacrifice persistence and key rotation. KERI [Smith, 2021] achieves blockchain independence through Key Event Logs but lacks selective disclosure and uses correlatable Autonomic Identifiers.

1.2 Gap Analysis

did:ion [Buchner, 2021] provides strong decentralization through Bitcoin anchoring but is fundamentally Bitcoin-dependent. The Sidetree protocol batches operations into Bitcoin transactions, creating a dependency on Bitcoin’s 10-minute block time and fee market. Identity resolution requires reconstructing the Sidetree operation tree from Bitcoin data.

did:ethr [Thorstensson, 2019] uses a lightweight Ethereum registry (ERC-1056) for key management. While simple, it inherits Ethereum’s gas costs, throughput limitations, and smart contract risks. No selective disclosure capability.

AnonCreds [Group, 2023] provides sophisticated selective disclosure via CL-signatures [Camenisch, 2004] but relies on Hyperledger Indy blockchain infrastructure and pairing-friendly curves (BLS12-381) that are not post-quantum safe.

BBS+ signatures [Boneh, 2004] [Tessaro, 2023] enable efficient selective disclosure through pairing-based signature schemes. While cryptographically elegant, they require pairing-friendly curves, increasing implementation complexity and precluding post-quantum migration.

The Gap: No existing blockchain-anchored DID system combines: (1) blockchain agnosticism with a concrete on-chain implementation, (2) selective disclosure without pairing curves, and (3) anti-censorship operations where authorization is decoupled from transaction submission.

1.3 Our Approach

Mosaic DID introduces a three-layer architecture:

• Keyvault (Cryptographic Foundation): Hierarchical deterministic key derivation (BIP-32/39/43/44 [Wuille, 2012] [Palatinus, 2013]) with a multicipher abstraction supporting multiple signature algorithms (Ed25519 [Bernstein, 2012], secp256k1 [Research, 2000]) from a single mnemonic seed. Extensible to new cipher suites without protocol changes.

• Morpheus Protocol (Identity Layer): DID document management, verifiable credential issuance and presentation, and JSON Digest selective disclosure [Rundgren, 2020]. Credentials are signed off-chain; only key management operations touch the ledger.

• Blockchain Pallet (Persistence Layer): Abstract journal interface instantiated as a Substrate [Technologies, 2018] pallet for the Mosaic Trust Network. Materialized on-chain state (no event replay), bounded collections for parachain Proof-of-Validity constraints, and anti-censorship operation design.

1.4 Contributions

1. Blockchain-agnostic DID architecture with abstract journal interface, decoupling identity operations from any specific chain. Reference implementation on Substrate with materialized state and six-right capability model.

2. JSON Digest selective disclosure enabling privacy-preserving credential presentation via canonical JSON hashing and Merkle-proof field masking – without BBS+ signatures, pairing curves, or trusted setup.

3. Anti-censorship DID operations where cryptographic authorization lives inside the signed operation. Any blockchain account can submit operations for any DID, preventing censorship by fee-paying intermediaries.

4. Production implementation spanning 18 Rust crates with native, WebAssembly, and C FFI bindings (Section 7).

2. Related Work

W3C DIDs. The W3C DID specification [Sporny, 2022] provides a standardized framework but leaves persistence and cryptography to DID methods. Most production methods are chain-locked: did:ion [Buchner, 2021] (Bitcoin), did:ethr [Thorstensson, 2019] (Ethereum). The did:web method uses DNS/HTTPS, inheriting centralized trust assumptions. did:key provides true decentralization but lacks persistence, key rotation, and selective disclosure.

KERI. KERI [Smith, 2021] achieves blockchain independence through Key Event Logs (KELs) and witness networks. Pre-rotation commitments prevent unauthorized key changes. However, KERI’s Autonomic Identifiers (AIDs) are correlatable across all interactions – every interaction uses the same identifier. KERI provides no selective disclosure and no privacy-preserving credential presentation.

Anonymous credentials. CL-signatures [Camenisch, 2004] [Camenisch, 2002] introduced anonymous credentials with hidden master secrets. BBS+ signatures [Boneh, 2004] [Tessaro, 2023] enable efficient selective disclosure through pairing-based multi-message signing. SD-JWT [Fett, 2024] provides hash-based selective disclosure for JWTs but lacks the structural flexibility of JSON Digest’s recursive masking. All pairing-based schemes (CL, BBS+, Coconut [Sonnino, 2019]) rely on assumptions incompatible with post-quantum migration.

Substrate-based identity. Substrate [Technologies, 2018] provides a framework for building application-specific blockchains (parachains) within the Polkadot [Wood, 2016] ecosystem. Existing Substrate identity pallets (e.g., pallet-identity) focus on on-chain attestations rather than W3C DID compliance. KILT Protocol implements did:kilt on Substrate but is locked to the KILT parachain with no agnostic journal abstraction.

Selective disclosure approaches. Three paradigms exist for selective disclosure: (1) algebraic (BBS+, CL-signatures) – cryptographically strong but require pairing curves; (2) hash-based (SD-JWT, JSON Digest) – simpler, no pairings, but weaker privacy guarantees; (3) zero-knowledge (Groth16 [Groth, 2016], STARKs [Ben-Sasson, 2019]) – strongest privacy but highest computational cost. Mosaic DID uses hash-based selective disclosure via JSON Digest, trading algebraic unlinkability for implementation simplicity and post-quantum compatibility.

Novelty claim validation. We survey blockchain-anchored DID systems across four dimensions: blockchain agnosticism, selective disclosure, anti-censorship operations, and materialized state. No surveyed system achieves all four. Full survey in Appendix B.

3. Threat Model

Adversary classes. We consider five adversary types:

Passive observer ($\mathcal{A}_\mathrm{obs}$): monitors on-chain transactions and off-chain credential presentations. Attempts correlation and traffic analysis.

Active network attacker ($\mathcal{A}_\mathrm{net}$): intercepts, modifies, and replays messages between parties. Cannot compromise blockchain consensus.

Compromised endpoint ($\mathcal{A}_\mathrm{end}$): gains access to a device’s derived keys but not the master seed or mnemonic backup.

Censoring validator ($\mathcal{A}_\mathrm{cens}$): controls a subset of blockchain validators and refuses to include DID operations from targeted identities. Novel adversary class addressing blockchain-specific censorship risks.

Malicious verifier ($\mathcal{A}_\mathrm{ver}$): attempts to extract more information from a credential presentation than the holder intended to disclose.

Security goals. G1 (Selective Disclosure Soundness): A masked credential presentation does not reveal information about masked fields beyond what is inferrable from the disclosed fields. G2 (Operation Authorization): Only keys with appropriate rights can execute DID operations; the submitting account’s identity is irrelevant. G3 (Key Binding): A valid credential presentation proves possession of the signing key without revealing it. G4 (Censorship Resistance): No single validator or submitter can prevent a legitimately authorized DID operation from being included.

Trust assumptions. The blockchain provides eventual consistency and tamper-evidence (standard BFT assumptions). BLAKE3 [O'Connor, 2020] provides collision resistance and pre-image resistance. BIP-39 mnemonics [Palatinus, 2013] provide sufficient entropy for master seed generation. JCS canonicalization [Rundgren, 2020] is deterministic and invertible.

4. Architecture

4.1 Design Principles

Ledger as timestamp oracle. The blockchain provides ordering and timestamping of key management events. Credentials and personal data never touch the ledger – only key changes, right assignments, and content hash timestamps (BeforeProof).

Blockchain agnosticism. The identity protocol communicates with the ledger through an abstract journal interface (Section 4.4). The reference implementation targets Substrate, but the protocol layer is chain-independent.

Privacy by architecture. Credentials are issued, stored, and presented entirely off-chain. The ledger stores only public key material and capability assignments – never credential content.

4.2 Keyvault: Cryptographic Foundation

The keyvault generates all cryptographic material from a single BIP-39 mnemonic seed:

$$\mathit{master} = \mathrm{PBKDF2\text{-}SHA512}(\mathit{mnemonic},\; \texttt{"mnemonic"} \,\|\, \mathit{passphrase},\; 2048)$$

From the master seed, hierarchical deterministic (HD) derivation follows BIP-32/43/44 paths:

$$\mathit{child}_i = \mathrm{HMAC\text{-}SHA512}(\mathit{parent}.\mathit{chain},\; \mathit{parent}.\mathit{key} \,\|\, \mathrm{ser}(i))$$

Multicipher abstraction. Rather than committing to a single signature algorithm, Mosaic DID provides a type-erased cryptographic abstraction:

Currently supported suites:

• Ed25519 (e): Edwards curve with Blake2b-MAC key IDs. Battle-tested, fast.
• secp256k1 (s): ECDSA with Bitcoin-compatible key derivation. Hardware wallet interoperability.
• Ed25519-BLAKE3 (o): Ed25519 with BLAKE3 [O'Connor, 2020] key IDs. Modern, faster hashing.

New cipher suites (e.g., post-quantum ML-DSA-65) can be added by implementing the multicipher trait without protocol changes.

4.3 DID Method: did:mosaic

DID derivation:

$$\mathit{did} = \texttt{"did:mosaic:"} \,\|\, \mathrm{multibase}(\mathrm{BLAKE3}(\mathit{pk}_\mathrm{initial}))$$

where $\mathit{pk}_\mathrm{initial}$ is the first public key registered for the DID.

DID Document state. Unlike event-sourced designs (KERI, did:ion/Sidetree), Mosaic DID uses materialized state: the current DID document is stored directly on-chain, not reconstructed from a log of operations. This reduces resolution complexity from $O(n)$ (where $n$ is the number of historical operations) to $O(1)$ lookup.

Rights model. Each key in a DID document is assigned a subset of six capabilities:

1. Update – modify the DID document (add/revoke keys, change rights)
2. Impersonate – authenticate as the DID (sign challenges)
3. Delegate – grant rights to other keys
4. Issue – issue verifiable credentials on behalf of the DID
5. Revoke – revoke previously issued credentials
6. Recovery – recover control after key compromise. Recovery semantics are reserved for Phase 2; the right is defined in the type system but no RecoverDid operation exists in the current protocol version.

The first key registered for a DID automatically receives Update, Delegate, and Impersonate rights.

CRUD operations:

• Create: Register initial public key with implicit rights.
• Read: Direct storage lookup (materialized state, $O(1)$).
• Update: AddKey, RevokeKey, AddRight, RevokeRight, UpdateRights – each a signed operation (Section 6).
• Deactivate: Revoke all keys (irreversible).

4.4 Abstract Journal Interface

The BeforeProof operation timestamps a content hash on-chain without revealing the content itself – a minimal Proof-of-Existence primitive. This enables credential issuers to prove that a credential existed before a specific block height without disclosing the credential content.

5. JSON Digest and Selective Disclosure

5.1 Canonical JSON Hashing

JSON Digest provides deterministic, structure-preserving hashing of JSON documents following JCS canonicalization [Rundgren, 2020]:

The recursive structure ensures that the digest of a composite value depends on the digests of its children – forming a Merkle-like hash tree over the JSON structure.

5.2 Selective Disclosure via Masking

A holder can mask fields in a signed credential without invalidating the signature, because the signature covers the root digest, and the root digest can be recomputed from any combination of revealed values and masked digests:

Key property: Replacing a JSON value with its digest does not change the parent’s digest. This follows directly from the recursive definition – the parent hashes $D(v)$ regardless of whether $v$ is a raw value or a pre-computed digest.

5.3 Comparison with BBS+ Selective Disclosure

JSON Digest and BBS+ [Tessaro, 2023] both enable selective disclosure but with different tradeoffs:

Property	JSON Digest	BBS+
Pairing curves required	No	Yes
Post-quantum compatible	Yes (hash-based)	No
Unlinkable presentations	No*	Yes
Trusted setup	None	None
Implementation complexity	Low	High
Proof size	$O(k)$ hashes	Constant
Recursive masking	Yes	No

* Same credential, same disclosed fields → same presentation. Linkable across presentations with identical disclosure sets.

The critical tradeoff is unlinkability: BBS+ produces randomized presentations that are unlinkable even when disclosing the same fields from the same credential. JSON Digest presentations are deterministic – a verifier who sees the same disclosed fields can correlate presentations. For applications where unlinkability is not required (e.g., KYC, age verification, professional certification), JSON Digest provides a simpler, post-quantum-compatible alternative.

6. Security Analysis

We provide proof sketches for the core security properties. Full proofs with game-hop details are in preparation for the extended version.

Proof sketch. The signature covers $D(\mathit{credential})$ – the root digest. A masked presentation replaces values with their digests but preserves the root. For the root to remain valid with altered original values, the adversary must find a collision in BLAKE3: a different value $v' \neq v$ such that $D(v') = D(v)$. This contradicts BLAKE3 collision resistance (birthday bound $2^{128}$). $\square$

Proof sketch. Each DID operation carries a cryptographic signature from a key registered in the DID document with the appropriate right. The pallet validates: (1) the signing key exists in the DID state, (2) the key holds the required right, (3) the signature is valid, (4) the nonce is fresh. Forging an operation without the private key requires breaking EUF-CMA. Using a key without the required right fails validation at step (2). $\square$

Proof sketch. The pallet’s authorization check examines only the signature inside the operation, not the origin (submitting account). The ensure_signed(origin) call verifies that someone paid the transaction fee but does not constrain who. If the original submitter is censored, any other account can resubmit the identical signed operation. Under blockchain liveness, at least one honest validator will include it. $\square$

Proof sketch. The credential is signed by a key registered in the issuer’s DID document. The verifier resolves the issuer’s DID at the claimed issuance height (BeforeProof timestamp), checks that the signing key held the Issue right at that height, and verifies the signature. Forging requires either breaking EUF-CMA or retroactively modifying the on-chain DID state (contradicting blockchain immutability). $\square$

7. Anti-Censorship Operations

A distinctive architectural choice in Mosaic DID is the separation of authorization from submission.

In traditional blockchain DID systems, the account submitting a transaction must also be the DID controller (or an authorized delegate). This creates a censorship vector: if validators collude to exclude transactions from a specific account, that DID is frozen.

Mosaic DID decouples these concerns:

$$\mathrm{TX} = (\underbrace{\mathit{submitter}}_{\text{pays fee}},\; \underbrace{\mathrm{SignedOp}(\mathit{did}, \mathit{op}, \sigma_\mathit{auth})}_{\text{authorization}})$$

The pallet validates $\sigma_\mathit{auth}$ against the DID’s registered keys and rights. The submitter’s identity is irrelevant to authorization – it only determines who pays the transaction fee. This means:

• A censored user can ask any willing account to relay their signed operation.
• Relay services can batch-submit operations without needing DID controller keys.
• Meta-transaction patterns (gasless DID operations) are native, not bolted on.

8. Substrate Integration

8.1 Pallet Design

The reference implementation is a Substrate pallet (pallet-mosaic-did) with the following on-chain storage:

$$\begin{aligned} \mathtt{DidStates} &: \mathrm{StorageMap}\langle\mathrm{Did}, \mathrm{DidState}\rangle \\ \mathtt{BeforeProofs} &: \mathrm{StorageMap}\langle\mathrm{ContentId}, \mathrm{BeforeProofRecord}\rangle \end{aligned}$$

Materialized state. Each DID’s current state is stored directly – no event replay is needed for resolution. This contrasts with did:ion’s Sidetree model where the resolver must reconstruct state from a tree of operations anchored in Bitcoin transactions.

Bounded collections. For parachain compatibility (PoV size limits), all collections are bounded:

• Maximum 32 keys per DID
• Maximum 64 rights assignments per DID
• Maximum 16 operations per extrinsic batch

Validate-then-apply pattern. Each extrinsic first validates all operations in read-only mode, then applies mutations atomically. On any validation failure, the entire batch is rejected (no partial application).

8.2 BeforeProof: Proof of Existence

The BeforeProof operation records a content hash with a block height timestamp:

$$\mathrm{BeforeProof}(\mathit{content\_id}) \rightarrow (\mathit{content\_id}, \mathit{block\_height}, \mathit{created\_at})$$

This enables credential issuers to prove that a credential existed before a certain time – without revealing the credential itself. The content ID is a BLAKE3 hash of the canonical JSON credential, computed via JSON Digest.

9. Evaluation

9.1 Implementation

The Mosaic DID implementation spans 18 Rust crates with approximately 12,000 lines of source code (excluding tests and build artifacts):

Layer	Crate	LOC
Cryptographic core	keyvault	3,200
Identity protocol	morpheus-proto	1,596
JSON Digest	json-digest	850
Substrate pallet	pallet-mosaic-did	977
DID types (no_std)	mosaic-did-types	620
Blockchain adapter	hydra-proto/sdk	1,800
Vault (wallet)	vault	1,400
SDK + bindings	sdk, sdk-wasm, sdk-ffi	1,773
Total		~12,216

Language bindings. The SDK is available as:

• Native Rust library (cdylib + rlib)
• WebAssembly module via wasm-bindgen (npm package)
• C FFI bindings for mobile integration (Android JNI, iOS)

9.2 Benchmark Methodology

Benchmarks are in preparation. The following table structure will be populated with measurements from the reference implementation on x86-64 Linux.

Layer	Operation	Median
Keyvault
	BIP-39 seed generation (24 words)	TBD
	Ed25519 keygen (HD derivation)	TBD
	secp256k1 keygen (HD derivation)	TBD
	Ed25519 sign (256 B)	TBD
	Ed25519 verify	TBD
	secp256k1 sign (256 B)	TBD
	secp256k1 verify	TBD
JSON Digest
	Canonical hash (1 KB credential)	TBD
	Mask field (single path)	TBD
	Verify masked presentation	TBD
DID Operations
	DID creation (on-chain)	TBD
	Key addition (on-chain)	TBD
	Right assignment (on-chain)	TBD
	DID resolution (storage lookup)	TBD
Credential Lifecycle
	Credential issuance (sign + digest)	TBD
	Presentation creation (mask + sign)	TBD
	Presentation verification	TBD

9.3 Comparative Analysis

Property	Mosaic	did:ion	did:ethr	KERI	AnonCreds
Blockchain agnostic	Yes	No	No	Yes	No
Selective disclosure	Yes	No	No	No	Yes
Anti-censorship ops	Yes	No	Partial	N/A	No
Materialized state	Yes	No	Yes	No	Partial
Key rotation	Yes	Yes	Yes	Yes	Partial
Multi-cipher support	Yes	Partial	No	Partial	No
Off-chain credentials	Yes	Yes	No	Yes	Partial

Yes = native. Partial = partial support. No = absent. N/A = not applicable.

10. Discussion and Limitations

Linkability. JSON Digest selective disclosure is deterministic: the same credential with the same masked fields produces the same presentation. This enables cross-session correlation by verifiers who compare presentations. BBS+ avoids this via randomized proofs. For applications requiring unlinkability (e.g., anonymous voting), JSON Digest is insufficient; BBS+ or ZK proofs are needed.

No post-quantum signatures. The current cipher suites (Ed25519, secp256k1) are not post-quantum safe. The multicipher abstraction is designed for extensibility – ML-DSA-65 or SLH-DSA suites can be added – but no PQ suite is implemented. JSON Digest’s hash-based construction (BLAKE3) is post-quantum compatible for selective disclosure.

On-chain storage costs. Materialized state trades resolution speed ($O(1)$) for storage cost: each DID’s full current state is stored on-chain. For parachains with strict PoV limits, the bounded collections (32 keys, 64 rights) constrain DID document complexity.

Chain dependency. While the architecture is blockchain-agnostic, the current implementation requires some blockchain for key management timestamping. Fully off-chain operation (like KERI) is not supported – the journal interface mandates an ordered, tamper-evident log.

Relay trust. Anti-censorship operations depend on the availability of willing relay accounts. If no relay submits the operation, censorship succeeds. Mitigation: public relay services with economic incentives (fee reimbursement protocols).

10.1 Future Work

• Post-quantum cipher suite: Add ML-DSA-65 multicipher implementation for PQ signature readiness.
• Cross-chain DID resolution: Extend the journal interface to support multi-chain resolution (resolve a DID anchored on chain A from chain B).
• BBS+ integration: Optional BBS+ selective disclosure for applications requiring unlinkability, alongside JSON Digest.
• Formal verification: Machine-checkable proofs of pallet state transition correctness.
• Performance benchmarks: Complete the benchmark suite and comparative evaluation against did:ion and did:ethr implementations.

11. Conclusion

Mosaic DID provides a blockchain-agnostic foundation for self-sovereign identity that addresses the fragmentation problem in current DID ecosystems. By decoupling identity operations from any specific chain through an abstract journal interface, Mosaic DID enables identity portability without sacrificing the ordering and timestamping guarantees that blockchains provide.

The JSON Digest selective disclosure mechanism offers a practical alternative to pairing-based approaches (BBS+, CL-signatures): simpler implementation, post-quantum compatible hash functions, and recursive structural masking – at the cost of presentation linkability. For the majority of credential use cases (KYC, professional certification, age verification), this tradeoff is acceptable.

The anti-censorship operation design – where authorization lives inside the signed operation rather than at the transaction submission layer – addresses a censorship vector unique to blockchain-anchored identity systems. Combined with materialized on-chain state ($O(1)$ resolution) and a six-right capability model, Mosaic DID provides a production-ready SSI architecture with 18 Rust crates, WebAssembly bindings, and a Substrate pallet reference implementation.

Appendix A: Reference Implementation Mapping

The reference implementation is available as open-source software. The following table maps paper concepts to implementation crates for reproducibility.

Paper Concept	Crate	Language
Keyvault (HD wallet)	keyvault	Rust
Multicipher abstraction	keyvault/multicipher	Rust
Morpheus protocol	morpheus-proto	Rust
JSON Digest	json-digest	Rust
Verifiable credentials	morpheus-proto/data	Rust
JWT encoding	morpheus-proto/crypto	Rust
Substrate DID pallet	pallet-mosaic-did	Rust
Mosaic DID types (no_std)	mosaic-did-types	Rust
Abstract journal	journal-proto	Rust
WebAssembly bindings	sdk-wasm	Rust/WASM
C FFI bindings	sdk-ffi	Rust/C

Appendix B: Novelty Matrix

System	Chain Agnostic	Sel. Discl.	Anti-Censor	Mat. State	Multi-Cipher	Off-Chain VC	Missing
did:ion [Buchner, 2021]	No	No	No	No	Partial	Yes	Bitcoin-locked, event-sourced
did:ethr [Thorstensson, 2019]	No	No	Partial	Yes	No	No	Ethereum-locked, no SD
did:web	No	No	No	Yes	Partial	Partial	Centralized (DNS/HTTPS)
did:key	Yes	No	N/A	No	Partial	Partial	No persistence
KERI [Smith, 2021]	Yes	No	N/A	No	Partial	Yes	No SD, correlatable AIDs
AnonCreds [Group, 2023]	No	Yes	No	Partial	No	Partial	Indy-locked, pairing curves
KILT Protocol	No	Partial	No	Yes	No	Yes	KILT parachain-locked
Mosaic DID	Yes	Yes	Yes	Yes	Yes	Yes	–

References

1. [1] {Certicom Research. {SEC. 2000.
2. [2] {Hyperledger AnonCreds Working Group. {AnonCreds. 2023.
3. [3] {Parity Technologies. Substrate: The Blockchain Framework for a Multichain Future. Software framework, 2018.
4. [4] Alberto Sonnino, Mustafa Al-Bassam, Shehar Bano, Sarah Meiklejohn, George Danezis. Coconut: Threshold Issuance Selective Disclosure Credentials with Applications to Distributed Ledgers. Proceedings of the 26th Annual Network and Distributed System Security Symposium ({NDSS, 2019. [link]
5. [5] Alex Biryukov, Daniel Dinu, Dmitry Khovratovich. Argon2: New Generation of Memory-Hard Functions for Password Hashing and Other Applications. Proceedings of the 2016 {IEEE, 2016. [link]
6. [6] Anders Rundgren, Bret Jordan, Samuel Erdtman. {JSON. 2020. [link]
7. [7] Christopher Allen. The Path to Self-Sovereign Identity. Blog post, 2016.
8. [8] Dan Boneh, Xavier Boyen, Hovav Shacham. Short Group Signatures. Advances in Cryptology -- {CRYPTO, 2004. [link]
9. [9] Daniel Buchner, Tobias Looker, Orie Steele. {DID. 2019.
10. [10] Daniel Buchner, Orie Steele, Tobias Looker. Sidetree Protocol Specification v1.0. 2021.
11. [11] Daniel Fett, Kristina Yasuda, Brian Campbell. Selective Disclosure for {JWTs. 2024.
12. [12] Daniel J. Bernstein, Niels Duif, Tanja Lange, Peter Schwabe, Bo-Yin Yang. High-Speed High-Security Signatures. Journal of Cryptographic Engineering, 2012. [link]
13. [13] Eli Ben-Sasson, Iddo Bentov, Yinon Horesh, Michael Riabzev. Scalable, Transparent, and Post-Quantum Secure Computational Integrity. Advances in Cryptology -- {CRYPTO, 2019. [link]
14. [14] Gavin Wood. Polkadot: Vision for a Heterogeneous Multi-Chain Framework. White Paper, 2016.
15. [15] Gavin Wood. Ethereum: A Secure Decentralised Generalised Transaction Ledger. Yellow Paper, {EIP, 2014.
16. [16] Hugo Krawczyk, Pasi Eronen. {HMAC. 2010. [link]
17. [17] Jack O'Connor, Jean-Philippe Aumasson, Samuel Neves, Zooko Wilcox-O'Hearn. {BLAKE3. Specification, 2020.
18. [18] Jan Camenisch, Anna Lysyanskaya. Signature Schemes and Anonymous Credentials from Bilinear Maps. Advances in Cryptology -- {CRYPTO, 2004. [link]
19. [19] Jan Camenisch, Els {Van Herreweghen. Design and Implementation of the {idemix. Proceedings of the 9th {ACM, 2002. [link]
20. [20] Jean-Philippe Aumasson, Samuel Neves, Zooko Wilcox-O'Hearn, Christian Winnerlein. {BLAKE2. Applied Cryptography and Network Security ({ACNS, 2013. [link]
21. [21] Jens Groth. On the Size of Pairing-Based Non-interactive Arguments. Advances in Cryptology -- {EUROCRYPT, 2016. [link]
22. [22] Joel Thorstensson, Pelle Braendgaard, Mircea Nistor, Oliver Terbu. {did:ethr. 2019.
23. [23] John R. Douceur. The {Sybil. Peer-to-Peer Systems: First International Workshop ({IPTPS, 2002. [link]
24. [24] Manu Sporny, Dave Longley, Markus Sabadello, Drummond Reed, Orie Steele, Christopher Allen. Decentralized Identifiers ({DIDs. 2022.
25. [25] Manu Sporny, Dave Longley, David Chadwick. Verifiable Credentials Data Model v1.1. 2022.
26. [26] Manu Sporny, Dave Longley, Dmitri Zagidulin, Orie Steele. {did:key. 2021.
27. [27] Manu Sporny, Dave Longley, Gregg Kellogg, Markus Lanthaler, Pierre-Antoine Champin, Niklas Lindstr{\"o. {JSON-LD. 2020.
28. [28] Marek Palatinus, Pavol Rusnak, Aaron Voisine, Sean Bowe. {BIP. 2013.
29. [29] Michael Prorock, Orie Steele, Oliver Terbu. {did:web. 2023.
30. [30] Peter W. Shor. Polynomial-Time Algorithms for Prime Factorization and Discrete Logarithms on a Quantum Computer. SIAM Journal on Computing, 1997. [link]
31. [31] Pieter Wuille. {BIP. 2012.
32. [32] Ralph C. Merkle. A Digital Signature Based on a Conventional Encryption Function. Advances in Cryptology -- {CRYPTO, 1988. [link]
33. [33] Samuel M. Smith. Key Event Receipt Infrastructure ({KERI. 2021.
34. [34] Stefano Tessaro, Chenzhi Zhu. Revisiting {BBS. Advances in Cryptology -- {EUROCRYPT, 2023. [link]
35. [35] Whitfield Diffie, Martin E. Hellman. New Directions in Cryptography. IEEE Transactions on Information Theory, 1976. [link]