How it Works

In order to explain how Yo-Ga-X works, let’s first look at an example use case, which also was a part of the GAIA-X-Med project.

Example Use Case

In order to cooperate by sharing resources and data, different Participants inside the service ecosystem — some of them providing services, others consuming them, and others possibly doing both — form service compositions.

To realize self-determined cooperation, our Yo-Ga-X framework lets Participants negotiate compositions of services and collects the explicit informed consent of all involved Participants.

Thus, to help Providers be informed when consenting, every Consumer of a service is required to obtain certificates for certain trust enabling information about themselves from adequate institutions, such that the Provider can trust in the validity of the given information.

In our example use case, this is important for every service:

For the Hospital service, a patient has their identity certified by an E-Identity provider, so that the hospital (currently acting as a custodian of his data) can verify that the requester is actually allowed to access the requested information due to utilizing their right of providing information.
For the Patient service, an AI company has to obtain certificates for trust enabling attributes from institutions trusted by patients, which would convince patients with full data sovereignty to provide some of their data needed for a specific purpose — namely a way in which the AI company aims to generate value from said data.
For the AI company service, users obtain certificates for certain identifying attributes, not necessarily all of their identity information, from institutions trusted by AI companies and patients. AI companies can then restrict their types of users in order to better align with patients criterias for choosing companies that they provide data to, i.e. the service being used exclusively by health professionals or for scientific rather than commercial purposes.

In summary, the underlying task to be addressed by our Yo-Ga-X framework is the same for all three services in this service composition: to provide the necessary information before any service consumption in order to enable informed consent, specifically for the choice of which consumer to allow access to the provided service.

Of course, informed consent also has to be respected vice versa, such that consumers can make informed decisions about which services to consume, with the necessary information typically at least including identity of the service’s provider and terms and conditions of the service usage.

The Yo-Ga-X framework enables such negotiated service compositions based on informed consent and thus facilitates the service ecosystem for this example use case and many more in the following way, employing many of the concepts described in the Gaia-X Architecture Document 22.04:

To enable informed consent, the Yo-Ga-X framework employs credentials to represent the necessary information and allows to form contracts based on those credentials before any service consumption to represent the informed consent of both consumer and provider.

Yo-Ga-X provides Federation Services to facilitate the exchange of this information; like the Catalog, a service registy where service information is made available to potential consumers.

The four sub-processes of Yo-Ga-X

To reduce the complexity of the overall process, the Yo-Ga-X framework defines the following four sub-processes, each focusing only on a few involved participants and Federation Services:

Participant Onboarding, where both Providers and Consumers initially give information about themselves and join the Gaia-X-based federation, which is the base for the Yo-Ga-X-powered service ecosystem,
Service Onboarding, where Providers give information for and register their to-be-offered Service in the federation’s Catalog,
Service Discovery and Contract Negotiation, where Consumers browse the Catalog to find Services they are interested in and initiate the negotiation of a Contract with the Provider of a chosen Service,
Service Consumption, where consumers finally consume a Service they negotiated a Contract for, including the authentication at the Provider.

In the following, let’s take a look at these processes in further detail.

Participant Onboarding

During Participant Onboarding, all Participants — Consumers as well as Providers — first create a credential containing identifying details about themselves and their legal person which they wish to share with other Participants. The federation’s Compliance Service then validates the credential’s structure and certifies it as being part of the federation. Finally, the Participant receives a Participant Identity File, representing his participation in the federation while simultaneously acting as the passkey for authentication.

Service Onboarding

During Service Onboarding, Providers first create a credential containing details about the particular Service they intend to provide and certify that they are the Participant responsible for its management. Again, the Compliance Service validates the credential’s structure and certifies the Service as being part of the federation and that it belongs to the Provider. Finally, the Provider registers the Service in the Catalog, another Federation Service, where it can be discovered by potential Consumers.

Service Discovery and Contract Negotiation

During Service Discovery, Consumers first authenticate themselves at the Catalog as a Participant of the federation. They are able to browse it and choose a Service they intend to consume. This choice then initiates the Contract Negotiation process, during which the Negotiation Service, yet another Federation Service, corresponds with the soon-to-be Consumer and the Provider of the Service to form a Contract expressing the informed consent of both parties to the future service consumption.

Service Consumption

During the actual Service Consumption, Consumers attempt to authenticate themselves at the Provider’s Service using their Participant Identity File, containing their certificate of participation in the federation. Since this identifying certificate is also part of the Contract the Provider received during the Contract Negotiation process, the Provider can verify the requesting party’s identity and provide the Service according to the negotiated conditions.

Now that you have become familiar with the whole process of participating in a Yo-Ga-X enabled service ecosystem and have learned about several relevant concepts, you might want to:

Take a look at the Documentation and get to know individual components and their interactions.
Follow our simple guides and try Yo-Ga-X out for yourself!