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: 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

Coming soon

Work Package 3: Sovereign Data Exchange

Coming soon

Work Package 4: Compliance

Coming soon

Work Package 5: Portal

Coming soon