Allgemeines

Was ist Gaia-X?

Gaia-X stellt die nächste Generation eines Dateninfrastruktur-Ökosystems dar: ein offenes, transparentes und sicheres digitales Ökosystem, in dem Daten und Dienste in einer vertrauensvollen Umgebung zur Verfügung gestellt, gesammelt und gemeinsam genutzt werden können.

Die architektonische Struktur von Gaia-X basiert auf dem Prinzip der Dezentralisierung. Gaia-X ist das Ergebnis vieler einzelner Dateneigentümer (Nutzer) und Technologieakteure (Anbieter), die alle einen gemeinsamen Standard von Regeln und Kontrollmechanismen – den Gaia-X-Standard – annehmen.

Was sind die Schlüsselelemente von Gaia-X?

Diese neue föderierte Dateninfrastruktur ist:

  1. Dezentralisiert: Gaia-X verbindet zentralisierte und dezentralisierte Infrastrukturen in einem homogenen System.
  2. Sicher, vertrauenswürdig und vertraulich: Ziel ist es, ein modulares, sicheres, vertrauenswürdiges und benutzerfreundliches System zu schaffen, das die bestehenden Cloud-Anbieter und ihre Dienste zusammenführt und in dem Daten und Anwendungen so gehandhabt werden können, dass die volle Kontrolle über sie gewährleistet ist.
  3. Transparent: Vor allem kleine und mittlere Unternehmen profitieren von transparenten Märkten, einem breiten Zugang zu maßgeschneiderten Dienstleistungen und den dadurch entstehenden Möglichkeiten.
  4. Offen: Die Dateninfrastruktur wird nach dem Open-Source-Prinzip aufgebaut sein.
  5. Die Grundlage für die Schaffung eines Ökosystems: Die Infrastruktur wird zur Entstehung eines Ökosystems führen, das die digitale Souveränität der Nutzer von Cloud-Diensten stärkt und den europäischen Cloud-Anbietern hilft, ihr Geschäft zu vergrößern und ihre Wettbewerbsfähigkeit zu verbessern. Dieses Ökosystem wird die Innovation fördern und einen einfachen Zugang zu neuen digitalen Technologien bieten.

GAIA-X ist nicht dazu gedacht, mit bestehenden Angeboten (wie Hyperscalern) zu konkurrieren. Vielmehr soll Gaia-X verschiedene Elemente über offene Schnittstellen und Standards miteinander verbinden, um Daten zu aggregieren und eine Plattform für Innovationen zu schaffen. Das Projekt steht allen interessierten Akteuren offen, ob großen Industrieunternehmen, KMU oder Start-ups. Im Mittelpunkt stehen dabei die Nutzer, die ein Schlüsselfaktor für den Erfolg der digitalen Wirtschaft sind.

Welche Branchen sind/werden vertreten sein?

  • Landwirtschaft
  • Luftfahrt
  • Energie 
  • Finanzen
  • Geoinformation
  • Gesundheit
  • Industrie
  • Logistik
  • Mobilität
  • Smart Living
  • Raumfahrt

Was bringt Gaia-X? Welchen Nutzen habe ich davon?

Datenverfügbarkeit: Wir brauchen eine vertrauenswürdige, sichere und transparente Dateninfrastruktur, die für den Austausch und die Verarbeitung von Daten genutzt werden kann. Nur so können wir die Größenvorteile nutzen, die durch die Verfügbarkeit großer Datensätze in Europa entstehen.

Innovation: Wir brauchen ein digitales Ökosystem, das die Entwicklung innovativer Produkte ermöglicht und europäischen Unternehmen und Geschäftsmodellen hilft, sich zu vergrößern und global wettbewerbsfähig zu sein. Gaia-X bietet die Grundlage dafür.

Datensouveränität: Die bestehenden Cloud-Angebote werden derzeit von außereuropäischen Anbietern dominiert, die in der Lage sind, ihre Infrastruktur schnell zu skalieren, und die über eine beträchtliche Marktmacht und große Mengen an Kapital verfügen. Gleichzeitig beobachten wir weltweit wachsende internationale Spannungen und Handelskonflikte. Europa muss sicherstellen, dass es seine digitale Souveränität dauerhaft aufbauen und erhalten kann.

Warum sollten Unternehmen Gaia-X nutzen? Warum ist es so wichtig?

Gaia-X zielt darauf ab, Standards zu schaffen, Softwaregemeinschaften zu fördern und die Schaffung von Datenräumen zu erleichtern. Daher konzentriert sich die Gaia-X AISBL auf drei Ziele:

  • Architekturspezifikation, die die Funktionalitäten von Gaia-X beschreibt und Konformitätskriterien enthält.
  • Open-Source-Softwarecode, um eine offene Implementierung von Föderationsdiensten und eine Open-Source-Community zu gewährleisten.
  • Zertifizierungsinstrumente, einschließlich Methoden und Werkzeuge für die Konformitätsprüfung und Zertifizierung von Diensten.

Ziele sind:

  • Interoperabilität zwischen verschiedenen Datenknoten
  • Benutzerfreundliche Serviceangebote
  • Austauschbarkeit zwischen verschiedenen Dienstanbietern in einem souveränen Datenmarkt
  • Und die Zusammenarbeit und der Datenaustausch zwischen Edge-Instanzen und Cloud-Instanzen.

Wer kann sich beteiligen?

Gaia-X bleibt offen für neue europäische Interessenten, die sich beteiligen und einen Beitrag leisten wollen. Die Teilnahme an Gaia-X ist auch für Marktteilnehmer außerhalb Europas möglich, die unsere Ziele der Datensouveränität und Datenverfügbarkeit teilen.

Wie kann ich mich beteiligen?

Gaia-X ist offen für neue Interessenten, die es weiterentwickeln wollen. Jeder kann sich auf die Art und Weise einbringen, die seinen Bedürfnissen am besten entspricht – zum Beispiel durch das Einbringen von technischem Fachwissen, das Vorschlagen neuer Anwendungsfälle oder durch die aktive und kontinuierliche Teilnahme an einer der verschiedenen offenen Arbeitsgruppen.

Im Allgemeinen gibt es drei Möglichkeiten, sich einzubringen:

  1. Beitritt zur Gaia-X Association
  2. Arbeit in den nationalen Gaia-X Hubs
  3. Engagement in der Gaia-X Community (durch z.B. Teilnahme an Hackathons)

Was ist GXFS?

Die Gaia-X Föderationsdienste stellen die technischen Mindestanforderungen und Dienste dar, die für den Betrieb föderierter Gaia-X-Daten- und Infrastruktur-Ökosysteme erforderlich sind. Die GXFS Dienste werden bestehende Standards und offene Technologien nutzen, z.B. Open-Source-Software. 

Wo finde ich Gaia-X Anwendungsbeispiele?

Wie werden Sicherheit und Datenschutz gewährleistet?

Um Sicherheit und Datenschutz als integralen Bestandteil zu gewährleisten, muss jeder Föderationsdienst Sicherheit und Datenschutz by-design sicherstellen. Sicherheit und Datenschutz werden in jedem Lebenszyklusschritt eines Föderationsdienstes integriert werden.

Zu unseren Arbeitspaketen

Arbeitspaket 1: Identität & Vertrauen

Frage: Wäre es möglich FIDO2 Tokens in die Authentication einzubinden? Sind dazu Anpassungen am Framework notwendig?

Antwort: FIDO2 stellt ein passwortfreies Verfahren rein zur tokenbasierten Authentifizierung bereit. Die Verifiable Credentials in SSI werden verwendet, um kontextabhängig Attribute zur fachlichen Authentifizierung und auch zur Autorisierung abzufragen. Die dazu genutzten Verifiable Credentials werden in einer Wallet sicher verwaltet und hier wird im SSI Umfeld oft FIDO2 zum Öffnen der Wallet und erst im Anschluss die gespeicherten Credentials zur fachlichen Authentisierung verwendet. Deshalb ist FIDO2 und SSI eine parallele Entwicklung und kann entsprechend kombiniert werden.


Frage: Wann stehen minimal funktionsfähige Implementierungen insbesondere der für Holder und Verifier notwendigen Services zur Verfügung? Gibt es ein für Prototyping-Zwecke nutzbare Test Federations?

Antwort: Zum Gaia-X Hackathon im Juni 2022 wird bereits ein erster Stack auf Basis von OIDC4VP/SIOPv2 verfügbar sein und eine Registry zur Abfrage der Trust Anchor auch. Der gesamte Stack wird auf Kubernetes deploybar sein. Das ist ein Ergebnis aus dem Gaia-X Lab.


Frage: Werden zero knowledge proofs verwendet?

Antwort: Zero Knowledge Proofs gestalten sich in den bisherigen Frameworks als schwierig. Im Moment ist nur selective Disclosure auf Basis von BBS+ Signaturen geplant. In einer weiteren Stufe sollen dann auch weitere ZKP Verfahren unterstützt werden.


Frage: Inwiefern unterscheidet sich das dezentralisierte SSI-Konzept (z.B. im Sinne der technologischen Umsetzung) von bestehenden Lösungen – Beispiel „Green Pass“ in Italien?

Antwort: Sowohl SSI als auch DCC basieren auf dem Austausch von public key cryptography zwischen Teilnehmern. Bei DCC (dem Ansatz der in Italien genutzt wird) gibt es auch dezentral in jedem EU Land einen Issuer, teilweise sogar mehrere. Allerdings werden Daten hier zentral über einen Server der Europäischen Kommission ausgetauscht. Im SSI System hingegen verläuft die Verifikation komplett dezentral und in der Hoheit des Anwendungsfalls.


Frage: Wird die jeweilige Föderation selbst entscheiden welche zugrundeliegende Technologie (DLT oder auch zentral) zur Speicherung der DID Dokumente verwendet wird? In welchem System werden die DID Dokumente der Trust Anchors liegen? Welche Anforderungen muss eine Technologie erfüllen um dafür in Frage zu kommen?

Antwort: Jeder Use Case kann entscheiden, welche Speicherung akzeptabel ist. Eine Kommunikation zwischen Banken benötigt eventuell 100% auditierbare Systeme auf Basis von DLTs, während eCommerce mit did:web eventuell einen höheren Verbreitungsgrad anstrebt.


Frage: Wie und wo werden Policies für den PDP (Policy Decision Point) spezifiziert?

Antwort: In den Trusted Services steckt ein Policy Agent, der durch GitOps Methoden mit Policy-Definitionen versorgt werden kann. Der Prozess der Freigabe und des Ausrollens kann jede Federation und auch die Trust-Service Nutzer selbst definieren und umsetzen.


Frage: Kann man für Policy Decisions auch z.B. einen Open Policy Agent (OPA) anbinden?

Antwort: Die Trust Services sind eine Art umfangreicherer Open Policy Agent. Sie werden im Gitlab verwaltet, wo man auch spezifische Policies konfigurieren und verwalten kann. Das Ganze erfolgt in der Rego policy language.


Frage: Gibt es Standards für die Akzeptanz von Credentials? Welche Credentials Formate sollen zukünftig unterstützt werden?

Antwort: Standardisierte Semantische Schemas müssen noch erzeugt werden. Dies wird in kommenden Hackathons gemeinsam mit der Community vorangetrieben, um u.a. Schemas für die verschiedenen Domänen zu entwickeln. Als Credentials-Format werden sich vermutlich JSON-LD Credentials durchsetzen und dieses Format soll dann auch voll unterstützt werden. Gaia-X möchte diese jedoch nicht streng vorgeben, sondern will der Community folgen, weshalb ggf. auch mehrere Credential-Formate unterstützt werden sollen.   


Frage: Können Credentials auch biometrische Referenzen (Templates) sein wie z.B. Fingerabdrücke?

Antwort: Ein biometrischer Fingerabdruck kann als Verifiable Credential angelegt werden (z.B. Passfoto) und bei der Authentifizierung durch Abgleich verifiziert werden. Es gibt einige weitere Use Cases und Prototypen. Eine Realisierung in der Praxis ist noch nicht bekannt, da hier auch Datenschutzrichtlinien besonders beachtet werden müssen. Es wird aber langfristig eine Option darstellen.


Frage: Wird es auch client libraries in verschiedenen Sprachen geben, die man direkt einbinden kann, wenn es irgendwann viele verschiedene Implementierungen von verifiable Credentials gibt?

Antwort: Die Formate werden nach W3C Standards spezifiziert und diese werden dann in JSON LD Bibliotheken hinterlegt. Das Format als Container ist bereits definiert. Semantische Inhalte müssen über Schemas definiert werden; es gibt bereits Schemas, es können aber auch eigene Schemas erstellt werden. Zudem gibt es bereits in vielen Sprachen SDK’s (Go, Java, Kotlin, Python, JS&Typescript, Rust, C#, usw), um Credentials zu erzeugen und validieren.    


Frage: Im Trust Anchor Kontext, kann ein Holder auch einen Verifier überprüfen? Wenn ja, sind Informationen zum Verifier auch im Trust Anchor einsichtig?

Antwort: Dieses Thema wird in der Gaia-X Community ausführlich diskutiert und beinhaltet wichtige Fragen rund um die Grundkonzepte. Unter anderem wird im DIDComm Protokoll eine Verbindung hergestellt, bei der beide Parteien ihre Identität preisgeben. Der Holder kann somit den Verifier prüfen und entscheiden, ob er mit ihm Credentials austauschen will. Die Entscheidung kann in Gaia-X an die Trust-Services übergeben werden und diese können anhand konfigurierter Policies entscheiden, welche Trust-Anchor in einem bestimmten Kontext erforderlich sind.


Frage: In welcher Beziehung stehen Trust Anchors und Holders? Hat der Holder Kenntnis von oder Interaktion mit dem Trust Anchor? 

Antwort: In SSI wird bei der Validierung keine direkte Verbindung zum Issuer aufgebaut und somit findet auch keine direkte Interaktion zwischen Trust Anchors und Holders statt. Die Verifikation kann kryptographisch durch das Ermitteln der Public Keys und Auflösen der DID’s durch die Chain über die VerifiableRegistry (oft wird ein Ledger verwendet) erfolgen. Hierzu ist keine Verbindung zum Issuer oder referenzierten Trust-Anchor notwendig.


Frage: Soll der Personal Credential Manager (PCM) analog für robot accounts verwendet werden?

Antwort: Der PCM in der ersten Version ist nur für Menschen gedacht. Maschinen verwenden eher einen Backend Credential Manager oder den OCM.


Frage: Gibt es spezielle Voraussetzungen, um einen Personal Credential Manager anzubieten?

Antwort: Nein, es ist Open Source und kann frei verwendet und modifiziert werden.


Frage: Kommuniziert der Personal Credential Manager direkt mit der jeweiligen Speicher-technologie für DIDs oder über eine vom Federator bereitgestellte API?

Antwort: Er kommuniziert direkt beim Auflösen der jeweiligen DID Methode. Jede DID-Methode definiert ihr eigenes Protokoll und kann entsprechend sicher gestaltet sein.   


Frage: Handelt der Organization Credential Manager die Self-Descriptions einer Service-Instanz?

Antwort: Der Organization Credential Manager stellt die Endpunkte zur Verfügung, wo die Self-Descriptions abgerufen werden können.


Frage: Basieren alle Organization Credential Manager/Personal Credential Manager auf dem SSI Stack von Hyperledger Aries oder können auch andere SSI Stacks eingesetzt werden?

Antwort: Aries ist eine der Implementierungsmöglichkeiten und wird u.a. auch bei ein paar GXFS-DE Services verwendet, ist aber offen zu gestalten.


Frage: Ist der Notarization Officer lokal pro Föderation gedacht, wie auch die Notarization Services?

Antwort: Es kommt auf die Federation an. Besteht die Föderation aus unabhängigen juristischen Personen, gibt es auch mehrere Onboarding Officers/Notaries. Besteht die Föderation aus natürlichen Personen, könnte es Sinn machen, diese Funktionen zu zentralisieren.


Frage: Wie wird das europäische eIDAS Projekt in die GXFS Komponenten integriert?

Antwort: Notarization wird auch eine eIDAS Signatur beinhalten, um damit auch eine fortgeschrittene Signatur zu unterstützen. Angedacht ist, die ESSIF eIDAS Bridge Funktionalität zu implementieren und in den Service zu integrieren. Qualifizierte Signaturen sind in der ersten Phase nicht geplant. In einer späteren Phase sind auch eIDAS QS geplant. Eventuell kann später der GXFS Notarization Dienst für manche Use Cases auch durch die eSSIF Notarization API der EU mit eIDAS ersetzt werden.


Frage: Wird die Trust Service API irgendwo zentral betrieben und sind die Policies darin als globales Regelwerk zu verstehen? Oder ist die API ein Rahmenwerk, welches pro Federation bzw. Subökosystem definiert und betrieben wird?

Antwort: Die Trust Service API ist als Pendant zum Organization Credential Manager zu betrachten. Die relevanten Policies sind im Git Repository vorzufinden z.B. im Gaia-X Gitlab. Ein zentrales Gaia-X Hosting ist nicht angedacht.


Frage: Wird die jeweilige Föderation selbst entscheiden welche zugrundeliegende Technologie (DLT oder auch zentral) zur Speicherung der DID Dokumente verwendet wird? In welchem System werden die DID Dokumente der Trust Anchors liegen? Welche Anforderungen muss eine gegebene Technologie erfüllen um dafür in Frage zu kommen?

Antwort: Die Technologie muss vertrauenswürdig sein. Was das im konkreten Fall bedeutet, ist durch die Föderation zu bewerten. Der Trust Anchor benötigt nicht zwangsläufig DID Dokumente. Er kann auch als Compliance Framework definiert werden (z.B. jeder Issuer muss ein Credential von Typ X tragen). Neben einem Ledger können auch DID-Methoden wie z.B. DID:Web oder DID:DNS Einzug finden.


Frage: Wo wird die Trust API gehostet? Hostet jede Organisation sie selbst?

Antwort: Hier kommt es auf das Setup und die Sicherheitsanforderung an. Potenziell ist es eine Rest API und der Nutzer kann das Hosting selbst bestimmen und ggf. auch die Sicherheit attestieren lassen – Gaia-X plant hier bisher keine Vorgaben zu machen. Eine Föderation oder Organisation kann sich selbst Regeln auferlegen, wie dieser Service abzusichern ist.  


Frage: Kann grundsätzlich beispielsweise bei/nach Missbrauch jede Signatur revoked (zu Deutsch: entzogen) werden (Notarization-Provider, Firma, etc.)?

Antwort: Es gibt Revocation Mechanismen im W3C Standard, um Credentials zu entziehen. Bei Bedarf kann dieser Mechanismus auch erweitert werden. Generell sollten keine Credentials mit unendlicher Laufzeit ausgestellt werden. Die digitale Ausstellung erlaubt hochfrequente Erneuerung der Credentials. Ein Führerschein kann z.b. jeden Tag neu ausgestellt werden. Eine Revokation wird somit in den meisten Fällen überflüssig.


Frage: Wird es eine einzige Verifiable Data Registry geben?

Antwort: Es kann so viele Registries geben wie es Anwendungsfälle gibt.


Frage: Bedeutet Implementierung eine Umsetzung im Rahmen des Eclipse Dataspace Connectors? Wenn nein, wo findet die Implementierung statt?

Antwort: Der EDC ist eine Implemtierungsvariante für Data Connectoren. Nach aktueller Einschätzung ist es kein Federation Services, da die Ausführung beim Participant und nicht beim Federator erfolgt. Je nach Akzeptanz für den EDC kann ein Anschluss an die Federation Services erfolgen, zum Beispiel zu den Data Contracting und Data Monitoring Services.


Frage: Was passiert, wenn zwei Föderationen zwei verschiedene SSI Stacks nutzen? Wie wird Interoperabilität gewährleitstet?

Antwort: Wir versuchen das Interop Profile 2.0 umzusetzen, damit eine Interoperabilität zwischen den SDKs (Software Development Kits) weitgehend hergestellt wird. Dennoch ist der Standard und die Interpretation noch nicht ausgereift und damit erwarten wir am Anfang (Phase1) auch Probleme. Das Thema sicherstellen der Interoperabilität wollen wir in einer nächsten Phase bearbeiten. Aktuell werden aber schon weitere Frameworks aus dem Projekt „Schaufenster Digitale Identitäten“ in die Abstimmung miteinbezogen.  

Arbeitspaket 2: Föderierter Katalog

Frage: Wird es Client-Libraries geben, wenn die Implementierung abgeschlossen ist?

Antwort: Alle GXFS-Spezifikationen finden Sie unter: https://www.gxfs.eu/de/spezifikationen/. Die folgenden technischen Spezifikationen wurden im Frühjahr 2021 erstellt und in einer EU-weiten Ausschreibung vergeben.

Den Code der auf Basis der Spezifikationen entwickelt wird finden Sie hier: https://gitlab.com/gaia-x/data-infrastructure-federation-services.


Frage: Der aktuelle Entwurf des Gaia-X-Architekturdokuments enthält die folgende Aussage: „Jedem Ökosystem steht es frei, diese funktionalen Anforderungen so umzusetzen, wie sie es für richtig halten.“ Müssen bestimmte Bereiche der Gaia-X funktionellen Anforderungen gar nicht implementiert werden müssen, wenn sie nicht benötigt werden (z.B. Vertragsverhandlung, Protokollierung von Transaktionen)? Oder bedeutet die Aussage im Architekturdokument eher, dass diese Funktionen bereitgestellt werden müssen, aber jede Community frei entscheiden kann, wie diese Implementierung erfolgt? Gibt es außerdem eine Beschreibung von Mindestanforderungen, die sowohl aus technischer als auch aus organisatorischer/rechtlicher (z.B. DSGVO) Sicht notwendig sind, um einen Dienst als Gaia-X-konform zu bezeichnen?

Antwort: Die Definition von Verbunddiensten wird hier erfasst: https://gitlab.com/gaia-x/technical-committee/federation-services/federation-services-core/

Die GXFS-Projekte (www.gxfs.eu) liefern funktionale Referenzimplementierungen, die nicht als Gaia-X-konform verwendet werden müssen.

Antwort auf Frage 2: Dies wird inzwischen im Trust Framework (letzte offizielle Veröffentlichung, letzter Arbeitsentwurf) erläutert.


Frage: Ist es möglich, die Einhaltung der Gaia-X Labelling Criteria unter Berücksichtigung relevanter Normen und Standards (z.B. DSGVO, relevante Verhaltenskodizes, etc.) zu erreichen und dies durch die Selbstbeschreibungen der Dienste nachzuweisen? Würde dies bereits eine Mindestanforderung erfüllen, um einen Dienst als Gaia-X-konform zu bezeichnen? Oder sind weitere Anforderungen zu beachten, wie z.B. die Nutzung bestimmter Verbandsdienste?

Antwort: Die Compliance-Anforderungen werden noch diskutiert. Vorerst ist das Gaia-X Trustframework der relevante technische Dienst für die Ausrichtung. Bitte folgen Sie: https://gaia-x.gitlab.io/policy-rules-committee/trust-framework/


Frage: Ist das Attributvokabular bereits fest oder öffentlich verfügbar?

Antwort: Es ist über das Trust Framework öffentlich zugänglich (neueste offizielle Veröffentlichung, neuester Arbeitsentwurf). Das frühere 21.12-Architekturdokument hatte jedoch zusätzliche Attribute angegeben, die im Juli 2022 ihren Weg zurück in das Trust Framework finden werden.


Frage: Ist das Datenmodell eine vollständige Ontologie?

Antwort: Ein vollständiger Durchlauf von der Selbstbeschreibung bis zum überprüfbaren Berechtigungsnachweis finden Sie hier: https://gitlab.com/groups/gaia-x/lab/-/wikis/Quick-Guide-CLI-Credential-Creation-and- Verifikation (WIP)

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

Beginnt mit dem SD-Erstellungsassistenten zum Erstellen von SDs als JSON-LD aus SHACL-Shapes , die derzeit bei https://gaia-x.fit.fraunhofer.de/ gehostet werden. Diese Funktion wird bald bei GXFS gehostet.

Um dies einmalig für sich selbst zu erstellen, können Sie dies direkt selbst für einen Teilnehmerausweis inkl. Validierung tun. https://onboarding-portal.lab.gaia-x.eu/. Eine Schritt-für-Schritt-Anleitung finden Sie hier: 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


Frage: Sind die SHACL-Formen ein zusätzliche Komponente? Sie scheinen in VCDM 1.1 nicht referenziert zu sein.

Antwort: Das VCDM (Vector Calibration Data Management) definiert, dass sich die Ansprüche im RDF-Datenmodell befinden (im VCDM wird dies als „credentialSubject“ bezeichnet). SHACL kann verwendet werden, ist aber nicht erforderlich, um die Struktur von RDF-Diagrammen anhand eines Schemas zu validieren.

Der SD-Assistent verwendet dies als Grundlage, was eine sehr gute Grundlage für die Schemas ist (wie hier gerade erwähnt).

Diese werden im Rahmen des Compliance Service in Validierungsrichtlinien überführt. Dadurch können die Beschreibungen automatisch überprüft werden. Dies ist die Basis für eine erfolgreiche Skalierung des Trust Frameworks. Der Assistent enthält bereits eine große Anzahl von Beispielen, die Sie direkt ausprobieren können.  https://gaia- x.fit.fraunhofer.de/


Frage: Kann eine Signatur für eine kundenspezifische Änderung wiederverwendet werden?

Antwort: Das Attributvokabular wurde bereits im Gaia-X Architecture Document 21.12 spezifiziert und auf https://w3id.org/gaia-x/core/ veröffentlicht.  Die neueren Entwicklungen rund um das Trust Framework (neueste offizielle Veröffentlichung, jüngster Arbeitsentwurf) haben jedoch neue Bewegung gebracht. Eine erste Zusammenführung der bisherigen Attribute mit dem Trust Framework wird im Mai veröffentlicht, deckt aber noch nicht den vollen Umfang ab.


Frage: Gibt es Beispiele für SHACL-Formen, mit denen man den Fraunhofer Assistent ausprobieren kann?

Antwort: Der Assistent enthält bereits eine große Anzahl von Beispielen, die Sie direkt ausprobieren können.  https://gaia-x.fit.fraunhofer.de/

SHACL-Formen sind keine ontologischen Modelle. Sie dienen einem anderen Zweck. Ontologien beschreiben Konzepte und helfen bei der Ableitung von zusätzlichem Wissen. Erstens folgen die W3C-Ontologiesprachen der Open World Assumption und zweitens folgt SHACL der Closed World Assumption. Wenn in einer Selbstbeschreibung ein Attribut fehlt, handelt es sich um einen Fehler in der Formvalidierung (und so sollte es auch sein!). Aus Sicht der Ontologie könnte das Attribut an anderer Stelle im WWW definiert werden, wenn nicht in der vorliegenden JSON-LD-Datei (aber diese extrem dezentrale Ansicht ist nicht kompatibel mit dem vertrauensbildenden Ansatz von Gaia-X).


Frage: Wie stabil sind die Definitionen der Systeme derzeit (obligatorische Attribute usw.)?

Antwort: Sie sind noch nicht stabil. Die Selbstbeschreibungsschemata (d.h. für die Ansprüche innerhalb des VC/VP) haben eine solide ontologische Grundlage, welche sehr leicht in ihrem Ansatz ist (RDFS plus ein wenig OWL). Bisher lag der Fokus eher darauf, Konzepte/Attribute zu identifizieren, die aus Gaia-X-Sicht benötigt werden. Die zugrundeliegende Ausrichtung an bestehende Ontologien wie DCAT befindet sich noch in einem frühen Stadium, ist aber sehr wichtig, damit wir die bestehenden Standards einhalten.


Frage: Werden auch asynchrone Dienste beschrieben?

Antwort: https://www.asyncapi.com/

Gaia-X ist diesbezüglich neutral. Selbst für die tiefen Details synchroner APIs ist es nicht beabsichtigt, dass die Gaia-X Self-Description Schemas ihren eigenen Standard erstellen, sondern es wird auf bestehende OpenAPI-Beschreibungen verwiesen. (Es gibt ein Attribut für diese Referenz.) Darüber hinaus wird im Falle eines Gaia-X Data Service in „Gaia-X-Sprache“ nur wenig darüber gesprochen, wie die Daten aussehen (z. B. welchem Format / Standard sie entsprechen), die vom Dienst „offengelegt“ werden.

Die Gaia-X WG Service Characteristics befassen sich mit dem statischen Anspruchsteil der Selbstbeschreibungsschemas und unterstützen Spezifikations- und Tooling-Aufgaben innerhalb von GXFS-DE. Im Zuge dessen entstand der oben erwähnte Creation Wizard, der sich derzeit noch in https://gaia-x.fit.fraunhofer.de/ befindet, aber demnächst über https://gxfs.eu erreichbar sein wird.


Frage: Wie sieht es mit der Zusammenarbeit mit dem Eclipse Dataspace Connector aus?

Antwort: Informationen zum Eclipse Dataspace Connector (in dessen Kontext sicherlich eine teilweise „Client-Library“ für den Föderierten Katalog erstellt wird) finden Sie hier: https://github.com/eclipse- dataspaceconnector und hier https:// www.youtube.com/channel/UCYmjEHtMSzycheBB4AeITHg.  Erste Schritte, noch nicht in Richtung Katalog, sondern in Richtung Trust Framework, wurden beim Gaia-X Hackathon #4 im Juni 2022 unternommen.

Im Allgemeinen fällt eine bestimmte Datenkonnektorimplementierung nicht in den Geltungsbereich des konzeptionellen Kernmodells von Gaia-X, da es sich wie andere um eine Dienstkomponente handelt und nicht Teil des Föderationskonzepts ist. Grundlage hierfür ist ein Entscheid des Gaia-X Board of Directors:

Allgemeine Erklärung zu Datenkonnektoren

  • Der Datenaustausch ist für Gaia-X-Spezifikationen vorgesehen.
  • Data Connector-Produkte liegen außerhalb des Anwendungsbereichs der Gaia-X-Spezifikationen.
  • Data Connector-Dienste sind für das Gaia-X Trust Framework/Compliance vorgesehen.

Arbeitspaket 3: Souveräner Datenaustausch

Frage: Wie wird es technisch laufen, wenn Daten im System eines Konsumenten gelandet und verarbeitet worden sind, sie von dort wieder zu entfernen, wenn die Erlaubnis zur Nutzung und Verarbeitung dieser Daten entzogen wird? Ist diese Vorstellung realistisch?

Antwort: Hier kann es helfen die Daten nicht herauszugeben und die Verarbeitung nur unter Kontrolle des „Data Owners“ zu erlauben. Compute-to-Data Ansätze ermöglichen hier die technische Datensouveränität. Für bekannte Parteien mit sehr hohem Vertrauen können Verträge eine Verpflichtung erzeugen (aber nicht die technische Durchsetzung garantieren). Es gibt aber auch Konzepte und Technologien, um Nutzungsbedingungen auf Datennutzerseite zu erzwingen. Der technische Aufwand steigt aber damit an.  


Frage: Wie wird das Datenparadoxon aufgelöst? Wie kann ich beispielsweise sichergehen, dass jemand der meine Daten temporär in seinem Besitz hat, davon keine Kopie erstellt?

Antwort: Hier geht es um individuelle Risikoabwägungen und Impact Assessments die dann zu Entscheidungen in Bezug auf die Anwendungsfälle und Anforderungen (z.B. Schutz geistigen Eigentums, DSGVO Compliance usw.) führen. Der Vertragsdienst im Arbeitspaket 3 bietet hier eine Grundlage für Vertrauen auf Organisationsebene bei der Abwicklung und ermöglicht so auch einen Haftungsanspruch für den Datengeber.

Des Weiteren gibt es auch kostenpflichtige Cloud Service Lösungen, die umfangreiches Datenmanagement ermöglichen. Solche Lösungen sind sehr kostspielig und müssen im Kontext zum Aufwand und der Sensibilität der Daten gesetzt werden, sie können aber z.B. verhindern, dass Daten abgegriffen werden und sie können auch Zugang zu Daten via Online Tools verhindern.

Grundsätzlich gilt, dass immer geprüft werden muss, welche Nutzungsbedingungen für die Daten wichtig und relevant sind und ob diese beim Datennutzer auch umgesetzt werden können.


Frage: Inwiefern regelt ein Data Delivery Contract (DDC) auch finanzielle Stellgrößen wie z.B. den monetären Wert der Daten und oder auch Zahlungsbedingungen?

Antwort: In vielen Fällen ist anzunehmen, dass zukünftige Implementierungen auch diese Themen abdecken, von Prepaid bis Postpaid ist hier prinzipiell alles möglich, je nach Präferenz der Akteure. Aber auch kostenfreie Bereitstellung beispielsweise im Forschungskontext ist möglich und wichtig.


Frage: Wie ist das Technology Readiness Level zu bewerten? Entwickelt Gaia-X hier eine Technologie, die zum Ende des Jahres operativ einsetzbar ist oder geht es noch um angewandte Forschung und eine Perspektive für weit nach 2025?

Antwort: Die Planungen beziehen sich auf den Zeitraum 2022/2023, wesentlich längere Verzögerungen sind nicht vorhergesehen.


Frage: Beinhalten die Föderationsdienste im Bereich Datenaustausch auch Client-Libraries und Beispiele, oder nur den Server?

Antwort: Die Föderationsdienste entwickeln keine Clients für die Provider und Consumer, sondern im Wesentlichen die benötigten APIs und Services. Clients werden in anderen Projekten aber durchaus als Open Source Software entwickelt.


Frage: Wie lange kann eine Verhandlung von Verträgen dauern? Gibt es einen Maximalzeitraum?

Antwort: Es gibt keine Maximaldauer für Vertragsverhandlung.


Frage: Wie ist die Verbindung zum Eclipse Dataspace Connector (EDC)?

Antwort: Der Eclipse Data Space Connector kann Data Delivery Contracts mit anderen Datenkonnektoren auch ohne den Data Contract Service (DCS) aushandeln. Das gleiche trifft auch für den Data Exchange Logging Service (DELS) zu. Durch den modularen Aufbau sind auch andere Logging Services nutzbar. Der DCS ermöglicht aber auch die Vertragsaushandlung zwischen einer Partei, die den EDC nutzt und eine Partei ohne Datenkonnektor. Generell sind GXFS Connector agnostisch und stellen APIs zur Nutzung als Referenzimplementierungen für Contracting und Logging zur Verfügung.


Frage: Was für Technologien für Identitätsmanagement werden unterstützt? SSI?

Antwort: Der Data Contract Service (DCS) und der Data Exchange Logging Service (DELS) nutzen die Konzepte und Techologien von Arbeitspaket 1 Identität und Vertrauen.This includes SSI, Verifiable Credentials, X.509 Zertifikate für die Verknüpfung zu eIDAS. Die wesentlichen Standards sind unter anderem DIDComm, OpenID (for VCs), DIDs etc.

Prototypisch implementiert findet sich das Trust Framework im Gaia-X Lab Onboarding Portal, welches die Ausstellung und Verifizierung eines Gaia-X Participant Credentials ermöglicht. Das macht das Konzept erlebbar. https://onboarding-portal.lab.gaia-x.eu/ (Nutzt DID:WEB, OIDC4VP, SIOPv2).

Sehen Sie bitte auch die FAQ Seite für Arbeitspaket 1 für weiterführende Informationen zu dieser Thematik.


Frage: Wird technisch sichergestellt, dass die Log-Nachrichten korrekt sind, oder ist das ein juristisches Thema? Wenn zum Beispiel ein Daten Nutzer meldet, dass er die Daten gelöscht hat, obwohl er die Daten weiterhin vorhält?

Antwort: Die Sicherstellung der Korrektheit von Logging Nachrichten lässt sich durch unterschiedliche Maßnahmen erreichen. Hier sind organisatorische und juristische Mittel die einfachste Möglichkeit. Eine technische Validierung ist möglich, aber zum einen mit größerem Aufwand verbunden und zum anderen nicht im Fokus von GXFS.


Frage: Ist eine Unterstützung von Data Contract Service (DCS) und Data Exchange Logging Service (DELS) für Gaia-X Compliance zwingend notwendig?

Antwort: Nein.


Frage: Wenn der Data Contracting Service (DCS) auch dezentral im Connector implementiert ist, wie einigt man sich dann auf den Logging Service?

Antwort: Der Logging Service kann im Vertrag spezifiziert werden und kann damit Bestandteil der Verhandlung sein. Eine Federation kann diesen aber auch vorgeben.


Frage: Sind die Contracts des im Eclipse Dataspace Connector (EDC) integrierten Services identisch oder zumindest kompatibel zum Gaia-X Format?

Antwort: Der Eclipse Dataspace Connector (EDC) ist aktuell in einer Entwicklungsversion mit geplantem Release im Juni 2022. Sobald dieser Release des EDC verfügbar ist, können Kompatibilitätsthemen geprüft werden. Bis dahin kann man diese Einschätzung schlecht treffen, da noch nichts finales verfügbar ist. Die verwendeten Sprachen und Strukturen sind gleich, aber auch kleine Unterschiede können große Auswirkungen auf Kompatibilität haben, weshalb eine genauere Prüfung notwendig ist. Dennoch ist es das Ziel der Projekte sich hier auf einen gemeinsamen Stand zu einigen.


Frage: Wer beschäftigt sich mit der Integration von Data Contracting Service (DCS), Data Exchange Logging Service (DELS) und expliziten Data-Exchange-Services (e.g. WebAPIs usw.)?

Antwort: Die Umsetzung der ersten Version findet durch Auftragnehmer statt. Die Ergebnisse sind Open Source unter Apache License 2.


Frage: Wo werden die Technologien angewandt, in Piloten oder Kooperationen wie dem Mobility Data Space (MDS)?

Antwort: Die Technologien und Konzepte werden bereits in vielen Piloten angewandt und genutzt. Darunter sind auch sehr reife Projekte, wie der Mobility Data Space oder das Smart Connected Suppliers Network.


Frage: Wie ist aktuell IDS und Gaia-X zu betrachten? Kompatibel, komplementär?

Antwort: Die Entwicklungen sind eher komplementär, auch wenn es hier einige Überschneidungen gibt. Der Fokus von IDS ist der Datenkonnektor, während Gaia-X eine Soft Data Infrastructure im Fokus hat. Bei den Querschnittsthemen gibt es Aktivitäten, um einen gemeinsamen Standpunkt zu erreichen, z.B. in der Diskussion um die Nutzung von Rego oder ODRL für Usage Policies von Datenservices


Frage: Sind durch einen Federator bestimmte Aufgaben einfacher umzusetzen? Analog dem Beispiel jemand betreibt den Logging Service den Consumer und Provider nutzen?

Antwort: Der Federator kann bestimmte Aufgaben in einer Federation übernehmen und macht das Zusammenarbeiten in der Federation somit wesentlich einfacher. Der Federator erfüllt somit eine wichtige Funktion für die Gesamtfunktionalität der Federation. Die Entlohnung eines Federators hängt maßgeblich vom Business Case einer Federation ab. Skalierungseffekte und Kosteneinsparungen sowie neue Geschäftspotenziale der einzelnen Teilnehmer sollten hier natürlich berücksichtigt werden.


Frage: Existieren Smart Contracts (z.B. solidity) für GXFS, tracing über eine Distributed Ledger Technology (DLT) würde generell Sinn ergeben, oder?

Antwort: Nein, es gibt noch keine vorgefertigten Smart Contracts aus dem GXFS Projekt. Aber es gibt Arbeiten, auch im Rahmen der Minimal Viable Gaia Gruppe in diese Richtung. Die Nutzung von DLT ist generell denkbar in diesem Kontext, aber nicht die einzige Technologie.  


Frage: Welche Art von Policy soll ein Federator einhalten, der am Ende auch Daten (Log) sammelt?

Antwort: Wie ein Ökosystem aufgebaut wird und welche Policies zugrundeliegen, muss in den einzelnen Federations festgelegt werden. Hier gibt es keine one-size-fits-all Antwort.

Arbeitspaket 4: Regelkonformität

Frage: Wer stellt das User Interface (UI) für die Compliance Dienste bereit?

Antwort: Es gibt hier keinen zentralen, one-size-fits-all Ansatz. Stattdessen wird jede Föderation selbst ihr User Interface entwickeln.


Frage: Wer betreibt die Prozesse in der Registry und beim Onboarding? Wer betreibt die Prozesse, wenn es zum Beispiel an Updates geht?

Antwort: Auf Dauer ist eine vollständige Dezentralisierung vorgesehen über die Föderationen. Föderationen sind bestplatziert, um diese Prozesse zu koordinieren, da sie die besten Einblicke über Ziele, Grundvoraussetzungen und sonstige Rahmenbedingungen, die in ihrem Ökosystem relevant sind, haben. Ein erster Anstoß erfolgt aber zunächst über die Gaia-X Association.


Frage: Gibt es sowas wie einen Beirat für Neuerungen am Compliance Framework, insbesondere auch zur Klärung von etwaigen Streitpunkten?

Antwort: Die relevanten Dokumente, die das Compliance Framework bilden, sind das Gaia-X Policy Rules Dokument, das Gaia-X Trust Framework und das Gaia-X Labelling Dokument. Alle drei Dokumenten werden von der Gaia-X Association weiterentwickelt. Änderungen obliegen dem Gaia-X Association Board of Directors.


Frage: Wie genau fließen die Labels in den Compliance Prozess ein? Wie werden sie angewandt?

Antwort: Die Labels sind optional und keine Voraussetzung zur Teilnahme in einer Föderation. Im Rahmen der Selbstbeschreibungen können Informationen zu Labels angegeben werden. Labels müssten gesondert bei der Gaia-X Association oder einer anderen Stelle beantragt werden. Es kann sein, dass weitere Nachweise erbracht werden müssen, um ein Gaia-X Label zu erhalten. Das Label ist ein zusätzlicher Schritt, der über die pure Gaia-X Compliance hinausgeht.


Frage: Was bringt einem Service Anbieter ein Gaia-X Label?

Antwort: Ein Label ist ein Differenzierungskriterium. Dadurch können Anbieter beispielsweise einem potenziellen Kunden gegenüber nachweisen, dass ihre Dienste auf besondere Weise auditiert und geprüft sind. Ein Label kann so beispielsweise im Bereich Risk Assessment Orientierung und Transparenz für Kunden bieten.


Frage: Ist auch eine Bewertungsoption für Services geplant? Zur „Sicherstellung“ u.a. von Daten- und Servicequalität? Wenn ja, wie würde dann deren Korrektheit sichergestellt?

Antwort: Ein Feedbacksystem ist eine interessante Idee, ist so aber nicht im Rahmen des Onboarding und Accreditation Workflows vorgesehen.


Frage: Mit welchen indirekten Kosten ist die Erreichung eines Gaia-X Labels Level 3 für Unternehmen verbunden?

Antwort: Das lässt sich pauschal nicht sagen und hängt von der Ausganslage eines Anbieters ab. Wenn schon relevante Testate existieren (bspw. C5, Unterzeichnung eines GDPR Code of Conduct, Portabilität sichergestellt wurde etc.) sollte der Aufwand überschaubar sein. Das Gaia-X Level 3 sollte aber ein wirkliches Ausnahmelabel sein (z.B. zur Anwendung im Bereich kritischer Infrastrukturen), das Label Level 2 sollte 98% der strengen Anforderungen abdecken.


Frage: Wie wird das Vertrauen in den Notarisation Service sichergestellt?

Antwort: Der Betrieb erfolgt durch akkreditierte Trust Anchors. Zudem wird eine dezentrale Überprüfbarkeit auf Basis der kryptographischen Methoden zur Prüfung der Attestate (Verifiable Credentials, etc.) gesichert.


Frage: Sind im Portal auch Graphen und Auswertungen zu Performance Kennzahlen des Continuous Automated Monitoring (CAM) zu erwarten?

Antwort: Ja, Graphen und Auswertungen können in einem Dashboard verfügbar gemacht werden.


Frage: Sind bestimmte Erfüllungen über das Assessment in der öffentlichen Beschreibung gespiegelt und ist für den Nutzer erkennbar, welche Requirements vom Service erfüllt werden (und ob entsprechende Nachweise vorliegen)?

Antwort: Ja, das ist auf jeden Fall möglich, auch wenn jede Federation natürlich entscheiden kann, welche Infos im Katalog sichtbar sind.

Arbeitspaket 5: Portal

Frage: Muss ich meine Identität angeben, um den Katalog und das Portal einer Föderation anzusehen?

Antwort: Föderationen entscheiden selbst, ob ihr Katalog öffentlich zugänglich ist oder nicht. Es kann sein, dass Teile des Katalogs öffentlich zugänglich sind und andere Teile erst nach Registrierung und Verifizierung zu erreichen sind. Ein öffentlich zugänglicher Katalog für alle Föderationen kann als Zusatz zu den einzelnen Föderationskatalogen mit einbezogen werden. Aktuell ist dies in Klärung der Gaia-X Association, ob und wer einen solchen Katalog operationalisiert.  


Frage: Wo gibt es Vorlagen für die Selbstbeschreibungen zu finden? Kann man diese auch aus dem Katalog herunterladen?

Antwort: Die Arbeitsgruppe Service Lifecycle hat Beispiele für die Selbstbeschreibung in einem Gitlab Repository bereitgestellt. Berechtigung ist notwendig, um auf die Inhalte zuzugreifen, und kann über die WP Leiter C. Lange-Bever und A. Strunk angefordert werden.


Frage: Welche Ontologien für Selbstbeschreibungen können verwendet werden?

Antwort: Die jeweils aktuelle Version der Ontologie ist veröffentlicht unter https://w3id.org/gaia-x/core, jetzt auf Stand Trust Framework 22.04. Die Ontologie definiert Klassen und Attribute, schränkt aber deren Verwendung nur schwach ein. Was der creation wizzard unter https://gaia-x.fit.fraunhofer.de/ (demnächst offiziell über gxfs.eu) zusätzlich leistet, ist eine SD gegen ein Schema zu validieren. Das ist eine Schwester der Ontologie, technisch gesprochen SHACL shapes, aber auch verlinkt von dieser w3id-Seite.


Frage: Wie wird der Zusammenhang zwischen natürlicher Person und ihrem Unternehmen hergestellt? Insbesondere wenn wir von der ersten Person, die ongeboardet wird, ausgehen?

Antwort: Erster Schritt wäre, sich bei der Föderation zu bewerben bzw. die Aufnahme in die Föderation zu beantragen. Die Person muss in diesem Zuge auch diverse Dokumente ausgefüllt haben. Im Portal geht der Onboarding Prozess dann mittels des Organisational Credential Managers (OCM) vonstatten. Dort prüft dann der Notarisierungsdienst, ob die Angaben der Person legitim sind und stellt der Person dann für seine oder ihre Organisation ein verifiable credential (VC) aus. Das VC ermöglicht dann einen Abgleich zwischen Unternehmen und Föderation. Detailiert ist dieser Prozess in der IDM Spezifikation, dem Arbeitspaket Identität und Vertrauen bzw. in der Onboarding Spezifikation des Arbeitspakets Compliance einsehbar.


Frage: Können Föderationen frei von mehreren Akteuren erzeugt werden oder ist die Gründung einer Föderation reglementiert?

Antwort: Es besteht keine Reglementierung als solche für die Gründung einer Föderation. Erst wenn sich eine Föderation Gaia-X anschließen möchte, besteht Prüfungsbedarf. Aktuell wird hierzu ein Dokument entwickelt, das Anforderungen definiert. Dieses Dokument ist noch in Arbeit.


Frage: Die Credentials und Selbstbeschreibungen der Dienstanbieter und der darunterliegenden Angebote (Composition) müssen ebenfalls verfügbar sein. Wie wird dies im Portal adressiert? Erfolgt dies durch dauerhaftes Zugriffsrecht auf die entsprechenden PCMs und OCMs oder Caches?

Antwort: Selbstbeschreibungen werden über das Trust-Framework der GAIA-X AISBL verifiziert.Credentials der Selbstbeschreibungen von Service Providern bzw. deren Selbstbeschreibungen von Services o.ä. werden mit abgerufen und können im Credential Manager (Wallet) hinterlegt werden. Das Portal greift aktuell auf die im Katalog referenzierten SDs zu. Die abzurufende SD bringt ein verifiziertes Credential der SD mit.


Frage: Ist es möglich, auch nur die Identifikations- und Credential-Komponente/API zu nutzen, zum Beispiel für eine eigene Anwendung, in der ich auch Unternehmen Zugang gewähren will?

Antwort: Ja, das ist möglich. Die zugehörigen Komponenten werden in den entsprechenden Arbeitspaketen (Lots) entwickelt und man kann auch nur einzelne Dienste als Open Source Source Code beziehen, anpassen und verwenden. Ein Bindung erfolgt über eine API der entsprechenden Komponenten.


Frage: Ist es auch möglich oder geplant technische User zu registrieren und zu verwalten damit nicht alles an einem Mitarbeiter hängen bleibt?

Antwort: Das wurde in Spezifikationsphase 1 nicht betrachtet, könnte aber in Spezifikationsphase 2 betrachtet werden. Technische User sind in Unternehmen häufig nicht gerne gesehen, weil oft nicht ganz klar ist, wer sich hinter einem technischen Nutzer verbirgt. Prinzipiell ist dies eine Vereinbarung zwischen Anbieter und Nutzer. Zum Beispiel, wenn ein Daten-Offering über einen Software-Dienst genutzt werden soll, so muss das anbietende Unternehmen entscheiden, welche Authentifizierung notwendig ist.


Frage: Welche SHACKL Forms sind für welchen Service Selbstbeschreibungen geeignet? Gibt es eine Beschreibung zu diesen Formularen und den einzelnen Feldern?

Antwort: Wir verweisen hier auf das Gaia-X Trust Framework, wo es eine Liste von Attributen gibt, die für die Beschreibung einer Organisation oder eines Dienstes notwendig sind. Des Weiteren arbeitet Fraunhofer an weiteren Ausarbeitungen der Selbstbeschreibungsvorlagen und wir planen diesbezüglich weitere Workshop Formate zur Ausarbeitung der Attribute und Vorlagen.


Frage: Wie wird beim Notarization Service Vertrauen hergestellt?

Antwort: Vertrauen wird über sogenannte Trust Anchors sichergestellt, die im Gaia-X Trust Framework erwähnt werden. Hier bitte für Details die jeweilige Spezifikation im Arbeitspaket Compliance anschauen.