Release 0: Sol
Detailing our 1st release since finishing Techstars
Everything Starts with Identity
There are many companies tackling the blockchain identity problem, and for good reason: all applications begin with identity. And we want to help. The Transmute Platform will combine the best of centralized and decentralized services. In order for users, clusters, and services to communicate securely we need to define how identities are expressed. Historically, decentralized identity systems have been difficult to achieve. Systems like GPG rely on key servers and the web of trust to establish reputation for public keys. Services like Keybase attempt to bootstrap key reputation from social media profiles. Each of these approaches has advantages and challenges, but the common denominator is public key cryptography.
Directories
If you have worked on authentication and identity development in the past, you will be familiar with the concept of a directory. LDAP and Active Directory have become backbone technologies for enterprise IT and key servers for decentralized identity. This release was focused on building support for decentralized identities into centralized directory technology that is already widely adopted by enterprises. This work involved adding UI to our React dashboard and updating our API to support registration and group management. We have also done some exploratory work regarding the DID spec and LDAP integration — which we are still cleaning up and hope to share soon.
Groups
Directories like LDAP and Active Directory make use of groups, and it’s fairly common to use group membership for authorization. For example, all nurses can read patient profile data for their hospital group, but not others. This release we focused on the centralized side of group membership. This use case relies on the integrity of the directory and discretionary access control. In other words, the directory admins can move users between groups, but users cannot control what groups they are assigned to. This is valuable and familiar to enterprise system administrators, but not very compatible with decentralized identity. This structure is specifically helpful to Transmute because it means we can segregate our users on the centralized side, allowing selective access to new features based on billing information or reputation.
Registration
However, there are issues that need to be addressed when considering what it means to add a new member to a directory. These include proofing of communication channels (verify your email), proofing of public keys (verify you can sign), and linking of public keys in cases where you need different keys to support different protocols (for example: Ed25519, secp256k1 for use with SSH, PGP, etc.).
For this release, we focused on the basics of registration. We came up with a flow that works, but it still has some limitations we will be addressing in upcoming releases.
Our current registration flow involves submitting public key pairs to our centralized API. We then extract the email from the keys, verify that they have signed each other, and create a new directory entry in a deactivated state, which will become activated once the user verifies their email.
Obviously, this flow requires the users to have email and protect access to it… which might not be a good idea. It also does not leverage the DID spec fully; PII (email) is linked to the keys, and the separation of PII and keys is one of the major features of the DID spec. We’ll be working to address this in the next release as well.
Recovery
Any identity system that does not discuss recovery from theft or failure up front, in clear language, should be avoided. We consider the concept of recovery and continuity of identity in both the centralized and decentralized senses.
Centralized account recovery is something many readers may be familiar with. Forgot your password? You can reset it by showing you still control your email… But what happens when you don’t control your email? In most cases recovery is handled by establishing a protocol for recovery, and then protecting that protocol from attack. In the case of forgot password, you are protecting your email account. In the case of recovery keys, you are protecting a set of keys or a unique identifier that you will be required to provide in the case of email theft or compromise.
The challenging part of recovery is that the attacker gets to play too. Whatever protocol you pick, the attacker can attempt to impersonate the user, and use the recovery mechanism to gain control of the account. We’ve seen this with SMS in particular, once an attacker has the ability to receive SMS codes, they can use this ability to lock you out of your account.
Centralized recovery involves backup keys and proof of control over communication channels, whereas decentralized recovery involves backup keys and revocation certificates.
We have explored and implemented some forms of simple recovery this release around compromised keys. It’s also worth stressing that when a private key is stolen or published, the identity can now be forged. This is why it’s important to use revocation certificates. They are required to tell users of public key crypto-systems that a key is no longer to be trusted. The support for revocation certificates in key servers, and the concept of continuity of identity in general, is tough.
Continuity of identity is not always desirable. Sometimes, you don’t want to link the reputation of your old account to your new one. Sometimes you do. The method of support for this is built on digital signatures, and can rely on social systems as well. For example, more people will trust that you have changed keys if all your friends sign a message saying you have.
There are other problems with recovery, such as sybil attacks, and privacy which require careful consideration.
Summary
We focused on the basics of identity in both centralized and decentralized systems for this release. We evaluated centralized directory technologies, including LDAP, and we implemented centralized authentication flows, which provide short lived tokens that represent identities in a centralized directory (JWT Bearer flows). We developed support for extending GPG to support Ethereum and centralized directories with a specific eye towards wider DID compatibility. We implemented simple registration flows for these systems and some forms of recovery for the case of private key compromise.
Next Release
For the next release, the Transmute team will tighten up our directory and identity work to ensure DID compliance. We’ll also extend our identity system to support better forms of decentralized groups, document management, and messaging.
