Page History

...

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:

1. generate a csr using some client provided private key / encryption algorithm. (e.g. ECDSA prime256v1);
2. include the self-signed csr generated from the private key when enrolling new user with the fabric CA client;
3. build endorsement proposal with transaction payload and sign using the private keys encryption algorithm;
4. send signed proposal to required peers and check responses;
5. if valid build a new commit with the endorsement from (2), sign commit with the private key encryption and send to peers;

see function offlineSign(idx,network,chaincodeName,tx_params) in /asset-transfer-basic/application-javascript/app.js

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.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. The role of Trust ID is authenticating the DIDs as a security layer for a desired network where the payload is deliveredOne 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)

...