Your question gets to the heart of many use cases. And with v2.0 release coming, this is a great time to have the discussion. You have two options to choose from depending on your specific requirements:
1) Key-level endorsement policy (v1.3 and higher)
- Key creates bound by chaincode endorsement policy and chaincode logic (e.g. you could set chaincode endorsement policy to any org, if you'd like any org to create keys).
- Key creator sets endorsement policy for future key updates - future key updates must be endorsed by specified org, or set or orgs
- Applicable to both public channel data and private data collections. Private data collection may be org-specific or a subset of channel members.
2) Implicit org-specific private data collection (new in v2.0)
- Org-specific private key namespace (implicitly available for each org in the channel, no need to define) - only the specific org stores the data, other orgs receive hash only.
- All key creates and updates must be endorsed by the specific org
- The org can share their private key on a need-to-know basis by allowing other orgs to query chaincode on their peer (key-level ACL could itself be managed in the org's private key space)
- The org can also share their private data with another org by creating the same key/value in the other org's private key space, the 'receiving' org must endorse.
- A corresponding public channel key could also be written in the create transaction (or later), if the org would like to share their data with all channel members.
- On-chain hashes are used to verify that the shared private data matches the original private data.
What is still not possible? Public channel keys segmented into org-specific namespaces that require the specific org to endorse creates/updates. That is, consider a more general collection concept, where on each collection you could specify not just endorsement policy (as in v2.0), but also whether the data is public or private. You can essentially get there using the techniques mentioned above, but if first class support is important to a large number of uses cases, direct support could be added in a future release. Let us know what you think!
"Anoop Vijayan" ---01/28/2020 03:39:03 AM---Hello Fabric guys, I have a scenario where there are X orgs in a Hyperledger Fabric network.
From: "Anoop Vijayan" <anoop@...>
To: "fabric@..." <fabric@...>
Date: 01/28/2020 03:39 AM
Subject: [EXTERNAL] [Hyperledger Fabric] Storing/Retrieving key values in a collaborative way - endorsement policy
Sent by: fabric@...
Hello Fabric guys,
I have a scenario where there are X orgs in a Hyperledger Fabric network.
I would like to have each org can create/set/reset their respective values for key(s).
However, other orgs should be able to only read them but not modify them.
Also, as there is only possible to set one policy per Chaincode, I have to use `OutOf()` but this would end up to an ability to modify org1’s changes without involving org1.
Lets say there are 10 orgs in a Hyperledger Fabric network.
Usual approach which we all know that works:
1. N (say N=2) Orgs should be able to set a unique key+value pair (can be implemented with Endorsement policy of type `OutOf(E[, E...])`)
- Org1 creates the key+value pair and gets signed from any of OrgX (2..N)
2. Implicit: Any 2 Orgs is able to modify any key+value pair
3. Any one of those orgs is able to get the value from the key (IIRC)
1. An org (containing multiple peers) should be able to set a unique key+value pair
2. Only that org can modify the key+value pair which it had set
3. Any one of orgs in Hyperledger Fabic network is able to read value from key
I have tried going through older mail archives (not all though) and didn’t find anything relevant.
The closest one which had relevance is, solved by private data collection which I am not sure if that solution applies here.
Hyperledger Fabric version can be: 1.4.x or 2.x
Please let me know your suggestions. Any answers like “Hyperledger is not suited for your purpose…” is also welcome :)