Identity Management on DokChain: Part One

Identity management is the foundation of the DokChain Network. Here we describe our contextually relevant identity management protocol (CRIMP). The popular public blockchain networks like Bitcoin and Ethereum are intentionally divorced from a notion of identity. In fact, they are designed to be anonymous. These networks have the idea of an account, embodied by a key pair, which is agnostic to everything about the actual real-world key holder. DokChain, however, will be connecting patients, hospitals, insurance companies, banks, manufacturers, etc, and so it is vital that participation in the network involve more than just an anonymous account. On the other hand, the Network must aggressively protect all information about its participants so that each transaction sends only the minimum data needed to the minimal number of participants. For example, a bartender does not need to know anyone's age in order to serve them a drink, they need only know that they at least 21 years of age. We confront, head on, the conflict between privacy and security, and also the conflict between privacy and convenience.

To ensure that identities are legitimate and not fraudulent, we must perform identity validation (if your name is John Jacob Jingleheimer Schmidt, we need to figure out which John Jacob Jingleheimer Schmidt you are) and identity verification (proving that an identity actually is who they claim to be) with the richest data available. But, in order to protect the privacy of these identities, everything an identity does on DokChain must use the least rich data available. Our multi-party identity by consensus, solves the first problem, while our contextually relevant identity management protocol (CRIMP) solves the second one. In order to explain both of these concepts, we must first explain a design pattern, named cryptographically verified data driven smart contracts, which we developed in order to make both multi-party identity and contextual relevance possible.


First we go into detail about how cryptographically verified data driven smart contracts allow us to store and retrieve data on DokChain. This will allow us to go into detail about how the rest of our identity management system works. First and foremost, all the personally identifying information transmitted through the network will be encrypted so that only the intended recipients can access it. In fact, our cryptographically verified data driven smart contract pattern (henceforth CVDDSC) guarantees data integrity, leaves a transparent audit trail, and protects privacy. Its works as follows.

The CVDDSC pattern is a very general method for storing and retrieving data, but for sake of example we take the scenario where Jane Doe wants to give an identity provider access to view her retinal scan. The CVDDSCs go hand in hand with specific, off-chain services. Like every entity on the DokChain, each such service (there will be many) will be represented by a public key on the network. Supposing that the retinal scan can be retrieved by a url, and possibly a password, the first thing that Jane does is to encrypt this url and password with the CVDDSC service's public key. Optionally, the url can lead to a copy of the retinal scan which has been encrypted with the identity provider's public key (this way the CVDDSC service cannot view the raw data, but at the cost of not being able to grant access to the retinal scan to anyone besides the one identity provider). Jane then digitally signs the retinal scan and executes a smart contract which places the encrypted url and password and digital signature on the blockchain. When the CVDDSC service sees this information on the blockchain, it then decrypts the url and password with its private key and retrieves the data. If the digital signature is valid, the CVDDSC service then creates a new digital signature with its private key, encrypts the data with its public key, and stores the encrypted data for later retrieval. The service then executes a smart contract which places the following on the blockchain: an encrypted (with Jane's public key) url and password for the data's new location, and the new digital signature. Jane can then check the new digital signature. If everything is legitimate, she then executes a smart contract which records her acknowledgment of the new digital signature. The data is now securely stored by the CVDDSC service and both parties have attested to the validity of the data. Moreover, digital signatures are permanently stored on the blockchain if ever an audit is needed later.

Jane can now give the identity provider permission to view the retinal scan. Jane does this by executing a smart contract which will place an access grant, and any associated permissions such as expirations, for the identity provider on the blockchain. With an access grant the identity provider can now make a request on the blockchain to view the data. When such requests appear on the blockchain, the CVDDSC service responds by generating a one-time token for access to the data, encrypting this token with the requester's public key, and placing the encrypted token on the blockchain. Once decrypted, the token can be used once off-chain with the CVDDSC service to obtain the data, or retinal scan in our example. As with the storage process described in the previous paragraph, this data access leaves a record of everything that happened on the blockchain for later auditing. Note that, in this process on the blockchain there is no private or personally identifiable information and only public keys and merkle tree addresses have been passed between parties.

Cryptographically verified data driven smart contracts are used on DokChain anytime private data is transmitted from one party to another. If an identity provider wishes to perform knowledge-based authentication with a consumer, then every question is transmitted to the consumer using CVDDSCs, and every answer is transmitted back to the identity provider using the same process.

Having explained how data is stored and retrieved on DokChain, we can now go into detail about multi-party identity by consensus. An identity on DokChain will use CVDDSCs to become verified by multiple identity providers. At the end of each verification proof, the identity provider will place information on the blockchain indicating basic metadata such as confidence scores. No personally identifying information is revealed, just that a certain entity represented by a public key has gone through verification with a named identity provider and that the provider attests to some confidence using some named method, etc. Through smart contracts, DokChain will be able to aggregate information across multiple vendors for identity verification. The data sources used by the vendors will vary over different domains, such as finance and health care, and the combined confidence of the identity proofs increases the statistical significance of the verification proof. DokChain is a private blockchain network, and as such the DokChain Alliance members will participate in on-chain governance which controls the way that identity verification data is aggregated and how the combined confidence is computed by smart contracts. Even the voting mechanism itself will be managed by smart contracts. Having a transparent and adaptable way of controlling identity verification allows us to maintain the integrity of the identity proofs independent of any single point of failure. Moreover, the governed smart contracts aggregating this identity data are flexible enough to allow dynamic weighting of data types and sources.

Once an individual successfully completes the multi-party identity by consensus process, the network only sees that an account, represented by a public key, has met the verification requirements. The corresponding private key can be owned and managed by the individual on a personal device such as a phone or personal computer. Additionally, we have implemented a key recovery system so that encrypted data is not lost in the event that the private key is lost, such as when a device damaged.

The main idea powering the recovery is the use of Shamir's Secret Sharing Scheme. Secret sharing, in general, is a method for creating shares of a secret in such a way that no information about the secret can be determined until some number of shares are observed together. For example, a secret could be split into five shares so that the secret is only revealed when 3 or more shares are combined. The minimum number of shares needed to reveal the secret is called the threshold. The DokChain recovery method uses secret sharing to distribute encrypted shares of the private key. In order to enable recovery, the key owner must choose some number of trusted third parties to give shares to. Examples of trusted parties are known alliance members, such as PokitDok, or other devices owned by the same entity, such as a secondary phone or tablet. Each share is encrypted with the associated trusted party's public key and then placed on the blockchain with a smart contract, ensuring that the whole process is transparent. If the private key owner ever needs the shares back, in order to recover the private key or to have access to the key on a secondary device, they can go through the identity by consensus process again and then ask the trusted parties for the shares back. As with everything on DokChain, the request is done by way of a smart contract and is permanently recorded in the blockchain. When the trusted party sees the request on the blockchain, and that a new key pair has been verified, it can decrypt the share with its private key and then re-encrypt it with the new public key of the requester. This re-encrypted share is then placed onto the blockchain for retrieval by the requester. Once someone has retrieved enough shares to meet the threshold requirement, the private key can be reconstructed and recovery is complete.

We now explain the other main component of identity management on DokChain, namely CRIMP. Many interactions on DokChain will involve some party needing to know some amount of personally identifying information about another party. Our contextually relevant identity allows us to disclose only what is necessary. To do this, we use cryptographically verified data driven smart contracts together with another off-chain service to perform sensitive computations. There will be one such service per sensitive computation. We explain how this works by way of example.

Suppose that someone selling a product on DokChain needs to know that any identity that it interacts with is at least 21 years of age. The seller does not need to know anyone's actual age, just that they meet this threshold. DokChain will then provide a service which allows the seller to gain this minimal information with the consent of the individual. It works as follows. If Jane Doe wishes to prove to the seller that she is at least 21, she uses CVDDSCs to give the age service access a document which contains her birthday and a digital signature from and identity provider attesting to the birthday. Jane then executes a smart contract which places a request on the blockchain for the age service to perform its off-chain computation with the document. After the service finishes this task, the seller can retrieve the results using CVDDSCs. The result will be the value, true or false, indicating that Jane is at least 21. Because Jane's full age is not relevant in this context, the seller does not learn her birthday. All that is relevant is whether or not she is at least 21.

The hypothetical age service is actually distributed and represented by multiple public keys on DokChain and is maintained by alliance members running DokChain nodes. The design is very general and can be adapted to fit any contextual relevant transaction that we wish to support. The services can be run inside of a secure enclave, such as Intel's SGX, for added security.

Identity management is a very exciting use case for blockchain technologies, and healthcare is a perfect domain to utilize all the different aspects of identity.

About jaredcorduan

Ph.D. From Dartmouth in mathematical logic with a passion for all things Charleston.

View All Posts