The following specification describes a way to verify real people digitally in a pure decentralized way. It's important to know that this is not an idea of a blockchain or company idea more than a practical approach to *Self-Sovereign Identities using basic cryptography.
A decentralized identity is an approach to identify and authenticate users and entities without a centralized authority. Decentralized Identity and Self-Sovereign Identity are currently the two approaches to decentralized identity.
Decentralized Identity (DID) relies on a ledger (whether custom server or blockchain) to secure and manage identities and their transactions. For a custom centralized server, each user needs to create an account and implies fees for maintaining that server. For custom blockchain, each user needs to create a new wallet and implies fees for gas.
Self-Sovereign Identity (SSI) where the user data is stored with the user, is not a blockchain (nor server) which implies no fees. With SSI, users can authorize identity verifiers all or parts of their inforamtion on a case-to-case basis. Currently, the internet community use SSI and DID interchangeably, but the majority are in fact DID.
Any SSI website/platform that has a blockchain or requires you to create a wallet is really a DID.
The DID specifications defined by W3 define a wide array of identities (people, companies, cars, planes, books, etc.) that is applicable for both DID and SSI.
There are many existing implentations of DID. KTS describes how to acheive the core goals of SSI with personal identities.
You can also think of KTS as decentralized KYC (Know Your Customer)
At a high level, KTS objectively sends user information and verifications from verifiers to consumers. The consumer uses that information to prove the uniqueness and authenticates the user. The following describes KTS in detail.
The following describes the general cryptography practices of this specification in order to separate the technicality from the specification.
Users will need to generate (or use an existing) a public and private key generated using the Elliptic Curve Digital Signature Algorithm. The public key will be used as the user's unique identifier and the private key will be used to sign verifiable messages (or Signed Messages).
All requests should include a signed message hash to verify that the user did in fact made the request. Like wise, all responses should include a signed message hash to verify that the user did in fact made the response.
All messages should be encoded first into a Content Identifier (CID). This CID hash will be the encoded message that will be finally signed by the user.
Finally, the payload being transported should include both the message signature and the original data.
The user groups of this specification are the holder, the verifier, and the consumer.
- The holder is the owner of the information.
- The verifier validates the information.
- The consumer processes the information.
The term "information" used in this specification refers to the data used to identify and verify a user. The information contains the following three sections.
- Identity - The user information to validate
- Proof - Proof that user owns the information to validate
- Verified By - A list of verification data submitted by validators
The following describes a typical identity verification flow.
- A holder requests to be verified by a verifier.
- The verifier requests the identity, proof and possible additional information from the holder in order to verify the information.
- The holder sends their identity, proof, and additional information to the verifier as well as signed messages for the identity, proof, and additional information.
- The verifier uses all the requested information (as well as external means) to score the probability that the holder matches information provided (between 0-10000).
- The verifier responds with the results as well as the signed message for the results.
- The holder saves the results with their information
The following sections explicitly describes the holder information being sent and received for visualization purposes.
The following table contains the data points used to identify the holder for verifiers and consumers.
| Identity | Required | Type | Desciption |
|---|---|---|---|
| First Name | Yes | String | First name found on your ID |
| Middle Name | No | String | Middle name found on your ID (or empty string) |
| Last Name | Yes | String | Last name found on your ID |
| Origin | Yes | String | Country of Origin (can be a digital Country) |
| Wallet Address | Yes | String | Wallet Address |
The following table contains user data points used to verify the user's identity only by verifiers.
| Proof | Required | Type | Desciption |
|---|---|---|---|
| Registry | Yes | String | ie. Passport, Drivers License, National ID |
| ID Number | Yes | String | Unique Number found in the ID Type specified |
| Photo of ID | Yes | String | Base64 Image of Photo ID |
| Selfie | Yes | String | Base64 Image of Self holding Photo ID |
| Signature | Yes | String | Base64 Image of Physical Signature |
The responses of verifiers will contain the following information.
| Verification | Required | Type | Desciption |
|---|---|---|---|
| Subject | Yes | String | Wallet address of holder |
| Verifier | Yes | String | Wallet address of verifier |
| Score | Yes | String | 0 - 10000 |
| Timestamp | Yes | String | yyyy-mm-dd hh:mm:ss Z |
| Expires | No | String | yyyy-mm-dd hh:mm:ss Z |
| Data | No | String | Extra hash information |
The following describes how to become a verifier.
- A new verifier requests to be verified by an existing verifier.
- The existing verifier requests the identity, proof and possible additional information in order to verify the information.
- The new verifier sends their identity, proof, and additional information to the verifier as well as signed messages for the identity, proof, and additional information.
- The existing verifier uses all the requested information (as well as external means) to score the probability that the new verifier matches information provided (between 0-10000).
- The existing verifier responds with the results as well as the signed message for the results.
- The new verifier saves the results with their information.
The following sections explicitly describes the holder information being sent and received for visualization purposes.
The following table contains the data points used to identify the verifier for verifiers and consumers.
| Identity | Required | Type | Desciption |
|---|---|---|---|
| Registry | Yes | String | The organization that issues registration |
| Name | Yes | String | The registered name of the verifier |
| ID | Yes | String | The registered business name of the verifier |
| Origin | Yes | String | Country of Origin (can be a digital Country) |
| Website | Yes | String | ex. verifier.business |
| Wallet Address | Yes | String | Wallet Address |
The following table contains user data points used to verify the user's identity only by verifiers.
| Proof | Required | Type | Desciption |
|---|---|---|---|
| Photo of Registration | Yes | String | Base64 Image of Photo ID |
The responses of verifiers will contain the following information.
| Verification | Required | Type | Desciption |
|---|---|---|---|
| Subject | Yes | String | Wallet address of new verifier |
| Verifier | Yes | String | Wallet address of existing verifier |
| Score | Yes | String | 0 - 10000 |
| Timestamp | Yes | String | yyyy-mm-dd hh:mm:ss Z |
| Expires | No | String | yyyy-mm-dd hh:mm:ss Z |
| Data | No | String | Extra hash information |
Along with the expiry, a verifier's is valid as long as all of their verifiers are still valid. A verifier should not respond with an expiry longer than their own expiry or other wise would invalidate their validation.
Unlike holder and verifiers, consumers do not need to be verified and can request holders for information using the following flow.
- A holder requests to be consumed by a consumer.
- The consumer requests the identity, verifications and possible additional information from the holder in order to consume the information.
- The holder sends their identity, verifications, and additional information to the consumer as well as signed messages for the identity, and additional information. (the verifications do not need to be signed)
- The consumer uses all the requested information for consumtion.
The following notes describes the ways KTS could be implemented.
- The genesis verifier should make a verifier registry that users in their network can use to discover services.
- To prove self-sovereignty, applications should be able to store information while being offine.
- To prove self-sovereignty, applications should allow users to save and load their information to and from a file respectively.
- Verifiers can adopt the W3DID spec to service holders.
The following describes the possible fail points for this specification.
- Verifiers could verify holders and other verifiers without due dillegence. Consumers should be able to report discrepencies to the verifier and the genesis verifier. The genesis verifier should post these discrepencies for other consumers to review.
- Bad actors verification cannot be revoked. The genesis verifier should post these discrepencies for other consumers to review. Consumers should to cross check verifiers before using their checks as a basis for identity.
- Genesis verifier has expired. This is a network fail as there is no way for the genesis verifier to be verified.