5. Federation Services

Federation Services are necessary to enable a Federation of infrastructure and data, provided through an open source reference implementation. This will open up technology wherever possible, while existing Certifications and standards for Accreditation will be recognized.

Details about the operationalization of Federation Services will be outlined in the upcoming Federation Services documents. Details about the role of Federation Services for Ecosystems are elaborated in the section Gaia-X Ecosystems, with an overview shown in the figure below.

• The Federated Catalogue constitutes an indexed repository of Gaia-X Self-Descriptions to enable the discovery and selection of Providers and their Service Offerings. The Self-Descriptions are the properties and Claims of Participants and Resources, representing key elements of transparency and trust in Gaia-X.

• Identity and Trust covers identification, authentication and authorization, credential management, decentralized Identity management as well as the verification of analogue credentials.

• Data Sovereignty Services enable the sovereign data exchange of Participants by providing a Data Agreement Service and a Data Logging Service to enable the enforcement of Policies. Furthermore, usage constraints for data exchange can be expressed by Provider Policies within the Self-Descriptions.

• Compliance includes mechanisms to ensure that Participants adhere to the Policy Rules in areas such as security, privacy, transparency and interoperability during onboarding and service delivery.

• Gaia-X Portals and APIs will support onboarding and Accreditation of Participants, demonstrate service discovery, orchestration and provisioning of sample services.

Gaia-X Federation Services and Portal as covered in the Architecture Document

5.1 Federated Catalogue

Self-Descriptions intended for public usage can be published in a Catalogue. There, they can be found by potential Consumers. Further, they form the starting point for building specific decentralized Catalogues. The goal of Catalogues is to enable Consumers to find best-matching offerings and to monitor for relevant changes of the offerings. The Providers decide in a self-sovereign manner which information they want to make public in a Catalogue and which information they only want to share privately.

A Provider registers Self-Descriptions with their universally resolvable Identifiers in the desired Catalogue to make them public. The Catalogue’s Self-Description Storage caches copies of the raw content of any such individual Self-Description. The content is an RDF graph serialized in JSON-LD, which includes Claim statements as specified below. All individual Self-Descriptions are aggregated into one overall Self-Description Graph. This is because individual Self-Descriptions can reference each other. The Self-Description Graph is the basis for advanced query mechanisms that consider the references between and among Self-Descriptions.

The system of Federated Catalogues includes an initial stateless Self-Description browser provided by the Gaia-X, European Association for Data and Cloud, AISBL. In addition, Ecosystem-specific Catalogues (e.g., for the healthcare domain) and even company-internal Catalogues (with private Self-Descriptions to be used only internally) can be linked to the system of federated Catalogues. The Catalogue federation is used to exchange relevant Self-Descriptions and updates thereof. It is not used to execute queries in a distributed fashion.

Cross-referencing is enabled by unique Identifiers as described in Identity and Trust. While uniqueness means that Identifiers do not refer to more than one entity, there can be several Identifiers referring to the same entity. A Catalogue should not use multiple Identifiers for the same entity.

In addition to Self-Descriptions, a Federated Catalogue also manages Self-Description Schemas. A Federated Catalogue should only accept the submission of Self-Descriptions that validate against a Schema known to the Catalogue, as specified below. Gaia-X develops an extensible hierarchy of Schemas that define the terms used in Self-Descriptions. Some Schemas are standardized by the Gaia-X AISBL and must be supported by any Catalogue. It is possible to create additional Schemas specific to an application domain, an Ecosystem, Participants in it, or Resources offered by these Participants. Schemas have the same format as Self-Descriptions, i.e., they are graphs in the RDF data model, serialized as JSON-LD. A Schema may define terms (classes, their attributes, and their relationships to other classes) in an ontology. If it does, it must also define shapes to validate instances of the Ontology against.

The system of Federated Catalogues comprises of top-level decentralized Catalogues as well as Ecosystem-specific Catalogues (e.g., for the healthcare domain) and even company-internal Catalogues with private Self-Descriptions to be used only internally. Self-Descriptions in a Catalogue are either loaded directly into a Catalogue or exchanged from another Catalogue through inter-Catalogue synchronization functions.

Since Self-Descriptions are protected by cryptographic signatures, they are immutable and cannot be changed once published. This implies that after any changes to a Self-Description, the Participant as the Self-Description issuer has to sign the Self-Description again and release it as a new version. The lifecycle state of a Self-Description is described in additional metadata. There are four possible states for the Self-Description lifecycle. The default state is “Active”. The other states are terminal, i.e., no further state transitions are allowed. All states are listed below:

• Active

• End-of-Life (after a timeout date, e.g., the expiry of a cryptographic signature)

• Deprecated (by a newer Self-Description)

• Revoked (by the original issuer or a trusted party, e.g., because it contained wrong or fraudulent information)

The Catalogues provide access to the raw Self-Descriptions that are currently loaded including the lifecycle metadata. This allows Consumers to verify the Self-Descriptions and the cryptographic proofs contained in them in a self-service manner.

The Self-Description Graph contains the information imported from the Self-Descriptions that are known to a Catalogue and in an “active” lifecycle state, as well as the Schemas used by these Self-Descriptions. The Self-Description Graph allows for complex queries across Self-Descriptions.

To present search results objectively and without discrimination, compliant Catalogues use a query engine with no internal ranking of results. Users can define filters and sort-criteria in their queries. But if some results have no unique ordering according to the defined sort-criteria, they are randomized. The random seed for the search result ordering is set on a per-session basis so that the query results are repeatable within a session with a Catalogue.

Self-Descriptions intended for public usage can be published in a Catalogue where they can be found by potential Consumers. The goal of Catalogues is to enable Consumers to find best-matching offerings and to monitor for relevant changes of the offerings. The Providers decide in a self-sovereign manner which Self-Descriptions they want to share with a public Catalogue and which ones they only want to share privately. Options for private sharing include private Catalogues as well as channels external to Gaia-X, such as encrypted email.

A Visitor is an anonymous user accessing a Catalogue without a known account. Every Non-Visitor user (see Principal in section 3.2) interacts with a Catalogue REST API in the context of a session. Another option to interact with a Catalogue is to use a GUI frontend (e.g., a Gaia-X Portal or a custom GUI implementation) that uses a Catalogue REST API in the background. The interaction between a Catalogue and its GUI frontend is based on an authenticated session for the individual user of the GUI frontend.

5.1.1 Self-Description

Gaia-X Self-Descriptions express characteristics of Resource templates, Resources, Service Offerings and Participants and are tied to their respective Identifier. Providers are responsible for the creation of their Self-Descriptions. In addition to self-declared Claims made by Participants about themselves or about the Service Offering provided by them, a Self-Description may comprise Credentials issued and signed by trusted parties. Such Credentials include Claims about the Provider or Resources, which have been asserted by the issuer.

Self-Descriptions in combination with trustworthy verification mechanisms empower Participants in their decision-making processes. Specifically, Self-Descriptions can be used for:

• Discovery and composition of Service Offerings in a Catalogue

• Tool-assisted evaluation, selection, integration and orchestration of Service Instances and Resources

• Enforcement, continuous validation and trust monitoring together with Usage Policies

• Negotiation of contractual terms concerning Resources of a Service Offering and Participants

Gaia-X Self-Descriptions are characterized by the following properties:

• Machine-readable and machine-interpretable

• Technology-agnostic

• Adhering to a Schema with an expressive semantics (ontology) and validation rules (shapes)

• Interoperable, following standards in terms of format, structure, and included expressions (semantics)

• Flexible, extensible and future-proof in that new properties can be easily added

• Navigable and referenceable from anywhere in a unique, decentralized fashion

• Accompanied by statements of proof (e.g., certificates and signatures), making them trustworthy by providing cryptographically secure verifiable information

The exchange format for Self-Descriptions is JSON-LD. JSON-LD uses JSON encoding to represent subject-predicate-object triples according to the W3C Resource Description Framework (RDF).

A Self-Description contains the Identifier of the Asset, Resource or Participant, metadata and one or more Credentials as shown in the figure below. A Credential contains one or more Claims, comprised of subjects, properties and values. The metadata of each Credential includes issuing timestamps, expiry dates, issuer references and so forth. Each Credential can have a cryptographic signature, wherein trusted parties confirm the contained Claims. Claims may follow the same subject-predicate-object structure of the data model. The W3C Verifiable Credentials Data Model¹ is the technical standard to express Credentials and Claims using JSON-LD². When there exist multiple Credentials for the thing that is being self-described, e.g., Credentials issued and signed by Providers themselves, plus other Credentials such as Certifications provided by independent external bodies, they may be bundled into a Verifiable Presentation. This most general case of a Self-Description is presented in the figure below.

Self-Description assembly model

The generic data model for Claims is powerful and can be used to express a large variety of statements. Individual Claims can be merged to express a graph of information about Resources (subjects). For example, a Node complying with ISO 27001 is shown in the figure below.

Linked Claim statements as a graph representation

The Self-Description of one entity may refer to another entity by its Identifier. Identifiers in Gaia-X are URIs and follow the specification of RFC 3986. While uniqueness means that Identifiers do not refer to more than one entity, there can be several Identifiers referring to the same entity. A Catalogue should not use multiple Identifiers for the same entity. Depending on the prefix of the URI, different technical systems are defined to ensure uniqueness of Identifiers. For example, the use of a domain-name as part of the Identifier, where only the owner of the domain-name shall create Identifiers for it.

The relations between Self-Descriptions form a graph with typed edges, which is called the Self-Description Graph. The Catalogues implement a query algorithm on top of the Self-Description Graph. Furthermore, Certification aspects and Usage Policies can be expressed and checked based on the Self-Description Graph that cannot be gained from individual Self-Descriptions. For example, a Consumer could use Catalogue Services to require that a Service Instance cannot depend on other Service Instances that are deployed on Nodes outside a Consumer-specified list of acceptable countries.

To foster interoperability, Self-Description Schemas are defined. They introduce classes, i.e., sets of instances of the same type, which may form an extensible hierarchy. For each class, properties are defined that an instance of the class can have. These include attributes, having immediate literal values of some datatype (called “datatype properties” in the W3C Web Ontology Language OWL³), values that are instances of auxiliary classes (e.g., a class that groups all information related to the deployment of a Service as a distinct node in the graph), or reusable values that are instances of concepts from controlled vocabularies (the latter two being called “object properties” in OWL). Properties also include relationships, having values that are instances of some other class in the Gaia-X Conceptual model (e.g., the relationship between an Asset and its Provider, also OWL object properties). Self-Description Schemas should include shapes⁴, i.e., sets of conditions used to validate whether a Self-Description has instantiated classes and properties according to their definition. In particular, shapes should specify which properties are mandatory to be used by every instance of a given class, and which ones are optional. A Self-Description has to state which schemas are used in its metadata. Only properties and relations defined in these schemas must be used.

The Gaia-X Federation Services specification describes how core Self-Description schemas based on the Conceptual Model are created and maintained. Individual Gaia-X Ecosystems can extend the schema hierarchy for their application domain.⁵ Such extensions must make an explicit reference to the organization that is responsible for the development and maintenance of the extension.

Schematic inheritance relations and properties for the top-level Self-Description

The Self-Description Schemas can follow the Linked Data best practices⁶ which makes the W3C Semantic Web family⁷ a possible standard to be built upon to enable broad adoption and tooling.

Gaia-X aims at building upon existing schemas, preferably those that have been standardized or at least widely adopted⁸ to get a common understanding of the meaning and purpose of any property and Claim statements. Examples of attribute categories per Self-Description in Gaia-X are discussed in the Appendix A1,

.

For frequently used attribute values, it is recommended that they be maintained in the same governed process as Self-Description Schemas, i.e., by giving them unambiguous identifiers maintained in Controlled Vocabularies. Examples include standards against which a Participant or an Asset has been certified, or classification schemes, e.g., for the sector in which a Provider is doing their business.⁹ It is recommended to reuse Controlled Vocabularies where they already exist, e.g., ECLASS to identify products and services. The W3C SKOS Simple Knowledge Organization System provides a way of managing Controlled Vocabularies in a way that is compatible with the RDF data model and thus with Self-Description Schemas.¹⁰

5.2 Identity and Trust

Identities, which are used to gain access to the Ecosystem, rely on unique Identifiers and a list of dependent attributes. Gaia-X uses existing Identities and does not maintain them directly. Uniqueness is ensured by a specific Identifier format relying on properties of existing protocols. The Identifiers are comparable in the raw form and should not contain more information than necessary (including Personal Identifiable Information). Trust - confidence in the Identity and capabilities of Participants or Resources - is established by cryptographically verifying Identities using the Federated Trust Model of Gaia-X, which is a component that guarantees proof of identity of the involved Participants to make sure that Gaia-X Participants are who they claim to be. In the context of Identity and Trust, the digital representation of a natural person, acting on behalf of a Participant, is referred to as a Principal. As Participants need to trust other Participants and Service Offerings provided, it is important that the Gaia-X Federated Trust Model provides transparency for everyone. Therefore, proper lifecycle management is required, covering Identity onboarding, maintaining, and offboarding. The table below shows the Participant Lifecycle Process.

Participant Lifecycle Process

An Identity is composed of a unique Identifier and an attribute or set of attributes that uniquely describe an entity within a given context. The lifetime of an Identifier is permanent. It may be used as a reference to an entity well beyond the lifetime of the entity it identifies or of any naming authority involved in the assignment of its name. Reuse of an Identifier for a different entity is forbidden. Attributes will be derived from existing identities as shown in the IAM Framework Document v1.2¹¹.

A ‘Secure Digital Identity’ is a unique Identity with additional data for robustly trustworthy authentication of the entity (i.e. with appropriate measures to prevent impersonation) This implies that Gaia-X Participants can self-issue Identifiers for such Identities. It is solely the responsibility of a Participant to determine the conditions under which the Identifier will be issued. Identifiers shall be derived from the native identifiers of an Identity System without any separate attribute needed. The Identifier shall provide a clear reference to the Identity System technology used. Additionally, the process of identifying an Identity Holder is transparent. It must also be possible to revoke issued Identity attributes¹².

5.2.1 Trust Framework

A Trust Framework is required for the Gaia-X Participants to create mutual trust between and among peers and foster Service Offerings to be provided and consumed.

This Trust framework is not enforced by the Gaia-X Association, however, only Gaia-X Participants following the policies, technical specifications, and interoperability criteria set up by the Gaia-X Association could have their Service Offerings awarded with Gaia-X Labels.

Gaia-X Association focuses on defining the policies which consider EU regulations and open technical means to provide a transparent model supporting privacy and self-determination of all Ecosystems. The chain of trust, without the need for a global and traceable unique ID across Gaia-X is needed.

Once the Trust Framework model is in place, the Gaia-X Participants can vote and elect their own trust anchors following the rules put in place by the Association. For example, the Gaia-X Ecosystem’s Participants could agree to use the EU list of eIDAS Trusted Lists¹³ as one of the trust anchors for service providers and Conformity Assessment Bodies.

This model allows specific Gaia-X Ecosystems to set up their own trust anchors and Federators as long as those are following the rules defined by the Gaia-X Association. Inter-ecosystem interoperability is achieved by leveraging common GAIA-X technology while having members join each specific Federation under its own rules. In such a model, interoperability across Ecosystems requires Participants to simultaneously be members of several Gaia-X-compatible Ecosystems / Federations.

Self-Descriptions (see section Federated Catalogue) play another crucial part in establishing Trust within Gaia-X. In addition to non-trust-related information, which can be updated by the Participant, they contain trust-related information on the Participant level, which in turn connects to the organization’s Identity System on the Principal level. The trust-related part is vetted according to Gaia-X Policy and electronically signed by a CAB. Possible further changes regarding the trust related information leads to a re-verification. The Gaia-X Association in turn provides a Gaia-X Registry, which lists its policies, schemas and commonly accepted trust providers’s Identities as mentioned before.

Service Offerings may have different levels of Trust. During service composition, it is determined by the lowest trust state of the Service Offering upon which it relies. The trust state of a Service Offering will not affect the trust state of a Participant. On the other hand, a Policy violation of a Participant can result in losing the trust state of its service.

5.2.2 Hybrid Identity and Access Management

The Identity and Access Management approach relies on a two-tiered approach which is currently work in progress and will be part of the next release of this document.

In practice, this means that Participants use a selected few Identity Systems for mutual identification and trust establishment, SSI being the recommended option for interoperability. After trust is established, underlying existing technologies already in use by Participants (on the “Principal level”) can be federated and reused, for example Open ID Connect or domain specific x509-based communication protocols.

Gaia-X Participants might need to comply with additional requirements on the type and usage of credentials management applications such as mandatory minimum-security requirements, such as Multi-factor authentication. Server-to-Server Communication plays a crucial role in Gaia-X and the integration of self-sovereignty must be worked out in more detail.

5.2.2.1 Federated Trust Model

The Federated Trust Model relies on the Gaia-X Federated Trust Component, which queries and verifies trust related information (like Gaia-X Labels, domain specific certifications) of Participants to determine whether they meet other Participants’ respective trust requirements.

This chapter describes the components required to provide an attested secure chain of trust & identities. Service implementations and the corresponding service delivery layer may include End-User services, distributed microservice architectures across multiple Participant domains, and/or cross domain data or digital service delivery

5.2.2.1.1 Architecture principles for this approach

Mutual trust based on mutually verifiable Participant identities between contracting parties, Provider and Consumer, is fundamental to federating trust and identities in the Principal layer. Heterogeneous ecosystems across multiple identity networks in the Participant layer must be supported as well as heterogeneous environments implementing multiple identity system standards. The high degree of standardization of Participant layer and Principal layer building blocks of the Gaia-X Federated Trust framework must ensure that there is no lock-in to any implementation of identity network and Identity System likewise.

5.2.2.1.2 Chain of trust and identity

The Gaia-X Participant Identity & Trust framework delivers a secure chain of trust and identities to the service delivery layer.

Mutual participant verification In the Participant layer, the Gaia-X Federated Trust Component implements the functionality to resolve and verify the Participant identity of the contracting parties. The Consumer verifies the Provider identity, the Provider verifies the Consumer identity. Successful mutual Participant verification results in a verified Participant Token representing the trust between Provider and Consumer.

Identity System federation

In the Principal layer, the Federation Plugin implements the functionality to federate trust between the Identity Systems of the contracting Participants based on the successful mutual Participant verification described above. The federation of trust between the identity systems is based on the identity system standard implemented for the service delivery layer. Required for the federation is a secure mutual exchange of the required federation metadata. This exchange must be secured based on the Verified Participant Token. Exemplary Identity Systems standards supporting federation are: OIDC/OAuth2 (draft), SAML, SPIFFE/SPIRE. Identity System federation may also include federating the trust between certificate authorities supporting X.509 for Principals.

Identification and Authentication

Once successfully federated, the Identity Systems are enabled to identify and authenticate the Principals in the service delivery layer of the contracting parties. Federated Principal identities are mutually trusted based on the federation of the Identity Systems of the contracting Participants.

5.2.2.1.3 Attestation of trust

In addition to providing a secure chain of trust and identity, the Gaia-X Federated Trust framework attests the chain trust from service delivery layer to the Participant identity. The attestation may include according to required trust policies of the service delivery: * resolving the Participant identity * checking the Tags of the Participant identity * attesting the mutual Participant verification * attesting the exchanged federation metadata

5.2.2.1.4 Integration of the framework

The Gaia-X Federated Trust framework is in essence agnostic to implementations of identity network, verification method as well as identity system standard.

Gaia-X Participants Identity Network integration

Different networks are supported by corresponding implementations of the Gaia-X Federated Trust Component serving as a client component of the Gaia-X approved Participant identity network. Provider and Consumer do not need to be registered on the same network. On each side the respective Gaia-X Federated Trust Components need to integrate with the network the contracting partner is registered with.

Principal Identity Integration Layer

While the interface to the Gaia-X Federated Trust Component is standardized, the federation mechanism of the Federation Plugin is specific to the implemented Identity System supporting current and future standards like OIDC/OAuth2 (draft), SPIFFE/SPIRE, PKI. Furthermore, multiple Identity Systems required for complex service offerings, like for example OIDC for user Principals, SPIRE for service Principals, are perfectly supported meaning that multiple Identity Systems on either side can be federated by corresponding plugins based on the very same mutual Participant identity verification if required for the service delivery.

5.3 Data Sovereignty Services

Data Sovereignty Services provide Participants the capability to have full self-determination of the exchange and sharing of their data. They can also decide to act without having the Data Sovereignty Service involved, if they wish to do so.

Informational self-determination for all Participants includes two aspects within the Data Ecosystem: (1) Transparency, and (2) Control of data usage. Enabling Data Sovereignty when exchanging, sharing and using data relies on fundamental functions and capabilities that are provided by Federation Services in conjunction with other mechanisms, concepts, and standards. The Data Sovereignty Services build on existing concepts of usage control that extend traditional access control. Thus, usage control is concerned with requirements that pertain to future data usage patterns (i.e., obligations), rather than data access (provisions).

5.3.1 Capabilities for Data Sovereignty Services

The foundation for Data Sovereignty is a trust-management mechanism to enable a reliable foundation for peer-to-peer data exchange and usage, but also to enable data value chains involving multiple Providers and Consumers. All functions and capabilities can be extended and configured based on domain-specific or use case-specific requirements to form reusable schemes.

The following are essential capabilities for Data Sovereignty in the Gaia-X Data Ecosystems:

Capabilities for Gaia-X Data Sovereignty Services

5.3.2 Functions of Data Sovereignty Services

Information services provide more detailed information about the general context of the data usage transactions. All information on the data exchange and data usage transactions must be traceable; therefore, agreed monitoring and logging capabilities are required for all data usage transactions. Self-determination also means that Providers can choose to apply no Usage Policies at all.

The Data Sovereignty Services in Gaia-X implement different functions for different phases of the data exchanges. Therefore, three distinct phases of data exchanges are defined:

• before transaction
• during transaction
• after transaction

Before the data exchange transaction, the Data Agreement Service is triggered and both parties negotiate a data exchange agreement. This includes Usage Policies and the required measures to implement those. During transactions, a Data Logging Service receives logging-messages that are useful to trace each transaction. This includes data provided, data received, policy enforced, and policy-violating messages. During and after the transaction the information stored can be queried by the transaction partners and a third eligible party, if required. The figure below shows the role of the aforementionentioned services to enable sovereign data exchange.

Data Sovereignty Services Big Picture

The Data Agreement Service enables data transactions in a secure, trusted, and auditable way. It offers interfaces for the negotiation detailing the agreed terms for planned data exchange. The service is not meant to handle the transaction of data (which is described in the negotiated data contracts).

The Data Logging Service provides evidence that data has been (a) transmitted, (b) received and (c) that rules and obligations (Usage Policies) were successfully enforced or were violated. This supports the clearing of operational issues but also identifies fraudulent transactions.

The Provider can track if, how, and what data was provided, with the Consumer being notified about this. The Consumer can track if data was received or not, and, additionally, track and provide evidence on the enforcement or violation of Usage Policies.

5.4 Compliance

Gaia-X defines a Compliance framework that manifests itself in the form of a code of conduct, third party Certifications / attestations, or acceptance of Terms and Conditions. It is detailed in the Policy Rules document. Requirements from the field of security (e.g., data encryption, protection, or interoperability) form the basis for this Compliance framework. The main objective of Federation Services Compliance is to provide Gaia-X users with transparency on the Compliance of each specific Service Offering.

Federation Services consist of two components: First, the Onboarding and Accreditation Workflow (OAW) that ensures that all Participants, Resources and Service Offerings undergo a validation process before being added to a Catalogue; Second, the Continuous Automated Monitoring (CAM) that enables monitoring of the Compliance based on Self-Descriptions. This is achieved by automatically interacting with the service-under-test, using standardised protocols and interfaces to retrieve technical evidence. One goal of the OAW is to document the validation process and the generation of an audit trail to guarantee adherence to generally accepted practices in Conformity Assessments. In addition to the general onboarding workflow, special functions must include:

• Monitoring of the relevant bases for Compliance
• Monitoring of updates to Service Offerings that could trigger revisions / recertifications for Compliance
• Suspension of Service Offerings
• Revocation of Service Offerings

5.5 Gaia-X Portals and APIs

The Gaia-X Portals support Participants to interact with Federation Services functions via a user interface, which provides mechanisms to interact with core capabilities using API calls. The goal is a consistent user experience for all tasks that can be performed with a specific focus on security and Compliance. The Portals provide information on Resources and Service Offerings and interaction mechanisms for tasks related to their maintenance. Each Ecosystem can deploy its own Portals to support interaction with Federation Services. The functions of the Portals are further described below.

A Portal supports the registration of organizations as new Participants. This process provides the steps to identify and authorize becoming a Participant. Additionally, organizations are assisted in registering as members of the Gaia-X association AISBL. Participants are supported in managing Self-Descriptions and organizing Credentials. This includes Self-Description revisions and administration. A Portal further offers search and filtering of Service Offerings and Participants, based on Federated Catalogues. Additionally, solution packaging refers to a composition mechanism for the selection and combination of Service Offerings into solution packages to address specific use cases possible with a Portal. To orchestrate the various APIs, an API framework to create a consistent user and developer experience for API access and lifecycle is introduced. An API gateway will ensure security for all integrated services. An API portal will provide a single point of information about available API services and version management.