Planned:
Consumer Disclosures WG and DAO
Identity Solutions
How to implement an identity solution for the blockchain accounting applications using Hyperledger Indy, Aries, and TrustID. We have an approved mentorship for integrating TrustID, Kamlesh has also gotten one approved for integrating Fabric and Aries, and Robin has been doing a lot of work with Indy lately -- so this should be a very good discussion.
- Good resources to get started with the tools and frameworks of Hyperledger for Self Sovereign Identity (SSI) solutions
- A curated list of self-sovereign identity resources - https://github.com/animo/awesome-self-sovereign-identity
- High-level process flow with a mobile app: (6min) https://www.youtube.com/watch?v=bZrWAsD42-I
- Hyperledger Indy and Plenum. Plenum is the consensus protocol used in Indy: (33min) https://www.youtube.com/watch?v=bZrWAsD42-I
- Hyperledger Indy, Aries, and Ursa in the TOIP stack: (65min) https://www.youtube.com/watch?v=FfuhlF9ZYPM
- Hyperledger Aries Cloudagent Python - architectural deep dive: (81min) https://www.youtube.com/watch?v=FXTQEtB4fto
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:
Hyperledger is committed to creating a safe and welcoming community for all. For more information please visit the Hyperledger Code of Conduct. |
---|
Time:
- Monday, April 26, 2021 at 09 AM Pacific
- Add Climate Action and Accounting SIG calls to your calendar
Dial-In Information: [ZOOM]
You can join either from your computer or from your phone:
- From computer: https://zoom.us/j/6223336701?pwd=dkJKdHRlc3dNZEdKR1JYdW40R2pDUT09
- From phone: +1(855)880-1246 (toll free US number) or view International numbers
Meeting ID: 622 333 6701
5 Comments
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:
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.
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.
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).
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?
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.