Hyperledger fabric client registration - hyperledger-fabric

How is an end user client registered on the hyperledger Fabric network? does he need to call a smart contract for this or is the registration process done by some other procedure?

In order for end-users or clients to interact with the network, it is necessary to register them in the network.
First of all, you will need to implement Fabric Node/Java SDK to connect the blockchain network. Then You have to follow the below steps:
Create a connection profile for each organization.
Register the administrator user of each of the organizations.
After registering the admin, you can use these identities to generate the other users.
Kindly check the fabric-samples/fabcar/javascript folder where you will get all the sample code that you can study.

There is one more way to do this. You can use fabric ca client CLI commands too. See link below.
https://hyperledger-fabric-ca.readthedocs.io/en/release-1.4/clientcli.html#fabric-ca-client-s-cli

Related

How to make a user authentication using hyperledger fabric

i have a current channel of hyperledger fabric with chaincode that does CRUD operations my question is that is there any way to make a method in a chaincode that registers the new user when certain condition match.
You can use one of several methods to get the identity of the user:
GetCreator
GetId
GetMSPId
They are part of the Client Identity Chaincode Library, documented here: https://pkg.go.dev/github.com/hyperledger/fabric-chaincode-go/pkg/cid#section-readme
The Hyperledger Fabric docs provide some help for access control also if you're interested in that: https://hyperledger-fabric.readthedocs.io/en/latest/private-data/private-data.html?highlight=getmspid#private-data-sharing-patterns

Hyperledger Fabric: signing channel update

I am using Hyperledger Fabric v2.2 with multiple organizations setup. I want to join a new organization to an existing channel. The problem is in signing channel update.
Fabric docs says that there are two main implementations of signing:
“pass it along” - admin of Org1 signs channel update and sends in to Org2 admin, Org2 admin signs and sends to Org3 and so on, until enough signatures will be collected.
"The other option is to submit the update to every Admin on a channel and wait for enough signatures to come back. These signatures can then be stitched together and submitted. This makes life a bit more difficult for the Admin who created the config update (forcing them to deal with a file per signer) but is the recommended workflow for users which are developing Fabric management applications."
All samples that I found describes only the first implementation. But how to do it with the second? I found the related code in HLF Node.js SDK v1.4 but can't find the same for v2.2.
I had the same doubt, until I saw this here.
The Fabric v2.x SDKs only support transaction and query functions and event listening. Support for administrative functions for channels and nodes has been removed from the SDKs in favor of the CLI tools.
No more admin function starting from v2.x tho. Not sure if I answered your question.

Verify Indy Credential from within Fabric Chaincode

I'm trying to combine the core strengths of the two Hyperledger projects, Indy / Aries and Fabric.
In the scenario we have an Indy network for SSI and a Fabric network managing a token. The Fabric token accounts should be tied to the Indy identities. Furthermore, an identity is only allowed to move tokens when it can proof to be an active member of the golf club.
This means, the Fabric endorsers need a way to see the identity's DID and to verify the golf club credential.
Question: Is there a best practice architecture to achieve that?
My current approach is to let the user send a <Proof Proposal>,<Receiver>,<Qty> message via her Aries agent to a server connected with the Fabric network. The server then sends a transaction including this data to all endorsers via the fabric-sdk. Now, the chaincode gets executed at each organisation. The chaincode tells its Aries agent to verify this Proof Proposal, which leads to a huge amount of connection invitations and proof requests against the users agent. Once the verification is successful, the chaincode continues execution and changes the state.
I see several (potential) problems:
The user must accept many connection invitations manually (if there's no hardcoded auto-accept whitelist)
Even you could avoid the connection attempts (maybe /w ephemeral challenges? Documentation for that?), there would still be massive parallel traffic, due to the presentation protocol, incoming from a decently large fabric network.
Here's a visualisation:
Am I missing something? Do you have any hints / experiences about how this can be accomplished?
Kind regards

what is application signature in hyperledger fabric and how to set it?

what is Application's own signature in this context, and how can someone using hyperledger fabric node SDK can set the application's signature?
the application that you are talking about is simply a client app which talks to the ledger. The issue here is not the client app, the issue here is that you need a proper endorsement policy which establishes how anything goes onto the ledger.
Imagine this scenario ...
you have 2 orgs, Org1 and Org2, both owning one peer, P1 belongs to Org1, P2 belongs to Org2 and both peers joined on a channel, let's call it defaultchannel.
you deploy and instantiate your chaincode and set a basic endorsement policy which is 1-Of.
Each org has a client application, running against their own peer. When Org1 submits a transaction to the ledger, its validity is endorsed by itself, but not by the second org, because your policy requires only one to accomplish this. Basically in any network where you have more than one org, you really want a proper endorsement policy. 2-Of would work in the case of our example as any transaction would need to be validated by both orgs and that gives the ledger much better integrity.
Bottom line, your fabric network needs to be properly built and protected, especially in a production environment and this allows it to be protected by any client apps which have rights to interact with it. Your network being protected means that it doesn't matter how a client app is built and what it tries to do, it won't be able to bypass mechanisms such as the endorsement mechanisms.

Ability to use participant identity created with Composer CLI to launch composer rest server

I have created participants using the node CLI and Business Network Connection. I have also assigned them with an identity.
Now; is it possible to use this identity to launch the composer-rest-server as this participant? E.g. could this be turn into a card that I can import and use? I have the userSecret saved.
see answer here -> How to create participant , there identities via rest api that generated by composer rest server without importing cards via /importwallets?
for more detail.
But yes - you can use that BUSINESS NETWORK card (eg. like: restadmin#my-network) as the 'identity' (because the identity's cert/key are part of the BN card that connects the business network, when you use it to launch your REST server instance). So that would be an administrative id that's used to launch a REST server.
Then (therafter), any standard blockchain identities could come along and USE the REST API client (eg. after authenticating, etc etc) - that's why you've stood up the REST server instance :0-) - each REST client user, will connect to the REST server with their own BN cards (and again, containing its own identity cert/key, and which is mapped to a participant in the Composer business network) and that user's card would be imported into the users REST API Wallet to then use to interact with the deployed business network as that identity.

Resources