Identity Platform Detailed Use Cases

Three weeks ago, we announced to the public our blockchain based identity platform. We appreciate the community response and have been hard at work on the formal white paper. Today, we would like to release the first half of the white paper: the detailed use cases. Stayed tuned for the second half, the technical implementation.

Introduction

In todays business landscape, the platform owns and monetizes the data which constructs the individual identity, making sharing or revocation of that data (right to be forgotten) disadvantageous. The European Union (EU) views data privacy as a fundamental right and has crafted the General Data Protection Regulation (GDPR) to enforce adherence.

The Trusted Identity Platform allows for the creation, management, and sharing of identities using a distributed ledger overlaid on the DataNexus routing platform. This gives individuals the ability to to control and monetize who gets their identity data and when, along with the ability to revoke access to that data at any time. The ledger records identity grants, transfers, and revocations allowing enforcement, auditing and compliance. This provides a public platform to both audit and enforce entity compliance.

Use Cases

We envision four primary uses cases around identities: creation, granting, sharing, and revocation.

Identity Creation

Identity creation is the first step in the sharing of entity information. The business entity is assumed to have created at least one public/private key pair to use in the encryption of customer information. There is no technical limitation on key pairs by customer segment, region, or even individual, though this would be extreme and require extra effort in key management and escrow.

  1. An entity:individual logs into entity:business1 web portal and creates an entity:individual:identity. By creating an identity, an implicit grant and right to use is established between the entity:individual and entity:business1.
  2. This instantiates a local public/private entity:individual:key pair and uploadsĀ  the entity:individual:public key to entity:business1 for encryption and storage.
  3. Next, entity:business1 records the entity:individual:public key in the local key store. This allows the public keys of all entities who have opted in to data portability to be synchronized to the DataNexus global key store.
  4. Now entity:business1 can encrypt and securely store the entity:individual:identity in a local data store. At this point the entity:individual:identity is only readable by entity:business1 with the consent of the entity:individual. While the data is decrypted in local inflight processing, it is never stored in plaintext at rest.

The distributed ledger records the communications and actions between entities. Note that the keys themselves are exchanged through the DataNexus platform, not as payload within the ledger.

Identity Granting

Identity granting is a powerful way for the individual entity to control who gets their data and how it is used. In the initial case of identity creation, an implicit grant is normally assumed (see the section on identity creation). Many businesses have established relationships with either internal units or external partners, for example an automobile dealership may have preferred insurance carriers, an insurance carrier may have financially separate units that deal with automotive and home, or healthcare providers may have data analytics companies to assist in preventive care. These businesses can offer the individual incentives to share data in the forms of discounts, thus allowing the individual not only control over their personal information, but also the monetization of it.

  1. The entity:individual logs into entity:business1 web portal and grants identity sharing to a specific approved second entity (partner, sub-company, etc) also opting into the data portability agreement. By opting into the data portability agreement, an implicit grant and right to share is established between the entity:individual and other entities. In return, they are given some incentive to do so, such as a small discount if they enter into a financial transaction with the second entity.
  2. This instantiates a second local public/private entity:individual:key pair and uploads the entity:individual:public key to entity:business2 for encryption and storage.

Identity Sharing

Once identity grants have been established between all participating entities, the actual sharing of the identity data can occur.

  1. A point-to-point encrypted tunnel is established between entity:business1 and entity:business2 based on ledger validation at a pre-established data exchange interval.
  2. A decryption and encryption of the entity:individual:identity occurs prior to transmission. Entity:business1 first decrypts the entity:individual:identity as normal and then encrypts entity:individual:identity using the public key of entity:business2 (retrieved from the global key store).
  3. Next, entity:business1 sends the encrypted entity:individual:identity over the tunnel to entity:business2 where it is decrypted using the public key of entity:business1 and then encrypted with entity:business2 private key and entity:individual:public key and stored.
  4. The encrypted tunnel is taken down until the next exchange session.

Identity Revocation

At any time, either side of an identity relationship can choose to end the grant which allows information exchange to occur. This is usually in response to a change in the business relationship, for example a customer may wish to change providers.

  1. The entity:individual logs into entity:business1 web portal and revokes the entity:individual:identity grant either explicitly or implicitly by ending the relationship.
  2. Next, entity:business1 must delete all data keyed to the entity:individual.
  3. The entity:individual:public key is deleted from the entity:business1 key store.
  4. Finally, the key deletion should propagate to the master key store to reflect that the public key between the entity:individual and entity:business1 is no longer valid.

Author: Christopher Keller

CTO @ DataNexus

One thought

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s