Self-Sovereign Identity & Cryptographic Keys

• Self-Sovereign Identity & Keys is a decentralized framework that enables user-centric digital identity management using locally generated cryptographic key pairs and resolvable DIDs.
• The system employs a finite state machine for key lifecycle management, covering creation, binding, rotation, revocation, and recovery to ensure secure operations.
• Key management design patterns such as master-subkey delegation, hot-cold wallet storage, and threshold key sharding provide resilience and interoperability across different deployment contexts.

Self-sovereign identity (SSI) is a paradigm for decentralized, user-centric control over digital identifiers and credentials, fundamentally grounded in cryptographic key management. SSI dispenses with central authorities for identity assertion and instead lets users, organizations, or devices generate, store, rotate, and recover cryptographic key pairs anchoring decentralized identifiers (DIDs). Key management, ledger anchoring, credential issuance, presentation, secure communication, and interoperability are orchestrated via standardized operations and protocols. This article synthesizes the essential models, reference architectures, cryptographic primitives, lifecycle operations, and cross-system considerations for SSI keys, referencing published models and protocols.

1. Key Generation, Binding, and SSI Data Model

The foundation of SSI is public-key cryptography, with identity authority rooted in possession of secret keys. Key generation is a local, controller-side operation using schemes such as Ed25519, X25519, secp256k1, P-256/ECDSA, or BBS+ (for selective disclosure ZKP use cases) (Yildiz et al., 2022, Reece et al., 2022). Given a key-generation algorithm $\mathcal K$ and group generator $G$: $sk \;\stackrel{\$}{\leftarrow}\; \mathcal{K}, \quad pk = G(sk)$The controller publishes only the public key$pk$$in association with a <a href="https://www.emergentmind.com/topics/decentralized-identity-did-layer" title="" rel="nofollow" data-turbo="false" class="assistant-link" x-data x-tooltip.raw="">DID</a>—a URI such as <code>did:example:1234567890abcdefghi</code>.</p> <p>The DID Document is a JSON(-LD) object specifying:</p> <ul> <li><code>verificationMethod</code>: array of key definitions, e.g.,$$G$5

Key usage: authentication, assertion, keyAgreement, or delegation

Optional service endpoints

This DID Document is resolvable via a DID Resolver to obtain the current public key(s) for the DID, supporting both authenticity and trust establishent (Yildiz et al., 2022, Garzon et al., 2021).

2. Key Lifecycle: States, Rotation, and Recovery

SSI systems formalize key lifecycle per a finite state machine with canonical states (Liu et al., 2020):

• Created → Stored → Bound → Rotated/Compromised/Revoked/Recovered

Key management operations include:

• Binding: registering a public key to a DID and anchoring it (potentially on a blockchain or distributed ledger)
• Rotation: on compromise or expiration, controllers generate a fresh key pair $(sk', pk')$and update the DID Document with$pk'$$, removing or marking the previous key as revoked</li> </ul> <p>$$\text{old DIDDoc} \xrightarrow{\scriptstyle \text{update}} \text{new DIDDoc with } pk'$$</p> <ul> <li><strong>Recovery</strong>: threshold secret sharing (e.g., Shamir’s) can split a private key into$$n$shares, requiring any$t$of$n$to reconstruct:</li> </ul> <p>$G$0

  Recovery ensures resilience against device loss or local compromise (Liu et al., 2020). Recovery events are expected to trigger DID Document updates for replacement or re-assignment of keys.

  • Revocation: key deletion or credential status flipping. Key and credential revocations are managed via status lists (bitstrings), accumulators (e.g. for CL-signatures in Hyperledger Indy), or explicit revocation registry entries. Verifiers must validate the current status of the key or delegated right before accepting proofs (Yildiz et al., 2022, Reece et al., 2022).

  3. Key Management Design Patterns and Authorization

  SSI systems adopt several design patterns to support diverse operational and security requirements (Liu et al., 2020, Liu et al., 2020):

  • Master-Subkey Generation: A master (“root”/“management”) key delegates to subordinate signing or agreement keys. Subkeys may be bound to different DIDs or usage contexts. Only the master key is authorized to update (rotate, revoke) subkeys, with all such updates reflected in the on-ledger DID Document.
  • Hot-Cold Wallet Storage: Keys required for high-value operations (master keys) are stored on cold, air-gapped or hardware-protected wallets, while subkeys for day-to-day use may reside in hot (online) wallets.
  • Threshold Key Sharding (Recovery): Critical keys are split into $G$1 shares distributed among trusted guardians, supporting $G$2 recovery.
  • Delegate List / Group-Controlled DIDs: DID Documents may specify multiple controllers (e.g., via a controller array) and governance thresholds (e.g., N-of-M voting), supporting collective control and programmable key rotation (Segat et al., 8 Jul 2025).

  Table: Key Management Patterns in SSI | Pattern | Purpose | Implementation Context | |------------------|------------------------------|---------------------------------------| | Master-Subkey | Risk partitioning, privacy | On-ledger with auth-signature checks | | Hot-Cold Wallet | Security vs. usability trade | Hardware, local storage | | Threshold Shards | Loss resilience | Off-chain share distribution | | Delegation | Controlled authority sharing | DID Document + programmable contracts |

  4. Credential Issuance, Presentation, and Verification

  Verifiable Credentials (VCs) encode assertions about a subject. Key usage in the credential lifecycle is as follows (Yildiz et al., 2022, Reece et al., 2022):

  • Issuance: Issuer signs the credential contents using their private key (anchored in the issuer’s DID Document):

  $G$3

  • Presentation: The holder can present VCs or derive privacy-preserving verifiable presentations (e.g., using BBS+, CL, or ZKP suites), potentially revealing only a subset of attributes.
  • Verification: Verifier resolves the issuer's public key via DID resolution, verifies the cryptographic signature, and checks the current (non-revoked) status of keys and credentials.

  Advanced ZKPs (e.g., BBS+) facilitate unlinkability and selective disclosure, critical for privacy preservation in practical deployments (Yildiz et al., 2022).

  5. Secure Communication and Protocol Interoperability

  SSI leverages cryptographic keys for secure channel establishment and authenticated messaging, commonly via DIDComm v2 (Yildiz et al., 2022). DIDComm protocols standardize an envelope and handshake model wherein participants securely exchange ephemeral and static keys, authenticate each other by resolving DIDs, and then derive a symmetric session key: $G$4 DIDComm is protocol-agnostic, supporting layering over arbitrary transport mechanisms.

  For web interoperability, SSI solutions bridge to standards such as OpenID Connect (OIDC) via SIOPv2 (Self-Issued OpenID Provider) and OIDC4VP (OIDC for Verifiable Presentations), wrapping VCs or ZK presentations in JWTs (Yildiz et al., 2022, Lux et al., 2020). Signature suite and credential format translation (e.g., Ed25519 ↔ JWK, LD Proofs vs. JWTs) is an interoperability requirement, with suite upgrades, translation layers or facade APIs required to guarantee multi-stack compatibility.

  DID Resolving infrastructure (e.g., Universal Resolver) abstracts over heterogeneous DID methods and ledgers (did:web, did:ion, did:ethr, did:key, etc.) to yield a normalized DID Document shape (Yildiz et al., 2022).

  6. Security Properties, Governance, and Audit

  SSI systems derive their security from the following guarantees (Yildiz et al., 2022, Garzon et al., 2021, Segat et al., 8 Jul 2025):

  • Authenticity: Determined by control over private key and anchoring of public keys in a tamper-evident, often append-only, registry (blockchain or equivalent).
  • Non-repudiation: Signatures on credentials, presentations, and protocol handshakes, time-stamped and ledger-anchored.
  • Revocation and rotation: Immediate cryptographic invalidation of compromised or obsolete keys and credentials via on-chain or off-chain revocation registries.
  • Delegated/group control: Formal governance policies are supported for group-controlled DIDs, using on-ledger N-of-M threshold policies and auditable aggregation (e.g., BLS signatures for quorum-based updates) (Segat et al., 8 Jul 2025).
  • Resilience and privacy: Pairwise DIDs and off-chain encrypted storage mitigate correlation and privacy risks. Threshold key recovery and guardian models reduce the risk of permanent identity loss.

  Programmable architectures allow for policy-driven delegation, least-privilege rights transfer, and efficient update management for long-lived identifiers (Saavedra, 21 Jan 2026).

  7. Practical Deployment, Privacy, and Open Challenges

  SSI has been implemented in sectors such as mobility (e.g., electric vehicle charging (Kailus et al., 2024)), IoT (Perugini et al., 2023), finance, healthcare, and public sector digital identity (Reece et al., 2022), with deployments using permissioned ledgers (Hyperledger Indy/Sovrin), public blockchains, or decentralized name systems.

  Privacy is preserved by ensuring DIDs are non-revealing, never storing personal data on the ledger, and using privacy-preserving revocation (accumulator, pairwise VCs, or redactable proofs). Credential presentations minimize exposure via OIDC4VP, DIDComm, or equivalent protocols, with all private keys ideally isolated in secure hardware elements or strong software keystores (Schardong et al., 2021).

  Key open challenges include:

  • Scalability of ledger writes for high-frequency key events
  • Usability of recovery and backup for non-expert users
  • Interoperability among dozens of evolving DID methods, credential formats, and proof suites
  • Efficient integration of ZKPs for selective disclosure in real-world workflows
  • Programmable governance for group-controlled DIDs (Segat et al., 8 Jul 2025) and secure delegation to AI agents (Saavedra, 21 Jan 2026)

  These developments continue to evolve the SSI paradigm toward a fully decentralized, privacy-preserving, and auditably governed digital identity landscape (Yildiz et al., 2022).