TrustID

In today's call Maria 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 Maria Teresa Nietofor your presentation, and Kamlesh Nagwarefor setting this up!


zoom_0.mp4

  • No labels

2 Comments

  1. Si Chen

    I started on a discussion about this on the Fabric mailing list.  See https://lists.hyperledger.org/g/fabric/topic/80192384#9562

    Also, I spoke with Artem Bargeras well.  He suggested that we also take a look at:

    Since client signing could be supported in these ways, there seems to be no move on the part of the Fabric project towards client signing of transactions.

  2. Si Chen

    Some ideas for signing transactions with Metamask thru TrustId from Maria:

    It should be possible because at the end the Ethereum keys are a public and private key. So in the sdk it should be implemented the generation of the key and the creation of the JWS. From the chaincode side, it should be implemented the verification of the signature. From the metamask side, we should be able to point to a Hyperledger fabric network or, at least, an api to forward the request.