What is the best way of storing the clients registration information off-chain in hyperledger fabric

Question

I want to create an application with the Hyperledger fabric network and I'm unsure what the optimal way of processing and storing the clients information is. It is important for me that the personal information get stored off-chain to not slow down the network.
Right now this is the process I thought about:

1. Client fills out form in frontend
2. Application (backend) generates unique UUID
3. (registering enrolling UUID in the wallet) unsure about this step
4. Chaincode gets called which saves the UUID in the state database
5. The UUID and the personal information like Username, email, password get encrypted and saved in an off-chain database like postgreSQL.

That way the UUID can be connected to the personal information because the UUID is also stored off-chain and it is still totally anonymous.
But is it necessary to register and enroll the user through the Node SDK with the enroll and register function before being able to access the chaincode, because without the registration there would be no identity for the client in the network?
And I'm also cunfused if this function from the fabcar samples is the same as the enroll and register function from the node SDK?

Thanks for your efforts and helping me understand this matter.

Answer 1

The enroll code of fabcar is the enroll of node-sdk.
In other words, they are the same.

• node-sdk/enroll
• fabcar/enroll

const secret = await ca.register({
    affiliation: 'org1.department1',
    enrollmentID: 'appUser',
    role: 'client'
}, adminUser);
const enrollment = await ca.enroll({
    enrollmentID: 'appUser',
    enrollmentSecret: secret
});

---

First, let's talk about fabric's SDK.
In general, in order to query/invoke chaincode on the fabric SDK, you need to obtain fabric client authority.
Suppose you register a specific user UUID as a Client of Fabric and call the chaincode through that Client.
In this case, the order you should perform is as follows.

1. enroll admin-client to Fabric-CA
2. register user-client by admin-client to Fabric-CA
3. chaincode invoke by admin-client or user-client to Fabric-Network(peers, orderers)

step 1, when Fabric-CA is first operated, the administrator ID and password can be specified through specified parameters. Based on the specified ID and password, a client key/certificate with admin authority is issued from Fabric-CA and stored. (Fabric-CA is recommended to be operated in an organizational unit, and client authority is organization dependent.)

step 2, a new user can be registered through the admin-client key/certificate. Probably you would register the UUID as enrollmentID. When the registration process is finished, the user-client's key/certificate is issued by enrolling in Fabric-CA, and it is stored.

step 3, the chaincode is query/invoke through the stored admin-client/user-client key/certificate. Of course, it can be performed only if the client is authorized, and this is defined in the genesis block of the channel in the blockchain network (that is, it must be set in the configtxgen process)

Overall, if you look at the scenario, you can see the two processes divided.

1. In case of separate authentication server

• Build a new database(for off-chain).
• When registering as a member, the user's information(UUID, password ...) is stored in the database
• going through the fabric user-client registration process, the key and certificate are stored in the file system or database.
• When logging in, based on the newly established database, authentication is performed.
• When the chaincode of the fabric network is called while the user's validity is verified according to the authentication procedure, it operates based on the mapped key and certificate.

2. When using an organization as an authentication server within Hyperledger Fabric

• User information is stored in the blockchain through PDC(Private Data Collection) provided by Fabric.
• PDC is an off-chain technology, and only predefined organizations share data.
• Through this function, validity of data can be performed by all organizations participating in the channel, but only organizations with permission can view/edit the actual sensitive information.
• In the end, the process and procedure are the same, but all resources can be managed on the blockchain. (Like all technologies, they have pros and cons, and trade-offs need to be taken care of.)

---

[NOTE]
If you are going to query/invoke the chaincode of the fabric network, fabric-client privileges are essential. Of course, you can do some tricks. for example)

• register admin-client on the server.
• After that, it operates the same as the existing authentication server/resource server.
• If the chaincode of Fabric Network is called, and it is valid by the existing authentication server, the chaincode is executed through the admin-client authority issued in advance.
• This does not require a separate user-client registration/management procedure.

However, the authority on the blockchain is all dependent on external certification authorities.