The building blocks of blockchain-based digital identity

Are you protecting your users and sensitive O365 data from being leaked? Learn how Specops Authentication for O365 can help.

In earlier articles, I discussed what a shared digital identity can do as well as which organizations are the right starting point to adopt a solution for digital identity built using blockchain technology.

In the market today, we see a number of solutions that speak to the concept of self-sovereign identity – and how this will achieve the goals of a single privacy-preserving shared digital identity that is controlled by the user. However, a shared digital identity solution needs to be much more than just the blockchain and the smart contracts that can be run on the blockchain. In fact, most of these solutions are not engineered for enterprise use because they are not built to meet enterprise requirements around branding, consumer experience, deployment, security and predictable pricing.

In order for a blockchain-based digital identity solution to be successful, it needs meet a number of objectives for broad enterprise adoption.

Storing digital identities securely

To really deliver on the promise of user control for digital identity – which include consent and privacy – digital identity solutions need to provide a mechanism for the user to store and manage their PII on a personal device. But we know that personal smartphones, like most endpoint devices, are vulnerable to malware. And the only way to protect this information is to use hardware-grade security – such as that offered by a TPM (Trusted Processing Module) – and device-local biometrics, so only the user can enable the use of the TPM.

If privacy and consent management are important, and PII is to be controlled by the user, the solution must use the smartphone’s TPM to manage the private keys. While this provides the highest level of security, it also creates some interesting challenges in how the solution can handle migration of a profile from one device to another when private keys are locked into the TPM and cannot be migrated.

Brand enhancing user experience

Enterprises today put a lot of time and money in how they design their consumer experience – and in building the brand. Using a third-party mobile application as a digital identity for authentication is not something they will accept easily. When creating an identity ecosystem in a domain such as healthcare or finance, it is important that the branding of the solution reflects the ecosystem participants and inspires confidence in consumers. Thus, the branding will most likely need to be that of the consortium or group that is sponsoring the solution, which means the technology platform needs to be embeddable. This is true both on the device side (where the technology might take the shape of an SDK) as well as on the cloud (where a multi-tenanted platform would isolate customers from each other while providing each with a fully functional solution).

Efficient blockchain usage

The use of blockchain technology has its benefits, but it also has its challenges – especially with performance.

If the blockchain is public, it has to contend with other workloads – and for an identity ecosystem that is looking for highly performant and available identity operations, this could be an issue. To be able to control the service levels, a private/permissioned model is critical. Additionally, using proof-of-work as a consensus mechanism is very CPU intensive and the price of “gas” creates unpredictability in cost that enterprises do not want. Using proof of authority (similar to proof of stake, but more suited for consortium scenarios) is more efficient and eliminates the need for gas – making this far more appropriate for enterprise use.

For a blockchain, write operations are very expensive, but read operations are very cheap. So, first it’s important to understand what constitutes a write operation and control who can trigger one, as well as to minimize them. In an ecosystem that accepts digital identities, issuers can trigger write operations – making it very important to be able to control who can be an issuer of digital identities. Any operation done by a relying party – such as asking the user for their identity or user authentication – should only be a read-only operation.

Another key aspect of the blockchain is that the information that is stored on it is visible to everyone in the ecosystem. Therefore, no PII should ever be stored on the blockchain. An added benefit here is that this allows one to control the amount of data that will need to be stored on the blockchain by ensuring that the solution only stores transaction and state change data on it.

Support for trust

While technology is a crucial part of ensuring overall trust and security in the ecosystem, it is not the only part. What is equally, or perhaps more important, is that there are standards and processes for ensuring that all participants in an identity ecosystem are playing by the same set of rules. For example, all issuing parties must follow the same guidelines for issuing an identity document at a particular level of assurance (LOA). Such standards for “proofing” the user and the verification and certification process to ensure that issuing parties are following these standards, are critical for relying parties to have trust in the overall identity ecosystem. Such standards would typically be set according to the industry-specific business and regulatory needs of the participating members (e.g. healthcare or finance).

Further, just because an issuer has the ability to issue at a particular LOA doesn’t mean that they have followed the same level of due-diligence for each attribute of the user’s identity. As an example, the issuer may have verified the name at a higher assurance level, but not so for the user’s address. Hence, the solution must be flexible enough to represent the identity proofing ability of each issuer as well as the LOA with each attribute of the digital identity.

blockchain-based digital identity

Blockchain-based framework for trust

Secure backup and recovery

It is important to also recognize that devices may be lost, stolen or upgraded. In such cases, the user must be able to recover their identity and move their profile to a new device and be able to seamlessly continue with all the activities they were able to do previously.

There are also state records on the blockchain that tie identity documents that have been issued in the past to the public key of the old device that cannot be modified. While it might sound simple to address this with a “backup and restore” solution, in reality it is not so simple especially in the case where the solution uses hardware-generated private keys that are locked into the TPM of the device and not extractable and therefore cannot be “backed up.”

The blockchain can play an important role in recovery scenarios as well, allowing the system to record “equivalences” between the old device and new device. Of course, this raises the question of who is authorized to perform a recovery operation to established such equivalences. In some cases, the recovery process needs to be entirely user-controlled, where only the user can perform recovery using a special key that only they have access to. In other scenarios, there might also need to be a recovery agent that is trusted to assist the user in such cases.

Use of standards

Blockchain-based identity ecosystems are still in their early stages of evolution and there is a lot of activity in this space. Over the next few years, we expect the market will evolve and get more structured. It is therefore critical that current solutions be based on industry standards as far as possible and not on proprietary APIs and data formats. For example:

  • OAuth for requesting user identity information
  • OpenID Connect (OIDC) or FIDO for user authentication
  • X.509 and JWT as the data formats for identity claims
  • NIST 800.63 for Identity Assurance Level (IAL) and Authentication Assurance Level (AAL).

There are also emerging interoperability standards such as the Decentralized ID (DID) specification that let different identity ecosystems interoperate with each other. Customers can protect their investment by choosing solutions that adhere to as many of these standards as possible and not get locked into proprietary solutions.

Conclusion

The notion of digital identities has been around ever since smartphones became commonplace, but the ability to securely and easily use shared digital identity at scale for consumers has only now been made possible – with the combination of hardware-level security on mobile devices and blockchain technology. Initial adoption for blockchain-based digital identity will start with ecosystems that trust each other, and solutions will need to address enterprise needs for branding, consumer experience, deployment and security.