Nowadays, the legal entity that performs a conformity assessment of Cloud Service Providers (CSP) against relevant regulations and standards is the Conformity Assessment Body (CAB). It carries out audit following the required regulations. Once the audits are completed, a conformity assessment results report is submitted. MEDINA, as a framework for helping in the audit processes, also provides an additional tool for digitalizing the conformity assessment results report and considering it as part of the CSP identity.

This new tool is based on the Self-Sovereign Identity (SSI) concept. SSI is a kind of digital identity which provides control, security and portability. The individual (or organisation) to whom the identity belongs, owns, controls and manages their identity completely; they acquire responsibility for managing how, when and with whom they share their personal data.

In general, there are three actors involved in the SSI concept:

• Issuer

It provides verifiable credentials with identity attributes related to the user. It creates and signs credentials. In MEDINA, the CAB will be the trusted authority acting as issuer of the conformity assessment result reports, issuing verifiable credentials containing the reports details.

The verifiable credentials could include “public” attestations for being save in a public registry (including, for example, the final conformality assessment result) as well as “private” or “confidential” attestations, for being privately saved by the cloud service provider (including, for example, the specific non-conformities).

• Owner

It locally stores and controls the credentials about oneself. In MEDINA, the CSPs will be the owners who own, store and control the verifiable credentials with the conformity assessment result report details. Furthermore, they will generate verifiable proofs from the public or private verifiable credentials details issued by the CAB.

• Verifier

It needs to identify a user’s attribute or a set of them based on verifiable credentials by trusted issuers. In MEDINA, the CSPs clients could act as verifiers. They could ask their CSPs for proofs of conformity assessments, being able to verify their validity.

The verifier does not necessarily be related to the issuer, so, the only way to digitally prove credentials have been really issued by a trusted issuer, and have not been modified in any way, is by means of digital signatures. Digital signatures are based on applying a private key in a digital signature algorithm over a specific information. The signature can be verified using the same digital signature algorithm but with the associated public key. In the SSI context, digital signing is at least applied by the issuer to the credentials, becoming Verifiable Credentials, and by the owner to the presentations, becoming Verifiable Presentations.

Public keys associated to issuers and holders should then be known. Most of the current SSI implementations are backboned by Blockchain (or general Distributed Ledger Technologies, DLT), which can act as a suitable global repository for public key identifiers in SSI, as it solves several problems from traditional databases.

• Trust: Blockchain is based on a decentralized network of computers which is not owned by one single party, so it is not necessary to trust on any specific party.
• Integrity: Immutability is an inherent property of Blockchain guaranteeing tamper-proofed data.
• Availability: Blockchain is a network of computers across the globe and bringing down it is near to impossible.

The process for the cloud security certification management following the SSI approach is as follows:

1. The MEDINA framework detects the certificate state has changed, and it communicates the update to the CAB. The credential with the previous certificate state and conformity assessment result report details is automatically revoked and a new credential with the new certificate state is generated by the CAB.
2. The CAB will make necessary internal checks and add the CAB report (public and/or private part)
3. The CAB will then issue or not the new credential to the CSP with the updated information about the conformity assessment results.
4. The new credential with the new certificate state and associated conformity assessment result report signed by the CAB is shared with the CSP.
5. The CSP stores the new credential as part of its identity.
6. The CSP staff will be able to visualize the historical credentials they have, at any time.
7. If a CSP client needs to know the certificate state or any other information gathered in the conformity assessment result report, he/she will ask the CSP for a proof of the the credential signed by the CAB.
8. The CSP will answer the proof request with the necessary information.
9. The CSP client could then verify the validity of the proof (based on a credential signed by the CAB).