Planned:

Summary:

We went through the DAO voting scheme and discussed how to implement it with the Consumer Disclosure WG's sustainability scoring.  Robin Klemens helped make a couple of important improvements to prevent vote gaming: the maker of a proposal can only stake a fixed number of voting tokens on the proposal; there is a limited (4 hour window) for canceling and withdrawing your vote, and there is a fee for it; and makers of successful proposals get a 50% bonus to encourage them to make more helpful proposals. 

Then (starting at 55 minutes into the recording below) we discussed Kamlesh Nagware's mentorship for integrating Fabric and Aries and ours for integrating TrustID for client side security.  We discussed how Aries could be used to store decentralized identities (DIDs) on Fabric instead of on Indy, if TrustID could be used to authenticate with private keys in the Metamask wallet, and how to integrate them together.  

Recording:

20210426 ca2sig p2p programming call.mp4


Hyperledger is committed to creating a safe and welcoming

community for all. For more information

please visit the Hyperledger Code of Conduct.


Time:


Dial-In Information:  [ZOOM]

You can join either from your computer or from your phone:




  • No labels

5 Comments

  1. Si Chen

    Robin Klemens Kamlesh Nagware Vatsal Mishra Pritam SinghThanks for your input about the security features today.

    I'm thinking about this configuration for security:

    • Aries is used to establish multiple credentials for the user, for example that they're a customer of the utility with an account number, they have an account in a Metamask or similar wallet with an address, and they have a user id on the Fabric network or is known thru TrustId (I can go either way here.)  It will not store the account number or the private key of the address, just the public information.
    • When the user transacts with the Fabric network, it will sign the transaction with Metamask.  
    • TrustID will confirm that the user has signed, find the user's roles through Aries, and then send the transaction to Fabric chain code.
    • Fabric chain code will execute the transaction based on the user and their role.

    1. Peter Somogyvari

      Si ChenThank you for writing this up, it helped me a lot just reading through it.

      Quick question (and sorry if it's a trivial one): According to this plan, do all the user private keys reside in the MetaMask wallet (including the Fabric ones)?

      E.g. is the user completely in charge of their keys? Just asking because if MetaMask can be made to support Fabric keys somehow I'd be very much interested in further researching that for Cactus' Fabric connector as well.

      1. Si Chen

        Yes!  That's exactly what I'm hoping for.

        We've been using web3modal which will support Metamask and other wallets.  I think the keys could be in those wallets, and when you sign with your wallet, it could pass through TrustId to execute chain code.  TrustId could also contact Aries to verify your identity or role.

    2. Bertrand WILLIAMSRIOUX

      Thanks for the summary. This programming call + the presentation by Maria back in January have been a great crash course in TrustID. Some notes/questions on the integration of Aries, MetaMask, and Fabric (TrustID+Utility Emissions Channel).

      1. Aries: support generation, storage and communication of user credentials on the client side
        1. Use encryption libraries (e.g., Ursa) to generate private keys and construct DID documents (public keys) as an extension of TrustID sdk.
        2. Secure DIDcomm for client to pass proof of credential ownership (signatures) to an application
      2. TrustID: identity management layer for business logic  (e.g. Utility Emission Channel)
        1. establish trust anchor IDs used to validate user credentials
        2. Store ZK-proofs of validated user credentials
      3. Metamask: client side private key store
        1. Allow client to reuse private keys for multiple DIDs (user credentials)
        2. Self-sign certificates that are approved/validated by the trust anchors (replace trustID keystore on the filesystem)

      What about Indy? an independent public/permissioned identity network (e.g., Indy) would offer flexible credential authentication for use in applications outside fabric.

      Instead TrustID proposes a native identity authentication layer for Fabric as chain code using its private/permissioned consensus framework.

      If authentication was migrated to Indy, I guess something similar to TrustID would still be needed, as the gate keeper of the private network? Indy does not guarantee access to Fabric. Is this a fair description? If so could one setup TrustID to accept Indy’s authentication layer, setting the access policy, i.e., only DID’s approved by the fabric CA can call on peer chaincode?

      1. Si Chen

        I think TrustID is for security and Indy is for identity, so the difference is TrustID can be used to authenticate a user to Fabric using some credentials (private keys), whereas Indy records different identity credentials that have been issued to the user but does not store the credntials.  Combining the two, then, we can authenticate the user and know that they are also a customer of the utility.