Summary

This PR introduces the core infrastructure for the did:mosaic DID method on the Mosaic Trust Network, derived from the IOP Morpheus SSI Stack. It includes type definitions, DID document state management, and a Substrate pallet implementing Phase 1 (MVP) operations.

Key Changes

New Crates

• mosaic-did-types — Core type definitions for the DID system:

  • Did — DID identifiers derived from BLAKE3-256 hash of initial public key
  • KeyId, ContentId — Identifiers for keys and content
  • DidOperation — 5 core Phase 1 operations (AddKey, RevokeKey, AddRight, RevokeRight, TombstoneDid)
  • Right — 6-right model (Update, Impersonate, Delegate, Issue, Revoke, Recovery)
  • KeyType, KeyPurpose — Cryptographic algorithm and W3C verification relationship types
  • MultiSignature, MultiPublicKey — Algorithm-agile signature support (Ed25519, secp256k1)
  • DidDocumentState — Internal state representation with key validity tracking and rights management
  • DidDocument — W3C DID Core 1.0 compliant JSON output structure

• pallet-mosaic-did — Substrate pallet for on-chain DID management:

  • submit_did_operations — Atomic batch submission of signed DID operations
  • register_before_proof — Permissionless BeforeProof timestamp registration
  • Storage maps for operations audit log, nonces, tombstoned DIDs, and BeforeProof records
  • Validation logic for operation authorization and replay protection
  • Comprehensive unit tests covering DID creation, key rotation, rights management, and tombstoning

Implementation Details

• Anti-censorship design: Transaction submitter account ≠ DID controller; authorization verified via cryptographic signatures inside operations
• Implicit DID creation: First AddKey operation creates the DID; identifier must equal BLAKE3-256(public_key)
• Implicit rights: Initial key automatically has Update and Impersonate rights; other rights must be explicitly granted
• Replay protection: Per-key nonce tracking prevents operation replay
• Atomic batching: All operations in a batch succeed or all fail; no partial state changes
• Historical state: DID documents can be reconstructed at any block height by replaying operations
• W3C compliance: DID documents output in W3C DID Core 1.0 format with Mosaic-specific extensions

Testing

• Unit tests validate DID creation, string serialization, operation types, rights system, and DID document state reconstruction
• Tests cover key rotation flows, tombstoning, and validity checking at specific block heights

Notes

• Phase 1 focuses on core DID operations and BeforeProof; Phase 2 will add service endpoints, recovery operations, and additional key types
• Full cryptographic signature verification is deferred to RPC query layer where DID document state can be reconstructed