6. Service & Subclasses

Here is the main model for service composition, also included in the Gaia-X Architecture document.

A Service Offering can be associated with other Service Offerings.

classDiagram
    ServiceOffering o-- Resource: aggregationOf
    Resource o-- Resource: aggregationOf

class Resource{
    <<abstract>>
}

    Resource <|-- "subClassOf" PhysicalResource: 
    Resource <|-- "subClassOf" VirtualResource
    VirtualResource "1" <-- "*" InstantiatedVirtualResource : instanceOf

    ServiceOffering "1" ..> "1" Participant : providedBy

    PhysicalResource "1" ..> "0..*" Participant : ownedBy
    PhysicalResource "1" ..> "0..*" Participant : manufacturedBy
    PhysicalResource "1" ..> "1..*" Participant : maintainedBy

    VirtualResource "1" ..> "1..*" Participant : copyrightOwnedBy

    InstantiatedVirtualResource --> "1" Resource : hostedOn

    InstantiatedVirtualResource <..> ServiceInstance : equivalent to
    InstantiatedVirtualResource "1" ..> "1..*" Participant : tenantOwnedBy
    InstantiatedVirtualResource "1" ..> "1..*" Participant : maintainedBy

6.1 Service offering

This is the generic format for all service offerings

termsAndConditions structure

dataAccountExport structure

The purpose is to enable the participant ordering the service to assess the feasibility to export its personal and non-personal data out of the service.

{
  "dataAccountExport": [
    {
      "requestType": "API",
      "accessType": "digital",
      "formatType": "application/json"
    },
    {
      "requestType": "supportCenter",
      "accessType": "physical",
      "formatType": "application/octet-stream"
    }
  ]
}

Personal Data Protection Regimes Gaia-X strives to contribute compliance with the protection of personal data, i.e., privacy. Gaia-X envisages its implementation internationally, whilst not neglecting its European sources.

Conformity with specific requirements deriving from different regimes protecting personal data, will be subject to respective Labels. Nonetheless, it is considered significant added value, to allow Customers to filter Service Offerings by applicable regimes.

Thus, Service Offerings shall be able to identify Personal Data Protection Regimes in their respective Self Description. Such identified regimes do not entail any trusted or verified statement of compliance.

Non-exclusive list of Personal Data Protection Regimes:

• GDPR2016: General Data Protection Regulation / EEA
• LGPD2019: General Personal Data Protection Law (Lei Geral de Proteção de Dados Pessoais) / BRA
• PDPA2012: Personal Data Protection Act 2012 / SGP
• CCPA2018: California Consumer Privacy Act / US-CA
• VCDPA2021: Virginia Consumer Data Protection Act / US-VA

The participant may wish to refer to ISO/IEC 27701 as a tool for comparing the various data protection regimes.

To enable interoperability, it is strongly recommended to refer to the options as provided in the Gaia-X Registry. The Gaia-X Registry will allow for the possibility to select one or several of such regimes, as well as the possibility to add additional regimes. Maintenance of the registry shall regularly assess the individually identified regimes and - where appropriate - add such regimes to the pre-defined list of Personal Data Protection Regimes.

Consistency rules

• the keys used to sign a SERVICE OFFERING description and the providedBy PARTICIPANT description should be from the same keychain.

Compliance with Criteria of Policy Rules and Labelling Document (PRLD) In cases, where there is no additional attribute defined in the Trust Framework or the PRLD, and where the PRLD refers to the Trust Framework as verification process, it shall - for the time being - suffice that the Cloud Service Provider submits a self-signed Verified Credential indicating the relevant Criterion alongside the statement of implementation by “true” or “false”.

The syntax shall be as follows:

Those criteria are signed by the Participant providing the service

As an option, the Cloud Service Provider shall have the possibility to add a string identifying any third-party standards that might be of relevance.

6.2 Service Instance / Instantiated Virtual Resource

An Instantiated Virtual Resource is an instance from a Virtual Resource.
An Instantiated Virtual resource is a running resource exposing endpoints such as, and not limited to, a running process, an online API, a network connection, a virtual machine, a container, an operating system.

Service Access Point

A service access point is an identifying label for network endpoints used in the OSI model.

The format below doesn’t represent all possible service access point types.

Difference between Virtual Resource and Instantiated Virtual Resource

In red, a VirtualResource.
In blue, an InstantiatedVirtualResource.
The InstantiatedVirtualResource exposes serviceAccessPoint configured with Access Control, used by Participant to access other Resource.

6.3 Data exchange component

A data exchange component offering, including but not limited to, a connector, a platform, a service bus, a messaging or an event streaming platform or REST APIs, must fulfil those requirements:

The data exchange component is a service to negotiate (signaling layer) and exchange dataset (media layer).

The negotiation shall be performed based on the policies from the policy attribute of the Gaia-X Self-Description of the entities - Participants, Services, Resources - involved in the data transaction.

Note: in case at least one of the Gaia-X Self-Description of the entities involved in the data transaction contains policies that can’t be understandable by an algorithm, the data exchange component can fallback to manual negotiation.

Consistency rules

• the service offering shall contain or point to a InstantiatedVirtualResource self-description with at least one serviceAccessPoint with a name “contractNegotiationEndpoint”.
• the output of the “contractNegotiationEndpoint” shall point to the result of the negotiation signed by all the Participants in direct link with the negotiation. (Note: direct link is defined by all Participants returned by a Breadth-first search algorithm, starting from the Data Resource being negotiated, with a path length of 1)

$.aggregationOf[?(@.type == "InstantiatedVirtualResource")].serviceAccessPoint[?(@.name == "contractNegotiationEndpoint")]

6.4 Verifiable Credential Wallet

A wallet enables to store, manage, present Verifiable Credentials:

6.5 Interconnection

An interconnection enables a mutual connection between two or more elements.

6.6 Catalogue

A catalogue service is a subclass of serviceOffering used to browse, search, filter services and resources.

[1]: Using the Verifiable Credential terms, it’s up to the issuer to control and decide if the credential’s id can be dereferenced and the holder to implement access control of the verifiable credentials.

6.7 Interoperability, Portability, Switchability and Intellectual Property Protection (experimental)

This section introduces important Gaia-X principles.
While the format of the attributes are not yet defined, the sections below give insights about the future requirements.

6.7.1 Interoperability

This covers how the service offering can communicate with another service, such as making or responding to requests.

The aim of the future attributes is to provide:

• a list of agreements in place with other service providers to ensure interoperability between systems
• a list of URL to interoperability capabilities and transparency documentation

See ISO/IEC 19941:2017-5.2.1 for a description of the facets that need to be addressed.

6.7.2 Data Portability

This refers to the porting of data (structured or unstructured) from one cloud service to another, public or private.

Note: Data portability will inevitably be limited to Customer Data and a subset of Derived Data as determined by contract, privacy regulations, etc. See the ServiceOffering.dataAccountExport attribute.

The aim of the future attributes is to provide:

• a list of publicly filed declarations of adherence such as SWIPO Code of Conduct

If a Gaia-X service offering includes multiple cloud services with different data portability capabilities, it is expected to have separate Self-Descriptions for each type of data portability capabilities.

Note 2: The SWIPO codes of conduct do not cover all cloud service categories (e.g. there is no specific SWIPO Code for PaaS), so it is not possible to mandate this attribute for all services.

See ISO/IEC 19941:2017-5.2.2 for a description of the facets that need to be addressed.

6.7.3 Application Portability

This refers to the porting of customer or third party executable code from one cloud service to another, public or private.

Note: Application portability is highly complex, especially when it comes to identity management, license, access control lists, privacy controls, transfer of credentials, etc.

The aim of the future attributes is to provide:

• a list of URL pointing to a declaration of adherence such as SWIPO Code of Conduct
• a list of URL pointing to a declaration of whether and how the application license can be switched to another service provider

If a Gaia-X service offering includes multiple cloud services with different data portability capabilities, it is expected to have separate Self-Descriptions for each type of data portability capabilities.

Note 2: For SWIPO Code of Conduct:

• This can apply to executable code within an IaaS virtual machine instance, or code that can be executed within a larger SaaS application (such as scripts or SQL stored procedures).
• This codes of conduct do not cover all cloud service categories (e.g. there is no specific SWIPO Code for PaaS), so it is not possible to mandate this attribute for all services.

See ISO/IEC 19941:2017-5.2.3 for a description of the facets that need to be addressed.

6.7.4 Switchability

This refers to moving a customer’s account from one service provider to another, including the change of contracts and necessary technical changes.

Service switching is highly complex. Moving a customer to another cloud application provider requires identifying a destination which is in the same broad category of cloud service offering, and where the common functionality offered by the original service and the destination meets the minimum business needs of the customer wishing to switch. Since all services evolve constantly this is a moving target, and each customer will have different criteria. In addition, there can be considerable legal issues to be addressed. This includes the “policy” facets of data and application portability as described in ISO/IEC 19941:2017, but also the unique specifics of contracts and any possible implications for security and this continued compliance with privacy and data protection regulations. Responsibility for each stage of the switching process (including security, liability, and privacy compliance) will need to be determined and agreed in advance by all parties.

The aim of the future attributes is to provide:

• a list of URL pointing to a declaration of whether and how a cloud service contract can be switched to another service provider
• a list of URL pointing to required or available policies for switching
• a list of URL pointing to a declaration of whether and how the Identity and Access Management function can be switched to another service provider

Note 1: At present there do not seem to be any established Codes of Conduct or other frameworks that cover these aspects.

6.7.5 Intellectual Property Protection

The term Intellectual property (IP) refers to unique and value-adding creations of the human mind. IP enables the granting of property-like rights over new discoveries, new knowledge and creative expressions. IP relates to but is not limited to know-how, products, processes, software, data, and artistic works. The rights resulting from various forms of IP are referred to as intellectual property rights (IPR). IPRs can provide usage rights or rights to exclude third parties from using what is protected to the owner. Trust is paramount in the willingness for partners to collaborate and share information. IPRs can ensure the confidence of the partners that their knowledge capital and investment will be respected in the frame of acknowledged context and therefore that the use of the information shared will remain in the agreed context for the agreed duration. IPRs can exist in the form of Copyright, Patents, Trademarks, Industrial Designs, Geographical Indications and Trade Secrets. (see WIPO and ISO 56005:2020(en))

The aim of the future attributes is to provide:

• a possibility to declare IP ownership and the IPR type
• usage rights, agreements and controls

See the list of WIPO Standards, Recommendations and Guidelines and the ISO 56005:2020(en) for a description of the facets that need to be addressed.