Work Packages

These questions and answers were collected during the Gaia-X Federation Services Deep Dive Sessions that took place between March and June 2022. The recorded sessions can be found in the video section of this website. The GXFS-DE Team is at your disposal to answer any questions in cases of further interest: info@gxfs.de

Work Package 1: Identity & Trust

Question: Would it be possible to include FIDO2 tokens in the authentication? Are adjustments to the framework necessary for this?

Answer: FIDO2 provides a password-free method purely for token-based authentication. The Verifiable Credentials in SSI are used to query context-dependent attributes for functional authentication and also for authorization. The Verifiable Credentials used for this purpose are securely managed in a wallet, and here in the SSI environment FIDO2 is often used to open the wallet and only then the stored credentials are used for subject authentication. Therefore, FIDO2 and SSI are parallel developments and can be combined accordingly.

Question: When are minimally functional implementations available, especially of the services required for Holder and Verifier? Are there test federations that can be used for prototyping purposes?

Answer: For the Gaia-X Hackathon in June 2022, a first stack based on OIDC4VP/SIOPv2 will already be available and a registry to query the Trust Anchor as well. The whole stack will be deployable on Kubernetes. This is a result from the Gaia-X Lab.

Question: Are zero knowledge proofs used?

Answer: Zero knowledge proofs are proving difficult in the current frameworks. At the moment, only selective disclosure based on BBS+ signatures is planned. In a further stage, other ZKP processes will also be supported.

Question: How does the decentralized SSI concept differ (e.g. in terms of technological implementation) from existing solutions – example “Green Pass” in Italy?

Answer: Both SSI and DCC are based on the exchange of public key cryptography between participants. With DCC (the approach used in Italy), there is also a decentralized issuer in each EU country, sometimes even several. However, data is exchanged centrally via a server of the European Commission. In the SSI system, on the other hand, verification is completely decentralized and under the control of the use case.

Question: Will the respective federation itself decide which underlying technology (DLT or also central) will be used to store the DID documents? In which system will the DID documents of the trust anchors be stored? What requirements must a technology fulfill in order to be considered for this?

Answer: Each use case can decide which storage is acceptable. A communication between banks may need 100% auditable systems based on DLTs, while eCommerce with did:web may aim for a higher penetration rate.

Question: How and where are policies specified for the PDP (Policy Decision Point)?

Answer: Trusted services contain a policy agent that can be supplied with policy definitions using GitOps methods. The process of release and rollout can be defined and implemented by each federation and the trust service users themselves.

Question: Is it possible to connect e.g. an Open Policy Agent (OPA) for Policy Decisions?

Answer: The Trust Services are a kind of more comprehensive Open Policy Agent. They are managed in Gitlab, where you can also configure and manage specific policies. The whole thing is done in the Rego policy language.

Question: Are there standards for the acceptance of credentials? Which credential formats should be supported in the future?

Answer: Standardized semantic schemas still need to be created. This will be driven forward in upcoming hackathons together with the community in order to develop schemas for the various domains, among other things. JSON-LD credentials will probably prevail as the credentials format, and this format should then be fully supported. However, Gaia-X does not want to strictly specify these, but wants to follow the community, which is why several credential formats are also to be supported if necessary.

Question: Can credentials also be biometric references (templates) such as fingerprints?

Answer: A biometric fingerprint can be created as a Verifiable Credential (e.g. passport photo) and verified by matching during authentication. There are several other use cases and prototypes. A realization in practice is not yet known, since data protection guidelines must also be particularly observed here. However, it will be an option in the long term.

Question: Will there also be client libraries in different languages that can be directly included when there are eventually many different implementations of verifiable credentials?

Answer: The formats are specified according to W3C standards and these are then stored in JSON LD libraries. The format as a container is already defined. Semantic content must be defined via schemas; schemas already exist, but custom schemas can also be created. In addition, SDK’s already exist in many languages (Go, Java, Kotlin, Python, JS&Typescript, Rust, C#, etc) to create and validate credentials.

Question: In the Trust Anchor context, can a Holder also check a Verifier? If so, is information about the verifier also visible in the Trust Anchor?

Answer: This topic is discussed extensively in the Gaia-X community and includes important questions around the basic concepts. Among other things, the DIDComm protocol establishes a connection where both parties reveal their identity. The holder can thus check the verifier and decide whether to exchange credentials with it. The decision can be passed to the trust services in Gaia-X, and these can use configured policies to decide which trust anchors are required in a particular context.

Question: What is the relationship between Trust Anchors and Holders? Does the Holder have knowledge of or interaction with the Trust Anchor?

Answer: In SSI, no direct connection to the issuer is established during validation and thus no direct interaction between trust anchors and holders takes place. Verification can be performed cryptographically by determining the public keys and resolving the DIDs through the chain via the VerifiableRegistry (a ledger is often used). No connection to the issuer or referenced trust anchor is necessary for this.

Question: Should the Personal Credential Manager (PCM) be used analogously for robot accounts?

Answer: The PCM in the first version is for humans only. Machines are more likely to use a backend credential manager or the OCM.

Question: Are there any special requirements to offer a Personal Credential Manager?

Answer: No, it is open source and can be freely used and modified.

Question: Does the Personal Credential Manager communicate directly with the respective storage technology for DIDs or via an API provided by the Federator?

Answer: It communicates directly when resolving the respective DID method. Each DID method defines its own protocol and can be designed to be secure accordingly.

Question: Does the Organization Credential Manager handle the self-descriptions of a service instance?

Answer: The Organization Credential Manager provides the endpoints where the self- descriptions can be retrieved.

Question: Are all Organization Credential Managers/Personal Credential Managers based on the Hyperledger Aries SSI stack or can other SSI stacks be used?

Answer: Aries is one of the implementation options and is also used by a few GXFS-DE services, but is to be designed openly.

Question: Is the Notarization Officer meant locally per federation, as well as the Notarization Services?

Answer: It depends on the federation. If the federation consists of independent legal entities, there will be several onboarding officers/notaries. If the federation consists of natural persons, it might make sense to centralize these functions.

Question: How will the European eIDAS project be integrated into the GXFS components?

Answer: Notarization will also include an eIDAS signature to support advanced signatures. It is planned to implement the ESSIF eIDAS Bridge functionality and integrate it into the service. Qualified signatures are not planned in the first phase. In a later phase eIDAS QS are also planned. Possibly, the GXFS Notarization service can later be replaced by the eSSIF Notarization API of the EU with eIDAS for some use cases.

Question: Is the Trust Service API operated centrally somewhere and are the policies in it to be understood as a global set of rules? Or is the API a framework that is defined and operated per federation or sub-ecosystem?

Answer: The Trust Service API can be seen as a counterpart to the Organization Credential Manager. The relevant policies can be found in the Git repository, e.g. in the Gaia-X Gitlab. A central Gaia-X hosting is not planned.

Question: Will the respective federation itself decide which underlying technology (DLT or also central) will be used to store the DID documents? In which system will the DID documents of the trust anchors be stored? What requirements must a given technology fulfill in order to be considered for this?

Answer: The technology must be trustworthy. What this means in a specific case is to be evaluated by the federation. The Trust Anchor does not necessarily need DID documents. It can also be defined as a compliance framework (e.g., each Issuer must carry a Type X credential). In addition to a ledger, DID methods such as DID:Web or DID:DNS can also be used.

Question: Where is the Trust API hosted? Does each organization host it itself?

Answer: It depends on the setup and the security requirement. Potentially it is a Rest API and the user can determine the hosting themselves and if necessary also have the security attested – Gaia- X does not plan to make any specifications here so far. A federation or organization can impose its own rules on how to secure this service.

Question: Can any signature be revoked (notarization provider, company, etc.), for example, in the event of or after misuse?

Answer: There are revocation mechanisms in the W3C standard to revoke credentials. If needed, this mechanism can also be extended. In general, credentials should not be issued with an infinite lifetime. Digital issuance allows high frequency renewal of credentials. A driver’s license, for example, can be reissued every day. Revocation thus becomes superfluous in most cases.

Question: Will there be a single Verifiable Data Registry?

Answer: There can be as many registries as there are use cases.

Question: Does implementation mean implementation within the Eclipse Dataspace Connector? If not, where does the implementation take place?

Answer: The EDC is an implementation variant for data connectors. According to the current assessment, it is not a federation service, since the execution takes place at the Participant and not at the Federator. Depending on the acceptance of the EDC, a connection to the Federation Services can be made, for example to the Data Contracting and Data Monitoring Services.

Question: What happens when two federations use two different SSI stacks? How is interoperability ensured?

Answer: We are trying to implement the Interop Profile 2.0 so that interoperability between the SDKs (Software Development Kits) is largely established. Nevertheless, the standard and the interpretation is not yet mature and thus we expect problems at the beginning (Phase1). We want to work on the issue of ensuring interoperability in the next phase. At present, however, other frameworks from the “Digital Identities Showcase” project are already being included in the coordination.

Work Package 2: Federated Catalogue

Question: Will there be client libs when the implementation is done?

Answer: All GXFS specifications can be found at: https://www.gxfs.eu/de/spezifikationen/. The following technical specifications were prepared in spring 2021 and awarded in an EU-wide tender. The code according to specifications can be found here: https://gitlab.com/gaia-x/data-infrastructure-federation-services

Question: The current draft of the Gaia-X architecture document contains the following statement: “Each ecosystem is free to implement those functional needs as they see fit.” Do certain areas of the Gaia-X Functional Needs not have to be implemented at all if there is no need for them (e.g. contract negotiation, logging of transactions)? Or does the statement in the architecture document rather mean that these functions have to be provided, but each community is free to decide how this implementation is done? Also, is there a description of minimum requirements that are necessary from a technical as well as from an organisational/legal (e.g. GDPR) point of view in order to designate a service as Gaia-X compliant?

Answer: The definition of Federation Services is captured here: https://gitlab.com/gaia-x/technical-committee/federation-services/federation-services-core/

The GXFS projects (www.gxfs.eu) are delivering functional reference implementations whicha re not mandatet to be used to be Gaia-X compliant.

Answer to question 2: This is meanwhile explained in the Trust Framework (latest official publication, latest working draft).

Question: Is it possible to achieve compliance with the Gaia-X Labelling Criteria by taking into  account relevant norms and standards (e.g. GDPR, relevant Codes of Conduct, etc.) and to prove this via the self-descriptions of the services? Would this already fulfil a minimum requirement to designate a service as Gaia-X compliant. Or are there further requirements to be observed, such as the use of certain federation services?

Answer: The compliance requirements are still under discussion. For the time being, the Gaia-X Trustframework is the relevant technical service for alignment. Please follow: https://gaia-x.gitlab.io/policy-rules-committee/trust-framework/

Question: Is the attribute vocabulary already fixed or publicly available?

Answer: It is publicly available via the Trust Framework (latest official publication, latest working draft). However, the earlier 21.12 Architecture Document had specified additional attributes, which will find their way back into the Trust Framework in July 2022.

Question: Is the Data Model a complete ontology?

Answer: A complete run-through from Self-Description to Verifiable Credential is available here: https://gitlab.com/groups/gaia-x/lab/-/wikis/Quick-Guide-CLI-Credential-Creation-and- Verification-(WIP)

Quick Guide CLI Credential Creation and Verification (WIP) – Wiki – Gaia-X Lab:  GitLab.com

Starts with the SD Creation Wizard for creating SDs as JSON-LD from SHACL shapes curently hosted at  https://gaia-x.fit.fraunhofer.de/. This function will be hosted via GXFS soon.

To create this for yourself once, you can do this directly yourself for a Participant Credential incl. validation. https://onboarding-portal.lab.gaia-x.eu/. You can find step-by-step instructions here: https://gitlab.com/gaia-x/gaia-x-community/gx-hackathon/gx-hackathon-3/-

/wikis/uploads/3d5f6539e21a7c7e476f27a64bfbaa66/20220328_Gaia- X_Lab_Onboarding_Portal_and_Registry.pdf

Question: Are the SHACL shapes an additional component? They do not seem to be referenced in  VCDM 1.1.

Answer: The VCDM (Vector Calibration Data Management) defines that the claims are in the RDF data model (in the VCDM this is called “credentialSubject”). SHACL can be used, but is not required, to validate the structure of RDF graphs against a schema.

The SD Wizard uses this as a basis, which is a very good basis for the schemas (as just mentioned here).

These are transferred into validation policies within the framework of the Compliance Service. This allows the descriptions to be checked automatically. This is the basis for a successful scaling of the Trust Framework.

The wizard already carries a large number of examples; you can try them out directly. https://gaia- x.fit.fraunhofer.de/

Question: Can a signature be reused for a customised change?

Answer: The attribute vocabulary was already specified in the Gaia-X Architecture Document 21.12 and published at https://w3id.org/gaia-x/core/. However, the more recent developments around the Trust Framework (latest official publication, latest working draft) have brought new movement. A first merging of the previous attributes with the Trust Framework will be published in May, but this does not yet cover the full scope.

Question: Are there examples of SHACL shapes that can be used to try out the Fraunhofer Wizard?

Answer: The wizard already contains a large number of examples, you can try them out directly. https://gaia-x.fit.fraunhofer.de/

SHACL shapes are not an ontological models. They    serve a different purpose. Ontologies describe concepts and help in inferring additional knowledge. Firstly, the W3C ontology languages follow the Open World Assumption, secondly SHACL follows the Closed World Assumption. If a self-description is missing an attribute, it is an error in the shape validation (and that’s how it should be!). From the ontology’s point of view, the attribute could be defined somewhere else in the WWW, if not in the JSON-LD file at hand (but this extremely decentralised view is not compatible with Gaia-X’s trust-building approach).

Question: How stable are the definitions of the schemes at present (mandatory attributes, etc)?

Answer: They are not yet stable. The self-description schemes (i.e., for the claims within the VC/VP) have a solid ontological basis, that is rather lightweight (RDFS plus a little OWL). So far the focus has been upon identifying concepts/attributes that are needed from the Gaia-X point of view. The underlying alignment with existing ontologies such as DCAT is still at an early stage, but very important so that we are compliant with existing standards.

Question: Are asynchronous services also described?

Answer: https://www.asyncapi.com/

Gaia-X is neutral on this. Even for the deep details of synchronous APIs, it is not intended that the Gaia-X Self-Description Schemas create their own standard, but rather reference is made to any existing OpenAPI descriptions. (There is an attribute for this reference.) Furthermore, in the case of a Gaia-X Data Service, there is little talk in “Gaia-X language” about what the data looks like (e.g. which format/standard it conforms to) that is “exposed” by the service.

The Gaia-X WG Service Characteristics deals with the static  claim part of the self-description schemas, and support specification and tooling tasks within GXFS-DE. In this context, the above-mentioned Creation Wizard was developed, which is currently still at https://gaia-x.fit.fraunhofer.de/, but will soon be accessible via https://gxfs.eu.

Question: What about cooperation with the Eclipse Dataspace Connector?

Answer: Information on the Eclipse Dataspace Connector (in the context of which a partial “client library” for the Federated Catalogue will certainly be created), can be found here: https://github.com/eclipse- dataspaceconnector and here: https://www.youtube.com/channel/UCYmjEHtMSzycheBB4AeITHg. First  steps, not yet in the direction of the Catalogue, but in the direction of the Trust Framework, were taken at the Gaia-X Hackathon #4 in June 2022.

In general, a certain data connector implementation is not in scope of the core Gaia-X conceptual model as it is a service component like others and is not part of the Federation Services concept. This is based on a Gaia-X Board of Directors decision:

General Statement about Data Connectors

  • Data exchange is in scope for Gaia-X specifications.
  • Data Connector products are out of scope for Gaia-X specifications.
  • Data Connector services are in scope for the Gaia-X Trust Framework/Compliance.

Work Package 3: Sovereign Data Exchange

Question: How will it technically work if data has landed in a consumer’s system and has been processed, to remove it from there if the permission to use and process this data is withdrawn? Is this idea realistic?

Answer: Here it can help not to release the data and to allow the processing only under the control of the “Data Owner”. Compute-to-data approaches enable technical data sovereignty here. For well-known parties that enjoy very high trust, contracts can create an obligation (but do not guarantee technical enforcement). However, there are also concepts and technologies to enforce terms of use on the data user side. However, this increases the technical effort. 

Question: How is the data paradox resolved? For example, how can I be sure that someone who temporarily owns my data will not make a copy of it?

Answer: Here we enter into the purview of individual risk assessments and impact assessments that then lead to decisions regarding the use cases and requirements (e.g. protection of intellectual property, GDPR compliance, etc.). The contract service in work package 3 offers a basis for trust at organizational level during processing and thus also enables a liability claim for the data provider.

Furthermore, there are also paid cloud service solutions that enable comprehensive data management. Such solutions are very costly and must be placed in the context of the effort and sensitivity of the data, but they can, for example, prevent data from being tapped and they can also prevent access to data via online tools.

In principle, it must always be checked which terms of use are important and relevant for the data and whether they can also be implemented by the data user.

Question: To what extent does a Data Delivery Contract (DDC) also regulate financial parameters such as the monetary value of the data and or payment terms?

Answer: In many cases, it can be assumed that future implementations will also cover these topics, from prepaid to postpaid. Everything is possible here in principle, depending on the preference of the actors. But also free provision, for example in the research context, is possible and important.

Question: How can the Technology Readiness Level be evaluated? Is Gaia-X developing a technology that can be used operationally at the end of the year or is it still about applied research and a perspective for well after 2025?

Answer: The plans refer to the period 2022/2023, much longer delays are not foreseen.

Question: Do the Federation Services in the area of data exchange also include client libraries and examples, or only the server?

Answer: Federation services do not develop clients for the providers and consumers, but essentially the APIs and services they need. In other projects, however, clients are developed as open source software.

Question: How long can it take to negotiate contracts? Is there a maximum period?

Answer: There is no maximum duration for contract negotiations

Question: What is the connection to the Eclipse Dataspace Connector (EDC)?

Answer: The Eclipse Data Space Connector can negotiate data delivery contracts with other data connectors even without the Data Contract Service (DCS). The same applies to the Data Exchange Logging Service (DELS). Due to the modular structure, other logging services can also be used. However, the DCS also allows contract negotiation between a party using the EDC and a party without a data connector. In general, GXFS Connectors are agnostic and provide APIs for use as reference implementations for contracting and logging.

Question: What kind of identity management technologies are supported? SSI?

Answer: The Data Contract Service (DCS) and Data Exchange Logging Service (DELS) use the concepts and technologies of Work Package 1 Identity and Trust. Dies inkludiert SSI, Verifiable Credentials, X.509 certificates for linking to eIDAS. The main standards include DIDComm, OpenID (for VCs), DIDs, etc.

Prototypically implemented, the Trust Framework can be found in the Gaia-X Lab Onboarding Portal, which enables the issuance and verification of a Gaia-X Participant Credential. This makes the concept come alive. https://onboarding-portal.lab.gaia-x.eu/ (Uses DID:WEB, OIDC4VP, SIOPv2).

Please also see the FAQ page for Work Package 1 for further information on this topic.

Question: Is it technically ensured that the log messages are correct, or is this a legal issue? For example, if a data user reports that he has deleted the data even though he still holds the data?

Answer: Ensuring the correctness of logging messages can be achieved through various measures. Here, organizational and legal means are the easiest option. A technical validation is possible, but on the one hand associated with greater effort and on the other hand not in the focus of GXFS.

Question: Is support for Data Contract Service (DCS) and Data Exchange Logging Service (DELS) mandatory for Gaia-X compliance?

Answer: No.

Question: If the Data Contracting Service (DCS) is also implemented decentrally in the connector, how do you agree on the Logging Service?

Answer: The logging service can be specified in the contract and can therefore be part of the negotiation. However, a federation can also specify this.

Question: Are the contracts of the Services integrated in the Eclipse Dataspace Connector (EDC) identical  or at least compatible with the Gaia-X Format?

Answer: The Eclipse Dataspace Connector (EDC) is currently in a development version with a planned release in June 2022. As soon as this release of the EDC is available, compatibility issues can be checked. Until then, it is difficult to make this assessment, as nothing final is available yet. The languages and structures used are the same, but even small differences can have a major impact on compatibility, which is why a closer examination is necessary. Nevertheless, the aim of the projects is to agree on a common stand here.

Question: Who deals with the integration of Data Contracting Service (DCS), Data Exchange Logging Service (DELS) and explicit Data Exchange Services (e.g. WebAPIs, etc.)?

Answer: The implementation of the first version is carried out by contractors. The results are open source under Apache License 2.

Question: Where are the technologies applied, in pilots or collaborations such as the Mobility Data Space (MDS)?

Answer: The technologies and concepts are already being applied and used in many pilots. These include very mature projects, such as the Mobility Data Space or the Smart Connected Suppliers Network.

Question: How should IDS and Gaia-X be viewed at the moment? Compatible, complementary?

Answer: The developments are quite complementary, even if there is some overlap here. The focus of IDS is the data connector, while Gaia-X focuses on a soft data infrastructure. In the cross-cutting areas, there are activities to reach a common position, e.g. in the discussion about the use of Rego or ODRL for usage policies of data services.

Question: Are certain tasks easier to implement with a Federator? Analogous to the example, someone operates the logging service that consumers and providers use?

Answer: The Federator can take over certain tasks in a Federation and thus makes working together in the Federation much easier. The Federator thus fulfils  an important function for the overall functionality of the Federation. The remuneration of a Federator depends largely on the business case of a Federation.  Scaling effects and cost savings as well as new business potentials of the individual participants should of course be taken into account here.

Question: Do Smart Contracts (e.g. solidity) exist for GXFS, tracing via a Distributed Ledger Technology (DLT) would generally make sense, wouldn’t it?

Answer: No, there are no ready-made smart contracts from the GXFS project yet. But there is work in this direction, also within the framework of the Minimal Viable Gaia Group. The use of DLT is generally conceivable in this context, but not the only technology.

Question: What kind of policy should a Federator comply with that also collects data (log) at the end?

Answer: How an ecosystem is built and which policies it bases itself on must be determined within the individual Federations. There is no one-size-fits-all answer here.

Work Package 4: Compliance

Question: Who provides the user interface (UI) for the compliance services?

Answer: There is no central, one-size-fits-all approach here. Instead, each Federation will develop its own user interface.

Question: Who handles the processes in the Registry and for the Onboarding?  Who handles the necessary processes when it comes to updates, for example?

Answer: In the long run, a complete decentralization via the Federations is envisaged. Federations are best placed to coordinate these processes because they have the best insights into goals, prerequisites and other frameworks that are relevant in their ecosystem. However, a first impulse will be provided by the Gaia-X Association.

Question: Is there such a thing as an advisory board for innovations in the Compliance Framework, in particular to clarify any points of contention?

Answer: The relevant documents that make up the Compliance Framework are the Gaia-X Policy Rules Document, the Gaia-X Trust Framework and the Gaia-X Labelling Document. All three documents are being further developed by the Gaia-X Association. Any changes are the responsibility of the Gaia-X Association Board of Directors.

Question: How exactly do the labels feed into the compliance process?  How are they applied?

Answer: The labels are optional and not a prerequisite for participation in a Federation. As part of the Self-Descriptions, information about labels can be provided. Labels would have to be applied for separately with the Gaia-X Association or another official entity. Further evidence might have to be provided in order to obtain a Gaia-X label. Therefore, the label is an additional step that goes beyond pure Gaia-X compliance.

Question: What are the benefits of a Gaia-X label for a service provider?

Answer: A label is a differentiation criterion. This allows providers to prove to a potential customer, for example, that their services are audited and verified in a special way. For example, a label can provide orientation and transparency for customers when conducting risk assessments.

Question: Is there also a rating system planned for services offered? To ensure data and service quality, among other things? If so, how would correctness be ensured?

Answer: A feedback or rating system is an interesting idea, but it is not intended as part of the onboarding and accreditation workflow.

Question: What are the indirect costs of achieving a Gaia-X Level 3 label for companies?

Answer: This cannot be said in general terms and depends on the initial situation of a provider. If relevant attestations already exist (e.g. C5, signing of a GDPR Code of Conduct, portability has been ensured, etc.), the effort will most likely be manageable. However, the Gaia-X Level 3 should be a real exception label (e.g. for use in the field of critical infrastructures), the Level 2 label should cover 98% of the strict requirements.

Question: How is trust in the Notarization Service ensured?

Answer: The operation is carried out by accredited trust anchors. In addition, a decentralized verifiability based on the cryptographic methods for checking the attestations (Verifiable Credentials, etc.)  secured.

Question: Are graphs and evaluations of performance indicators of Continuous Automated Monitoring (CAM) also to be expected in the portal?

Answer: Yes, graphs and evaluations can be made available in a dashboard.

Question: Are certain fulfillments of requirements reflected in the public descriptions via the assessment and is it clear to the user which requirements are met by the service (and whether there is corresponding evidence)?

Answer: Yes, this is definitely possible, although each Federation can of course decide which information is visible in the Catalogue.

Work Package 5: Portal

Question: Do I have to provide my identity to view the Catalogue and Portal of a Federation?

Answer: Federations decide for themselves whether their Catalogue is publicly accessible or not. It may be that parts of the Catalogue are publicly accessible and other parts can only be reached after registration and verification. A publicly accessible Catalogue for all Federations can be included as an addition to the individual Federation Catalogues. Currently, this is in clarification of the Gaia-X Association, whether and who operationalizes such a Catalogue. 

Question: Where can I find templates for the Self-Descriptions? Is it possible to download them from the Catalogue?

Answer: The Service Lifecycle working group has provided examples of Self-Descriptions in a Gitlab repository. Authorization is necessary to access the information and can be requested via the WP leaders C. Lange-Bever and A. Strunk.

Question: Which ontologies for Self-Descriptions can be used?

Answer: The current version of the ontology is published under https://w3id.org/gaia-x/core, now at Trust Framework 22.04. The ontology defines classes and attributes, but only slightly restricts their use. What the creation wizzard under https://gaia-x.fit.fraunhofer.de/ (soon officially via gxfs.eu) does additionally is to validate an SD against a schema. This is a sister of the ontology, technically speaking SHACL shapes, but also linked from this w3id page.

Question: How is the connection established between the natural person and his or her company? Especially if we start from the first person to be onboarded?

Answer: The first step would be to apply to the Federation or to apply for admission to the Federation. The person must also have completed various documents in this context. In the Portal, the onboarding process then takes place using the Organizational Credential Manager (OCM). There, the notarization service then checks whether the person’s details are legitimate and then issues the person with a verifiable credential (VC) for his or her organization. The VC then enables a comparison between the company and the Federation. This process can be viewed in detail in the IDM specification, in the Identity & Trust Work Package or in the onboarding specification of the Compliance Work Package.

Question: Can Federations be created freely by several actors or is the establishment of a Federation regulated?

Answer: There is no regulation as such for the establishment of a Federation. Only if a Federation wants to join Gaia-X, there is a need for validation. A document defining requirements is currently being developed for this purpose. This document is still in progress.

Question: The credentials and Self-Descriptions of the service providers and the underlying offers (composition) must also be available. How is this addressed in the Portal? Is this done by permanently accessing the corresponding PCMs and OCMs or caches?

Answer: Self-Descriptions are verified via the trust framework of the Gaia-X Association. Credentials of the Self-Descriptions of service providers or their Self-Descriptions of services or similar are also retrieved and can be stored in the Credential Manager (Wallet). The portal currently accesses the Self-Descriptions referenced in the Catalogue. The Self-Descriptions to be retrieved brings along a verified credential.

Question: Is it possible to use only the Identifications and Credential component/API, for example for your own application in which I also want to grant access to companies?

Answer: Yes, this is possible. The associated components are developed in the corresponding work packages (lots) and you can only obtain, adapt and use individual services as open source code. Binding takes place via an API of the corresponding components.

Question: Is it also possible or planned to register and manage technical users so that not everything depends on one employee?

Answer: This was not considered in specification phase 1, but could be considered in specification phase 2. Technical users are often not well liked within companies, because it is often not quite clear who is hiding behind a technical user. In principle, this is an agreement between provider and user. For example, if a data offering is to be used via a software service, the offering company must decide which authentication is necessary.

Question: Which SHACKL forms are suitable for which service Self-Descriptions? Is there a description of these forms and the individual fields?

Answer: We refer here to the Gaia-X Trust Framework, where there is a list of attributes necessary to describe an organization or service. Furthermore, Fraunhofer is working on further elaborations of the Self-Description templates and we are planning further workshop formats for the elaboration of the attributes and templates.

Question: How is trust established in the Notarization Service?

Answer: Trust is ensured via so-called trust anchors, which are mentioned in the Gaia-X Trust Framework. Please refer to the respective specification in the Compliance Work Package for details.