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

Folgt in Kürze

Arbeitspaket 3: Souveräner Datenaustausch

Folgt in Kürze

Arbeitspaket 4: Regelkonformität

Folgt in Kürze

Arbeitspaket 5: Portal

Folgt in Kürze