I am a beginner in Hyperledger Indy and due to the fact that it is at a very initial stage, I am facing some issues in understanding the basic concepts. I could not find any information about Trustee and Steward. I would appreciate if someone can explain these roles.
Hyperledger is a public permissioned network. It means that anybody can see the transaction but only a few can write the transaction into the ledger. Stewards are the ones who can write the transaction into Hyperleder Indy ledger maintained by Sovrin.
Stewards can be a high profile Government-owned institution whose task is to run and maintained the sovrin network. To become a steward, there is a proper onboarding process defined by Sovrin.
Trustee
The trustee's role is to become a guardian for other identity holders in case of recovering identities. e.g User A can nominate User B to be his trustee so that in case of User A lost his mobile, identity can be still recovered with the help of User B. User B can be banks or any trusted service provider or Individuals.
Bonus Point
Trust Anchor(TA):
TA's are the link between User and Stewards. TA can be banks, universities, hospitals, service providers, insurance companies. TA's are onboarded by approvals of Stewards. So TA accepts the request from user and forwards this request to Stewards in case of writing into the ledger.
In an Indy based network there are some initials users called endorsers, these include stewards and trustees. Only trustees and stewards can create new endorsers and a trustee can be created only by other trustees. You can read more information in the Hyperledger Indy official documentation in the genesis-transactions section
STEWARDS
Indy is designed to be operated such that everyone can see the contents of the blockchain (public), but only pre-approved participants, known as stewards, are permitted to participate in the validation process (permissioned).
TRUSTEES
To understand trustees I suggest you read the documentation about Trustee Setup Protocol, assumptions section, I report here some parts that in my opinion are useful for understanding the concept of trustee through a series of features that it guarantees as an entity to other network users.
Trustees can be granted various capabilities by identity owners:
Safeguarding a recovery share. This will be the most common
Revoke an authorized agent on behalf of an identity owner
Provision a new agent on behalf of an identity owner
Be an administrator for managing identity owner agents
SOVRIN NETWORK (a further concept of trustee)
In the Sovrin Network (a single, global instance of Hyperledger Indy), each node is operated by a Sovrin steward, an organization (company, government, university, etc.) that has agreed to a legal agreement that defines how they will operate their node (minimum hardware, network access, monitoring, security, maintenance, etc.) within the rules defined in the Sovrin governance framework. The Sovrin Foundation, through its governance frameworks, provides governance for the network, the use of nodes and coordinating the software upgrades (including adding new features) to the nodes. In addition to the concept of trustee already described in the Sovrin network the Foundation includes a Board of Trustees to oversee the business and legal aspects of the network and a Technical Governance Board to oversee the technical aspects.
Related
some questions about service accounts and best practises on GCP.
1) I'm able to create a "brand new" service account. How can I ensure that this new service account doesn't have any kind of privileges bound to it? I'm asking this because for a project I need to create multiple service accounts with only one permission: write access to a single Google Storage bucket. Nothing more. How can I ensure that this is the only granted permission and nothing else ?
2) Should I create a new Google Cloud Project for every customer I have, in example, one project for each website that I'll host to GCP or a single company project (in this case, my company) would be enough to hold all Compute Instances, Storage buckets and so on, needed by my customers ?
Managing hundreds of project would be overkill, if possible, i prefere to avoid this, without impacting secutiry.
Thank you.
You can only constrain service account permissions to enabled services that implement IAM (the Google Cloud Platform services including Cloud Storage). For services that don't implement IAM, the only way to limit a service account's auth is through OAuth scopes.
Projects appear provide a more robust security perimeter for you to separate your tenant customers. Additionally, you get enforced separation of billing, logging, auditing etc. It's debatable whether managing per customer projects (each owning a bucket and related service accounts) has different security than a multi-customer project (with many buckets and service accounts) since service accounts may be easily extended across projects. I recommend whichever path you choose, you ensure control is effected programmatically to minimize human error of granting one customer's account(s) to another customer's bucket(s).
HTH!
I am a beginner with hyperledger composer, I am not clear with ACL (access control) in hyperledger composer. Sorry, if my question have problem.
Why we need ACL?
When we use it?
Where we use it?
To control access to resources on the ledger, or the kinds of CRUD operations (can I create an asset, can I update an asset), or kind of transaction types a participant of the business network can perform.
Because you want to apply access control - security 101 !
It is applied usually within the realms of a business network. So if I have a business network called 'Commodity Trading' I may only wish 'Trader 1' (a participant) to see his own historical trades on the business network - and not see others' trades. Yet I may allow him (by access rules) to be able to execute certain trade types, because of his role, in that Trade Brokerage. You get the picture.
ACL stands for Access control language and constitutes an important part of our composer network. Hyperledger as we know is a permissioned blockchain and ACL helps in achieving that. It helps in writing rules which define the different access levels of any participant of the ecosystem. We can define whether a participant can CREATE, READ, UPDATE or DELETE asset. We can restrict their access to the assets as well.We use ACL whenever there is are participant at different levels in our network and we don't need each of them to perform every operation on the assets.
You must go through this link once : https://hyperledger.github.io/composer/v0.16/reference/acl_language
Is there a way to make transactions in SawTooth private?
I know HyperLedger Fabric has "channels" and Quorum has private transactions, so looking for something similar but don't see it:
https://sawtooth.hyperledger.org/docs/core/releases/latest/architecture.html
Of course theoretically one could implement encrypt/decrypt process, but this cumbersome to track (if it is an encrypted or decrypted payload)
Since Sawtooth is permissioned it is possible to set up users that have different roles and access rights. This would allow you to create transactions that are private to specific identities.
You can configure a validator to only accept transactions from identities listed in a local config file. Or, use the identity namespace to set the allowed identities, which will be checked when a transaction is received from a client or when a block is validated.
See the identity transaction family for more details of how Sawtooth manages identities and permissions:
The identity system described here is an extensible role and policy based system for defining permissions in a way which can be utilized by other pieces of the architecture. This includes the existing permissioning components for transactor key and validator key, but in the future may also be used by transaction family implementations.
The identity namespace:
Encompasses ways to identify participants based on public keys
Stores a set of permit and deny rules called “policies”
Stores the roles that those policies apply to
There is an experimental feature called Sawtooth Private Data Objects (PDO). Blockchain objects that are kept private through encryption.
For more information, see https://github.com/hyperledger-labs/private-data-objects/tree/master/sawtooth
For docs, see links in this tweet: https://twitter.com/kellymolson/status/1019299515646406656
Alternatively, you can encrypt your payload so others without a private key cannot see it in the blockchain. Or you can just store a hash/checksum in your payload.
We can use Private Transaction Families provided by the Hyperledger labs.
https://github.com/hyperledger-labs/private-transaction-families
The system is based on a generic distributed ledger infrastructure (Hyperledger Sawtooth) and an Intel® SGX (Software Guard Extensions) 'hardened' Transaction Processor which provides a mechanism to enable Hyperledger Sawtooth to contain private information that is both not publicly available but required to validate transactions.
For more information about how Private Transaction Families work, see the following link
https://github.com/hyperledger-labs/private-transaction-families/blob/master/SPECIFICATION.md
Currently in Hyperledger Fabric 1.0 there is a central membership service. I want a way to make it decentralized so that atlas 50% of the members have to agree for a new member to join the network. How can I achieve this?
The idea is basically put the membership logic in chain code and let member service fetch data from chain code at the time of enrollment. But how to enforce this, I mean how do we know that membership service is actually reading from blockchain and not cheating.
This is actually natively support by Hyperledger Fabric, and the behavior you describe is actually the default for channel membership changes.
Each channel begins life with a genesis block. The contents of this genesis block define the channel members, as well as policies for which users from these organizations are authorized to perform different functions on the blockchain. For instance, some users may be allowed to submit transactions, but not read the whole blockchain, while others could do both.
To change the channel membership, you submit a channel reconfiguration transaction. This transaction specifies the new membership, and must include enough signatures to authorize this modification. By default, this is signatures from the admins of a majority of the organizations.
The policy framework is actually quite powerful, and with a little knowledge, you can define even more powerful rules. For instance, you could require that OrgA and 3/10 other organizations sign off to change membership. Or, you could require that all but one Org agree to make any membership change, or an infinite number of other permutations.
Some links you might find helpful:
http://hyperledger-fabric.readthedocs.io/en/latest/configtxgen.html
http://hyperledger-fabric.readthedocs.io/en/latest/policies.html
http://hyperledger-fabric.readthedocs.io/en/latest/configtx.html
The documentation and tools around reconfiguration are a little lacking at the time of this writing. The most useful place you can probably look is:
https://github.com/hyperledger/fabric/tree/release/examples/configtxupdate
There are two protobuf structures you must familiarize yourself with, the common.ConfigUpdate, and the common.Config. Channels are created by submitting a signed config update to the ordering service, which generates a corresponding config embedded in the genesis block.
The policy which governs membership changes for a channel is specified as the mod_policy field of the Application group, which is a subgroup of the Channel group. This field defaults to Admins, which refers to the policy definition Admins within the Application group. By default, this policy is set to MAJORITY of the Admins policies for the organization groups defined under the Application group.
So, to modify this policy before creating your channel, you would decode the configtx to JSON using the configtxlator tool, make your modifications, and then encode it back using the configtxlator tool once again. Submitting this new transaction will create the channel with the policy you specified.
If you wish to modify membership after the fact, the process is similar. Retrieve the current channel configuration, decode and modify it, then use configtxlator to compute a config update structure which represents your change. Gather signatures via peer channel signconfigtx then submit it to modify your channel's configuration.
This process is obviously all a bit manual at the moment, but in the future, common tasks should be automated by the SDKs and the tooling should improve as well.
Note: configtxlator is a REST service so that it can be accessed conveniently from inside your SDK application, independent of language.
As a quick addendum. You asked how you can be sure that no one is 'cheating' and not really getting the required signatures. This is also built into the system. All changes to the channel configuration are validated not only by the ordering network, but by all peers in the system. If a configuration arrives which cannot be validated, then all nodes in the network will notices, and will halt usage of that channel until corrective administrative action is taken.
For decentralised membership, that is not dependent on a centralized CA, take a look at Blockstack.
Is it possible to allow for someone in hyperledger rights only to read, and to others read+write?
So, can you specify different roles for users?
I'm going to answer the question based on Hyperledger Fabric v1.0.0.
The short answer is yes.
There are a couple of areas to discuss:
1) Ability to send (broadcast) and receive (deliver) transactions to/from the ordering service.
As you know, in order for transactions to make it to the ledger, they must go through an ordering service. An ordering service can be divided up into channels (in simplest terms think of channels as being unique ledgers). Each channel has policies which define who is able to read and write from/to the channel. The documentation on this topic is being updated, but basically there are channel reader and writer policies. If you cannot "write" to the channel, you cannot submit transactions to the ordering service. Additionally, if you don't have access to write to a channel, you cannot send endorsement proposals to peers for chaincode which is deployed on channel you don't have write permission for.
These policies are all part of channel configuration transactions (for which the documentation is currently being updated / created).
2) Chaincode
Beyond the channel-based policies mentioned above, it is also possible to restrict access to chaincode functions as well. This is actually typically handled from within chaincode itself and it is up to the deployer / developer of the chaincode to handle this (especially in the current 1.0.0-alpha release). There is some additional work underway to add some access control libraries which will make doing this a lot simpler