Project Plan - Implement Client Side Security for Climate SIG Fabric Application

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

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

Tasks

An error occured while executinng macro:

Access token 4 not found

Icon

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 REST API using the Metamask plugin.

We will also look into using the TrustID project for managing DID access to different networks of the blockchain carbon accounting project. 

The first step in this project is to setup the offline signing process.

TustID generated DID credentials will be used to sign transactions on the utility emissions channel Fabric network. 

Rather than hosting a password protected copy of the DIDs private key within the TrustID-SDK, the keys are too be stored on the client side. The plan it so configure a custom RPC on the Metamask plugin (however any client key store could be used) to sign transaction payloads destined for the emissions channel.

This will require over-ridding the key-store management in the trustID-SDK.

The role of Trust ID is authenticating the DIDs as a security layer for a desired network where the payload is delivered.

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.?