In today's peer programming call, we went through Robin Klemens's docker-compose-setup and the REST API for accessing the chain code.  You can see a demo of this in the beginning of the attached video.

The big question today was how to extend this to a UI.  We looked at a UI example with opentaps SEAS, which is an application developed for managing building energy data.  This application supports multiple users who could set up multiple sites (think buildings) each of which could have utility meters that have billing data associated with them.

The UI could be an Application which is run by many different auditors connecting to different peer nodes through REST API's.   The peer nodes then connect to the ledger.  We could support many different applications which use REST to connect to the ledger, many different instances of each application, and many different peer nodes on the ledger through this architecture.  It would not be routed through one application or one REST server accessing the ledger. 

We can think of an Application as being run by an Auditor organization, which could then support many Users.  Each User could be a customer or employee of the Auditor and work with multiple Sites, and each Site would have multiple Utilities from which the Auditor gets billing and energy use data.

The Application would need to create credentials for each User, then the User would access the ledger to record and get emissions data with its credentials.  It would be up to the User to hold its credentials however they would like – in hardware, local, or cloud-based wallets.   

To do this, we would need to expand the current REST api to:

  • allow Admin user to issue credentials for Users through the Certificate Authority on the ledger
  • allow User to use credentials for accessing ledger requests

The scope of our current work is to get this working on local development environment, and later work on TLS security and cloud deployment.

We also decided to continue development using docker-compo-setup and Go and to finish the Go chain code instead of the Node.js version.

The Go chain code will be converted to use contract API from shim.

Finally we decided to get some help with UI design, so if anybody reading this would like to help on the front end design, please let me know.

We will have our next call in 2 weeks time.

Recordings of Today's Call

Climate Accounting WG Peer Programming 2020-08-31 11.21.00 AM Part 1.mov

Climate Accounting WG Peer Programming 2020-08-31 11.21.00 AM Part 2.mov

  • No labels

16 Comments

  1. Robin Klemens

    Si Chen thanks for this great sum up.

    1. Si Chen

      Thanks Robin Klemens

      I looked up how other service providers use authentication keys.

      Google API will take an authentication key as part of the GET request URL, for example: 
      https://maps.googleapis.com/maps/api/geocode/json?address=Richmond%2C+VA%2C+Richmond%2CVA&bounds=&components=&region=&language=&key=<my-key-here>

      Amazon will take it as part of the Authentication header of a request. See https://docs.aws.amazon.com/apigateway/api-reference/making-http-requests/

      1. Robin Klemens

        Thanks, Si Chen for providing the information!.
        This week, I had some great discussions with Kamlesh Nagware about the design of the REST API.
        In general, there are two ways we could design the REST API and thus handle private key management of the customer.

        The first way is to store the private keys of all customers at the REST API Layer in a KeyStore. This could be an HSM for example. The chart below gives a high-level overview of such an architecture.
        Each auditor organization provides a REST API and Frontend for all customers which were registered by this organization. The customer would authenticate themselves via username and password in some OAUTH2 style. The REST Server would then access the customer's private key to sign the transaction to the blockchain.


        Pros:

        • Customer doesn't need to store their keys on every device they use
        • User friendly in terms of easy login and key handling

        Cons:

        • All of the private keys of one organization are stored in a central database
        • Org admin is granted permanent access to all private keys and could misuse them (of course also without having access to the keys, the org admin could revoke all certificate. Different story)

        In the second, more decentralized approach, each customer is in charge of storing their private keys by themselves. Thus, no private keys will be stored at the REST API Layer. This could be done by offline-signing the transactions. In the scenario, the hosting of the REST Server and frontend wouldn't require any of the auditors and the customer could choose which frontend and REST API they want to use.

        Pros:

        • No central storage of private keys
        • More Decentralization
        • Increased privacy
        • Less power to and dependency on the auditor organizations
        • There is no instance in the system with access to more than one customer's private key and thus costumer`s identity
        • No need to trust any provider in terms of keeping my (the costumer's) private key safe
        • Higher availability of service

        Cons:

        • An extra amount of work for customers; is in charge of key handling
        • If a customer loses their private key it is lost. (Keys cannot be restored as passwords

        In the scope of our prototype, the second approach in which we sign transactions offline would require too much work to do. Therefore, we should implement a simple user authentification and store the private keys encrypted at the REST server layer. However, in the future, I prefer to have costumers keep their own private key and thus make the API and frontend level more independent as this is more in line with the distributed nature of blockchains.

        I'd be happy for your feedback. And many thanks to Kamlesh Nagware for his help!

        Best
        Robin


        1. Kamlesh Nagware

          Robin Klemens  Yes Indeed its great discussion, Lets discuss in next SIG meeting and we can get more feedback from community. Also Si Chen posted regarding REST API server architecure in Hyperledger Fabric rocket chat/mailing list.Lets see what other says about this.

          Thanks

          Kamlesh

          1. Robin Klemens

            Kamlesh Nagware yes, I saw the post of Si Chen in the Hyperledger Rocket chat. After further discussions in our next meeting, we could also reach out to some Hyperledger Fabric Developers/Maintainers. David Boswell offered to connect us to the community if we have specific needs. Having someone of Fabric community in one of our future calls could benefit us all.

            1. Si Chen

              Robin Klemens Could you explain what is required in "the second approach in which we sign transactions offline"?  We don't have to implement a full-scale client side DID management or wallet app.  All we need to do is instead of keeping the keys on the server side (behind the REST api), pass it back as a request to the client.  Then for future requests, instead of looking for the key on behind the REST api, just accept the key from the client.  Then it's the client's responsiblity to store, secure, and manage those keys.

              Perhaps we could find some other open source code like https://github.com/Nas2020/VC4AvParts and reuse some of their components to do this?

              1. Kamlesh Nagware

                Si Chen Robin Klemens this repo is based on Hyperledger Indy so don't know how we can use it. Hyperledger Indy components and fabric not interoperable . 

                 https://github.com/Nas2020/VC4AvParts 

              2. Robin Klemens

                Si Chen
                In the scope of a PoC, we could store the private key on the local file system and use the fabric-sdk-node to sign the transaction which we send could send to either the REST API or directly to the blockchain. 
                For development beyond that, we can orientate ourselves on web3.js more specifically on web3-eth-accounts. We could implement a "wallet" which stores the private key of the customer with the functionalities to receive unsigned transactions, sign the transaction with the private key, and send the signed transaction back to the sender. 
                As Kamlesh Nagware already mentioned, by default, there is no interoperability given between Hyperledger Fabric and Indy/Aries, yet. 

                In addition to the scenario you describe, the customer could also generate their private keys by themselves with tools like OpenSSL and use the REST API to only enroll with CSR (scroll down to the end of the website).

                1. Si Chen

                  Robin Klemens I like this last idea: How about we have customer generate a private key and just have the REST API enroll key?

                  1. Robin Klemens

                    Si Chen in terms of decentralization, I totally agree. But we should not forget about usability since generating their own private keys could keep customers from participating. 
                    We could provide both ways or better ask customers for their feedback as soon as the first version of the prototype is ready.
                    In the meeting next Monday, we should spend some time prioritizing the functionalities we want to implement in the upcoming weeks.   

                    1. Kamlesh Nagware

                      Si Chen I agree withRobin Klemens 

                    2. Si Chen

                      Robin Klemens Kamlesh Nagware That is certainly true.  I think here we can think of it as either a technical user (using Debian?) making his own security key or a non-technical user (using an iPhone) getting a key from an app like https://connect.me/   In either case if we can interact with the key the user has generated, we can keep the POC scope to be reasonable while still being compatible with other blockchain/DLT/decentralized development out there.

                      1. Robin Klemens

                        I opened an issue in GitHub. Please feel free, to add more information.
                        https://github.com/opentaps/blockchain-carbon-accounting/issues/11

            2. David Boswell

              Robin Klemens Yes, I'm happy to help connect this group with others in the community.  Could you provide more specific details about what questions the group has about Fabric to help me figure out the right person to invite?

  2. Si Chen

    Robin Klemens Chris Gabriel from Hyperchain Labs will be demoing some of his work with using the Fabric Certificate Authority, with which he has built a carbon network for different organizations (carbon emitter, regulator, renewable energy project manager, verifier, etc.) during our next Peer Programming call (2020-09-14)  I think this will be pretty interesting.

    1. Robin Klemens

      Si ChenGreat news. I'm looking forward to the demo of Chris Gabriel.