Becoming a Participant

In order to start consuming GAIA-X-Med services, you first need to become a compliant GAIA-X-Med Participant.

This document aims to explain the onboarding process in greater detail. If you wish to skip the long-winded explanation, feel free to go straight to the Participant Onboarding Guide.

Warning

To allow for more rapid development and evaluation cycles in the GAIA-X-Med research project, every certificate signing request from anyone is signed unconditionally through an automatic process, meaning that there is no controlling instance for a Participant making Claims about themselves.

In a production system, this process should be replaced/supplemented accordingly by a third party that checks a Participant’s Claims for truthfulness. This is essential for establishing trust between Participants.

The Concept of (Participant) Identities in GAIA-X-Med

Authentication inside the GAIA-X-Med ecosystem is based on the concept of decentralized or self-sovereign identities. In short, this means that there is no ecosystem- or federation-wide database of user accounts; instead, every Participant is responsible for creating, managing and storing their own credentials, which are later used to authenticate against the ecosystem (akin to an ID card).

Decentralized Identifier

As a Participant, your identity is realized through a Decentralized Identifier Document (or DID document), which contains your keypair’s public key (used to verify your signatures) as well as a link to your Verifiable Presentation, which in turn contains certain claims about yourself as a Participant relevant to GAIA-X-Med (such as name, address and contact details) as well as a Compliance Credential (issued by GAIA-X-Med and proving the authenticity of your claims).

Credential Store files

Files managed by the Credential Store.

During authentication, your DID document is accessed by the central Authentication Service, which means that it must be discoverable.

DID Document Discoverability

To be discoverable, a DID document has to be hosted at a publicly accessible location, which is specified through its unique DID identifier. Of the several methods for transporting DID documents offered by the DID specification, GAIA-X-Med has chosen the did:web method, which makes DID documents available through HTTPS web servers (and ensures trust through ownership of the domain). This means that your DID document has a unique corresponding DID URL, which in turn translates into a HTTPS URL where the DID document can be found.

A full did:web URL, consisting of method and identifier, could look like this: did:web:participant.com:johndoe

This translates into the corresponding HTTPS URL https://participant.com/johndoe/did.json, where your DID document is expected to be.

Note

For more information and examples regarding DID document path resolution, please refer to the did:web specification (in particular the section Read (Resolve)).

In practice, it follows that:

  • you need to host your DID document on a publicly accessible HTTP server,

  • the document needs to be hosted on the path the DID identifier resolves to, and

  • the usage of TLS (HTTPS) is mandatory.

We have created tools that help you to adhere to this naming and structure specification (the Credential Manager) and to help you upload and host your documents (the Identity Store). The Participant Onboarding Guide explains their usage.

Note

Your DID URL will become your unique GAIA-X-Med identifier (your “username”, if you will). So with the example above, your identity (or “username”) as seen by a GAIA-X-Med compatible Service would become did:web:participant.com:johndoe.

Verifiable Credentials

Main article: Verifiable Credentials

A Participant has to make certain claims about themselves (details such as full name and address), which are stored inside a Verifiable Credential (or VC for short). In essence, this is a self-signed document of a certain structure, expressing that you as a signer confirm the validity of the claims contained within. The signature is produced by the private key corresponding to the public key in your DID Document, so anyone with your DID URL can confirm the authenticity of your credentials.

Verifiable Presentations

One or more Verifiable Credentials can be bundled together inside a Verifiable Presentation (or VP for short), which essentially just acts as a container format. VPs can be signed in the same way as VCs; even if you’re not the issuer of the VCs. (This could be used to make a statement, for example, that you as the signer of the VP have acknowledged the VCs and their content.)

As a GAIA-X-Med Participant, your DID Document contains a link to the Verifiable Presentation containing your own Participant Verifiable Credential (more commonly also known as “Self-Description”) as well as one more Verifiable Credential: the GAIA-X-Med Compliance Credential.

GAIA-X-Med Compliance

In order to be a compliant GAIA-X-Med Participant, it is not enough to just offer your Participant credentials (or “Self-Description”) to another party since they are only self-signed – you could simply make up any claim about yourself.

There is one more step that is performed during onboarding, which is presenting your own self-signed credential to the GAIA-X-Med Compliance Service. The Compliance Service performs a few basic checks on your credentials:

  • whether the presented information is complete,

  • whether the presented information is in the correct format,

  • whether your DID document is resolvable and the signature of your Verifiable Credential(s) are valid,

  • whether the certificate(s) that were used to sign the Verifiable Credential(s) are resolvable to a Trust Anchor known to the Registry Service.

The last step in particular ensures that only certified legal persons known to the GAIA-X-Med ecosystem can issue trustworthy claims.

After your credentials pass the Compliance checks, you will receive a Compliance Credential signed by the Compliance Service. This credential is essentially a stamp of approval linked to your Verifiable Credential(s), confirming that their contents have been officially approved by the GAIA-X-Med ecosystem.

In practice, the Compliance Credential is yet another Verifiable Credential that you need to bundle together with your own credentials into a Verifiable Presentation and upload to your web server. A link to this Verifiable Presentation is included in your DID document to make the Presentation discoverable during the authentication process.

In implementing these steps, GAIA-X-Med largely follows the principles for identity and trust defined by the Gaia-X Trust Framework 22.04, where Participants and Service Offerings are considered to be “compliant” if they have valid credentials (or “Self-Description”) that are signed by a Trust Anchor, and only those with compliant credentials are allowed access to the ecosystem.

GAIA-X-Med Trust Anchors

In GAIA-X-Med, the Federator team (WP 110-130) serves a similar role to a Gaia-X Trust Anchor.

More concretely, we hold a certificate authority (CA) that is able to sign certificate signing requests (CSR) using the Certificate Service. Our instance of the Gaia-X Registry Service only recognizes certificates signed by our CA as valid; therefore, only Verifiable Credentials (“Self-Descriptions”) of either Participants or Service Offerings signed by a key that belongs to our certificate chain will be accepted by the Compliance Service as valid and can be used for identification in the GAIA-X-Med ecosystem.