Some Reflections About Identity and Security Tokens: Part II

This is the second part of an article exploring ideas about identity capabilities in security tokens. In the first part, we explored some of the basic principles of identity and extrapolated them to the world of crypto-securities. Today, I would like to focus in a technical model to enable some of those principles integrated with existing security token platforms.

The main premise of this two-part article is that identity should evolve as an independent protocol of security token architectures. Instead of being tied to a specific security token protocol or issuance model, identity should become one of the fundamental building blocks of interoperability across security token platforms. The first part of this article outlined five key properties of identity representations in the context of security tokens:

· User-Owned, App-Enforced: In a security token model identity should be owned by users and enforced by the different security token apps like issuance platforms or exchanges.

· Claims-Based: A identity in a security token app should be a set of claims or assertions about a specific user or entity.

· Reversible: To enforce securities law, identity representations should be reversible which means regulators we should be able to retrieve the documents that were used to generate the assertions about an user.

· Based on Identity Standards: In the last few years, the security token industry has produced a lot of high-quality standards such as SAML or OpenID Connect that have been adopted across many of the applications we used every day. Instead of building new standards, I believe security token protocols should leverage some of the established standards as part of its protocols.

· Programmable: Identity should be able to be reused into other security token protocols.

Adapting those five principles to security token models provides a guideline of how identity should work. An investor should submit proofs-of-identity in order to undergo processes such as know-your-customer(KYC), anti-money-laundering(AML) or accreditation. The proof-of-identity can be in the form of documents or identity carried from existing providers. Upon completing the process, the identity of the user should be built using a set of claims that assert relevant properties to securities law (ex: jurisdiction, industry certifications etc). Those properties will be used as part of compliance rules during the transfer of crypto-securities. Finally, the right regulators could use the identity of the user can be used to retrieve relevant documents to a compliance process.

The Identity Dilemma: To Decentralize or not to Decentralize

The fundamental question to enable identity protocols in security token models is whether to follow a traditional centralized approach or emerging decentralized identity models. The centralized scheme relies on an identity provider that acts as the issuer and validator of identity tokens.

This centralized model seems to align well with the current generation of security token platforms but obviously introduces yet another level of centralization in security token architectures. There is nothing intrinsically wrong with centralized identity models; the entire internet relies on them. However, when you have a runtime based on decentralized protocols, a centralized identity model introduces an obvious friction. After all, how decentralized can a protocol be when relies on a central authority for one of its key functionalities?

In order to address the challenges of enabling identity in blockchain runtimes, the industry has steadily gravitated towards decentralized identity models that leverage blockchain protocols as a first-class citizen. Some of the most forward thinking work in this space is coming from the Decentralized Identity Foundation(DIF) which has brought together some of the most important players in the identity management and blockchain markets.

Decentralized Identity Models for Security Tokens

The emerging field of decentralized identities looks to leverage decades of technological progress in identity methods and standards in the new world of decentralized runtimes. To achieve that, identity needs to be reconstructed using an architecture moves a lot of the traditional identity dynamics into a decentralized network of participants.

Microsoft has been one of the leaders in the identity management space for the last 20 years but even they realize that blockchain runtimes require a new identity models. Inspired by DIF, Microsoft recently proposed a forward-thinking architecture to enable decentralized identities in blockchain runtimes. The Microsoft architecture includes the following components:

· W3C Decentralized Identifiers (DIDs): IDs users create, own, and control independently of any organization or government. DIDs are globally unique identifiers linked to Decentralized Public Key Infrastructure (DPKI) metadata composed of JSON documents that contain public key material, authentication descriptors, and service endpoints.

· Decentralized systems: DIDs are rooted in decentralized systems that provide the mechanism and features required for DPKI.

· DID User Agents: Applications that enable real people to use decentralized identities. User Agent apps aid in creating DIDs, managing data and permissions, and signing/validating DID-linked claims.

· DIF Universal Resolver: A server that utilizes a collection of DID Drivers to provide a standard means of lookup and resolution for DIDs across implementations and decentralized systems and that returns the DID Document Object (DDO) that encapsulates DPKI metadata associated with a DID.

· DIF Identity Hubs: A replicated mesh of encrypted personal datastores, composed of cloud and edge instances (like mobile phones, PCs or smart speakers), that facilitate identity data storage and identity interactions.

· DID Attestations: DID-signed attestations are based on standard formats and protocols. They enable identity owners to generate, present, and verify claims. This forms the basis of trust between users of the systems.

The architecture outlined above can be adapted to security token models without major modifications. In the context of security tokens, we can envision security token platforms to issue DIDs containing attestations about the result of the user’s KYC-AML processes. Those DIDs will be captured on-chain via decentralized hubs and will be incorporated as part of compliance protocols such as Securitize’s DS, TREX or ST-20.

The Zero-Knowledge-Proof Data Stores

The concepts of attestations or claims as well as decentralized hubs are some of the most important principles of decentralized identity models. One interesting idea is to combine decentralized hubs with zero-knowledge-proofs protocols such as zk-SNARKs to add another level of privacy to the DIDs while allowing other protocols to validate identity attestations. I like to call this concept zero-knowledge stores and has been embraced by protocols like uPort. For instance, we can envision a security token protocol that needs to validate that an investor is both accredited and based in Germany. Those claims/attestations can be expressed as SNARKs and validated at transfer time without revealing anything about the user’s identity. I recently presented a thesis about zk-SNARKs and KYC models which provides an idea of zero-knowledge-stores might work.

Some Protocols that Might Help

The space of decentralized identity is certainly very nascent but there are already some relevant efforts that might serve for inspiration to security token protocols. Here are some of my favorites:

· uPort: uPort has been steadily building a series of protocols and solutions for managing identities in decentralized applications. The current stack is compatible with Ethereum smart contracts and can be leveraged in permissioned blockchain applications

· Azure BaaS: The Azure team has done a remarkable job extending the core protocols of different blockchain to leverage Azure Active Directory identities. A recent example of this work was the implementation of the proof-of-authority consensus protocol in Ethereum applications.

· Sidetree: It is a composition of code-level components that include deterministic processing logic, a content addressable storage abstraction, and state validation procedures that can be deployed atop Layer 1 decentralized ledger systems (e.g. public blockchains) to produce permissionless, Layer 2 DID networks.

Just like compliance, identity is likely to become a standalone building block of security token architectures and one that should serve as an enabler for other capabilities. While centralized models might be the easiest way to build the first generation of identity models, decentralized identity architectures are likely to dominate in the long term. Efforts like DIF or the work of companies like Microsoft and uPort can provide a solid starting point to enable decentralized identity models in security tokens.

Some Reflections About Identity and Security Tokens: Part II was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.