I am trying to design a Hyperledger Fabric solution with following requirements
The users are signed-up with an organization
The user should however have their individual identities on Blockchain
The users would interact with Blockchain through a web application
The users should store their own private keys / certificates
Individual user's key / certificate should be used to sign the transaction going to Blockchain. The organization however should not have access to user's private key / certificate
Instead the web application should merely transfer the signed content of the transaction to Blockchain, making it tamper-proof
Are there any solutions available that would cater to these requirements, so that the users continue to work through the web application only?
Can node.js SDK for Fabric be used on the client side to sign the transaction using the locally stored private key / certificate on user's desktop / laptop?
As of right now, no, there are no solutions available to cater to these requirements as the node SDK does not currently support a separation of logic between signing transaction proposals and sending transaction proposals. Step 6 is not possible with the 1.2 SDK.
Separating that logic is slated for the 1.3 release.
Related
Basically trying to find resources to understand Sovereignty wrt to identities.
How Identities are maintained within Hyperledger Indy?
how can the decentralized digital nature of identities
benefit to avoid data and identity thefts?
How can the users own and control their identities ?
How to integrate SSIs with Hyperledger Fabric ?
Identities on Hyperledger Indy are Pairwise Pseudonymous Identifiers by default to prevent identity correlation. Decentralised Identifiers (DIDs) act as the primary keys on the ledger. DIDs on the ledger point to the DID Descriptor objects (DDOs), signed JSON objects that can contain Public Keys and Service Endpoints for a given identifier.
Decentralised Identifiers will help us to maintain an audit trail for identities. Decentralised identifiers will provide tamper evidence that makes identity theft quite difficult. The implementation approach also matters. In the Hyperledger Indy implementation, we get the ability to revoke credentials. If we can see any trace of an audit trail on a possible attempt of identity theft, we can revoke the identity and credentials.
When it is a self sovereign identity created by the user, there will be separate identity issuer, identity maintainer / ledger and identity verifier. Through pairwise identity architecture, identity issuer will always be able to control the identity records and identity workflows.
With regard to Hyperledger Fabric integration, a few possible options exist. All of them are in the research and experimentation phase. However it is worth exploring. Please let me list a few of them.
Hyperledger Foundation Projects for 2019 - HLD Fabric + HLD Indy
Stack Overflow - Communication between HLD Fabric - HLD Indy
Self-Sovereign Identity is a new decentralized identity where control of identity is not with the issuer but it is with citizens. e.g Currently your National ID is maintained and governed by an Issuer which is Government, but as per Self Sovereign Identity, it is you, who will manage your national ID and decide what to do with it. Now identity will be citizen-centric, not issuer-centric and that's how decentralize identity differ from normal identity services.
Now let me answer the following question:
1: How Identities are maintained within Hyperledger Indy?
Ans - Identities are maintained at two levels, public DID, schema, and other Public details are stored inside Hyperledger Indy ledger but Citizen's personal Information, Verifiable credentials (driving license, national id) are stored in a Hyperledger Aires-based Mobile Wallet app.
2: how can the decentralized digital nature of identities benefit to avoid data and identity thefts?
Ans - Now Identities are stored in users' own mobile wallets encrypted with keys that are far safer than identities that are getting stored with the issuer and act as a honey pot for attackers. Facebook, Twitter, Gmail data leaks are common nowadays.
Another good things are even if your identities are compromised, as long as attackers don't have a private key/master key, those identities can’t be utilized for any purpose.
if your master key is compromised, there is a way to recover the key as well as revocation of compromised identity is possible.
3: How can the users own and control their identities?
Ans - This is the basis of self-sovereign identity, Issuer will create verifiable credentials like your driving license, sign with its own Public Key which is embedded as part of DID in Hyperledger Indy ledger and issue it. The user will store that verifiable credential in a mobile wallet. Now User can decide to whom to share this verifiable credential. Now if the user went to a car rental company, the car rental company will create a presentation proof asking for driving license details, User mobile wallet will create a response of that presentation proof and sent it to the car rental company. Car rental company verify the proof by getting the public keys of the issuer DID from the Indy ledger. This is how identities will be issue, controlled by citizens and verification will be done without contacting Issue (Driving License Authority ) at all.
4: How to integrate SSIs with Hyperledger Fabric?
Ans - As of now, there are no such enterprise developments happening. SSI is a very generic term, SSI can be implemented using Ethereum which is uport/DAF Project, Hyperledger Aries, and other open-source DLTs. Integrating with Fabric depends on the use case and workflow.
Want to create a app using hyperledger Febric for multiple registred users, Also user can manage own data, transfer asset.
I also want to authenticate users based on login token given by back end of our app to the blockchain.
Any idea how can i do this ?
its a broad question, but you can get some insights into your use case below.
First, see resources here - https://github.com/hyperledger/composer-knowledge-wiki/blob/latest/knowledge.md#node-app and here -> How to bring an app developed on Hyperledger Composer to production? plus Composer identity / card programmatic generation (eg identity isue etc) example here -> https://github.com/hyperledger/composer-knowledge-wiki/blob/latest/knowledge.md#cardapis
see also this Stack Overflow for links on existing samples that can give you some insights -> How to bring an app developed on Hyperledger Composer to production?
On Authentication of users based on token - see overview of REST server authentication here -> https://hyperledger.github.io/composer/latest/integrating/enabling-rest-authentication.html and check out these two token-based auth tutorials -> https://hyperledger.github.io/composer/latest/tutorials/google_oauth2_rest and https://www.codementor.io/gangachris125/passport-jwt-authentication-for-hyperledger-composer-rest-server-jqfgkoljn
In comopser rest server I know its advisable to store network card with composer rest server. Now what if I dont want to store my network card in rest server wallet. How to sign transaction indvidually by passing my certificate during calls to rest server.
You can use Cloud-based wallets see -> https://hyperledger.github.io/composer/next/business-network/cloud-wallets available from v0.18.x onwards
You can use the Composer JS APIs to connect to the business network with a business network card, and then transact on the network, as that blockchain identity. Example here -> https://github.com/hyperledger/composer-sample-networks/blob/master/packages/pii-network/test/pii.js#L119 onwards (instead of MemoryCardStore shown here, you can use FileSystemCardStore to work with a card in your wallet store)
See also Hyperledger Composer Web application user authentication for more information
I started composer rest server in multi user mode, using github oAuth authentication. I opened one session in chrome and one in firefox (to emulate as two different users) and authenticated using github. Now in one browser I wish to use one network card and in chrome another network card. Now when I import a network card in firefox same is reflected in Chrome as well. Doesn't it defeats purpose of authourisation ? So if one user is using its network card to perform transaction the other user will also be using the same network card as its been set as default for composer rest server. How to deal with scenario ?
The default is set at the REST Client - not the REST server. You're consuming the REST APIs as a client - as the two different blockchain identities (contained in each of your business network cards). Once a client has authenticated to the REST API, that client can add Blockchain identities to a wallet. The wallet is private to that client, and is not accessible to other clients. When a REST client makes a request to the REST server, a Blockchain identity in each clients wallet is used to digitally sign all transactions made by that client (because the identity is set as default, at the time).
The github authentication scheme is a 'delegated' authentication scheme and is using a client application (id and secret) authentication mechanism to enable a client to use the REST APIs and get a token, without needing to authenticate as a user every time.
I had this same problem. Configured the composer rest server with multi user using a jwt strategy, but I was seeing the same wallet (and the same default card) regardless of which user was logged in.
I found that the loopback-component-passport package which largely manages the wallet data was importing my users correctly, but they were all being associated with the same identity because the identity id was taken from the COMPOSER_PROVIDERS config and not the signing in user.
To fix it I modified loopback-component-passport/lib/models/user-identity.js.
Look in the UserIdentity.login method around line 100 where the userIdentity is being populated.
Change:
provider: provider,
to something like
provider: profile.sub,
depending on your payload / user profile.
After that each user will have their own identity registered in your loopback database and each signed in user should have their own wallet.
I was reading this pretty cool article this morning:
https://medium.com/#CazChurchUk/developing-multi-user-application-using-the-hyperledger-composer-rest-server-b3b88e857ccc
I am interested in the Rest Server features but I have a couple of questions on it:
How does the Rest Server knows which wallet to use for a specific logged-in client?
How to create channels and join peers from/using the Rest Server?
Thanks hackers!
Once a REST client (where the wallet is) has authenticated to the REST Server, that client can add Blockchain identities (one or more) to its own REST client wallet. The wallet is private to that client, and is not accessible to other clients. When a client makes a request to the REST server, a Blockchain identity in the clients wallet is used to digitally sign all transactions made by that client (and the REST server knows who that is on the business network as that identity is mapped to a participant).
Please note that this feature requires that clients trust the REST server. This trust is required because this feature requires that the REST server stores the clients Blockchain identities as part of the card. Therefore, it is strongly recommended that clients only use REST servers that are managed by a trusted party, such as an administrator within their organization.
All information regarding authenticated users and their wallets (containing each users business network cards when multiple user mode is enabled) is persisted in a LoopBack data source by using a LoopBack connector. You would normally set up a persistent store such as MongoDB and the REST server would use a Loopback adapter to access the MOngoDB store. REST clients that have authenticated via a strategy will normally get an access token (once they authenticate) and which is stored locally (such as in the browser for OAUTH2)
Channels and Peers (which come from Hyperledger Fabric) are configured in connection profiles (connection.json file) which are part of the business network cards built for a participant of the business network. The REST server itself doesn't 'join peers or channels' it knows about it because it is started with a business network card (and the definition of the channel and peers are known to the REST server that discovers the business network to which it relates). Obviously you can stand up many REST server instances to serve the different 'living' business networks deployed (on whatever channels (ledgers) or peers defined in the profile) in an organisation.