System
The system consists of a private blockchain, the Consent Chain, with a proof of authority for mining, a set of contracts, an example IT-Service and a Consent Handling Service. It also uses the users external ethereum account e.g. from the mainnet, or other public blockchains, for signature when accepting or denying a consent form. If the user do not have one or choose to not use it they have to sign by entering the password again for their ethereum account on the Consent Chain that is created during registration.
This solution do not handle digital identity but is strongly related to it. How to connect them two or create a digital identity inside the Consent Chain is not considered in this prototype. This prototype accepts signature from an external ethereum account e.g. from the mainnnet or other public blockchains, stored locally in the users keystore. If not provided by the user the system falls back to creating a signature based on the Consent Chain ethereum account for the user. In both cases it requires the password for unlocking the account.
In this prototype an ethereum accounts on the Consent Chain will be created for each user and administrator (company) when they register for the IT-Service or the Consent Handling Service.
Company A, either internal or external to the consortium, can administrate their consent factory on the blockchain through the consortiums web portal and request new consent forms for registered users.
Company B is an external company to the consortium, i.e. not a member, when they create an IT-Service they can only check the status of a consent form, creating consent files and requesting consents from users by using the external Consent Handling Interface. They are considered a Company A when administrating their consent factory. This type of company is not included in the prototype yet, focus is for members for now.
Company C are internal (members) to the consortium and can perform any operations on the blockchain. They do not have to use the public consent handling service interface. They can go towards the contracts directly and create IT-Services using the blockchain directly for consent handling.
Company D:s are internal to the consortium and performs the mining of the blocks in the blockchain. They are the authorities of the consortium and can perform any operation on the blockchain. They can do all of the things a Company C can do in addition to mining.
The consent handler service is a web application that allows administrators to manage their consent factory, i.e. consent templates and makes it possible to create new consent forms for users, based on those templates. The user can also administer the requested consents from other companies. Normally this would be integrated into the IT-Service or other service e.g. through micro services.
This is an example IT-Service that allows users to register and login to use the example IT-service. In this prototype it is the same as the Consent Handler Service but typically this would be the companies own IT-Service integrated with the consent handling service e.g. through micro services.
This could also have been developed as a dapp running on the users device connected to the mainnet or other blockchain where his external ethereum account is used. The dapp could then via the external Consent Handler Interface manage the consents.
This interface allows external companies to allow their IT-Service (outside the consortium) to register users, create an initial consent file for the user, to create new consent forms for a user and to check a consent forms status e.g. through micro services.