...
- 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
Github issues macro query labels=mentorship-trustid repo blockchain-carbon-accounting user hyperledger-labs token 4
| query | labels=mentorship-trustid |
|---|---|
| repo | blockchain-carbon-accounting |
| user | hyperledger-labs |
| token | 4 |
Explanation
Explanation of the project goes here.
Methodology
Methodology followed is here.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 use the TrustID project, including an SDK to interact with the trustID solution (DID generator/manager) implemented as Fabric chaincode.
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.?