CODEWITHSUNDEEP
hyperledger-fabrichyperledgerhyperledger-fabric-ca
user3567365
user3567365

Reputation:

Unique id for a user across multiple organizations for ACL at the chaincode level in Hyperledger Fabric

i have a serious issue with Identity management at the chain code level, i am building an app where people can upload their education and work exeperience documents and the educational institutes and previous companies can approve it, i have this issue in doing so:

  1. Person is a universal participant, he is not dependent on any organization, i want to give him a universal identity irrespective of organizations and msps, because he can use any organization just to connect to the network as he does not maintain any peer. Now since i am not relying on the MSP credentials inside the chaincode because the user can access from any organization, how can i validate that it is the same person who has invoked a function. For example in Etherum, we can just use msg.sender as this is the user's Ethereum address and this is a universal identity.

  2. There is no import private key function in fabric-ca-client node sdk, how can a Person import his old private key when he switches organizations or uses a peer from a different organization?

Please help me in understanding how to implement universal identity for participants and authentication at the chaincode level

From what i have understood: MspId + CertId gives you a unique id at the chaincode level:

  1. What would happen if the certificate is revoked? If a certificate is revoked then the user cannot perform transactions on the network and there is no way in which he could use his previous account.
  2. Can a user use a certificate issued from msp of org1 via org2 peer? For example, if he was issued a certificate from an educational institute, then later he wants to perform some transactions from the peer of his employer.

UPDATE : I thought of a solution, maybe we could pass additional information, ie. an additional signed message from the user's private key, and a corresponding public key, using this public key i can write a method in chaincode to verify that the message was signed using the corresponding private key and identify the user. This mechanism will have no impact by the certs used to invoke the chaincode.

Can anyone validate this mechanism?

Upvotes: 0

Views: 452

Answers (2)

Gari Singh
Gari Singh

Reputation: 12053

For your second issue, the Node SDK does allow you to use existing cryptographic credentials via the Client.createUser(opts) function.

For your first issue, it's important to understand that basic access control for Fabric is done at the channel level with two basic permissions: ChannelReaders and ChannelWriters. Generally channel membership and permissions are at the organization level.

So let's say you have 5 organizations (Org1-Org5) running peers and you use a single channel channel1. You would add Org1-Org5 as members of the channel and use the default access control which means that all organizations have read/write access to the channel. You would then instantiate your chaincode on channel1. At this point, any client issued a certificate/credential by any of Org1-Org5 can invoke the chaincode on channel1 on any peer(s) from Org1-Org5 which have joined channel1 and have the chaincode installed.

Another option would be to create a different org (let's call it ClientOrg) which issues certificates for all clients (Org1-Org5 would only issue identities for their peer nodes and administrators). You could add ClientOrg to your channel and then clients would be able to invoke the chaincode as well. I'd also make sure that the endorsement policy for the chaincode did not include ClientOrg.

Upvotes: 1

Andrei Dragotoniu
Andrei Dragotoniu

Reputation: 6335

In Ethereum or any other blockchain, a public address is not a way to prove identity. An account has a public address and a private key which you can use to sign messages to prove they come from the right person. That private key is what identifies you.

In Hyperledger, every user has to belong to an organisation. It's not meant to be a system where random users can participate and change data as they see fit. Certificates play an important role and if those are revoked then there is no more access to the system, period.

I suggest you look into using Hyperledger Indy as it deals with your exact scenario : https://www.hyperledger.org/projects/hyperledger-indy

Upvotes: 1

Related Questions