SIMPL Specification

23,333 kr like-new 48 Dawood Hamidi

Beskrivelse

1. Document Status

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.

2. Conformance

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.

3. Introduction

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.

4. 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 several key problems:

1. Pseudonymous digital identity - tied to a physical identity.
2. User control over digital identity – eliminating reliance on centralized identity providers.
3. Verification of identities – ensuring online credentials correspond to real individuals using cryptographic proofs.
4. Sharing of identity-related data - allowing secure and transparent sharing of data

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).

4.1 Identity Trust Model

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

• MUST extract cryptographic material from a TA
• MUST perform necessary processes to verify chip authenticity. For example, an Active Authentication (AA) challenge.
• MUST extract and store all relevant claims and their proofs. See VCR

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

4.1.1 Considerations

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.

In transactions where a TA is used, there is often a final verification check done by comparing the photo on the document with the one providing the document. This verification step is the actual crucial part tying the document to the bearer. It is therefor recommended to implement something similar in a SSIMPL wallet. In case of the ICAO ePassport implementations, one could extract the raw bytes from the DG2 (the photograph on the document) and let the user take a picture of themselves. Using image-comparison algorithms/software, it would be possible to add this verification.

4.2 Levels of Authentication

SSIMPL DIDs can come in two forms: ephemeral and stable. The ephemeral DIDs are created from randomly selected BIP32 children keypairs from their respective stable parent BIP32 keypair. Whereas, their stable counterparts are based upon the actual parent keypairs OR by storing the path to the actual child keypair. The latter situation would give you the benefit of being able to decide for yourself what the scope/lifetime of a keypair would be.

• Level 0: ephemeral DID + TrustAnchorProof confirms human ownership (bot detection).
• Level 1: stable DID + TrustAnchorProof confirms human ownership (bot detection) and identifies owner spanning multiple sessions.
• Level 2: Level 0/1 + unverifiable attributes (e.g. the owners home address) requested via scope.
• Level 3: Level 2 + verifiable credentials requested via scope.

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.

4.3 Roles

• Identity The owner of the TA and user of the network.
• Wallet: The actual software responsible for encapsulating the owners TA.
• 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.

5. The did:ssimpl Method

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.

5.1 DID Syntax

A did:ssimpl identifier has the following structure, conforming to the generic DID syntax defined in [DIDCORE]:

ssimpl-did     = \"did:ssimpl:\" ssimpl-specific-id\r\nssimpl-specific-id = Multibase( network-bytes || pk-bytes )\r\nnetwork-bytes  = country-bytes subnetwork-byte node-byte\r\ncountry-bytes  = 3ALPHA        ; ICAO 9303 alpha-3 country code\r\nsubnetwork-byte = 1OCTET       ; unsigned integer 0–255\r\nnode-byte      = 1OCTET        ; unsigned integer 0–255\r\npk-bytes       = 33OCTET       ; compressed secp256k1 public key\r\n

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.

Example 1: Example DID

did:ssimpl:3vYhGpQrKmNxTfBwLsAeDcJqZiUoMbXn

The above identifier decodes to: country = NLD, subnetwork = 0, node = 3, public key = 02ab….

5.2 Byte Layout

The 38-byte payload prior to Multibase-encoding is laid out as follows:

Offset012345 – 37FieldCountry (3 bytes)Subnetwork (1 byte)Node (1 byte)Public Key (33 bytes)ExampleNLD0x000x0302ab 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.

5.3 Decoding Algorithm

Given a did:ssimpl identifier, the following algorithm recovers the network coordinates and public key:

1. Strip the did:ssimpl: prefix to obtain the method-specific identifier string.
2. Multibase-decode the string to obtain a byte array. The result MUST be exactly 38 bytes. If not, the DID is malformed.
3. Extract bytes[0..2] (inclusive) as the country code. Interpret as ASCII. The result MUST be a valid ICAO 9303 alpha-3 country code.
4. Extract bytes[3] as the subnetwork identifier (unsigned integer).
5. Extract bytes[4] as the node identifier (unsigned integer).
6. Extract bytes[5..37] (inclusive) as the 33-byte compressed secp256k1 public key.

5.4 Key Derivation

The keypair corresponding to a did:ssimpl identifier is derived using [BIP32] hierarchical deterministic key derivation. The seed is computed as:

seed = HASH( mnemonic )\r\nDID keypair = BIP32( seed )\r\n

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 ) )\r\n

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.

Note

The salt MUST be changed between identity rotation events to ensure that successive DIDs derived from the same mnemonic are computationally unlinkable.

6. Network Addressing

6.1 Network Structure

SSIMPL networks are organized 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.

6.2 DNS Addressing Scheme

Individual nodes are addressed using DNS subdomain names under the networks domain e.g. ssimpl.org. The addressing scheme is:

<country>.<subnetwork>.<node>.<domain>\r\n

Where <country> is the lowercase ICAO 9303 alpha-3 country code, <subnetwork> is the decimal subnetwork number, and <node> is the decimal node number.

Example 2: DNS address examples

nld.0.3.ssimpl.org

Netherlands, subnetwork 0, node 3.

usa.4.12.ssimpl.org

United States, subnetwork 4, node 12.

deu.0.0.ssimpl.org

Germany, subnetwork 0, node 0.

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\r\n<country>.ssimpl.org                 ; any node in country\r\n

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.

Note

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.

6.3 Network Resolution from a DID

Given a did:ssimpl identifier, the corresponding network and node are resolved as follows:

1. Decode the DID per the algorithm in 5.3 Decoding Algorithm to obtain country
2. Construct the DNS address: (start with 0 for subnetwork/node) lower(country).<subnetwork>.<node>.ssimpl.org.
3. Resolve via DNS to obtain the peer\'s IP address and port.
4. To query any peer in the same subnetwork (e.g. for ledger synchronisation), resolve lower(country).ssimpl.org.

6.4 Network Segregation and Ledger Size

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.

Example 3: Ledger size estimates

At 200 bytes per entry and a ceiling of one million identities:

• Netherlands (NLD): single subnetwork, ~200 MB at full capacity.
• United States (USA): requires multiple subnetworks at meaningful adoption; each subnetwork ~200 MB.

6.5 Cross-Network Verification

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 synchronized 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.

7. Wallet Specification

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.

7.1 Wallet Requirements

Wallets MUST:

• Extract cryptographic material from a Trust Anchor (TA).
• Support Active Authentication challenge verification.
• Derive a BIP32 keypair (as defined in [BIP32]), from the BIP39 mnemonic (as defined in [BIP39]).
• Present the BIP39 mnemonic to the owner. Note: the BIP39 mnemonic should be stored redundantly, preferably offline.
• Generate a fresh BIP32 keypair (as defined in [BIP32]).
• Store the master BIP32 private key in a secure storage section of their device (e.g. Apple Keychain, Android Keystore).
• Sign and manage the TA data.
• Generate (BIP32 child) DIDs compliant with did:key for interoperability.
• Support JWT issuance and asymmetric key exchange.

Wallets SHOULD:

• Encrypt credentials for local storage.
• Extract and store additional VCs such as DG11 for user convenience.

7.2 Wallet Functionality

• Before any transaction, the Wallet MUST call either the Well-known Relay Peer, or one of it\'s known Relay Peers for the latest delta.
• If the Wallet is new, it must first be bootstrapped. Which means acquiring the full current Ledger. This is done by requesting delta\'s in chunks between epochs, starting with 0 (Unix Time). Until the Ledger is fully in place, the Wallet MUST NOT allow any transactions.
• Before any transaction, the Wallet MUST call either the Well-known Relay Peer, or one of it\'s known Relay Peers for the latest list of known Relay Peers.

7.3 Wallet Security

A SSIMPL Wallet has certain security scenario\'s that need to be addressed

• The owners TA is lost/stolen: The owner MUST revoke their current TA - No transactions can take place until a new TA has been used to bootstrap.
• The owners device is lost/stolen: The owner MUST use their BIP39 mnemonic to restore their Wallet on a new device, then the owner MUST revoke their current DID and reinitialize their wallet. AND The owner MUST revoke their current TA through Delegated Revocation.
• The owners BIP39 mnemonic is lost/stolen: The owner MUST revoke their current DID and reinitialize their wallet. This will result in a double entry in respect to the same TA. But the \'older\' one will be automatically ignored.
• The owners BIP39 mnemonic AND TA is lost/stolen: The owner MUST use their BIP39 mnemonic to restore their Wallet on a new device, then the owner MUST revoke their current DID and reinitialize their wallet. AND The owner MUST revoke their current TA through Delegated Revocation.
• ⚠️The owners BIP39 mnemonic AND TA is lost/stolen AND Delegated Revocation hasn\'t been configured: There is currently no way to come back from this scenario. Until the natural expiration of the used TA, a malicious actor could potentially impersonate the owner of the original Identity. SSIMPL implementations MUST therefore have a mandatory Delegated Revocation exchange flow.

7.4 Delegated Revocation

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.

7.5 Example 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 (VCR).
5. BIP39 mnemonic generation (and presentation to the user).
6. BIP32 keypair derivation and storage.
7. Signing of the TrustAnchorProof.
8. (lazy) publication of the TrustAnchorProof to the network.

8. Relay Peer Specification

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.

Note

Any network can use their own domain

The ring serves two distinct purposes:

1. Bootstrap and discovery— any client or new Relay Peer can locate an active peer without prior knowledge, by traversing the ring until a responsive node is found.
2. Exhaustive reconciliation— a client that detects ledger inconsistency can traverse the entire ring to collect and reconcile all known valid entries.

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.

8.1 Relay Peer Responsibilities

• Receive, validate and store new Registrations/Revocations.
• Propagate ledger changes to a minimum quorum of N = 3* other Relay Peers upon receiving a new valid ledger entry or revocation, using the traversal algorithm.
• Provide metadata about the ledger.

Note

*if N >= 3, otherwise the minimum quorum should just be N

8.2 Relay Peer Bootstrap and Verification

To enable deterministic network formation and secure onboarding of Relay Peers, the SSIMPL protocol defines a bootstrap and verification procedure.

8.2.1 Relay Peer Bootstrapping

Upon first contact with the network:

1. The DNS controller assigns the next available index and creates the corresponding DNS record {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.
2. Requests delta\'s from one (or more) of the Relay Peers in the network in chunks based on the time between two epochs. Starting with 0 (Unix Time) if it has never been online and otherwise starting with the epoch it was last online.

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.

9. Ring Traversal Algorithm

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:

9.1 For discovery (finding any single responsive peer)

1. Attempt contact with n.{i+1}.ssimpl.org.
2. If unresponsive, assume end of ring and wrap to 0.ssimpl.org.
3. Continue incrementally (1, 2, ...) until a responsive peer is found or all indices up to i have been exhausted.
4. An unresponsive node MUST be skipped; it is not an error condition.

9.2 For gossip propagation (pushing a ledger change)

1. Beginning at {country}.n.{i+1}.ssimpl.org, push the change to each responsive peer in sequence.
2. Count each successful push. If the minimum quorum of N = 3 successful pushes is reached, propagation is complete.
3. If the end of the ring is reached before quorum is met, wrap to n.0.ssimpl.org and continue.
4. If the full ring is exhausted without reaching quorum, propagation MUST still be considered complete — quorum is a best-effort guarantee.

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).

10. Ledger Specification

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

10.1 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 reconciliation.
• Mobile-friendly operation for large ledgers (5–30 GB).

10.2 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.

10.3 Merkle Tree

The SSIMPL ledger uses a Merkle tree to enable efficient verification of ledger state and individual entries.

10.3.1 Structure

• Leaves: Hashes of canonical ledger entries. See LedgerEntry
• Branches: Hashes of concatenated child nodes.
• Root: root_hash representing the current canonical ledger state.

Område

Berglyveien 9, Oslo, Norway