Identity mapping

Identity mapping is the process of converting the identity of an individual or an organization to an identity that is recognized on the network.

When looking at the solution from a business network perspective, what is the granularity of the identity that needs to be recognized? Will other organizations care whether Bob or Ann from ACME issued the transaction? In most cases, the answer will be no. Knowing that the transaction was issued by ACME will be sufficient.

Why is that, you may wonder. It is directly related to the concept of trust. Remember the concepts presented in Chapter 1Blockchain – Enterprise and Industry Perspective; blockchain solves the problem of time and trust. Understanding where the trust issues come from helps us rationalize what identities should be used to transact on the network. In most cases, our experience has been that trust issues occur between organizations.

If you think about a use case where a bank customer transacts through their bank portal, the customer will not care about the backend systems; they trust their bank's security system.

Having said that, there are situations where an identity will need to be mapped:

In this case, the integration layer will need to convert the inbound credentials (API Key, User ID and Password, JTW token, and so on) into a Hyperledger Fabric identity.

When working with the Hyperledger Composer REST gateway, you can configure it to support multiple users. The server leverages the node passport framework to manage this authentication. This provides the flexibility of supporting different models (for example, user ID/password, JWT, and OAUTH).

Once the client is authenticated to the server, there is an additional step that consists of loading the Hyperledger Composer business card into the server's user repository. There needs to be implicit trust between the client and the server, as the business card contains the private key.