Some Reflections About Identity and Security Tokens: Part I

Identity is the key element that differentiate security tokens from other blockchain protocols. In the current generation of security token platforms, identity is constrained to the use of “white lists” which represent a directory of investors approved to perform specific transactions. While white lists enable identity-based capabilities, they do not represent a form of identity in and out itself. As the security token space evolves, identity should evolve as a standalone protocols that are used across different security token platforms. Achieving this requires a careful balance between securities law, the characteristics of distributed ledger runtimes and decades of research in identity management protocols. In this two part article, I would like to explore some ideas about identity protocols that could be relevant to the next wave of security token platforms. The subject of identity is incredibly complex and even more so when we extrapolate to decentralized architectures. At the risk of oversimplifying some ideas, I am going to attempt to provide a logical path of reasoning to understand the characteristics of identity systems in security tokens and how some of those ideas can materialize from a technical standpoint. Understanding identity in the context of security tokens can be seen as a three-step question. Avoiding the Mistakes of the Internet One of the ideas that I find incredibly powerful to explain the relevance of identity in security token models is to compare it to the challenges of identity on the internet. Identity has long been considered one of the “fundamental missing blocks” of the internet. Architecturally, the internet didn’t include an identity protocol which meant that we had to produce second and third tier identity solutions as the internet evolved. The lack of universal consensus about what constitutes an identity on the internet has been the root cause of the increasing fragmentation of the ecosystem which have translated into vulnerabilities to cyber-security attacks. Just like the internet, blockchains have evolved without identity as a first-class citizen. The notion of identity by computation expressed in consensus protocols fall short to model many user centric business processes such as those required in securities transfer. Security tokens clearly rely on identity representations to enforce compliance checkpoints for specific transactions but I would argue that vision is short-sided. Compliance is just one of the many applications of identity in digital securities. To avoid the mistakes of the internet, identity should be established as a first-class building block in the architecture of security token platforms and as a key enabler of any other protocol in the space. The Laws of Identity There have been many computer science papers written about identity but none influenced my thinking about the space as published by Microsoft’s Distinguished Engineer . I was fortunate enough to interact with Cameron regularly at the time the paper came out and I must have driven him crazy with my silly questions trying to address my lack of understanding of a subject that I considered obvious until that point. Written in 2005, was the paper that influenced an entire generation of identity management solutions that solutions that still rule the market today. In his paper, Cameron explains many of the challenges of identity in the internet and outlines seven key principles that should be considered to enable digital identity systems: The Laws of Identity Kim Cameron The Laws of Identity Technical identity systems must only reveal information identifying a user with the user’s consent. User Control and Consent: The solution which discloses the least amount of identifying information and best limits its use is the most stable long-term solution. Minimal Disclosure for a Constrained Use: Digital identity systems must be designed so the disclosure of identifying information is limited to parties having a necessary and justifiable place in a given identity relationship. Justifiable Parties: A universal identity system must support both “omni-directional” identifiers for use by public entities and “unidirectional” identifiers for use by private entities, thus facilitating discovery while preventing unnecessary release of correlation handles. Directed Identity: A universal identity system must channel and enable the inter-working of multiple identity technologies run by multiple identity providers. Pluralism of Operators and Technologies: The universal identity metasystem must define the human user to be a component of the distributed system integrated through unambiguous human-machine communication mechanisms offering protection against identity attacks. Human Integration: The unifying identity meta-system must guarantee its users a simple, consistent experience while enabling separation of contexts through multiple operators and technologies. Consistent Experience Across Contexts: The seven laws of identity evolved the identity management space from monolithic solutions to federated architectures based on a new notion known as claim-based identity. Fundamentally, the claims-based theory of identity has four fundamental elements: · An identity is a set claims that represent assertions about the truth related to a specific subject or person. Identity: · An entity that can generate claims based assertions about a specific user. Identity Provider: · An entity that will accept and trust the identity issued by a specific provider. Relying Party: · The entity that is abstracted by an identity representation. User: Let’s put these four concepts in practice with an example of a person going to a liquor store to purchase some alcoholic beverages. Before completing the purchase, the user needs to present the store representative with a valid form of identity such as a driver’s license. This identity includes certain claims about the user such as age or address which were asserted by a trusted identity provider(like The Department of Motor Vehicles in The US). In this example, the store representative acts as a relying party trusting the claims asserted by the identity provider. The Laws of Identity were transformational for its time but they were also created for a world with centralized gate keepers. Just the notion of a trusted identity provider introduces an indirect level of dependency on a centralized authority. The emergence of blockchains and decentralized runtimes forced the laws of identity to be adapted to a world in which the trust is place of math and cryptography instead of centralized authorities. Identity and Security Tokens: From Apps to Protocols The obvious benefit of identity in the context of security tokens is to enforce securities law and compliance rules. However, if we reduce the value of identity to those elements we are drastically constraining the potential of crypto-securities. Universal identity representations brings many intangible benefits to security token architectures which are essential to the evolution of the space. · In a blockchain runtime such as the ones running security token platforms, users should be able to own their identity and use it to interact with different applications. This highly contrasts with today’s security token models in which every platform is creating their own identity representation. User-Centric vs. App-Centric Identity: · Imagine if the same investor can reuse the results of a KYC process to participate on invest on security tokens issued by different platforms. Interoperability: · Investors can use a single identity to login to different marketplaces or DApps that interact with security tokens. Portability: · Compliance rules can be authored against universal identity representations without any dependencies on specific platforms. Programmable Compliance: · Identity should be the foundation of new forms of consensus such as Proof-Of-Authority that avoid expensive computation logic. Consensus Models: In the context of security tokens, identity models sit at the intersection identity protocols, decentralized blockchain architectures and securities law. The key challenge for evolving identity in security token solutions is to transition from app-centric identity models such as proprietary KYC to programmable identity protocols. That transition is likely to include some centralized models at the beginning but eventually evolved into more decentralized protocols. Factoring the areas listed previously, we can arrive to a few characteristics of a universal identity representation in security tokens: · In a security token model identity should be own by users and enforced by the different security token apps like issuance platforms or exchanges. User-Owned, App-Enforced: · A identity in a security token app should be a set of claims or assertions about a specific user or entity. Claims-Based: · 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. Reversible: · 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. Based on Identity Standards: · Identity should be able to be reused into other security token protocols. Programmable: With this in mind, we can start thinking how to design an identity protocol for security tokens. That will be the subject of my next post.