Abstract
Implement client side security for the Climate SIG's Hyperledger Fabric application, so that transactions could be signed using Metamask through TrustId.
Mentor and Mentee
| Mentor | Mentor | Mentor | Mentor | Mentee |
|---|---|---|---|---|
Si Chen US PST | Vatsal Mishra IST | Maria Teresa Nieto CEST | Kamlesh Nagware IST | Bertrand Rioux AST (UTC +3) |
Communication channel: Email + Github
Project repo: https://github.com/hyperledger-labs/blockchain-carbon-accounting/tree/mentorship-trustid
Deliverables
- 1 Integrate TrustID with Fabric utility emissions channel
- 2 Use Metamask to sign Fabric transactions through TrustId
- 3
- 4
Milestones
Eval 1:
- a Integrate TrustID with Fabric
- b Get Metamask to sign transactions through TrustId
Eval 2:
- c
- d
Eval 3:
- e.
- f.
Eval 4:
- g.
- h.
Timeline
| Week | Task/Plan | Status |
|---|---|---|
| May 24 - May 28 | Set up project plan. | |
| May 31 - June 11 | Review TrustID from our previous call. Develop plan for integrating Fabric, TrustID, and Metamask. Integrate TrustID with Fabric. | |
| June 14 - June 25 | Finish integration of TrustID with Fabric. Integrate Metamask into TrustID to sign Fabric transactions. | |
| June 28 - July 2 | Get ready for first Evaluation | |
| July 5 - July 9 | Demo of signing Fabric transaction with Metamask thru TrustId. Eval 1 | |
| July 12 - July 23 | ||
| July 26 - August 6 | ||
| August 9 - August 13 | ||
| August 16 - August 27 | Eval 2 | |
| August 30 - Sept 3 | ||
| Sept 6 - Sept 17 | ||
| Sept 20 - 24 | ||
| Sept 27 - Oct 1 | Eval 3 | |
| Oct 4 - Oct 15 | ||
| Oct 18 - Oct 29 | ||
| Nov 1 - Nov 5 | ||
| Nov 8 - Nov 12 | Eval 4 Final evaluation and presentation of project |
Tasks
Explanation
This project will offer tools for the signing of transactions/contracts in a distributed network using trusted identity credentials that are fully controlled by private keys held by the client rather and not hosted in a password protected key-store.
Methodology
The project will enable users of the fabric utility emissions channel to use offline private key to sing transaction proposals.
Offline signing will be integrated into the channels javascript REST API using the Metamask plugin.
We will also look into potentially using TrustID for securing access of DIDs to different networks of the blockchain carbon accounting project. TustID generated DID credentials will be used to sign transactions on the utility emissions channel Fabric network.
The first step in this project is to setup offline signing following this tutorial. This includes several steps:
- generate a csr using some client provided private key / encryption algorithm. (e.g. ECDSA prime256v1);
- include the self-signed csr generated from the private key when enrolling new user with the fabric CA client;
- build endorsement proposal with transaction payload and sign using the private keys encryption algorithm;
- send signed proposal to required peers and check responses;
- if valid build a new commit with the endorsement from (2), sign commit with the private key encryption and send to peers;
The above process can be used for offline signing directly onto the utility emissions channels, or we can configure offline signing on TrustID. Trust ID acts as a security layer for linking DID/key pairs to a desired network where the payload is delivered. The offline signing is delegated to TrustID so that the same DID/key pairs can be used to interact with different networks.
This will require over-ridding the key-store management in the trustID-SDK. One could also do this directly in the SDK of the targeted Fabric network. Using TrustID instead means the offline signing logic is managed through TrustID, and we don't have to worry about setting up offline signing within each target network.
TrustID-sdk currently provides drivers for delivering payloads from the same DID to different (potentially multiple) Hyper-ledger networks. However, new drivers may be developed to use the same DID for access to other networks requiring the security provided by TrustID (e.g., besu)
Questions?: TrustID security and decentralization
The admin.(?) of the TrusID chain-code authenticates and delivers the payload to the registered network as the admin (not the registered user).
As I understand this mean the TrustID admin has to be an organization registered to the Fabric network as a proxy for the registered trustID credentials? Payload approvals need to be registered somewhere, should this occur on the TrustID nework?.
Do we care about TrustID network structure - i.e. how many peers do we need. I guess for development 1 is enough but a real use case would benefit from multiple both from a performance but also to represent different interest (i.e., more than one organization that operate the TrustId chaincode) ...
During the video I recall a conversation about how to use TrustID to perform the authentication only and send the signed payload as the authenticated user, f. From the Video call with Maria I understood that this is not straightforward, but could be done by implementing TrustId as system chain-code at the lower level (e.g., like fabric validation, endorsement chain-code).
I guess this is outside the scope of this mentorship, but maybe seomthing to look into.?