11. Annex Optional attributes

The following defines the optional attributes that are suggested to be used to describe Participants, Services, and Resources.

11.1 Participant

Legal person

11.2 Resource & Subclasses

Resource

Physical Resource

Sustainability

The following attributes have to be linked to a service offering, physical resource or legal person.

11.3 Service & Subclasses

Service offering

Personal Data Protection Regimes Gaia-X strives to contribute compliance with the protection of personal data, i.e., privacy. Gaia-X envisages its implementation internationally, whilst not neglecting its European sources.

Conformity with specific requirements deriving from different regimes protecting personal data will be subject to respective Labels. Nonetheless, it is considered significant added value, to allow Customers to filter Service Offerings by applicable regimes.

Thus, Service Offerings shall be able to identify Personal Data Protection Regimes in their respective Self Description. Such identified regimes do not entail any trusted or verified statement of compliance.

Non-exclusive list of Personal Data Protection Regimes:

• GDPR2016: General Data Protection Regulation / EEA
• LGPD2019: General Personal Data Protection Law (Lei Geral de Proteção de Dados Pessoais) / BRA
• PDPA2012: Personal Data Protection Act 2012 / SGP
• CCPA2018: California Consumer Privacy Act / US-CA
• VCDPA2021: Virginia Consumer Data Protection Act / US-VA

The participant may wish to refer to ISO/IEC 27701 as a tool for comparing the various data protection regimes.

To enable interoperability, it is strongly recommended to refer to the options provided in the Gaia-X Registry. The Gaia-X Registry will allow for the possibility to select one or several of such regimes, as well as the possibility to add additional regimes. Maintenance of the registry shall regularly assess the individually identified regimes and - where appropriate - add such regimes to the pre-defined list of Personal Data Protection Regimes.

Service Instance / Instantiated Virtual Resource

Service Access Point

A service access point is an identifying label for network endpoints used in the OSI model.

The format below doesn’t represent all possible service access point types.

11.4 Specific Services

The following describes optional syntax recommendations.

Verifiable Credential Wallet

A wallet enables to store, manage, present Verifiable Credentials:

Interconnection

An interconnection enables a mutual connection between two or more elements.

Catalogue

A catalogue service is a subclass of serviceOffering used to browse, search, and filter services and resources.

[1]: Using the Verifiable Credential terms, it’s up to the issuer to control and decide if the credential’s id can be dereferenced and the holder to implement access control of the verifiable credentials.

11.5 Interoperability, Portability, Switchability and Intellectual Property Protection (experimental)

While the format of the attributes is not yet defined, the sections below give insights about the future requirements.

Interoperability

This covers how the service offering can communicate with another service, such as making or responding to requests.

The aim of the future attributes is to provide:

• a list of agreements in place with other service providers to ensure interoperability between systems
• a list of URL to interoperability capabilities and transparency documentation

See ISO/IEC 19941:2017-5.2.1 for a description of the facets that need to be addressed.

Data Portability

This refers to the porting of data (structured or unstructured) from one cloud service to another, public or private.

Note: Data portability will inevitably be limited to Customer Data and a subset of Derived Data as determined by contract, privacy regulations, etc. See the ServiceOffering.dataAccountExport attribute.

The aim of the future attributes is to provide:

• a list of publicly filed declarations of adherence such as SWIPO Code of Conduct

If a Gaia-X service offering includes multiple cloud services with different data portability capabilities, it is expected to have separate Self-Descriptions for each type of data portability capability.

Note 2: The SWIPO codes of conduct do not cover all cloud service categories (e.g. there is no specific SWIPO Code for PaaS), so it is not possible to mandate this attribute for all services.

See ISO/IEC 19941:2017-5.2.2 for a description of the facets that need to be addressed.

Application Portability

This refers to the porting of customer or third party executable code from one cloud service to another, public or private.

Note: Application portability is highly complex, especially when it comes to identity management, licenses, access control lists, privacy controls, transfer of credentials, etc.

The aim of the future attributes is to provide:

• a list of URL pointing to a declaration of adherence such as SWIPO Code of Conduct
• a list of URL pointing to a declaration of whether and how the application license can be switched to another service provider

If a Gaia-X service offering includes multiple cloud services with different data portability capabilities, it is expected to have separate Gaia-X Credentials for each type of data portability capability.

Note 2: For SWIPO Code of Conduct:

• This can apply to executable code within an IaaS virtual machine instance, or code that can be executed within a larger SaaS application (such as scripts or SQL stored procedures).

• This code of conduct does not cover all cloud service categories (e.g. there is no specific SWIPO Code for PaaS), so it is not possible to mandate this attribute for all services.

See ISO/IEC 19941:2017-5.2.3 for a description of the facets that need to be addressed.

Switchability

This refers to moving a customer’s account from one service provider to another, including the change of contracts and necessary technical changes.

Service switching is highly complex. Moving a customer to another cloud application provider requires identifying a destination which is in the same broad category of cloud service offering, and where the common functionality offered by the original service and the destination meets the minimum business needs of the customer wishing to switch. Since all services evolve constantly this is a moving target, and each customer will have different criteria. In addition, there can be considerable legal issues to be addressed. This includes the “policy” facets of data and application portability as described in ISO/IEC 19941:2017, but also the unique specifics of contracts and any possible implications for security and this continued compliance with privacy and data protection regulations. Responsibility for each stage of the switching process (including security, liability, and privacy compliance) will need to be determined and agreed upon in advance by all parties.

The aim of the future attributes is to provide:

• a list of URL pointing to a declaration of whether and how a cloud service contract can be switched to another service provider
• a list of URL pointing to required or available policies for switching
• a list of URL pointing to a declaration of whether and how the Identity and Access Management function can be switched to another service provider

Note 1: At present, there do not seem to be any established Codes of Conduct or other frameworks that cover these aspects.

Intellectual Property Protection

The term Intellectual property (IP) refers to unique and value-adding creations of the human mind. IP enables the granting of property-like rights over new discoveries, new knowledge and creative expressions. IP relates to but is not limited to know-how, products, processes, software, data, and artistic works. The rights resulting from various forms of IP are referred to as intellectual property rights (IPR). IPRs provide ownership, i.e. the capacity to grant the IP usage rights (licensing), to assign the IP and rights to exclude third parties from using what is protected by the owner. Trust is paramount in the willingness of partners to collaborate and share information. IPRs can ensure the confidence of the partners that their knowledge capital and investment will be respected in the frame of acknowledged context and therefore that the use of the information shared will remain in the agreed context for the agreed duration. IPRs can exist in the form of a Patent, Utility model, Copyright, Trademark, Industrial design, Geographical Indication or Trade Secret (see WIPO and ISO 56005:2020(en))

In the context of the Gaia-X Trust Framework, IP can be declared on Service Offering, PhysicalResource, SoftwareResource and / or DataResource level.

Consistency Rules - For every declaration, a unique ID (intellectualPropertyID) will be automatically generated and assigned. All other declared attributes in the section have to reference that ID. - The declaration of IP can be on service level (identifiable through the name and providedBy) and/or resource level (identifiable through ownedBy[] and producedBy[]). The intellectualPropertyID has to link to one or multiple unique Service Offering, PhysicalResource, SoftwareResource and/or DataResource. - If IP is wished to be declared, intellectualPropertyOwner[], intellectualPropertyOwnershipType[], iPRegistrationProof[],iPExpirationDate, geographicValidity and usageRightsAgreements[] are mandatory. - usageRightsExpirationCondition and usageRightsExpirationTime have to be linked to one or multiple usageRightsAgreements within usageRightsAgreements[].