4. Gaia-X Trust Framework Architecture¶

4.1 Elements of a Trust Framework¶

A (generic) trust framework provides the methodology and technical specifications for collecting, organizing, and verifying information to support trust decisions - that is, decisions about whether an entity, piece of information, or transaction can be trusted.

The Gaia-X Trust Framework comprises the technical and organizational standards and open-source software for its operationalization, allowing the establishment of trust in digital ecosystems. It comprises two complementary elements:

• Specification of Gaia-X technical compatibility at the level of technical standards with an interoperable trust architecture, an open-source reference implementation (Reference Software Toolkit) and a corresponding compatibility test (Technical Compatibility Kit (TCK)) This specification includes blueprints for a digital ecosystem or data space authority to define its own governance framework and rulebook. (See DSSC v2.0: Data space governance framework/Data space rulebook)

• Specification of Gaia-X Compliance: A definition of particular criteria that ICT services, data exchange, and participants must fulfil and are evaluated by a Gaia-X Digital Clearing House (GXDCH), to be characterized as Gaia-X compliant to “Gaia-X Standard Compliance” and/or “Gaia-X Label”. This specification includes an extension mechanism (“Gaia-X compliance extensions”) to define additional Gaia-X Labels.

Figure 4.1 - The Gaia-X Trust Framework

Gaia-X Technical Compatibility, operated by trust service providers accepted by ecosystem Governance Authorities, can be used to implement ecosystem compliance rules.

Gaia-X Technical Compatibility is also an enabler for technical interoperability at the trust level across different ecosystems with different rule sets (e.g. European data rooms versus Asian trade corridors).

The Gaia-X Framework offers key advantages in the following areas:

Digital Ecosystems:

• Validates ecosystem compliance against established criteria.
• Verifies enabling and federation services meet ecosystem governance criteria, ensuring trust in these services.

Individual Participants:

• Supports self-determination in data and service usage by collecting and verifying credentials for compliance with ecosystem rules.
• Enables credential verification during participant negotiations.

Interoperability:

• Promotes agreement on common ontologies and Trust Anchors across ecosystems.

Extension and Delegation:

• Provides mechanisms for extending and delegating trust to enhance ecosystem flexibility.

4.2 Using the Trust Framework¶

The following sections describe some relevant applications of the Trust Framework.

4.2.1 Performing automated onboarding and offboarding¶

The implementation of the Trust Framework enables the automated onboarding of participants into an ecosystem or data space.

The governance authority of the ecosystem or data space defines policy rules and conformity schemes, which are translated into a digital format. This digital representation allows for validation and verification against the conformity scheme/s of the ecosystem/data space using the digital clearing house components, as described in detail in the “Gaia-X Technical Compatibility Specifications” section. Ecosystems can decide to rely, for the validation of attributes, on services provided by external trusted sources.

Successful verification of compliance with the ecosystem or data space conformity criteria results in the issuance of a membership credential, which authorizes participants to operate within the ecosystem or data space.

The same mechanism can be employed to identify participants who no longer meet compliance requirements and to initiate automated offboarding procedures.

4.2.2 Performing credential verification¶

Credential verification is executed by the Compliance Engine in conjunction with the Registry.

The ecosystem or data space defines credential schemas that specify the vocabulary for expressing claims about credential subjects. These schemas are represented as SHACL shapes, in accordance with the W3C Shapes Constraint Language (SHACL).

Credential schemas are published and maintained in the Registry to ensure consistent access and reuse.

At any point where Verifiable Credentials are issued or processed, the applicable SHACL shapes are known and constitute the shapes graph. Each Verifiable Credential constitutes a data graph. Verification is performed by validating the data graph against the shapes graph, as defined by the SHACL specification.

4.2.3 Identifying Ecosystem trust services¶

The discoverability of Ecosystem Trust Services can be enhanced using a catalogue of trustworthy registries following the Gaia-X technical compatibility specifications.

By easing the identification of ecosystem trust services, federation and creation of trust across ecosystems are supported.

Examples of ecosystem trust services are Credential stores, Auditing and Observability services, Marketplaces, Authorisation and Access services, together with standard services provided by Identity and Catalogue Providers.

4.3 GXDCH¶

The Gaia-X Digital Clearing House (GXDGH) is the mechanism adopted by the Gaia-X Association to provide running software to assert compliance without becoming a host or a point of centralisation for the ecosystem.

Each GXDCH instance must be operated by a service provider according to rules defined and approved by the Gaia-X Association.
The instances are non-exclusive, interchangeable, and operated by multiple market operators from different geographical locations and different industries. Such providers then have the role of Federator. The Gaia-X Association is not a Federator itself.

The GXDCHs are connected in a network to ensure free access and selection by Gaia-X adopters and consistency of the compliance data managed by these nodes.

Each GXDCH must provide public services to implement the compulsory elements necessary to achieve Gaia-X compliance, under the sole governance of the Gaia-X Association. Furthermore, each GXDCH can offer (or resell) services to support the extended adoption of Gaia-X (out of the governance of the Gaia-X Association).

The mandatory components to be included in the GXDCH can vary from one release to another, as more services become available with time. The updated list of components is available here.

All the components that go in the GXDCH are open-source, either reused or developed by the Gaia-X Association.

The following page displays for each Gaia-X Digital Clearing House the status of each of the components as well as whether it is UP or DOWN.

4.4 Gaia-X Conceptual Model¶

4.4.1 Terminology sources¶

The terminology employed in this section is informed by various sources, including the following recognised standards:

ISO/IEC 17000:2020 – Conformity Assessment — Vocabulary and General Principles This international standard, developed by the ISO Committee on Conformity Assessment (CASCO), provides standardized definitions and general principles related to conformity assessment activities, including the accreditation of conformity assessment bodies.

Verifiable Credentials Data Model v2.0 – World Wide Web Consortium (W3C) This specification defines a data model for expressing verifiable credentials on the Web in a cryptographically secure, privacy-respecting, and machine-verifiable manner. It outlines key concepts such as credentials, presentations, and associated roles like issuers, holders, and verifiers, facilitating interoperability and trust in digital credential ecosystems.

4.4.2 Definitions¶

Entity: item relevant for the purpose of operation of a domain that has recognisably distinct existence (source: ISO/IEC 24760-1:2019)

Participant: entity which is onboarded and has a Gaia-X Participant Credential. A Participant can take on one or more of the following roles: Provider, Consumer, and Operator.

Provider: a Provider operates Resources in the Gaia-X Ecosystem and offers them as services through Gaia-X Service Offering credentials. For any such service, the Gaia-X Provider defines the Service Offering, including terms and conditions as well as technical policies. Furthermore, it provides the Service Instance that includes a Credential and associated policies. A Gaia-X Provider is responsible for conformity to the claims made. If third-party data, services or infrastructure are part of the service offerings, the Gaia-X Provider can make those resources available (e.g., through Service Composition) but remains responsible and shall ensure coverage through appropriate back-to-back coverage.

Trusted Service Operator (TSO): Trusted Service Operators (TSO) are Gaia-X Providers that have been approved by the ecosystem governance authority to authoritatively provide one or more services to the ecosystem. There can be one or more Trusted Service Operators for a given type of service, e.g., a catalogue service. In that sense, other ecosystem Participants will trust this operator for this designated set of services.

WARNING: Do not mix Trusted Service Operators with Trust Service Providers (TSP): The first one (TSO) provides services you can trust, the last one (TSP) provides core elements of trust (in the form of verifiable credentials) for the ecosystem, e.g., identity or compliance credentials. See the Model Core later in this section.

Consumer: A Consumer is a Participant who searches Service Offerings and consumes Service Instances in the Gaia-X Ecosystem to enable digital offerings for End-Users.

Governance Authority: an ecosystem or data space Governance Authority (GA) is the body of a particular data space or ecosystem, consisting of participants, that is committed to the governance framework for the data space or ecosystem, and is responsible for developing, maintaining, operating and enforcing the governance framework (source: DSSC Glossary)

Conformity assessment: demonstration that specified requirements are fulfilled (source: ISO/IEC 17000:2020)

Object of conformity assessment: entity to which specified requirements apply (source ISO/IEC 17000:2020)

A Conformity Assessment Scheme is a set of rules and procedures that describes the objects of conformity assessment, identifies the specified requirements and provides the methodology for performing conformity assessment (source ISO/IEC 17000:2020)

Attestation: issue of a statement, based on a decision that fulfilment of specified requirements (5.1) has been demonstrated (source ISO/IEC 17000:2020)

Declaration: first-party attestation (source:ISO/IEC 17000:2020)

Certification: third-party attestation related to an object of conformity assessment, with the exception of accreditation (source ISO/IEC 17000:2020)

Accreditation: third-party attestation related to a conformity assessment body, conveying formal demonstration of its competence, impartiality and consistent operation in performing specific conformity assessment activities (source ISO/IEC 17000:2020)

Validation: confirmation of plausibility for a specific intended use or application through the provision of objective evidence that specified requirements have been fulfilled (source ISO/IEC 17000:2020)

Verification: confirmation of truthfulness through the provision of objective evidence that specified requirements have been fulfilled (source ISO/IEC 17000:2020

Conformity Assessment Body (CAB): a Conformity Assessment Body (CAB) is a body that performs conformity assessment activities, excluding accreditation. Source: ISO/IEC 17000:2020.

Trust Service Provider (TSP): a Trust Service Provider is an entity (need not be a Participant!) approved by the Governance Authority to authoritatively issue verifiable credentials for a given scope and purpose

• is itself identified by a Trusted Digital Identity
• issues (verifiable) credentials/certificates
• some TSPs act as Trusted Identity Providers and issue digital identities in this capacity
• in case a Conformity Assessment Body (CAB) is capable of issuing verifiable credentials for a given scope and purpose, it also qualifies as a TSP
• TSP may use validation by code

Notary: Notaries are entities (need not be a Participant!) approved by the Governance Authority, which perform validation based on objective evidence from Trusted Data Sources, digitalizing an assessment previously made. The Notaries are converting “non machine-readable” proofs into “machine-readable” proofs, i.e., verifiable credentials.

DUA Notary: A Data Usage Agreement (DUA) Notary is a specialization of a Notary validating the existence of a legally binding (e.g., signed by both parties, not revoked) Data Usage Agreement (DUA) between a Data Producer and a Data Consumer.

Data Producers have to submit a DUA to a DUA Notary; Data Consumers then may (or, if an ecosystem Governance Authority mandates it, have to) check with the respective DUA Notary before a data access whether the DUA is still valid. See Chapter 5 for more details.

Issuer: a role an entity can perform by asserting claims about one or more subjects, creating a verifiable credential from these claims, and transmitting the verifiable credential to a holder. (source W3C, Verifiable Credentials Data Model v2.0)

A Conformity Assessment Scheme is a set of rules and procedures that describes the objects of conformity assessment, identifies the specified requirements and provides the methodology for performing conformity assessment (source ISO/IEC 17000:2020)

The Conformity Assessment Scheme generates Label/Criteria based on the following conformity rules:

• List of permissible standards
• Technically verifiable attributes (e.g., GLEIF)
• Rulesets

A Label is a machine-readable, structured and signed document issued by the ecosystem-accredited Compliance services in case of a valid verification and validation of the criteria for a specific assessment scheme (source: generalisation from the Gaia-X Compliance Document).

Note: the criteria for Gaia-X Labels are defined in the Gaia-X Compliance Document.

Label A label collects a set of criteria.

Label / Criterion is validated by the following validation methods:

• Self-declaration
• Validation by code
• Conformity Assessment Body
• Existing credential/certificate

Evidence can be included by an issuer to provide the verifier with additional supporting information in a verifiable credential. This could be used by the verifier to establish the confidence with which it relies on the claims in the verifiable credential. It is expected that the credentials issued by the notaries contain the evidence of the validation process. (source: W3C Verifiable Credentials Data Model v2.0)

A Trusted Data Source is a source of the information used by the issuer to validate attestations. Notaries perform validations and issue attestations based on objective evidences from Trusted Data sources. The accepted Trusted Data Source categories and Notaries are determined within the Gaia-X Compliance document, while the detailed list of valid Trusted Data Sources and Notaries resides in the Gaia-X Registry.

Note: the full list of the most relevant terms used in the Gaia-X deliverables is available in the Gaia-X Glossary. For terms defined within it, the Gaia-X Architecture Document remains the authoritative source. The Gaia-X Glossary is updated periodically to reflect the latest versions of Gaia-X deliverables.

4.4.3 Model Core¶

The diagrams describe the organizations and concepts foundational to the translation of the rules in the conformity assessment schema defined by the governance authority into digital credentials and their subsequent verification.

The (Ecosystem/Data Space) Governance Authority:

• Defines one (or multiple) conformity assessment schemes, which are translated into a machine-readable format and stored in the Registry.
• Approves CABs as a validation method for specific scopes and purposes.
• Approves Trust Service Providers (TSPs) for given scopes and purposes.
• Selects and approves Trusted Digital Identities where a Trusted Digital Identity is bound to a cryptographic key.
• Approve Notaries for given scopes and purposes.

The Conformity Assessment Body:

• Acts as a validation method
• Has a scope
• May use a Notary
• If it can issue verifiable credentials, it will also act as a Trust Service Provider

Figure 4.3.1.a - Conceptual Model-1

The definition of compliance criteria (e.g. for participants and services offered in the ecosystem/data space) encompasses both the definition of conformity rules and the definition of required validation methods. The definition of accepted validation methods may involve the definition of existing standards that can be used to assess conformity, or the identification of attributes that can be technically verified, and the definition of the type of assessment required (e.g. declaration or certification performed by a Conformity Assessment Body). While establishing a conformity assessment schema, the Governance Authority also defines the list of Trust Service Providers that are approved as trusted issuers for specific scopes and purposes.

Figure 4.3.1b - Conceptual Model-2

From an implementation perspective, the Participants issue claims on themselves and the services they provide according to the format defined in the Registry. These claims are signed by approved Trust Service Providers, and the validation of compliance criteria is performed by the Compliance Engine based on the information (credential schemas/shape graphs) that are maintained and made available through the Registry. The Notary service supports the issuance of credentials.

4.4.4 Model for Federated Ecosystems¶

The Gaia-X Trust Framework establishes the foundation for interoperable trust across different ecosystems and domains. It enables ecosystems to federate by adhering to Gaia-X technical compatibility and by accepting a shared set of rules and associated Trust Service Providers for defined scopes and purposes.

As a mechanism for federation between two ecosystems, the governance authority of Ecosystem A may choose to recognize Ecosystem B’s membership credential as valid proof for onboarding into Ecosystem A.

4.5 Cross-Ecosystem Interoperability¶

Cross-ecosystems interoperability can be defined as “the ability of participants to seamlessly access and/or exchange data across two or more ecosystems. Cross-ecosystems interoperability addresses the governance, business and technical frameworks to interconnect multiple ecosystem instances seamlessly.” (adapted from the definition of “cross-data spaces interoperability” in the Glossary of the DSSC Blueprint v2.0).

A common semantic framework for describing participants, the services offered within an ecosystem, and for expressing policies is essential. Interoperable rulebooks—characterized by a commonly identified set of rules and mutually recognized Trust Service Providers—serve as additional enablers for cross-ecosystem interoperability.

Interoperability across ecosystems is further supported by adopting the Gaia-X Trust Framework, which provides specifications facilitating both technical and semantic interoperability. It also offers multiple sets of compliance criteria that can be modularized and extended by ecosystem governance authorities to meet their specific needs.

Finally, the Eclipse Conformity Assessment Policy (CAP) Ontology, which provides a standardized framework for expressing and verifying conformity assessment policies, represents another important asset for interoperability in data-sharing ecosystems.

4.6 Inter-Ecosystem Interoperability¶

Trust Frameworks in general - not just limited to the Gaia-X Trust Framework - intend to increase interoperability at the following four layers (ref. European Interoperability Framework):

• legal interoperability: specifying criteria related to jurisdictions or domain- or ecosystem-relevant legislation (e.g., GDPR, Data Act, Data Governance Act);

• organizational interoperability is enhanced by better aligning data transactions with (i) business processes and their (user) requirements and (ii) with common domain or ecosystem governance rules;

• semantic interoperability is supported by ensuring that the meaning of the exchanged information is preserved throughout exchanges between parties (for instance, by the definition of semantic models and common ontologies);

• technical interoperability derives from the use of international standards widely adopted and recognised

In the approach chosen by Gaia-X, these four layers are addressed in a two-pronged configuration:

• Gaia-X Compliance addresses legal and organizational interoperability (of trust)
• Gaia-X Technical Compliance addresses semantic and technical interoperability (of trust)

Depending on the particular configuration of an ecosystem’s trust framework, an ecosystem may also implement certain elements of organizational and legal interoperability using Gaia-X technically compliant mechanisms. For instance, an ecosystem may extend the Gaia-X core ontology for ecosystem participants to include certain credentials (e.g., a Business Partner Number) allowing the automated recognition of an organisation as a valid ecosystem participant; such an extended ontology may also include credentials specifying certain roles a participant may hold within an ecosystems, e.g., service provider or service consumer.

4.7 Services and Service Composition¶

4.7.1 Resources and Service Offerings¶

Resources describe, in general, the goods and objects of the Gaia-X Ecosystem.

Resource Categories

A Resource can be a:

• Physical Resource: it has a weight, a position in space and represents a physical entity that hosts, manipulates, or interacts with other physical entities.
• Virtual Resource: static data in any form and necessary information such as a dataset, configuration file, license, keypair, an AI model, neural network weights, …
• Instantiated Virtual Resource: an instance of a Virtual Resource. It is equivalent to a Service Instance and is characterized by endpoints and access rights.

A Service Offering is a set of Resources, which a Provider aggregates and publishes as a single entry in a Catalogue.

A Service Offering can be associated with other Service Offerings.

classDiagram
    ServiceOffering o-- Resource: aggregation of
    Resource o-- Resource: aggregation of

class Resource{
    <<abstract>>
}

    Resource <|-- "subclass of" PhysicalResource: 
    Resource <|-- "subclass of" VirtualResource
    VirtualResource <|-- "subclass of" InstantiatedVirtualResource

    InstantiatedVirtualResource <..> ServiceInstance : equivalent to

Services can be selected and composed across different ecosystems which rely on a common Trust Framework. This approach enables the creation of new service offerings that meet specific compliance requirements, as these are satisfied by the constituent services.

For example, a software provider might offer a service that utilizes multiple Cloud Service Providers, each of which complies with the requirement to use only data centers certified under ISO/IEC 27001.

4.8 Policies¶

4.8.1 Policy Definition¶

Policy is defined as a statement of objectives, rules, practices, or regulations governing the activities of Participants within Gaia-X. From a technical perspective, Policies are statements, rules or assertions that specify the correct or expected behaviour of an entity¹².

The Gaia-X Compliance Document defines the Gaia-X Policies for Service Offerings. They cover, for example, privacy or cybersecurity policies and are expressed indirectly as attributes of the Resources, Service Offerings, and Service Instances. The specific Policies have to be in line with the general Policies defined by Gaia-X.

4.8.2 Policy Description¶

The general Policies defined by Gaia-X form the basis for detailed Policies for a particular Service Offering, which can be defined additionally and contain particular restrictions and obligations defined by the respective Provider or Consumer. They occur either as a Provider Policy (alias Usage Policies) or as a Consumer Policy (alias Search Policy):

• A Provider Policy/Usage Policy constrains the Consumer’s use of a Resource. For example, a Usage Policy for data can constrain the use of the data by allowing to use it only for x times or for y days.
• A Consumer Policy describes a Consumer’s restrictions on a requested Resource. For example, a Consumer gives the restriction that a Provider of a certain service has to fulfil demands such as being located in a particular jurisdiction or fulfilling a certain service level.

graph TD;
    A[Policy Rules] --> |defines| B[general Gaia-X Policies]
    B --> |basis for| C[Resource-specific Policies]
    C -->D[Provider Policy/ Usage Policy]
    C -->E[Consumer Policy/ Search Policy]

Policies are expressed by one or more parties about one or more assets. An asset can also be a party, making this simple model recursive and capable of handling the most complicated user scenario, with multiple providers, consumers, federators, data intermediaries, data subjects, business legal representatives, employer/employee and much more.

flowchart TD
    party(Party)
    policy(Policy)
    rule(Rule)
    asset(Asset)
    action(Action)

%%    party -- expresses --> policy
    policy -- a non-empty set of --> rule
    rule -- ability/inability/obligation to exercise --> action
    action -- is an operation on --> asset
    asset -- subjects to --> rule
    party -- has role in --> rule
    asset -. can also be a .-> party

The workflow above is the generic representation of the Open Digital Rights Language (ODRL) model.

The main aspects to be considered from a technical point of view are:

• Policy representation: interoperable access and usage policies that are specified in a human- and machine-readable format. Policies generally express three possible restrictions: prohibitions, obligations, and permissions. Constraints defining a rule can be combined into more complex rules, which then form the applicable policy.
• Decision-making/policy engine: during the execution of a data transaction, the policies need to be evaluated. This decision typically requires context information. With the decision context, the policy engine will decide whether the request or usage is permitted. The evaluation process is handled by the policy engine, which is instantiated by the data product provider and the data consumer or a trusted third party.
• Enforcement and execution of policies: the enforcement and execution of policies is a key capability which needs to be implemented for both access and usage policies.

Realization of Policy Definition and Policy Enforcement follows the W3C ODRL specifications; the definition of the execution components follows NIST (see PDP and PEP)

4.8.3 Gaia-X Policy Reasoning Engine¶

The Gaia-X Policy Reasoning Engine allows for a comparison between policies set up by the provider of a service and usage intentions declared by a consumer, by leveraging the following standards:

• W3C ODRL (Open Digital Rights Language) to express policies
• W3C Verifiable Credentials
• JSON Path to evaluate the credentials
• RDF to represent the policies as triples (subject, predicate, object)
• SPARQL to query the RDF triples.

An open-source library to perform policy reasoning is being provided by the Gaia-X Lab.

4.8.4 Policy Decision Point (PDP)¶

4.8.4.1 Reference implementation¶

A specific ODRL profile has been built by the Gaia-X Lab with the purpose of being able to refer in a clear and precise way to verifiable credential claims in an ODRL Policy. This gives assignors of policies a way to enforce policies using trustworthy and verifiable claims from an assignee, and in doing so, having more trust and confidence in the enforcement of the policy.

4.8.4.2 Policy Enforcement¶

The Policy Enforcement Point (PEP) intercepts the request from the data product provider. For verification of the request, the decision context is set up and processed through the Policy Decision Point (PDP). After retrieving the relevant context information, the data request is verified. If the request is invalid, the data product provider sends a rejection that is processed by the data consumer. If the request is valid and certain actions are required, these are executed before granting data access or starting the transfer. The response is processed by the Data Consumer. If the request is valid, the same interception and processing steps as on the Data Product Provider side are executed (involvement of PAP, PDP, PEP, PIP). In the last phase, the data consumer provides proof of the implemented policy enforcement that the data product provider verifies. In case of an invalid proof, the data product provider can and must reject the interaction and may initiate further actions. If everything is valid, the transaction is completed.

The enforcement phase starts when the actual data transaction is executed, and it takes place throughout the data transaction. The goal of the enforcement phase is to evaluate the relevant rules of the policy and decide whether or not the data transaction is allowed to proceed unless an agreement or contract has already been negotiated, in which case, the only need is to verify the contract’s validity.

For the different types of rules, the evaluation might occur at different stages of the data transaction: - Access rules are primarily evaluated by the data provider before any data is exchanged. A data consumer may also check these rules when receiving data to ensure it is still according to the access rules. - Usage rules are evaluated by the data consumer when the data is used. Depending on the usage rule, evaluation might be required not just when starting to use the data but constantly throughout the lifecycle of the data usage. - Consent rules require the evaluation of consent of third parties, which might be revoked during the data transaction or data use. Therefore, evaluation should occur both at the data product provider and consumer sides.

4.8.5 Rights Delegation¶

4.8.5.1 Party Credential¶

The Party Credential is based upon the Verifiable Credentials Data Model v2.0 and is the basis for all IAA Parties such as Natural Persons, Services, Legal Persons, etc. The general purpose Party Credential is intended to be extended into specialized Credentials.

The Party Credential is defined by the following attributes:

VERY IMPORTANT NOTE

The credentialSubject.id must identify the DID Document that contains the verificationMethod (keypair) referenced by gx:holder property that belong to/is controlled by the Credential Holder. With this solution, the PartyCredential VC can be either publicly published in case it contains no sensitive data or kept private in case it contains PII - Personal Identifiable Information.

4.8.5.1.1 Private Party Credential¶

The Party Credentials containing PII are not considered to be published and reachable via their id to everybody, instead, they are intended to be stored in secure storage such as a wallet, secure storage device, secure vault storage, etc. An example of this type of credential is the NaturalPersonCredential, issued by a Legal Participant to one of his users/employees, with the purpose to entitle a Natural Person to interact with Relying Parties(RP) in a certain context This credential contains Name, Surname, identityAttributes, Roles, etc. and MUST NOT be published as Public Party Credentials (see later in this section) are. “Selective disclosure” during interaction with RP can be considered.

4.8.5.1.2 Private Party Credential Example¶

The following NaturalPersonPartyCredential example represents the scenario where the Participant did:web:did.actor:alice is issuing a credential that asserts several claims (givenName, surname, idRoles etc). This Credential is not published (the id is not public) and must be stored in the wallet of the holder.

Note that the gx:holder property is a did:key referencing a keypair owned by the Holder that identifies the public key of the target wallet.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://w3id.org/gaia-x/development#"
  ],
  "id": "did:web:did.actor:alice:credentials:private#1222331234",
  "type": ["VerifiableCredential"],
  "issuer": "did:web:did.actor:alice",
  "validFrom": "2023-08-28T23:00:00Z",
  "credentialSubject": {
    "id": "did:key:z4MXj1wBzi9jUstyPMS4jQqB6KdJaiatPkAtVtGc6bQEQEEsKTic4G7Rou3iBf9vPmT5dbkm9qsZsuVNjq8HCuW1w24nhBFGkRE4cd2Uf2tfrB3N7h4mnyPp1BF3ZttHTYv3DLUPi1zMdkULiow3M1GfXkoC6DoxDUm1jmN6GBj22SjVsr6dxezRVQc7aj9TxE7JLbMH1wh5X3kA58H3DFW8rnYMakFGbca5CB2Jf6CnGQZmL7o5uJAdTwXfy2iiiyPxXEGerMhHwhjTA1mKYobyk2CpeEcmvynADfNZ5MBvcCS7m3XkFCMNUYBS9NQ3fze6vMSUPsNa6GVYmKx2x6JrdEjCk3qRMMmyjnjCMfR4pXbRMZa3i",
    "type": "gx:NaturalPersonPartyCredential",
    "odrl:hasPolicy": [],
    "gx:holder": "did:key:z4MXj1wBzi9jUstyPMS4jQqB6KdJaiatPkAtVtGc6bQEQEEsKTic4G7Rou3iBf9vPmT5dbkm9qsZsuVNjq8HCuW1w24nhBFGkRE4cd2Uf2tfrB3N7h4mnyPp1BF3ZttHTYv3DLUPi1zMdkULiow3M1GfXkoC6DoxDUm1jmN6GBj22SjVsr6dxezRVQc7aj9TxE7JLbMH1wh5X3kA58H3DFW8rnYMakFGbca5CB2Jf6CnGQZmL7o5uJAdTwXfy2iiiyPxXEGerMhHwhjTA1mKYobyk2CpeEcmvynADfNZ5MBvcCS7m3XkFCMNUYBS9NQ3fze6vMSUPsNa6GVYmKx2x6JrdEjCk3qRMMmyjnjCMfR4pXbRMZa3i",
    "gx:identityAttributes": ["IdAttributeOne","IdAttributeTwo"],
    "gx:identityRoles": ["IdRoleOne","IdRoleTwo"],
    "gx:givenName": "John",
    "gx:surname": "Doe"
  },
  "credentialStatus": [{
    "id": "https://did.actor/alice/credentials/status/3#94567",
    "type": "BitstringStatusListEntry",
    "statusPurpose": "revocation",
    "statusListIndex": "94567",
    "statusListCredential": "https://did.actor/alice/credentials/status/3"
  },{
    "id": "https://did.actor/alice/credentials/status/4#23452",
    "type": "BitstringStatusListEntry",
    "statusPurpose": "suspension",
    "statusListIndex": "23452",
    "statusListCredential": "https://did.actor/alice/credentials/status/4"
  }],
  "proof": {
    "type": "JsonWebSignature2020",
    "created": "2023-08-28T13:25:35.827Z",
    "proofPurpose": "assertionMethod",
    "verificationMethod": "did:web:did.actor:alice#JWK2020",
    "jws": "eyJhbGciOiJQUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..Sq5VJHCFuIP-cC86EknRnB91WQxNI5X4QtI0mMR3Xzl8VY5bYfOAtpEsejYeDUbi3Oed0VwQBRCqd11HL7NFF-KH02D9I97nHBftBaXo8e0uWQTRk6TA8xq9oQRuNdnm15eR2zudOzKlH4ArXcBo-hUxUH6EH7YimT0Uu5NbsofN-5C2ovksogbugl-NkW3MKrGkAYzsyaEcgh-vSiRwSl4vwE55sDkn16QgMtsccwo9PR0kzECHp8KQZTM3Nwnv4jNN-F3zP-3Vn0B-cm-UgHPz1RYX6uKrc3A4TlJvk9rxQNfLbNot8ZaQBPoLMnd98bV6giNaGIbekVOUuBxUKg"
  }  
}

4.8.5.1.3 Public Party Credential¶

The Party Credential contains data that can be publicly accessed and queried.

4.8.5.1.4 Party Credential Lifecycle¶

• expired if the expiration datetime is older than the current datetime or the certificate containing the key used to sign the claim has expired.
• revoked
• if the key used to sign the array is revoked.
• if the credentialStatus has the statusPurpose property set to “revocation” and the value of status at position credentialIndex is true
• suspended if the credentialStatus has the statusPurpose property set to “suspension” and the value of status at position credentialIndex is true
• deprecated if another verifiable credential with the same identifier and the same signature issuer has a newer issuance datetime.
• active only if none of the above.

4.8.5.1.5 Party Credential Status¶

Verifiable Credentials are a fundamental component of secure data and identity systems, enabling the issuance and presentation of trustworthy and tamper-proof credentials. However, in dynamic and evolving environments, it is crucial to establish mechanisms for the timely revocation or suspension of these credentials in case of compromised or outdated information.

The use of Credential Status Lists (CSL), specifically the W3C Verifiable Credentials Bitstring Status List, addresses this need by providing a standardized approach to manage and communicate the revocation status of verifiable Credentials.

When a Verifiable Credential is issued, the issuer has the option to embed a reference to the Credential Status List (CSL) entry associated with the credential. This reference, often in the form of a Uniform Resource Identifier (URI), enables relying parties (commonly verifiers) to promptly determine the current status of the credential’s validity.

To validate the Verifiable Credential, the relying party retrieves the referenced Credential Status List entry using the provided URI. This entry contains information about the status of the credential, allowing to check if the credential is still valid, has been revoked/suspended, or has any other relevant status.

Relying parties can periodically update their local copy of the Credential Status List from trusted sources to ensure they possess the most current revocation status information. This practice prevents reliance on outdated or incorrect information, enhancing the overall security of the ecosystem.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://w3id.org/gaia-x/development#"
  ],
  "id": "https://did.actor/alice/credentials/status/3",
  "type": ["VerifiableCredential", "BitstringStatusListCredential"],
  "issuer": "did:web:did.actor:alice",
  "issued": "2021-04-05T14:27:40Z",
  "credentialSubject": {
    "id": "https://example.com/status/3#list",
    "type": "BitstringStatusList",
    "statusPurpose": "revocation",
    "encodedList": "H4sIAAAAAAAAA-3BMQEAAADCoPVPbQwfoAAAAAAAAAAAAAAAAAAAAIC3AYbSVKsAQAAA"
  }
}

4.8.5.2 Trusted Scope Credential¶

The Trusted Scope Credential is based on the Verifiable Credentials Data Model v2.0 and has the purpose of providing a machine-readable representation of the accreditation of a Trust Service Provider for a specific scope. This credential enables the usage of Party Credentials by defining their accredited issuers. Furthermore, the Trusted Scope Credential supports the cooperation and interoperability between organization/ecosystems/data spaces, by easing the use of external Trust Service Providers.

The Trusted Scope Credential mainly defines:

• The Scope within which the Trust Service Provider is accredited (within which the issued credentials are considered valid).
• The TrustServiceProviders entitled to issue Credentials in the above Scope
• The Vocabularies (expressed in SHACL) that semantically define the Credentials which can be issued by the TrustServiceProviders in the defined Scope.
• The Trusted List used to check DIDs issued by the Trust Service Provider.

The Trusted Scope Credential is defined by the following attributes:

The KindOfTrustedList type defines the list of identified implementations of Trusted Lists:

• Gaia-X Trusted List Generic REST API Specification
• Gaia-X IPFS (with ETSI TS 119 612 format)
• TRAIN
• EBSI
• (other possible implementations)

Important Note The Gaia-X Trusted List Generic REST API Specification is meant to be a simple API contract that, for a given DID, can return true if it is still valid. This will be very useful to enable integration of any custom trusted list not included in the defined list.

4.9 Ecosystem Trust Functions¶

In addition to the core elements, trust frameworks typically contain additional supplementary trust-related functions that accomplish or facilitate more specific tasks. Here we explain two functions included in this version of the Architecture Document, namely:

• means for rights or trust delegation and consent management

• computation of indexes providing interoperability metrics and information on the potential trustworthiness of an entity/element

4.9.1 Trust Indexes¶

Traditional assessment schemes defined by ecosystem authorities often face limitations:

• They do not automatically adapt to market dynamics, which typically evolve faster than the established rules.
• They fail to capture the complexities of organizational and semantic interoperability, effectively reducing interoperability to the most basic commonly accepted denominators.

To address these challenges, four Trust Indexes are introduced:

• veracity
• transparency
• composability, and
• semantic match

These indexes are designed to be utilized by all stakeholders — licensors, licensees, producers, providers, and consumers — as metrics for assessing interoperability and trust relative to other offerings within ecosystem catalogues. The intention is for the ecosystem to assist the market by providing measurement tools, enabling market participants to converge towards optimal solutions.

A more detailed explanation of the four indexes and the way to compute them is provided as an Appendix to the document.

4.10 Data Space Architecture using the Gaia-X Trust Framework¶

Data Spaces can leverage the Gaia-X Trust Framework to onboard participants by verifying compliance with their Data Space Rulebook and issuing corresponding proofs of membership to facilitate trusted data exchange.

As illustrated in the figure below, the Data Space Governance Authority defines the Data Space Rulebook, aiming to operationalize regulatory, business, and/or technical requirements.

The Data Space Rulebook must specify, in a machine-readable format, the Criteria, Compliance Rules, Validation Methods (via first-, second-, or third-party assessments, potentially relying also on technical means), and the accepted Trust Service Providers authorized to sign the required claims.

The Registry stores the lists of accepted Trust Service Providers along with the schemas for data space credentials, which serve as the vocabulary for claims about credential subjects (e.g., data space offering credentials and data space membership credentials). The Rules Engine validates data graphs against the shape graphs stored in the Registry to assess compliance with the Data Space Rulebook.

The assessment outcome is issued as a credential under the authority of the Data Space Governance Authority. Participants can store this credential using a Wallet Service (also referred to as a Credential Store) and use it as proof of compliance or for further qualification under a data space Conformity Scheme.

The setup of the Data Space is completed and can be enhanced by utilizing additional Trust Services accessible through a catalogue adhering to the Gaia-X technical compatibility specifications, along with protocols designed to enable contract negotiations and trusted data transactions.

Figure 4.10 - Data Space architecture enabled by the Gaia-X Trust Framework