Interview with Daniel Hardman (Chief Architect at Evernym and Technical Ambassador at Hyperledger)

Photo: Hyperledger Global Forum

Daniel Hardman is one of those inevitable names that come up whenever Self-Sovereign Identity is mentioned. He is the Chief Architect at Evernym, one of the world’s leading companies in Digital Identity

Evernym was the catalyst behind the creation of Sovrin, a Self-Sovereign Identity network based on a public permissioned blockchain. The Sovrin Network is run by a Federation of Stewards who are responsible for validating identity transactions to ensure consistency about what is written on the ledger and in what order. We are proudly one of those Stewards who are allowed to run a validator node. Along with IBM, Cisco, T-labs and 68 others (with the aim of having up to 300 Stewards within the network in the long run for optimal decentralised governance).

In an identity management scenario, a blockchain, like Sovrin, enables everyone in the network to have the same source of truth about which credentials are valid and who attested to the validity of the data inside the credential, without necessarily revealing the actual data. This brings privacy and security to Digital Identity as each person holds their identity credentials in their own devices and controls the digital relationships those credentials are used in and for. The user decides who gets to “see” them and how much of them they get to “see”.

But if one stores their digital identity credentials on a digital identity wallet on his devices (like a mobile phone), it begs the question: what if my phone is lost or stolen?

To answer this question we always draw from Daniel Hardman’s excellent paper.

According to him there are two steps to be taken

The first one is to revoke the device’s authorization to use credentials. Digital Identity credentials are only valid if used from a device that was authorized to do so. If a user’s phone is lost or stolen, that user could use another authorized device, like his laptop, to write on the blockchain that his mobile phone’s authorization is now revoked. 

This would take immediate effect and stop anyone from using the digital identity credentials on the phone. The thief would not be able to impersonate the user even if he has her passwords, biometrics or phone because the blockchain, immutable and secure, would contain a revocation registry for the phone.

Revocation of the device’s authorization impedes the thief to impersonate the user to create new relationships. The second step impedes the thief to explore the existing relationships between the device and other people or organisations. The second step thus is to revoke the existing relationship keys (pairwise connections where each of them has a unique key).

These two steps stop an identity thief to use digital identity credentials to access new services or explore relationships with existing ones. While conveniently letting the user still use his credentials on another device.

We had a chance to ask Daniel a few questions:

What are, in your opinion, the riskiest assumptions when writing an Software Development Kit?

SDKs have a very broad set of uses. It’s easy to assume that everyone using the SDK will be doing mobile, or servers. It’s much harder to build an SDK that also works for embedded or for SaaS. So I think platform assumptions are one of the most risky areas.

Another risky area is the threading model. Some people will want something simple. Others will want something that is very scalable or performant. It is hard to do both–so assumptions about this area are risky.

For you, what are the most promising SSI projects or repos?

I think hyperledger/aries-rfcs is super important. Also the peer did spec at openssi/peer-did-method-spec. And hyperledger/aries-cloudagent-python, hyperledger/aries-framework-dotnet, hyperledger/aries-framework-go, hyperledger/aries-protocol-test-suite.

What do you believe are the bottlenecks for the cross-ledger SSI? How soon can we see cross-ledger credentials exchanges?

I think the number one bottleneck right now is not related that strongly to ledgers, but rather to credential format. There are 3 credential formats that are in harmony with the VC spec, that are not mutually interoperable. Until we solve that problem, cross-ledger SSI will probably not happen.

I predict that this problem to be solved in the next 1-2 years, with Sovrin announcing support for other ledgers and other credential formats. That’s because it’s going to be easier for Sovrin to support the simple crypto of the other formats, than for the other formats to upgrade their crypto to support Sovrin-style credentials.

What are the upsides of using Zero MQ over a common HTTP Rest connection?

ZMQ trust is not based on certificates, but rather on possession of keys. We need these keys anyway, so the transactions from individual validators can be signed and verified by one another. So, ZMQ allows us to secure the conversation using keys we already had. If we were using HTTP/Rest, we would still have those keys and would still need to sign things, but then we would redundantly be encrypting. We would also have to make sure every validator node accepted the certificates from every other validator node, and certificate expiration would be a constant headache.

How hard would it be to replace the current Transport Layer Security architecture with SSI?

Very hard. I don’t expect this to happen any time in the next 5 years. It may never happen. TLS is good for trust between computers, not between humans–but since we will always need trust between computers, it may be here to stay…

Why was Rust chosen to write Indy-SDK?

We needed a language that could cross-compile for many different platforms, and that produced a C-callable API so lots of other languages could benefit from the artifacts it builds; if we didn’t have that, we’d have to write the same low-level crypto and wallet operations multiple times. Rust, Go, and C++ were the only serious candidates, and Rust had the nicest compiler options for cross-platform. Go’s C-callable support is harder to adapt when you are using Go routines. Rust is growing and is very popular with its developers.

Specific roadblocks other people in this space should look out for?

The biggest roadblock right now is the learning curve. The mental model is different from that of familiar web programming in important ways, and understanding how and why is hard.

I am encouraged because we now have agent frameworks that are becoming available, that allow a developer to be productive without knowing so many of the low-level details. This should help a lot with this challenge.

What are the books you have recommended most to others?

Two that have been relevant to me in recent years are Refactoring, by Kent Beck and Martin Fowler, and Working Effectively with Legacy Code, by Michael Feathers.

We, at Tykn, would like to thank Daniel Hardman for his time and for sharing his ideas and knowledge with us. Thank you, Daniel! Be sure to follow his Twitter.

Tykn is a digital identity company. We are now about to launch Ana, a digital identity management platform that allows organisations to issue tamper-proof digital credentials which are verifiable anywhere, at any time. If you’re keen on reading more we suggest you check out our Blog. There are interviews with Darrell O’Donnell, Elizabeth M. Renieris, Kim Hamilton Duffy and many more. There’s also our Definitive Guide to Identity Management with Blockchain.