TrustID

In today's call María Teresa nieto from TrustID joined us for a very interesting discussion on authenticating Hyperledger Fabric.

Currently in the utility emissions channel, the Fabric Certificate Authority issues security credentials (public and private key) for different users.  The client application, such as opentaps, is responsible for authenticating the user, and then it will call Fabric chain code on behalf of the user.  Fabric then uses its security credentials for that user to authenticate access to the chain code.  Therefore, the client application is responsible for making sure that it is calling the chain code on behalf of the right user.

TrustID would issue security credentials (distributed identifiers or DIDs) at the client.  Then we would call chain code through TrustID, and TrustID would authenticate against the user's locally stored security credentials and then call the chain code.  The advantage is that then we would be verifying against the user's locally available or distributed credentials, rather than relying on a centralized application.  This would also allow TrustID to potentially authenticate users on multiple blockchains.  

Some possible for extensions for TrustID:

• TrustID is currently performing the chain code operations as the admin user on the Fabric network.  Should it actually cause Fabric to perform operations as the authenticated user?
• Meanwhile it should be record which user authorized each operation, even if it is performing operations on the network as the admin user.

To move forward with TrustID, we should research the following topics:

1. What is the long-term plan for Fabric user authentication?  Should Fabric ultimately integrate TrustID to allow for native distributed identifiers?
2. How does TrustID compare with Indy and Aries?
3. How does TrustID compare to signing transactions offline directly (like in this tutorial)?

Thanks again María Teresa nietofor your presentation, and kamlesh nagwarefor setting this up!