Gaia-X has been launched in 2019. Since that, various working groups have been working on making the vision of Gaia-X come true. This article provides an overview of self-descriptions and their necessity when selecting suitable infrastructure providers. We show what a self-description can look like using the example of Cloud&Heat.
Recap: What is Gaia-X and what's its aim?
Gaia-X aims to create a federated open data infrastructure based on European values regarding data and cloud sovereignty. In this context, the initiators want to bring together different providers and technologies within a European transparent and legally secure data ecosystem. Thus, it should be easier for small and medium-sized enterprises to combine different services and switch service providers.
In order to achieve these goals, a functioning regulatory framework is required. The current state of this framework as well as the designation of actors can be found in the latest Gaia-X architecture document.
The Gaia-X framework is being elaborated within different working groups. One of them deals with the definition of self-descriptions for providers and their services.
What are self-descriptions and why are they necessary?
Within the Gaia-X ecosystem, there are different entities interacting with each other, such as Cloud users and providers. In this context, different requirements and service specifications come together. The consumer, on the one side, has specific requirements on a service (e. g. he's searching for a sustainable Infrastructure-as-a-Service solution being hosted in Germany). The provider, on the other side, offers a service with specific configurations (e. g. he provides a green IaaS solution based in Frankfurt/Main).
In order to verify whether the requested service and the offered requirements fit together, the parties should be able to check immediately whether the service provided fulfills all requirements with valid proof statements.
For a better understanding, the example given, is of course just an easy one. The fit between the user and provider can be seen through quiet easily (sustainable = green, based in Germany = Frankfurt/Main, Infrastructure as a Service = IaaS), but a machine-based algorithm might have its trouble merging detailed requirements and comprehensive offerings.
As Gaia-X networks different parties into one common ecosystem, any cloud provider can become a Gaia-X participant. Therefore, a common controllable vocabulary is necessary which describes the entities in the Gaia-X universe and makes digital infrastructures more transparent for the user. With Self-Descriptions, Gaia-X provides this vocabulary by defining a hierarchy of classes (= items to be described), such as IaaS Offerings and a set of attributes for each class to describe its properties, such as locality, computing and storage capacity.
Who's providing the self-descriptions?
Providers are responsible for the creation of their own Self-Descriptions as well as for their resources maintained by and services offered by them. These self-descriptions are published in a temper-evident manner within a federated catalogue, in which providers and their service offerings can be easily found and selected, or shared with third-parties directly.
Trust in Self-Descriptions
Trust is an important pillar of the Gaia-X eco-systems and self-descriptions play a significant role in this context. With self-descriptions, providers publish properties and capability of their services transparently, and consumers are able to decide in a self-sovereign manner which service to use and where to store and process their data. In order to support that vision, any claim of a self-description must be temper-evident and its authorship must be verifiable.
Therefore, the format of Gaia-X Self-Descriptions follows the W3C standard of Verifiable Presentation and Verifiable Credentials. Formally, a self-description is a Verifiable Presentation consisting of a set of Verifiable Credentials. A Verifiable Credential contains a set of Claims about credential subject made by the same issuer. To make the Verifiable Credential tamper-evident, at least one cryptographic proof has to be added to verify the issuer (= author) of this Verifiable Credential.
Self-Description of Cloud&Heat
To date, the number of available self-descriptions is still low. In this context, we at Cloud&Heat Technologies are one of the pioneers when it come to developing and providing our own self-descriptions. In order to provide a better understanding of how a self-description could look like, we want to share one using the example of Cloud&Heat.
The example consists of one Verifiable Credential issued by Cloud&Heat. It claims the registration number as well as the legal address of Cloud&Heat. Issuer as well as credential subjects are referred by Decentralised Identifiers (DID). Both Verifiable Credentials as well as the overall self-descriptions as Verifiable Presentation is self-signed by Cloud&Heat making authorship verifiable.
SD of Cloud&Heat
{
"@context": [
}, "http://www.w3.org/ns/shacl#",
"http://www.w3.org/2001/XMLSchema#",
"http://w3id.org/gaia-x/participant#",
"@nest"
],
"@id": "https://www.cloudandheat.com/participant_vp.json",
"@type": [
"VerifiablePresentation"
],
"issuer": "did:cloudandheat.com",
"issuanceDate": "2022-06-28T00:00:00Z",
"verifiableCredential": [
{
}, "@id": [ "https://www.cloudandheat.com/participant_vc.json" ],
"type": [
"VerifiableCredential"
],
"issuer": "did:cloudandheat.com",
"issuanceDate": "2022-06-28T00:00:00Z",
"credentialSubject": [
{
"@id": "did:cloudandheat.com",
{ "type": "participant",
"gx-participant:name": {
"@value": "Cloud&Heat",
"@type": "xsd:string"
},
"gx-participant:legalName": {
"@value": "Cloud&Heat Technologies GmbH",
"@type: xsd:string
},
"gx-participant:registrationNumber": {
"@value": "DEU1104.HRB30549",
"@type: xsd:string
},
"gx-participant:headquarterAddress": {
"@type": "gx-participant:Address",
"gx-participant:country": {
"@value": "DEU",
"@type: xsd:string
},
"gx-participant:street-address": {
"@value": "Königsbrücker Str. 96",
"@type": "xsd:string"
},
"gx-participant:postal-code": {
"@value": "01099",
"@type": "xsd:string"
},
"gx-participant:locality": {
"}, "@value": "Dresden
"@type": "xsd:string"
}
},
"gx-participant:legalAddress": {
"@type": "gx-participant:Address",
"gx-participant:country": {
"@value": "DEU",
"@type: xsd:string
},
"gx-participant:street-address": {
"@value": "Königsbrücker Str. 96",
"@type": "xsd:string"
},
"gx-participant:postal-code": {
"@value": "01099",
"@type": "xsd:string"
},
"gx-participant:locality": {
"}, "@value": "Dresden
"@type": "xsd:string"
}
}
}
],
}, "proof": {
"type": "JsonWebKey2020",
"created": "2022-06-28T00:00:00Z",
"proofPurpose": "assertionMethod",
"verificationMethod": "did:cloudandheat.com",
"jws": "eyJhbGciOiJQUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..7UrouiF0yDJcu_9KrEEDcSF6-.IXYxLWa8VtffNglvf902gKxR3mwpdv9yN0GHLgbNfhCvwwtc_b6YuLaktnDwpcjqG0cBkskX5J03y8fI1bpt5rljlic6l8nxda2KTd2Zhtd_S1AohLTpQ5rMF1rc1_vHfyqZy29psnBFOQOuv27YYDLH_L0V2H6_zAyBwFtKz7rz0w7ECqUwzHOk5F4U4TGKf8ZwKd_mXOEESi60mxm-.4lxH35QPYFxmciTaCCfcoZiMDQi6V-OTVauGdyFwryhgMFsx3pxbyhUFDiZWXut2zyOTHgQygkFUM9CpKIzbQ-3jlvIbUWu2ReJdud62Q"
}
}
],
}, "proof": {
"type": "JsonWebKey2020",
"created": "2022-06-28T00:00:00Z",
"proofPurpose": "assertionMethod",
"verificationMethod": "did:cloudandheat.com",
"jws": "eyJhbGciOiJQUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..J_51DRDXNP_vIT5GTSBmJRNv_ZAGmxeYLfP5HPPiLh7XXl3E2Cr6ANUUNqIz2fQ-Nj0iGHk9z7bk0BzO1OuTnFMFSb7tcGe8tJkQYtpLPldyOuXZ4DhEzcR2AB_Lsd1hLzxKfGh1jcDOYkz3p2_g_YzHookVt07gLR44Qya_hWkd12qAIbPsFseOv4uZ-.xaBxT7QOQV9k18D5lNPANpZrRaITCm78ZGgqu_vcpLEDcOXyhTmGK2O3E5b5Sbiwt8Dk8224e0r0p6o5Hm9kn7fyGipdmXXaKNooTMfczqSsMxvcQTQY6WS8GZUH4X4sXqIfod-vbF5xxtt4JriN_993A"
}
}
Self-descriptions are protected by cryptographic signatures. That makes them immutable meaning they can't be changed once they have been published. If the participant who created its self-description wants to make an edit, he must re-sign it after each change and release it as a new version.
