********************** 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 :doc:`/getting-started/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: 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 :ref:`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 :ref:`Compliance Credential ` (issued by GAIA-X-Med and proving the authenticity of your claims). .. figure:: ../../guides/identity-store-files.png :alt: 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: https://www.w3.org/TR/did-core/ .. _becoming-a-participant-did-document-discoverability: 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 :doc:`/getting-started/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``. .. _did-web: https://w3c-ccg.github.io/did-method-web/ .. _becoming-a-participant-vc: Verifiable Credentials ---------------------- **Main article:** :doc:`/documentation/key-concepts/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 :ref:`DID Document`, so anyone with your DID URL can confirm the authenticity of your credentials. .. _vc: https://verifiablecredentials.dev/ .. _verifiable-presentations: 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 :ref:`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: 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. .. _trust-framework: https://docs.gaia-x.eu/policy-rules-committee/trust-framework/22.04/ .. _becoming-a-participant-trust-anchors: 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.