@adlrocha - TrustID
A New Approach to Fabric User Identity Management
This past week has been pretty exciting professionally for me. I managed —finally— to share with the community all the work we’ve been doing around performance best practices in Hyperledger Fabric through a Hyperledger meetup, and we announced in the Hyperledger Blog TrustID, our new approach for a decentralized identity in Hyperledger Fabric. Today I want to walk you through TrustID a bit more in detail, and share my view of its future.
Setting the context
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 ofTrustID, 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.
Welcome TrustID
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: It 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: It stores every user DID. It implements basic setter and getter operations and enforces the desired access rights per organization.
Service Registry: It pays the registry role for services.
External service chaincodes: It 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 use 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.
The TrustID project is conformed by the aforementioned chaincode and a client SDK to ease the integration and interaction with TrustID-enabled networks. Let’s illustrate step by step the interaction of a user with a Fabric network using TrustID.
First, the user has to be registered in the platform. If a user wants to register to the platform with one of its identities he just needs to sign his DID using his private key and send it to the proxy contract. The proxy contract inspects the signature and adds the user to the registry. This registration process generates an “unverified user” with limited access to network services. The TrustID SDK includes all the required functionality to seamlessly set up a user wallet to manage DIDs, sign requests, and send them to the proxy contract.
Unverified user’s have only access to public services. In order to have access to more features, a “controller” has to verify him and grant him an access level in order to be able to call restricted services. Thus, the controller needs to send a signed verification request to the proxy to trigger this verification.
Verified users with a specific access level are entitled to the deployment of new services and their listing in the service registry.
Users can interact and “invoke” functions of a service contract by sending a signed request to the proxy contract stating the service to call, the function, and its arguments. The proxy contract authenticates the request, it builds the transactions, and delegate the calls to the corresponding contract.
Thus, every interaction with a TrustID-enabled network can be signed using the SDK and routed to the proxy contract to trigger the function significantly simplifying user interaction with a DLT network. The only network currently supported by the TrustID SDK is Hyperledger Fabric; and the proxy contract has only been implemented as Fabric chaincode —for now—. Nonetheless, the modular architecture of TrustID was designed to allow its implementation over other DLT platforms (more about this in just a moment).
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.
Planning its roadmap
So what are our plans for TrustID? The first thing we are really looking for is feedback from the community. We started TrustID as an internal project to solve a really specific problem in our product roadmap, but early in its development we realized that the scope of the project could be broader, more general, and we could share it with the community so it could also benefit from it and help us evolve it.
We are already collecting some feedback after announcing the project in the Hyperledger Blog, and according to this feedback we will discuss internally if it makes sense to share it on the Hyperledger Labs to get the community involved and open the project to contributions (let me clarify something here, the ultimate decision on whether or not to do this is not mine and we will have to discuss it internally in the team. This is not an official announcement of any kind, I just wanted to share my personal view on TrustID and what I think its future looks like. This is my personal view of the matter, as with everything else in this newsletter. That is why I decided to launch a “strictly personal and non-transferable” newsletter, so I could write my uncensored opinion —just in case—).
What would be my ideal next steps for TrustID? The way the SDK and the architecture of chaincodes have been designed opens the door to their extension to other types of networks and platforms. The SDK has been implemented in a general way so that making it compatible with other networks implementing TrustID would be as easy as adding a driver for the new network in the SDK. The architecture of chaincodes is also general enough to be easily ported and implemented to other platforms. So as a next step it would be great to refine the design of TrustID in Fabric and port the model to other platforms in the Hyperledger ecosystem such as Besu, Sawtooth or even Indy to validate the interoperability of the model between platforms and with other decentralize identity proposals.
TrustID, could also be devised as a standard gateway of interaction to decentralized services living in different networks. The same way you have blockchain wallets compatible with several networks (Ethereum, Bitcoin, etc.), using TrustID we could have the equivalent of a single user wallet for corporate networks (Fabric, Corda, etc.) so that corporations don’t have to reinvent the identity model for every specific DLT platform they use. TrustID could be a “wallet to rule them all”, and using TrustID a user or an application could trigger functions in any of the services hosted by these networks.
Again, TrustID was designed with a really specific problem in mind in a pretty contrained context, and now we are trying to generalize it to broad its scope. We would love to know your feedback about the project and the value you see in it so that we can plan its roadmap and next steps accordingly. Stay tuned for more updates about TrustID, and to learn more about the future series I am planning after my “Performance Best Practices in Hyperledger Fabric Series”. See you next week!