Undoubtedly, Hyperledger Fabric offers a core substrate of decentralization and trust to corporations. It opens the door to the development of new use cases and business models based on the benefits of DLT technologies. Fabric supports digital assets, distributed logic through chaincodes, privacy using channels and other schemes such as private data collections, and the use of custom consensus through endorsement policies. Sadly, Fabric “as-is” lacks a key component for a successful decentralized ecosystem, a decentralized identity.
Fabric uses X.509 certificates to authenticate every entity and member in the network. This is really convenient for corporate environments, as organizations can use their existing CA infrastructure to issue new certificates for users, peers and applications. Thus, as long as a certificate is issued by a trusted CA in the network (i.e., the CA from a valid MSP organization in the system) its holder will have permission to interact with the network.
This identity management scheme seems to work for a great gamut of use cases, but the problem arises the moment user continuity between different organizations is required. If user A holds a valid certificate issued by Org1, he is able to interact with the network through peers of Org1, or at least by entities that know how to validate its “chain of trust.” However, if user A wants to interact with the network through a Fabric app from Org2, peers of Org2 won’t be able to identify if A is a valid user in the network.
This is especially a problem when, instead of deploying a user-specific network where organizations and their relationships are well defined (where users belong to a single organization and only interact through this organization’s infrastructure), we launch a general-purpose network with users seamlessly interacting with any of the deployed applications over the network. This is the reason why we embarked in the development of TrustID, an attempt to decentralize Fabric’s identity.
In Telefónica we have been building TrustOS, an abstraction layer for blockchain platforms that enable companies and developers with a way of implementing their decentralized use cases without having to worry about the low-level complexity of DLT networks. One of the core engines of TrustOS is a general-purpose Hyperledger Fabric network. The first releases of TrustOS leveraged Fabric’s default identity management, so new users were authenticated through Telefonica-issued certificates. Initially, this made sense, as we were the only organization in the network deploying applications. Unfortunately, when we started on boarding new organizations and applications to the system, our users started suffering the aforementioned itinerancy issues. Any users who wanted to interact with more than one organization had to hold a valid certificate signed by every organization in the network through whose infrastructure he wanted to interact. In short, the management of user identities was a complete nightmare in terms of operation and UX.
We then decided to design TrustID as a standalone identity module for TrustOS. We followed a decentralized identity approach for its design, where users (and services) are identified through a DID. 
These DIDs follow the W3C standard, and they serve as a unique ID to identify users. DIDs aggregate all the pieces of public information required to authenticate a user (i.e., their public key or X.509 certificate).
In order to uniquely identify chaincodes and services deployed in TrustOS, we decided to also give them DIDs so that they could be seamlessly discovered and accessed even if they “live” in independent channels not shared by all the organizations of the network.
All the authentication and management of identities in the system is performed on-chain through an “Identity Chaincode.” This chaincode has the following parts:
- Chaincode proxy: This receives and routes every TrustID authenticated transaction. It’s responsible for authenticating users, interacting with the ID registries, and routing user calls to external chaincodes. It also implements the desired access policies by the different organizations.
- User Registry: This stores every user DID. It implements basic setter and getter operations and enforces the desired access rights per organization.
- Service Registry: This pays the registry role for services.
- External service chaincodes: This ensures service chaincodes with whom users want to interact can be deployed in any channel. Once requests are successfully authenticated, the proxy chaincode is responsible for forwarding transactions to them.
Thus, if user A wants to start interacting with the network, he requests the generation of a new DID. The related keys to this DID could be an existing X.509 issued by a valid organization, or even an Ethereum-related public key (internally we used all the JWS, JWE, JWK, secp256k1, etc. RFCs to make our Fabric infrastructure compatible with identities of any nature for the sake of interoperability). This DID generation request has to be validated by a valid organization of the network. Once verified, every transaction signed by user A and directed through the Proxy CC is authenticated successfully and delegated to the corresponding chaincode.
We developed TrustID to ease the management of identities for the case of TrustOS. Users shouldn’t need to hold a different set of credentials for each network or decentralized application they interact with. The same credentials used to access your owned Bitcoins and manage your tokens in Ethereum should let you update the state of a Fabric asset or launch a secondary market in TrustOS. This is the rationale behind TrustID. Moreover, pushing Hyperledger Fabric’s user identity management on-chain has opened the door to exciting consequences such as service interoperability between networks, or the use of Fabric as a universal authentication system, but more about this in future publications.