1. SSIMPL - Specification
The SSIMPL protocol described in the following specification addresses a few problems that have existed since the early days of the internet — certainly since Web 2.0:
How do you keep the owner of the online identity in control of their identity data?
There have been several iterations of OAuth in the past, one of which (Open ID Connect), was meant to add an identification layer to a protocol that's otherwise solely used for delegated authorization. This identity layer, however, has never been implemented in a way that anyone can truly rely on. It requires a certain amount of trust, which is provided in the form of billion-dollar companies saying "this data belongs to the person who just logged in". But it adds no guarantees about the validity of those claims. In order to minimize the amount of trust necessary for identification, it is essential that individuals are capable of managing their digital identity themselves, this is known as SSI - Self-Sovereign-Identity. But a self-issued identity still isn't worth much if it is not verified.
How do you verify someone’s digital identity?
Online, everyone can claim to anyone. For some systems - like social media - that could be fine. But for professional services, it is of the utmost importance that all parties taking part in any kind of transaction, have a verified identity shared among the other participants. This issue has become even more critical with the rise of AI and bots capable of impersonating individuals with minimal effort.
SSIMPL stands for Self-Sovereign Identity & Mondial Pseudonymous Ledger. Which tells us already quite a bit about its components. SSIMPL tries to find a balance between centralised and decentralised systems. It creates a bridge between the physical and digital worlds through authority-backed cryptographic proof. Therefor, implementing SSIMPL requires a trusted central authority (such as a government) that supports some form of one-time, cryptography-based identification for individuals.
1.1 The wallet
The wallet must be a decentralised BIP32-compliant implementation, backed-up up with a BIP39-compliant mnemonic phrase (stored offline). This wallet contains both a root keypair that can be used to sign and verify data and to authorize the bearer online, and all claims of the owner. It also supports creating child key pairs for pseudonymous authentication. The root public key is used to generate a DID (decentralised Identifier), which is then signed by the neutral third party. Furthermore, all encoded data, like the cryptographic keys, must be encoded using Multibase-encoding to ensure all peers of all possible future implementations always know which encoding is used.
At this point, in the spirit of Open ID Connect, the user has all the components needed to authenticate themselves online at multiple levels:
- Level 0: The DID belongs to a human being.
- Level 1: Level 0 + unverified claims attached to the DID (requested via scope).
- Level 2: Level 1 + verified claims attached to the DID (requested via scope).
Level 0 is sufficient to prove the user is not an AI or bot. Level 1 may be used when specific, unverified attributes are needed, like an address or a phone number. Level 2 provides verified claims. The requestor of these claims merely needs to request a certain scope of claims. You, as the owner then needs to approve this request and send them the requested claims, while signing them with your wallet.
At the same time, the user will have the ability to cryptographically sign anything they would want to be associated with. In other words: if they would like to be able to proof they were the original creator of some digital content, all they would need to do is sign it. Other people could sign it as well, of course, but signature cannot be created using a past date. So the first one to sign something, always can proof they were the original creator.
1.2 Identification
All users of the SSIMPL protocol must possess a modern Standardised e-passport. These contain cryptographic material used to verify the legitimacy of the passport, thereby delegating the authority of the identity represented to the bearer—assuming basic checks are met (e.g., does the bearer match the photo?). This bearer token-like construct can only be trusted if people take good care of their passports and also follow basic protocols in case of a lost or stolen passport.
By reading the NFC chip, one will get access to so-called 'data groups'. Each group represents some other part of the identity or the passport.
While reading the NFC chip, an implementation of SSIMPL is required to perform an Active-Authentication challenge, which makes the passport sign a randomly generated challenge with its embedded private key, which can then be verified by the key found in DG15. This challenge is there to proof that the passport was not in fact cloned or otherwise tempered with. The result of the challenge will be stored in the id wallet.
DG11 contains the personal details of the owner which can be the first basic, verified claims, stored in the id wallet.
1.3 Mondial Pseudonymous Ledger
In order to protect users from misuse, fraud and identity-theft, each wallet (and specifically the related public keys), must have a mechanism that allows them to be invalidated. These invalidated public keys must be published to a publicly accessible, append-only, preferably decentralized data storage. Anytime someone suspects their identity has been compromised, they're required to add their public keys to the ledger. This way, everyone can check whether the identity they're dealing with is actually valid.
The ledger also contains the public keys of so-called "neutral ledger authorities" (similar to a notary). Each entity that is allowed to sign newly created DIDs. This signature serves as proof that the owner of the DID successfully has authenticated themselves using their e-passport.
2.0 Peer-to-peer
In order to promote a truly trustless environment, all essential communication - like the transfer of identity-related data - must be done p2p. The client-server model must only be used for setting op connections between peers. So the server never receives any sensitive data, but merely acts as a guide to find other peers.
2. DoaToa - a SSIMPL implementation
DoaToa (Decentralised Open Auth & Trusted Open Auth) is the first SSIMPL implementation created. It consists of a client-side app (the id-wallet) and a few stateless microservices necessary to help set up decentralised communication and sharing of data. These microservices, while being centralised components, are meant to be 'the first of many' open-source interchangeable implementations. The same goes for the id-wallet. As long as the specification is followed, multiple implementations of both the centralised components and the wallet, should be able to co-exist.
2.1 The Wallet
The DoaToa id wallet offers an entire implementation of the SSIMPL client-side specification.
2.2 Mondial Pseudonymous Ledger
The ledger described in the specification has certain requirements tied to it. For example: it should be decentralised, and it must be append-only. Research for the right technology is still ongoing. We've had successful experiments with the IPFS. But blockchains like Arweave are still undergoing investigation. At the moment, a simple GitLab repository is used to store the ledger. Since entities that are allowed to mutate the ledger are limited, and DoaToa is still in the POC phase, this ought to be enough.
2.3 Security
In order to fully implement SSI, a user needs to have full control over their own data. There are several ways to accomplish this (using a hardware wallet for example), but DoaToa relies on a somewhat controversial take: most people have a smartphone and treat it with more respect than their passport. Smartphones these days lack true HSMs (Hardware Security Modules), which would be the best place for cryptographic material to exist. Due to this (hopefully temporary) imperfection in smartphones, DoaToa uses the keystores that exist on devices: Keychain on iOS and the KeyStore on Android. This introduces a few risks that need to be mitigated:
- The device is lost/stolen, the related wallet needs to be invalidated. - This is achieved by registering the DID on a decentralised ledger, stored on the IPFS. DoaToa provides this functionality. It would require you use the mnemonic phrase on a new device to re-create your wallet, then invalidate it. The user can then create a new wallet again.
- A user switches devices, the wallet needs to be re-created. - The mnemonic phrase can be used to re-create the old wallet. Always do take care to either delete the wallet from the device, or to factory-reset the device.
- The mnemonic phrase is lost/stolen. - The user will need to invalidate their current DID and create a new wallet (which will also mean the user gets a new mnemonic phrase)
- A user loses both their mnemonic phrase and their phone. - This scenario should be prevented at all costs, since everything relies on that mnemonic phrase. It is advised to use a (maybe even redundant) paper/metal backup to keep the mnemonic phrase safe.