# An Empirical Study of a Trustworthy Cloud Common Data Model Using Decentralized Identifiers
## 3 The Extended to Identify Management Scheme for Cloud CDM
### Issuing IRB Credential  
With a connection with the researcher's agent established the IRB issuer can interact with that agent. It might ask for a presentation to confirm the identity of the researcher. Figure 7: Schema definition for CDM identity issued by IRB. Eventually, it will reach the point of needing to issue a credential to the researcher. To do that, the controller passes to the framework the type of the credential, the data for the claims, and the connection identifier for the researcher, and the framework (for the most part) takes care of issuing the credential for the given research subject. Note that after offering the credential to the researcher, the response might not come back for hours. This is not an issue, the issuer framework will just wait. Once the credential is issued, an identifier for the credential is given back to the controller, which again stores that with the rest of the information it keeps on the researcher. To issue an Indy credential, the simplest instance of the protocol must have three steps:  
* The issuer sends the holder an offer message. * The holder responds with a request message. * The issuer completes the exchange by sending the holder an issue message containing the verifiable credential. The access policy defines programmatically the requirements for authorization to access CDM. The access policy defines these rules based on the CDM, user/group assignments, and ownership assignments. The IRB credential represents the access policy of CDM. Algorithm 2 describes the steps for issuing credential, and the detailed issuing flow is as follows. 1. The holder sends a proposal to the issuer (issuer receives proposal). When the holder starts with sending a proposal, it uses the/issue-credential-2.0/send-proposal endpoint. 2. The issuer sends an offer to the holder based on the proposal (holder receives offer). The issuer receives the proposal and can respond with an offer using the/issue-credential-2.0/records/[id]/send-offer endpoint. After this offer, the flow continues with the holder responding with a request. 3. The holder sends a request to the issuer (issuer receives request). If the holder automatically accepts offers and turns them into requests, then the issuing of credentials would be completely automated. That improves privacy--making the user in control of when and whom to share information with. 4. The issuer sends credentials to the holder (holder receives credentials). The issue credential protocol is used to enable an issuer to provide a holder with a verifiable credential. In this protocol:  
* There are two participants (issuer, holder). * There are four message types (propose, offer, request, and issue). * There are four states (proposed, offered, requested, and issued). 5. The holder stores credentials and sends acknowledgement to the issuer. Verifiable credentials are issued to the user and stored in his/her digital wallet, and the user decides when and where to use them. 6. The issuer receives acknowledgement. ```
1:for each Researcher agent do
2: Initiate DID Exchange with CDM provider agent to establish DIDComm channel. 3:Researcher agent delivers the CDM selected to CDM provider agent via DIDComm channel. 4:CDM provider offers Verified CDM token credential over DIDComm. 5:Researcher agent accepts and stores the credential
6:CDM provider encrypts the CDM and delivers the cipher CDM to CDM consumer agent with the IRB number approved by IRB
7:end for
7:The CDM is derived from the EMR of in CDM provider
8:Verified CDM token credential is specified by PROVIDER

### Proof the Credential

Privacy is important when dealing with CDM. The entities using DIDs will be able to express only the portions of their credentials. This expression of a subset of one's credential is called credential presentation. Specifically, the presentation refers to the verifiable data received by a verifier.