5. Operating Models¶

This section describes the link between the documented policy rules to which participants of an Ecosystem agree (for Gaia-X defined in the Policy Rules Compliance Document, Domains or Ecosystems may extend with own policy rules) and the implementation through the software components and processes defined in the technical architecture, described in this document, and associated specifications.

Gaia-X in its unique endeavour must have an operating model enabling a widespread adoption by small and medium-sized enterprises up to large organisations, including those in highly regulated markets, to be sustainable and scalable.

To achieve the objectives above, a non-exhaustive list of Critical Success Factors (CSFs) includes these points:

1. The operating model must provide clear and unambiguous added value to all Participants
2. The operating model must have a transparent governance and trust model with identified accountability and liability, that is clearly and fully explained to all Participants
3. The operating model must be easy to use by all Participants
4. The operating model must be financially sustainable for the Gaia-X Ecosystem
5. The operating model must be environmentally sustainable.

5.1 Context¶

Gaia-X provides a mechanism to translate Policy Rules as defined in regulatory, standards or commercial documents into criterial which can be digitally validated by a set of “Trust Anchors” which each ecosystem can define. This chapter describes the components an processed that operationalize this process.

5.1.1 Prerequisites¶

To achieve the above goals, it is recommended for the readers to be familiar with the two documents below:

• ISO/IEC 17000:2020 Conformity assessment definitions prepared by the ISO Committee on Conformity Assessment CASCO
• Verifiable Credentials Data Model definitions from the World Wide Web Consortium (W3C)

The two mentioned documents address different types of readers, and the following sections will establish links between the various terms used in those documents.

5.1.1.1 CASCO workflows¶

There is an overarching conformity system including one or more conformity schemes.

flowchart

    SystemOwner(System Owner)

    subgraph CASystem [Conformity Assessment System]
        direction TB
        SchemeOwner(Schema Owner)
        CAScheme(Conformity Assessment Scheme)
        SchemeOwner -- develops and maintains --> CAScheme
    end

    SystemOwner -- develops and maintains --> CASystem

5.1.2 Scheme model¶

flowchart

    CAScheme(Conformity Assessment Schemes)
    criteria(Specified Requirements)
    AB(Accreditation Bodies)
    CAA(Conformity Assessment Activities)
    CAB(Conformity Assessment Bodies)
    object(Objects of Conformity Assessment)
    SchemeOwner(Schema Owners)

    CAA -- demonstrate fulfilment of --> criteria
    criteria -- need or expectation applying to --> object
    CAB -- perform --> CAA
    AB -- issue accreditations to --> CAB
    CAScheme -- identify --> criteria
    CAScheme -- provide the methodology to perform --> CAA
    SchemeOwner -. award authority to .->  AB
    SchemeOwner -- develop and maintain --> CAScheme

5.1.2.1 Roles and mapping between CASCO and Verifiable Credential Data Model¶

The ISO/IEC 17000:2020 Conformity assessment and Verifiable Credentials Data Model documents mentioned above have different but overlapping scopes. To ease the analysis, two roles must be distinguished:

1. the body or party making a claim or attestation about an object.
2. the body or party cryptographically signing a claim or attestation.

While it is commonly expected that those two roles would be endorsed by the same identifiable legal or natural participant, it’s not always the case, especially when the CAB is not capable of performing digital signatures or when the credentialSubject contains several <subject> <predicate> <object> triples as defined in Resource Description Framework (RDF).

5.1.2.2 Gaia-X Credentials and Attestations¶

As seen in the previous section, an object can be described by bodies or parties having different relations with the object itself.

Gaia-X Self-Descriptions is a legacy term still used in different Gaia-X documents and refers to a self-signed set of claims.
This is equivalent to a Verifiable Credential where the holder is the issuer. In general, the term “Gaia-X Self Description” is replaced by “Gaia-X Credential”

This simple approach is not enough and below there is a mapping between a newer vocabulary used in the Gaia-X documents and ISO/IEC 17000:2020 definitions prepared by the ISO Committee on Conformity Assessment CASCO.

To be noted that all the terms above can be generically referred as attestation and all attestations are issued by conformity assessment body (CAB), including declarations.

5.1.2.3 Gaia-X Compliance schemes¶

The Gaia-X Conformity and Gaia-X Labels are implementations of the Gaia-X governance.

To operationalise them, a software implementation must be executed and turned into up-and-running services, providing traceable evidence of correct executions.

While the governance of the Gaia-X Compliance rules and process is and will stay under the control of the Gaia-X Association, the Gaia-X Compliance Service will go through several mutually non-exclusive deployment scenarios¹.

During the pilot phase, the current, non-final deployment is described below.

5.1.3 Extension by the ecosystems¶

An ecosystem can extend the definition of the Gaia-X Trust Anchors, Gaia-X Trusted Data Sources and Gaia-X Notaries as follows:

• the ecosystem governance can add more requirements on the eligibility of the Gaia-X Trust Anchors, hence selecting a subset of the Gaia-X Trust Anchors for the ecosystem domain.
• an ecosystem governance can add additional rules on top of the ones in this document by:
  • adding more criteria for a credential type. Example: adding requirements for a participant to join the federation, enforcing a deeper level of transparency for a Service Offering
  • selecting new domain-specific Trust Anchors for the new criteria.

! warning!: For already defined criteria, it will break Gaia-X Compliance to extend the list of Gaia-X Trust Anchors eligible to sign the criteria.

5.1.3.1 Compliance remediation¶

Gaia-X Compliance credentials may become invalid over time. There are three states declaring such a credential as invalid:

• Expired (after a timeout date, e.g., the expiry of a cryptographic signature)
• Deprecated (replaced by a newer Gaia-X Credential)
• Revoked (by the original issuer or a trusted party, e.g., because it contained incorrect or fraudulent information)

Expired and Deprecated states can be deduced automatically based on the information already stored in the Gaia-X Registry or Gaia-X Catalogues. There are no additional processes to define. This section describes how Gaia-X Credentials are revoked.

The importance of Gaia-X Compliance will grow over time, covering more and more Gaia-X principles such as interoperability, portability, and security. However, automation alone is not enough, and the operating model must include a mechanism to demotivate malicious actors to corrupt the Gaia-X Registry and Gaia-X Catalogues.

The revocation of Gaia-X credentials can be done in various ways:

• Revocation or Deprecation by authorship: The author of a Gaia-X credential revokes or deprecates the credential explicitly.
• Revocation by automation: The Gaia-X Compliance Service found at least one credential claim not validating the Gaia-X conformity rules.
• Suspension and Revocation by manual decision: After an audit by a compliant Gaia-X Participant, if at least one credential claim is found to be incorrect, the suspension of the Gaia-X credential is automatic. The revocation is submitted for approval to the Gaia-X Association with the opportunity for the credential issuer to state its views in a matter of days. To minimize subjective decisions and promote transparency, the voting results will be visible and stored on the Gaia-X Registry or in the local Ecosystem’s Registry.

5.1.4 Gaia-X Compliance Schema and Process¶

The following graph describes the generic compliance schema which is applied to Gaia-X conformance, labels and can be used for domain and ecosystem specific extensions:

The different types of Conformity Assessment Bodies are specified in the PRCD document.

5.2 Gaia-X Decentralized Autonomous Ecosystem¶

The operating model described in this chapter motivates the creation of a Gaia-X decentralized autonomous Ecosystem following the principles of a Decentralized Autonomous Organisation², with the following characteristics:

• Compliance is achieved through a set of automatically enforceable rules whose goal is to incentivize its community members to achieve a shared common mission.
• Maximizing the decentralization at all levels to reduce lock-in and lock-out effects.
• Minimizing the governance and central leadership to minimize liability exposure and regulatory capture.
• The ecosystem has its own rules, including management of its own funds.
• The ecosystem is operated by the ecosystem’s Participants

Other ecosystems are autonomous and this operating model does not enforce how internal ecosystem governance should be handled.

5.3 Data Usage operating model¶

The generic basic operating model for data usage of un-licensed data is quite simple:

Figure 5.1 - Data usage operating model – case 1

1. The Data Consumer queries the Data Product Catalogue and reviews the Data Product Descriptions to select a Data Product that corresponds to its needs.
2. The Data Consumer configures the Data Product in terms of data scope and operational characteristics and starts negotiating with the Data Product Provider.
3. When both find an agreement, they sign a configured Data Product Description to create the Data Product Usage Contract (DPUC) and can optionally notarize it in a Federated Data Product Usage Contract Store.
4. Then the instantiated Data Product can be activated resulting in actual Data Usage.

The operating model is a bit more complex when the Data Product includes licensed data. For instance, if the Data Product includes some personal data, then the GDPR imposes that the data subjects explicitly give their consent for the data usage and that they can revoke this consent at any time. Accordingly, a Data Usage Agreement has to be signed by the data subject, who acts as a Data Licensor, before the first data usage and the Data Usage Agreement validity has to be checked before each data usage. It is recommended to establish and sign the Data Usage Agreement during the negotiation phase between the Data Product Provider and the Data Consumer because, without this signed Data Usage Agreement, the agreement between the parties (i.e., the Data Product Usage Contract) would be legally void. Note that the Data Usage Agreement may be signed by a guardian (for minor persons) or a third party through a specific or generic power of attorney or specific legislation (for instance in the case of a sick person in a hospital). The process is similar for a Data Product for which the Data Owner did not give an unconditional usage right to the Data Product Provider and wants to precisely know who will use her/his data and for which purpose.

If the Data Consumer has access to the Data Licensor, then it can directly request the Data Usage Agreement – this is usually the case when the Data Consumer is using the data to provide a service to the Data Licensor (for instance when a sports training app get historical monitoring data from a sports watch provider). This is the most convenient and simple case, and it provides better privacy (the Data Product Provider does not know what the data will be used for). Otherwise, the Data Usage Agreement has to be collected by the Data Product Provider through the Data Producer.

In the first sub-case, the operating model is:

Figure 5.2 - Data usage operating model – case 2a

1. The Data Consumer queries the Data Product Catalogue and reviews the Data Product Descriptions to select a Data Product that corresponds to its needs.
2. The Data Consumer configures the Data Product in terms of data scope and of operational characteristics and starts the negotiation with the Data Product Provider.
3. The Data Consumer extracts the Data Usage Agreement template from the Data Product Description, fills it and adds its specific information (how the data will be used, the purpose, …), usually in a separate section that might not be communicated to the Data Product Provider. This Data Usage Agreement is sent to the Data Licensor who will sign it through a Data Usage Agreement Trust Anchor and send it back to the Data Consumer.
4. The Data Product Provider and the Data Consumer close the negotiation, and they sign the configured Data Product Description to create the Data Product Usage Contract (DPUC) which includes the appropriate part of the Data Usage Agreement. They can notarize this Data Product Usage Contract in a Federated DPUC Store.
5. Then the instantiated Data Product can be activated, and actual Data Usage can start. Before each Data usage, the Data Product Provider has to check the validity of the Data Usage Agreement through the Data Usage Agreement Trust Anchor.

The operating model for the second sub-case is the same except for step 3, where the Data Usage Agreement is requested by the Data Product Provider through the Data Producer. Note that the Data Consumer will have to provide the purpose of the Data usage, and this will be included in the Data Usage Agreement sent to the Data Licensor – this is part of the service configuration phase. Note also that the Data Producer might to counter-sign the Data Usage Agreement to guarantee that the person who signed the Agreement is really the Data Licensor of the data.

Figure 5.3 - Data usage operating model – case 2b

Note: The above operating model minimizes the functionalities of the Data Usage Agreement Trust Anchor. It is possible to imagine a slightly more complex Data Usage Agreement Trust Anchor that receives part of the Agreement from the various parties and communicates only the relevant parts to the appropriate actors. Hence in case 2b, the Data Product Provider will not know the purpose of the Data Consumer but only that the Data Licensor authorizes the data usage, while the Data Licensor will have access to the Data Consumer Purpose. We might also imagine a more complex Data Usage Agreement Trust Anchor able to compare predefined Usage Clauses and to advise the Data Licensor or even automatically grant agreement on behalf of the Data Licensor. For instance, the Data Licensor might specify that she/he allows transmission of some medical data to non-profit research laboratories which have appropriate certificates in terms of data security and data privacy – the Data Usage Agreement Trust Anchor would directly provide the general Data Usage Agreement and the Data Licensor would just receive a notification (and will always be able to revoke the agreement) - that could enable a more agile data economy. Data Intermediary services provided by some Gaia-X Lighthouse projects provide such elaborated functionality.

5.3.1 Data Intermediary generic operating model¶

Several Lighthouse projects implement the concept of Data Intermediary. Compared to the general Gaia-X Conceptual Model, a Data Intermediary is an actor who plays several roles: Data Product Provider acting as a proxy between the Data Producer and the Data Consumer, Provider operating a Data Product Catalogue (often named data marketplace), Data Usage Agreement Trust Anchor acting as a trusted proxy between the Licensor and the Data Consumer.

The generic operating model for the Data Intermediary role is as follows:

Figure 5.4 - Data Intermediary generic operating model

Many variants of this generic model can be defined. For instance, a general Data Usage Agreement may be proposed to the Data Licensor upfront when the Data Product is inserted in the Catalogue and the Licensor can trust the Data Intermediary to check the conditions and purpose before delivering data usage to a consumer.

Hence, the above model is given as a generic example. The ecosystems are free to define and implement the operating model adapted to their specificities.

5.4 Service Composition¶

To pursue the description of the service composition model, we focus on the steps required to implement service composition and describe the functions required to achieve end-to-end service composition across multiple service providers. Figure 5.5 depicts these steps and starts with a service request from the user (end user, tenant, information system manager) request.

Figure 5.5. Gaia-X Compliant Service Composition Steps

The user first describes the desired service using a domain-specific description language, generally JSON and YAML-based. This request is then parsed for specific end-user requirements extraction and added (concatenated) to a generic and high-level catalogue that contains service descriptions as part of a Catalogue and holds only functional descriptions of services and applications relevant to the user request, to ensure interoperability, compatibility, and portability requirements. These services are not localized a priori; location is to be set at a later stage in the service composition process. The same holds for some additional service attribute values, in some parts of the service description. These values are empty fields or wild cards that will only take on specific values once the user service request has been parsed for preferences, constraints and specific limitations (such as provider type, restrictions on localization and geographical area, unconstrained naming and addressing spaces and more). Some attribute values are only set (or resolved) and known at later stages of the service composition (as late as steps 4 and 5).

The user-expressed constraints, in step 1, are added to the functional description in step 2 to produce the actual service request that will be used to derive in a third step an extended representation of the service request. This extended representation, usually in the form of a tree (or complex service graph) representation and description of the extended service, now contains required services and resources as well as generic hosting nodes (not yet fully specified) needed to fulfil the service request. All properties and requirements from the initial service request therefore propagate to these tree nodes and leaves. This tree contains the relationships and dependencies of all services involved in building a solution to the initial user request and has as mentioned inherited all the service properties, constraints, restrictions, and obligations stated by the user in step 1. The fourth step is service discovery which will search in multiple catalogues.

The output of the fourth step produces, with the help of orchestrators and service composition, workflows and deployment plan production engines (external or even taken from the Gaia-X service offerings) to deploy the service instances and ensure their interconnection. The result is the production of a composite service graph that fulfils the initial end user request and its concrete instantiation in multiple hosting infrastructures and providers. In Figure 5.5, the service life cycle manager handles the service management at run time by interacting with the involved providers. This manager makes recommendations about possible adaptations, substitutions and adjustments of services depending on operational conditions to maintain SLAs according to established contracts between all stakeholders and processes. These contracts are considered during stages 1 to 5 of the service composition process depicted in Figure 5.5. These steps, not shown at this stage, will receive special attention in a future dedicated document.

Annex E provides a practical “service composition model example” involving multiple cloud providers, services and infrastructures that can be accomplished using currently available cloud services.