SSIMPL Specification – W3C Submission Draft

1. Overview

The SSIMPL protocol defines a Self-Sovereign Identity & Mondial Pseudonymous Ledger framework that allows individuals to maintain control over their digital identity while enabling verifiable credential issuance and revocation. It bridges physical trust anchors (e.g., ePassports) with digital identity systems, ensuring cryptographic verification without reliance on centralized authorities.

SSIMPL addresses two key problems:

  1. User control over digital identity – eliminating reliance on centralized identity providers.
  2. Verification of identities – ensuring online credentials correspond to real individuals using cryptographic proofs.

The protocol balances decentralization, peer authority, and optional server-assisted synchronization for efficiency and availability.

2. Identity Trust Model

SSIMPL identities are rooted in cryptographically verifiable credentials derived from Trust Anchors (TA), such as government-issued ePassports. A valid wallet:

  • Scans a Trust Anchor (TA) via NFC.
  • Performs an Active Authentication (AA) challenge.
  • Derives a Verifiable Credential Root (VCR) tied to the user’s DID.
  • Publishes this Verifiable Credential Root to Relay Peers.

This ensures only owners of verified physical credentials can create valid DIDs.

2.1 Levels of Authentication

  • Level 0: DID confirms human ownership (bot detection).
  • Level 1: Level 0 + unverified attributes requested via scope.
  • Level 2: Level 1 + verified credentials requested via scope.

3. Components

  • Peers: Mobile devices with the wallet installed.
  • Relay Peers: Servers that act both as Peers and distribution points, allowing other Peers to sync their ledger.

4. Wallet Requirements

Wallets MUST:

  • Perform NFC scans of Trust Anchors.
  • Support Active Authentication challenge verification.
  • Derive BIP32 keypairs from a BIP39 mnemonic.
  • Sign and manage the Verifiable Credential Root.
  • Generate DIDs compliant with did:key for interoperability.
  • Support JWT issuance and asymmetric key exchange.

Wallets SHOULD:

  • Encrypt credentials for local storage.
  • Store additional credentials such as DG11 for user convenience.
  • Send their signed VCR to Relay Peers.

4.1 Activation Process

  1. User installs wallet.
  2. Wallet prompts for MRZ line.
  3. NFC scan and extraction of passport data.
  4. Creation of Verifiable Credential Root.
  5. BIP39 mnemonic generation.
  6. BIP32 keypair derivation and storage.
  7. Signing of the VCR.
  8. Submission of the VCR to a Relay Peer.

5. Ledger Specification

The SSIMPL ledger is a deterministically canonical, peer-replicated structure tracking valid DIDs, maintained across Peers and Relay Peers.

5.1 Ledger Goals

  • Track valid DIDs without a central authority.
  • Support bounded state and deterministic pruning.
  • Enable single-peer verification.
  • Eventual consistency via optional gossip or client/server synchronization.
  • Mobile-friendly operation for large ledgers (5–30 GB).

5.2 Ledger Entries

Each DID Registration Entry contains:

  • data – Core credential and cryptographic proofs.
  • signature_document – Signature verifying the integrity of data.

data object contains:

  • verifiable_credential_root (did,did_expiry, ta_hash).
  • proof (DG15, AASignature, AAChallenge, SOD).

signature_document contains:

  • message – Hashed data.
  • signature – { public_key, algorithm, value }.
  • signer – DID of signing entity.

5.3 Ledger State and Canonical Construction

  1. Filter expired entries based on did_expiry and GRACE_PERIOD.
  2. Normalize entries into canonical byte format.
  3. Sort lexicographically by did_expiry then by hash(did).
  4. Compute root_hash using a Merkle tree over the current, complete, pruned ledger.

5.4 Ledger Validation Rules

An entry is valid if:

  1. current_time < did_expiry + GRACE_PERIOD.
  2. HASH(verifiable_credential_root.data) equals verifiable_credential_root.signature_document.message.
  3. The public key in the DID matches signature_document.signature.public_key.
  4. Signature verification succeeds: verify_signature( verifiable_credential_root.signature_document.message, verifiable_credential_root.signature_document.signature.value, verifiable_credential_root.signature_document.signature.public_key, verifiable_credential_root.signature_document.signature.algorithm )

Expired or invalid entries are ignored and removed during canonical construction.

5.5 Pruning and Mutability

  • Peers MAY remove their own entries and expired entries. To revoke a DID:

  • Remove the DID from the local ledger.

  • Submit a revocation payload to Relay Peers, containing:

  • data – { did, effective_epoch, previous_root_hash, new_root_hash, signature_by_did_key }.

  • signature_document – Signature verifying data.

  • Peers MUST NOT remove valid entries or modify others' entries.

  • Deterministic pruning ensures consistent ledger state across peers.

5.6 Synchronization

  • Peers exchange (epoch, root_hash) metadata.
  • Matching hash: No action required.
  • Hash mismatch: Request missing entries or snapshots.
  • Iterative delta exchange ensures eventual convergence.
  • Relay Peers act as distribution points while also validating entries.
  • Stateless Relay Peers may bootstrap from peers but should persist data for efficiency.

5.7 Security Properties

  • Single-peer revocation verification.
  • Privacy-preserving registration.
  • Resistance to illegal pruning and tampering.
  • Bounded state growth.
  • Eventual convergence under client/server synchronization.

6. Conclusion

SSIMPL provides a self-sovereign identity framework with a deterministic, peer-validated ledger, enabling secure, verifiable DIDs anchored in government-issued credentials.

All entries and operations are canonical, rule-derived, and independently verifiable by peers, ensuring a fully trustworthy and decentralized identity ecosystem.