Unofficial Draft
Copyright © 2026 the document editors/authors. Text is available under the Creative Commons Attribution 4.0 International Public License; additional terms may apply.
SSIMPL defines a self-sovereign identity framework backed by government-issued trust anchors and a peer-validated ledger.
This document is an independent Editor’s Draft published by the SSIMPL project. It is not affiliated with, endorsed by, or produced by the World Wide Web Consortium (W3C) or any W3C Working Group.
This draft may change at any time and should not be considered a stable standard.
No patent commitments are made through W3C or any standards organization.
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.
The internet has evolved rapidly, but with each iteration new challenges have emerged in protecting personal data. While legislation attempts to safeguard users’ rights, technical solutions are often necessary to prevent misuse and unauthorized access to sensitive information.
Current authentication and authorization methods rely heavily on centralized providers. OpenID Connect flows and other single sign-on mechanisms place identity management in the hands of commercial services, which cannot always guarantee the trustworthiness or privacy of the credentials they issue.
In contrast, physical-world identity verification relies on standardized, verifiable documents such as passports or driver’s licenses. Informal authorization uses signatures or initials, which provide contextually appropriate trust without centralized control. SSIMPL was designed to replicate these principles in the digital realm, providing self-sovereign, verifiable credentials while minimizing reliance on third-party intermediaries.
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 several key problems:
The protocol balances decentralization, peer authority, and (optional) server-assisted reconciliation 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 (TA).
SSIMPL identities are rooted in cryptographically verifiable credentials derived from Trust Anchors, such as government-issued ePassports. A valid wallet:
This ensures only owners of verifiable 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 (human) identity available at the moment.
These different levels allow people to authenticate themselves on several levels, depending on the context. Say a person would like to order a product from a website. Using SSIMPL, the webshop could request a certain scope of credentials (like a shipping address). The owner of the identity could then approve or disapprove this request. This flow is very similar to Open ID Connect, except that there is no need for a 3rd party.
A SSIMPL DID captures several things: a public key used for signing tied to a verifiable identity and the network where the identity is registered. The significance of the signature can be as little as 'I am a human being and have signed this piece of data', or as much as 'I am John Doe, age 39, and this is my DID'. DIDs rely on the owners ability to restore them when necessary, with the use of the BIP39 mnemonic.
A did:ssimpl identifier has the following structure,
conforming to the generic DID syntax defined in [DIDCORE]:
ssimpl-did = "did:ssimpl:" ssimpl-specific-id ssimpl-specific-id = Multibase( network-bytes || pk-bytes ) network-bytes = country-bytes subnetwork-byte node-byte country-bytes = 3ALPHA ; ICAO 9303 alpha-3 country code subnetwork-byte = 1OCTET ; unsigned integer 0–255 node-byte = 1OCTET ; unsigned integer 0–255 pk-bytes = 33OCTET ; compressed secp256k1 public key
The method-specific identifier is a single Multibase-encoded opaque string. It encodes 38 bytes: 3 bytes of country code, 1 byte of subnetwork identifier, 1 byte of node identifier, and 33 bytes of compressed public key. No delimiters are used. Decoding is deterministic by fixed byte offset.
The 38-byte payload prior to Multibase-encoding is laid out as follows:
| Offset | 0 | 1 | 2 | 3 | 4 | 5 – 37 |
| Field | Country (3 bytes) | Subnetwork (1 byte) | Node (1 byte) | Public Key (33 bytes) | ||
| Example | N |
L |
D |
0x00 |
0x03 |
02ab cd… |
The country code MUST be an ICAO 9303 [ICAO9303] alpha-3 code encoded as ASCII uppercase bytes. The subnetwork and node fields are unsigned 8-bit integers (range 0–255). The public key is a 33-byte compressed secp256k1 public key.
Given a did:ssimpl identifier, the following algorithm
recovers the network coordinates and public key:
did:ssimpl: prefix to obtain the
method-specific identifier string.
bytes[0..2] (inclusive) as the country
code. Interpret as ASCII. The result MUST be a valid ICAO
9303 alpha-3 country code.
bytes[3] as the subnetwork identifier
(unsigned integer).
bytes[4] as the node identifier
(unsigned integer).
bytes[5..37] (inclusive) as the 33-byte
compressed secp256k1 public key.
The keypair corresponding to a did:ssimpl identifier
is derived using [BIP32] hierarchical deterministic key derivation.
The seed is computed as:
seed = HASH( mnemonic ) DID keypair = BIP32( seed )
Where mnemonic is the user's secret mnemonic phrase, and HASH
is a cryptographically secure hash function (SHA-256 or equivalent).
For TA-backed identities, the mnemonic is additionally bound to the passport's AA public key:
seed = HASH( mnemonic || HASH( aa_public_key ) )
This binding ensures that possession of the DID keypair implicitly attests possession of the corresponding passport material, without exposing the AA public key or mnemonic to any external party.
The salt MUST be changed between identity rotation events to ensure that successive DIDs derived from the same mnemonic are computationally unlinkable.
SSIMPL networks are organised hierarchically by country and subnetwork. Each country identified by its ICAO 9303 alpha-3 code constitutes a top-level network. Large countries MAY be subdivided into subnetworks to bound ledger size on mobile devices.
Every peer holds a complete copy of the ledger for their own network. No peer holds a privileged or partial role. Relay peers and wallet peers are structurally identical.
A network SHOULD be sized such that its ledger remains manageable on a contemporary mobile device. A suggested ceiling is one million registered identities per subnetwork, corresponding to approximately 200 megabytes of ledger storage at maximum capacity. This is also where the subnetworks come into play. Each subnetwork can be used for one separate ledger. Depending on the identity you're interacting with, you either need your ledger AND theirs, or can keep using your own.
Individual nodes are addressed using DNS subdomain names under the networks domain
e.g. ssimpl.org. The addressing scheme is:
<country>.<subnetwork>.<node>.<domain>
Where <country> is the lowercase ICAO 9303
alpha-3 country code, <subnetwork> is the
decimal subnetwork number, and <node> is the
decimal node number.
A client wishing to reach any node within a given subnetwork MAY omit the node segment and resolve at the subnetwork level:
<country>.<subnetwork>.ssimpl.org ; any node in subnetwork <country>.ssimpl.org ; any node in country
DNS wildcard records SHOULD be configured to support these resolution patterns. The DNS infrastructure does not carry authoritative identity data; it serves only as a bootstrap mechanism for peer discovery.
Country codes in DNS addresses are lowercase for compatibility with DNS conventions, while country codes within DID byte payloads are uppercase ASCII per ICAO 9303.
Given a did:ssimpl identifier, the corresponding
network and node are resolved as follows:
country, subnetwork, and
node.
lower(country).subnetwork.node.ssimpl.org.
lower(country).subnetwork.ssimpl.org.
Country-based network segregation provides a natural bound on ledger size. Peers overwhelmingly interact with others from the same country, meaning most peers need only one ledger. Additional ledgers are downloaded lazily on first encounter with a foreign DID and MAY be pruned after a configurable period of inactivity.
For countries with populations where passport adoption would exceed the recommended per-subnetwork ceiling, additional subnetworks MUST be provisioned. Subnetwork assignment for new registrations SHOULD be load-balanced across available subnetworks within the country.
When a peer encounters a DID from a foreign network, they MUST download the relevant subnetwork ledger before verifying the identity. Ledgers are cached locally and synchronised incrementally on subsequent interactions.
A peer MAY pre-emptively download ledgers for networks they anticipate interacting with — for example, before international travel. Implementations SHOULD provide a mechanism for users to manage which ledgers are retained on their device.
Ledger freshness is maintained by delta synchronisation: a peer requests only entries added since their last known ledger state. Full re-download is not required after initial acquisition.
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. This cryptographic proof is contained within the so-called VCR. The Verifiable Credential Root is a VC, as defined in [VC], necessary to link the signer of this VC to the related public key & DID.
The VCR can also be used as the root of a chain of VCs. This way it can, either explicitly or implicitly, verify association to other credentials further up in the chain.
Wallets MUST:
did:key for interoperability.Wallets SHOULD:
A SSIMPL Wallet has certain security scenario's that need to be addressed
In order to mitigate the scenario where the user has no access to their wallet anymore, SSIMPL offers a relatively straight-forward solution: two Peers (you and someone you trust, like a close relative) exchange a complete Revocation. In case of emergency, either Peer can always revoke the other Peers DID.
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 therefore still fulfill all requirements to be called decentralized.
Any network can use their own domain
The ring serves two distinct purposes:
Index gaps MAY occur when a Relay Peer goes permanently offline. Gaps are acceptable and do not affect ring traversal. Re-indexing is outside the scope of this specification.
*if N >= 3, otherwise the minimum quorum should just be N
To enable deterministic network formation and secure onboarding of Relay Peers, the SSIMPL protocol defines a bootstrap and verification procedure.
Upon first contact with the network:
{country}.{subnetworkIndex}.{nodeIndex}.ssimpl.org pointing to the new Relay Peer's hostname. Where the network index can be
used to allow for multiple networks to co-exist.
Index assignment is strictly sequential: the assigned index MUST equal the highest currently assigned index plus one. The DNS controller is the sole arbiter of index assignment.
A newly registered Relay Peer MAY take several minutes to become discoverable via DNS, due to TTL propagation. This is acceptable behavior.
The ring traversal algorithm is used for both peer discovery and gossip propagation. Given a
node's own networkIndex n & nodeIndex i and the traversal purpose (discovery or propagation), a client or peer
MUST traverse as follows:
n.{i+1}.ssimpl.org.0.ssimpl.org.1, 2, ...) until a responsive peer is found or all indices up to
i have been exhausted.
{country}.n.{i+1}.ssimpl.org, push the change to each responsive peer in sequence.n.0.ssimpl.org and continue.A peer that receives a pushed change via gossip MUST validate the entry before storing it, and *MUST NOT* re-propagate it (the originating peer is responsible for reaching quorum).
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.
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.
*the way this index is shared is beyond the scope of this document. However, it is recommended to use a custom header like 'x-ssimpl-index'.
Repeat until reconciled:
If a Relay Peer encounters any kind of unrecoverable exception resulting in one or more missed entries, the ledgers' state will diverge from that of the network. This scenario should, eventually, be automatically repaired by other Peers requesting Delta's from the faulty Relay Peer. To spot divergence, the requested Relay Peer can see that the received 'currentEpoch' is larger than its own. A requested Relay Peer MUST in that scenario respond with 503 Service Unavailable and trigger a reconciliation process.
Because any Relay Peer may selectively withhold valid ledger entries — whether due to malice,
misconfiguration, or partial failure — no single peer's ledger can be considered authoritative
in isolation. The Merkle rootHash comparison allows a client to detect
divergence, but does not resolve it.
This section defines a reconciliation protocol that allows any peer or wallet to reconstruct the authoritative ledger state by exhaustively querying the ring.
The authoritative ledger state is defined as the union of all cryptographically valid entries across 2-N peers. This follows directly from two properties of the ledger:
Therefore: a larger valid ledger always supersedes a smaller one. Majority voting over
rootHash values is explicitly *not* the reconciliation mechanism — a single honest peer holding
one valid entry not present on any other peer is sufficient to make that entry canonical.
To perform full reconciliation, a client MUST:
rootHash over the canonical ledger. This is the post-reconciliation
authoritative state.
The client MAY then push any entries present in its reconciled ledger but absent from a given peer's ledger back to that peer, to aid network convergence.
The reconciliation protocol provides the following guarantees:
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 MUST be serialized in a canonical form before hashing and signing. These rules remove ambiguity in encoding and field ordering, preventing mismatches between peers.
Boolean and Null
true, false, and null MUST use JSON literals exactly as shown (case-sensitive).
There are many ways to encode raw bytes or strings, and more are being invented as we speak. It is highly inefficient to make these encodings contract-based. SSIMPL therefore highly recommends the use of the Multibase Data Format, as defined in [Multibase], which is deterministic.
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, 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>"
}
The following, canonical, JSON structure needs to be fed into a hash function (SHA-256 recommended) which results in the 'taHash'. It is specific for standardised ePassports. Other TAs should have their own canonical JSON structure.
{
"dateOfBirth": 580963131,
"documentExpiryDate": 1960861131,
"documentNumber": "ABC123...example",
"documentType": "P"
}
This canonical signature object pattern provides a single, consistent approach for proving authorship and integrity across all SSIMPL objects.
This section defines the reference API for Relay Peers in the SSIMPL protocol. It provides endpoints for DID registration, revocation, and ledger reconciliation.
All requests MUST be authenticated using a Bearer token, containing a signed
DID in the canonical
SignatureEnvelope format, Multibase-encoded.
You can also check the open-api spec here.
PUT /ledger
Purpose: Revoke a TA by submitting a revocation payload. Providing the taHash means that the related TA can NEVER be used again to initialize a Wallet. The taHash is mandatory for Delegated Revocation.
Request payload: Revocation
Response: 201 ACCEPTED
PUT /ledger
Purpose: Revoke a TA by submitting a revocation payload. Providing the taHash means that the related TA can NEVER be used again to initialize a Wallet. The taHash is mandatory for Delegated Revocation.
Request payload: LedgerDeltaRequest
Response: 200 OK
Response payload: LedgerDeltaResponse
Response: 409 CONFLICT
Response payload: none
This section is non-normative.
This appendix defines an optional mechanism for scoped, push-based credential distribution between peers. Subscriptions allow a peer to receive updates to specific verifiable credentials issued by another peer, without granting access to the full identity or affecting ledger state.
Subscriptions are off-ledger and do not participate in DID registration, ledger consensus, Merkle state construction, or revocation semantics. They are purely a delivery mechanism for already valid, cryptographically signed credentials.
A subscription represents a unidirectional relationship from a Subject to a Subscriber, granting the subscriber access to a bounded scope of credentials for a finite duration.
The Subject retains full control over:
A subscription is defined by the following conceptual properties:
The exact wire format of subscription objects is implementation-defined and outside the scope of this specification.
As far as authentication goes: it is recommended to use a Multibase encoded SignedObject<DID>.
Subscription-delivered credentials are verified in the same way as any other SSIMPL verifiable credential:
No ledger interaction is required to validate a subscription or its delivered credentials.
Subscriptions are revoked by the Subject by ceasing delivery of credentials and optionally notifying the Subscriber. Expired subscriptions MUST NOT be used to deliver new credentials.
Subscription revocation does not affect the validity of previously issued credentials, which remain verifiable according to their own signatures and expiry rules.
Implementations SHOULD take care to minimize metadata leakage through delivery endpoints and timing correlations.