Copyright © 2026 World Wide Web Consortium. W3C® liability, trademark and permissive document license rules apply.
SSIMPL defines a self-sovereign identity framework backed by government-issued trust anchors and a peer-validated ledger.
As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.
The key words MAY, MUST, MUST NOT, and SHOULD in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
This section describes the status of this document at the time of its publication. A list of current W3C publications and the latest revision of this technical report can be found in the W3C standards and drafts index.
This document was published by the Verifiable Credentials Working Group, the Decentralized Identifier Working Group, and the Web Authentication Working Group as an Editor's Draft.
Publication as an Editor's Draft does not imply endorsement by W3C and its Members.
This is a draft document and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to cite this document as other than a work in progress.
This document was produced by groups operating under the W3C Patent Policy. W3C maintains a public list of any patent disclosures (Verifiable Credentials Working Group), a public list of any patent disclosures (Decentralized Identifier Working Group), and a public list of any patent disclosures (Web Authentication Working Group) made in connection with the deliverables of each group; these pages also include instructions for disclosing a patent. An individual who has actual knowledge of a patent that the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
This document is governed by the 18 August 2025 W3C Process Document.
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:
The protocol balances decentralization, peer authority, and optional server-assisted synchronization for efficiency and availability. Everything is made to be deterministic by default, so no authorities whatsoever are required except the one that signed the Trust Anchor.
SSIMPL identities are rooted in cryptographically verifiable credentials derived from Trust Anchors (TA), such as government-issued ePassports. A valid wallet:
This ensures only owners of verified physical credentials can create valid DIDs.
Identity is hard to verify by nature. Using a state-issued TA is not a perfect solution, but it's the best deterministic proof of identity available at the moment.
The wallet is a Self-Sovereign means of identification that can be installed and bootstrapped entirely independent of any authority. It solely relies on cryptographic proof.
Wallets MUST:
did:key for interoperability.Wallets SHOULD:
This canonical signature object pattern provides a single, consistent approach for proving authorship and integrity across all SSIMPL objects.
In order to function properly, it is essential certain behavior is implemented:
The Relay Peer is a special kind of Peer in the sense that it is static and reachable over the internet on a fixed hostname. It acts like any other Peer, but it also adds a storage layer for the Ledger and serves as distribution point for the Ledger. All Relay Peers together form a subnetwork on which all other (mobile) Peers 'ride'. This is purely infrastructural to help communication between Peers. It doesn't give any special privileges or authorities to any of the Relay Peers and does therefor still fulfill all requirements to be called decentralized.
To enable deterministic network formation and secure onboarding of Relay Peers, the SSIMPL protocol defines a bootstrap and verification procedure.
The first time a new Relay Peer is bootstrapped, it MUST make itself known to a known (or a well-known Relay Peer,
e.g., root.ssimpl.org) to
obtain the first list of known Relay Peers. This is a hard-coded node that allows the network to kickstart itself and to
have zero knowledge upfront when adding a new Relay Peer.
Upon first contact with the network, a new Relay Peer:
The SSIMPL ledger is a deterministically canonical, peer-replicated structure tracking valid DIDs, maintained across Peers and Relay Peers.
did_expiry and GRACE_PERIOD.did_expiry then by hash(did).root_hash using a Merkle tree over the current, complete, pruned ledger.The SSIMPL ledger uses a Merkle tree to enable efficient verification of ledger state and individual entries.
root_hash representing the current canonical ledger state.xyz, a peer can provide the leaf hash and the branch hashes up to root_hash.root_hash.root_hash for a specific epoch.An entry is valid if:
current_time < did_expiry + GRACE_PERIOD.hash(verifiable_credential_root.data) equals verifiable_credential_root.signature_document.message.signature_document.signature.public_key.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.
Peers MAY remove their own entries and expired entries. To revoke a DID:
Peers MUST NOT remove valid entries or modify others' entries.
Deterministic pruning ensures consistent ledger state across peers.
{ epoch, root_hash } metadata.To enable efficient verification of ledger history and prevent forks from propagating, the SSIMPL protocol introduces Merkle checkpoints. These checkpoints allow peers to validate that their current ledger state stems from a previously agreed-upon canonical state.
A Merkle checkpoint is a snapshot of the canonical ledger at a given epoch, containing:
Merkle checkpoints serve three main purposes:
To verify a ledger using a checkpoint:
A mismatch indicates ledger tampering or divergence, and the peer MUST reject the inconsistent entries.
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.
To ensure that signatures are verifiable and consistent across all peers, every signed object in SSIMPL (including LedgerEntry and VerifiableCredentialRoot) MUST be serialized in a canonical form before hashing and signing. These rules remove ambiguity in encoding and field ordering, preventing mismatches between peers.
To verify a signature:
Canonicalization guarantees that:
All cryptographically signed objects in SSIMPL MUST follow a uniform, canonical structure, known as the * SignatureEnvelope*. This ensures consistency across all signed data, including ledger entries, Verifiable Credential Roots (VCR), revocations, and delta payloads.
Each signed object MUST include a SignatureEnvelope with the following structure:
message — The cryptographic hash of the canonical serialization of the data object.signature — Object containing the signature itself:publicKey — Base64url-encoded public key corresponding to the signing private key.algorithm — Signature algorithm used (e.g., EdDSA, ECDSA).value — Base64url-encoded signature value.signer — DID of the entity producing the signature.Example (in JSON for clarity):
{
"message": "<hash-of-canonical-data>",
"signature": {
"publicKey": "<multibase-encoded public="" key="">",
"algorithm": "<algorithm identifier="">",
"value": "<multibase-encoded signature="">"
},
"signer": "<did of="" signer="">"
}
This section defines the reference API for Relay Peers in the SSIMPL protocol. It provides endpoints for DID registration, revocation, and ledger synchronization.
All requests MUST be authenticated using a Bearer token, containing a signed DID in the canonical
SignatureEnvelope format, multibase-encoded.
POST /identity
Purpose: Allows (Relay) Peers to check the health an initial validity of the Relay Peer
Request payload (LedgerDeltaRequest):
| Field | Type | Description |
|---|---|---|
| data | integer | Last ledger epoch known to the peer |
| signatureEnvleope | string | Merkle root hash of the peer's current ledger state |
POST /ledger/delta
Purpose: Allows a Peer to request ledger entries that are newer than a given epoch, if the peer is out of sync.
Request payload (LedgerDeltaRequest):
| Field | Type | Description |
|---|---|---|
| lastEpoch | integer | Last ledger epoch known to the peer |
| rootHash | string | Merkle root hash of the peer's current ledger state |
Example:
{
"lastEpoch": 42,
"rootHash": "abcdef1234567890"
}
Response payload (LedgerDeltaResponse):
Field Type Description currentEpoch integer Current epoch of the relay peer ledger authoritativeRootHash string Merkle root hash after applying returned entries array Ordered ledger entries newer than lastEpoch
Example:
{
"currentEpoch": 43,
"authoritativeRootHash": "1234abcd5678ef90",
"entries": [
{
"data": {
"verifiableCredentialRoot": {
...
},
"proof": {
...
}
},
"signatureEnvelope": {
...
}
}
]
}
⸻
Register a DID
POST /ledger
Purpose: Register a new DID on the ledger.
Request payload: LedgerEntry object
Example:
{
"data": {
"verifiableCredentialRoot": {
...
},
"proof": {
...
}
},
"signatureEnvelope": {
...
}
}
Response: 200 OK on success.
⸻
Revoke a DID
PUT /ledger
Purpose: Revoke a DID by submitting a revocation payload.
Request payload: LedgerEntryRevocation object
Example:
{
"data": {
"did": "did:key:z6Mkw...example"
},
"signatureEnvelope": {
...
}
}
Response: 200 OK on success.
⸻
Shared Object Schemas
| Field | Type | Description |
|---|---|---|
| data | object | Contains the actual fields used for the signature |
| signatureEnvelope | object | Signature verifying the data |
| Field | Type | Description |
|---|---|---|
| data | object | Contains verifiableCredentialRoot and proof |
| signatureEnvelope | object | Signature verifying the integrity of data |
| Field | Type | Description |
|---|---|---|
| did | object | Contains did and identityDocumentHash |
| identityDocumentHash | object | Signature verifying the data |
| Field | Type | Description |
|---|---|---|
| data | object | Contains the DID being revoked |
| signatureEnvelope | object | Signature verifying the revocation |
| Field | Type | Description |
|---|---|---|
| DG15 | string | Data group 15 proof |
| AASignature | string | Active Authentication signature |
| AAChallenge | string | Active Authentication challenge |
| SOD | string | Security Object Document |
| Field | Type | Description |
|---|---|---|
| message | string | Canonical serialized representation of the signed data |
| signature | object | Signature object containing algorithm, publicKey, and value |
| signer | string | DID or public key identifier of the signer |
| Field | Type | Description |
|---|---|---|
| publicKey | string | Public key of signer |
| algorithm | string | Signing algorithm |
| value | string | Multibase-encoded signature value |