Team members:

Alex Casella (axc@bu.edu): Team captain, architect, backend & blockchain developer

Vidhu Bhatnagar (vidhu@bu.edu): Frontend developer

Iriana Rodriguez (irianar@bu.edu): Storyteller and researcher

Inspiration

Forest products are all around us — from our pencils and papers, to our furniture and flooring, and much more. We want to help the Forest Stewardship Council (FSC) and Docusign work as hard for our forests, as the forests work for us.

Unfortunately, the Coronavirus has made it difficult for the FSC certification body (CB) to provide a chain of custody certification for companies in the forest industry supply chain. Specifically, it has become harder for FSC to conduct onsite audits of these companies, which is crucial in the pursuit of deciding what makes an ethical forest industry.

What it does

To resolve this problem, we have built a web application that enables FSC auditors to virtually audit CoC applicants and issue these certifications. In addition, we have built a blockchain microservice to keep track of certifications with an immutable ledger. Let’s bring people who love forests together and help make today’s decisions work for tomorrow’s world.

From the forest to the end customer, our app can be used by all companies in its supply chain.

How we built it

Frontend UI

The frontend UI is built with React, Redux, and Ant Design. When a user first logs in, they enter a guided walkthrough of the certification process. Our interface supports multiple user roles (Applicant, CB, FSC, ASI). Each roles correspond to a different walkthrough experience tailored based on their permissions and needs. Data is persisted through the backend REST API server.

Authentication and Authorization

User login is done by exchanging their credentials for a JWT token from the backend server. This JWT token is signed by an asymmetric key and encodes information including user's email and role.

{
  "user": {
    "id": "5f48737f8968a481770ab4df",
    "email": "cb@cb.org",
    "name": "Tom",
    "role": "CB"
  },
  "iat": 1598755434,
  "exp": 1630291434
}

The token is decoded to facilitate Role Based Access Control.

Docusign and OAuth2

OAuth2 is used to make request to Docusign on behalf of a user. This is used to generate embedded signing ceremonies.

OAuth code and token exchange is facilitated by proxying requests through the backend server. When the token is received by the frontend, it is saved in the browser's local storage and refreshed when it's expired.

Google Drive Integration

A google drive folder is used to upload evidences and observations which are then evaluated by the auditor. This folder is embedded and integrated in the UI's observation step.

Evaluations

Evaluations allow the auditor to comment on observations. This data is persisted in Dynamics' evaluation schema. Every evaluation has a date, subject (observation) and the related certificate which the observation is part of.

CRUD operations on the evaluations schema are proxied through the backend server.

Live Chat

Our live chat feature allows different parties to communicate with each other in a unified chat interface. This allows conversations to be scoped to the certification in progress.

This is implemented using long polling which is what allows real time chat to take place. Periodically the UI polls the backend to check if any new messages are available. The chat component keeps track of whether a message was sent by the current user or by a different user, and uses this information to visually distinguish different messages.

Backend server

Our backend server is built with Node.js and Express. We have written our server side code in Typescript for the ability to do static type checking and less error prone code.

The server stores FSC data & schema, evaluations, and certificates to Microsoft Dynamics 365. Evaluations and certificates follow the required FSC schema. In addition, the server stores user info, roles, and audit comments to MongoDB Atlas.

The server exposes the following 15 REST APIs, consumed by our UI. The decoupling of server and UI is beneficial because we can scale up the server without impacting the UI, and the UI can be swapped out as needed.

Register user
POST api/user/

Get all registered users
GET api/user/

Login and authenticate
POST api/auth/

Get logged in user
GET api/auth/

Get all organizations from MS Dynamics CRM
GET api/org/

Add a new certificate to MS Dynamics. When the blockchain microservice is enabled this will add a certificate to the ledger as well
POST api/certificate/

Update an existing certificate's status to "Issued" in MS Dynamics. When the blockchain microservice is enabled this will update the certificate in the ledger as well
POST api/evaluation/certificate/:certificateID

Get all certificates from MS Dynamics
GET api/certificate/

Add a new evaluation for a certificate to MS Dynamics. Evaluations are only visible to FSC, ASI, and CB
POST api/evaluation/

Get all evaluations for a certificate from MS Dynamics
GET api/evaluation/certificate/:certificateID

Add a feedback comment for a certificate, comment is visible to CoC applicant
POST api/certificate/:certificateID/add_comment

Get all feedback comments for a certificate
GET api/certificate/:certificateID/comments

Get Docusign access token with authorization code
GET api/docusign/token

Get embedded signing URL for FSC Trademark License Agreement
POST api/docusign/agreement

Get embedded signing URL for FSC Certificate Template
POST api/docusign/final_certificate

We have also added an authentication middleware for role based access control of our APIs. Roles can be "CB", "FSC", "ASI", or "Applicant". The following is achieved:

  • Only a CB auditor can add an evaluation comment. These evaluations are only visible to CB, FSC, and ASI.
  • Only a CB auditor can issue a certificate and update a certificate.
  • Both the CB auditor and the CoC applicant can chat freely on evidences. As shown in the chat box feature of our UI.

In addition, we have integrated with DocuSign's eSignature APIs. The CoC applicant is required to sign the FSC Trademark License Agreement and the CB auditor is required to sign the FSC Certificate using embedded signing ceremonies.

For our demo, the server is deployed to AWS.

Blockchain microservice

Simply relying on a centralized database such as Microsoft Dynamics isn't enough. We have decided to take advantage of blockchain technology and add an immutable source of truth for each certificate issued by the FSC.

Our blockchain microservice is built on top of Hyperledger Fabric. Hyperledger Fabric is an open source private permissioned blockchain framework. The microservice's server is built with Node.js and Express. The server side code is written in Typescript. The server calls Hyperledger Fabric's Contract APIs to communicate with the blockchain network.

The smart contract chaincode is written in Typescript as well. It is ready to be hosted on a managed blockchain service such as the Amazon Managed Blockchain service.

Certificate object in the blockchain ledger:

@Object()
export class Certificate {
  @Property()
  public certificateID: string;
  public type: string;
  public company: string;
  public issuer: string;
  public issuanceDate: string;
  public status: string;
}

The microservice server exposes REST APIs, called by the backend server:

Add a certificate to the blockchain ledger
POST api/blockchain/certificates

We have made it optional for the backend server to connect to the blockchain microservice. In the backend server, the config setting is the enable_blockchain field in src/config/config.ts. After the chaincode is deployed to a managed blockchain service, this option can be turned on, and the microservice's server can be started. When this is enabled, the backend server can call the POST api/blockchain/certificates API when updating the certificate's status to "Issued" in Microsoft Dynamics. This creates a certificate in the immutable ledger.

Challenges we ran into

We have ran into a few challenges throughout the hackathon and have overcome all of them.

Most notably, we had a lot of back and forth on how and where we should deploy our blockchain microservice. We knew we wanted to deploy it to the cloud but weren't sure about which service we should use. After making sure the smart contract chaincode runs smoothly in a local network, we initially decided to deploy to an AWS EC2 Ubuntu instance. However, we soon realized that this would require an ongoing dev ops engineer to maintain the network. Then we did more research and decided the Amazon Managed Blockchain Service is a better alternative since Amazon took care of dev ops maintainance.

We also had a hard time getting Microsoft Dynamics web API to work with the provided Docusign Schema, and implementing the Docusign Embedded Signing API. In both cases, the error messages were vague and we had to take extra steps to log the response and figure out what went wrong. Eventually we got both to work.

Logistically, we had trouble finding other teams to collborate with for the super app collaboration. We have spoken to three different teams that worked on App 2 but they all ended up dropping out of the event.

Accomplishments that we're proud of

We are very proud of making a scalable and easy to use application that the FSC can take advantage of right away. We are also proud to have implemented the app using many different technologies. We made the choice to not use the easiest software and tools, but the right ones for the requirements. For example, even though it was more work for us, we have decided to use Typescript in our entire stack for the ability to do static type checking, leading to less error prone code. We have also decoupled the frontend, backend server, and blockchain microservice so that each piece can be scaled up as needed without impacting the others. We wanted to make an app that the FSC can take to production without much overhaul and we are proud to have accomplished this.

What we learned

This project helped sharpen our skills as developers and exposed us to new technologies such as Microsoft Dynamics and AWS CodePipeline.

More importantly, we learned about the importance of a well managed forest supply chain, as well as the efforts and difficulties around forest management. This hackathon has inspired us to more actively contribute to global conservation and saving the environment.

What's next for Greenblocks

We are proud to have gotten this far in our spare time in 2 months. However, there are a few improvements to be made if the FSC would like to use it in production.

  • On the frontend, implement a more seamless integration with google drive which allows users to drag and drop files, and directly add evaluations in the form of annotations in the file view.
  • Since there are multiple actors in this certification process, use of notifications and email alerts would help make the process more efficient.
  • Deploy the smart contract chaincode to a managed service.
  • Add additional features to the smart contract to allow more companies in the supply chain to participate.
  • Enhance authentication and restrict access to blockchain microservice APIs.

Try it out

Our UI is live at: http://docusignfsc.s3-website-us-east-1.amazonaws.com/login

Auditor: Email (case sensitive): cb@cb.org Password: password

CoC company representative: Email (case sensitive): Applicant@tree.org Password: password

Local environment

To start the UI:

cd frontend_app
tsc
npm install
npm run start

To start the backend server

npm install
npm run server

Checkout our demo video on Youtube!

Thank you Docusign and FSC for the opportunity to learn, give back, and compete in this hackathon.

Built With

Share this project:

Updates