## 4 Implementation
### Experimental Result  
Figure 10 shows that a transaction can be considered as the creation of a new DID when a researcher is registered to a DID registry running on the von-network. The transaction gives several pieces of information containing a public key (Verkey) and a DID (Nym) in the distributed ledger. Nym is associated with the legal identity of an identity owner. After registering IRB, a transaction as shown in Figure 11 is generated.  
Figure 12 shows an example of a researcher's DID that is stored in his/her wallet. The DID method is used for specifying the mechanism by which a particular type of DID and its associated DID document are created. The DID is a kind of pairwise DID that is intended to be known by its subject and exactly one other party. It is used for operating a secure decentralized authentication mechanism by using asymmetric cryptography technology. In this case, it is resolvable by two parties, the researcher and IRB.  
Figure 9: The result of consensus of transaction which is stored in their ledgers in nodes.  
* ```  
Figure 11: The result of a transaction when registering IRB in von-network.  
Figure 12: The example of the DID of a researcher.  
Figure 10: The result of a transaction when registering a researcher in von-network.  
To build a web interface for access control of cloud CDM services, flask is used as a web application framework. Hyperledger Aries Cloud Agent Python (ACA-Py) [25] is used as a framework for constructing a VC ecosystem. As shown in Figure 14, the web page illustrates that IRBs give invitation messages to researchers. The message is used to establish a connection between researchers and IRBs. As shown in Figure 15, an IRB should accept a request for invitation by taking the invitation message from a researcher.  
In response to the request, the IRB provides a VC with access to the CDM provider. It plays a role as a claim to prove the researcher's identity when connecting to the CDM provider. The researcher obtains permission to make CDM data via a CDM service from a CDM provider. The CDM provider issues a credential to take access of the CDM consumer.  
Figure 14: The invitation message which is generated by IRB.  
Figure 13: The result of a transaction of a credential schema, which is used for issuing a credential by IRB.  
The credential contains two keys and a seed. The seed is used to introduce randomization at the beginning of the CDM data encryption process. At the beginning of the chained block encryption process, the IV introduces randomization. Before encrypting the CDM data, the CDM data is separated into two parts. A symmetric key is used to encrypt each of the two CDM components, ensuring the privacy of the CDM data. Figure 16 shows the VC offered by the CDM provider after delivering encrypted CDM. The VC is used as proof to obtain permission to receive CDM data from the CDM consumer.  
Figure 16: VC offered by the CDM provider after delivering CDM encrypted.  
Figure 15: Accepting the invitation message by Researcher.  
As shown in Figure 17, the researcher receives the decrypted CDM data from IPFS when the proof issued by the CDM provider is presented to the CDM consumer. We observe that access to the CDM can be enabled through the user's request, which has been verified through the credentials.