Dear Community,
As the new year progresses, we are reaching you to keep you updated with the latest Gaia-X technical news.
This month we are delighted to share with you an overview of:
✔️ Our strategic plan for Q1
✔️ TC Reshape
✔️ TC New Rules
✔️ Tools: Service Desk
✔️ GXFS
Our Q1 Strategy Plan
============================
In Q1, we will answer and operationalise version 1.0 of the Gaia-X Compliance rulebook.
2022 is the adoption year for Gaia X; compliance requirements specifications and technical implementation will be essential to help us reach this goal.
Our compliance rulebook describes what it means and what is needed to be Gaia-X compliant from a technical and non-technical angle. Technically speaking, the compliance results will be verifiable credentials, and we need a stack that enables us to issue, sign, store, request, present, and revoke them. Non-technical includes all regulatory aspects.
The compliance rulebook is delivered according to the defined requirements of the Architecture Document. It’s also important to collaborate with the Lighthouse projects to leverage the synergies, accommodate their needs, and expedite the deployment on the market of the first Gaia-X services.
TC Reshape – Why
===========================
The Technical Committees are now re-organised, specifically defined in the following working groups and sub-working groups:
WG Architecture
WG Federation Services
WG Service Characteristics
SubWG Identity & Trust
SubWG Service Description Lifecycle
SubWG Service Composition
Gaia-X TC reshape aimed to improve efficiency and advance our organizational goals. At this time, it is necessary to build a machine to deliver, recognize gaps, and take a different direction to correct them – all of which are aligned with our strategy. The decision to reshape will be official from the BoD in February but in the meantime, we take the opportunity to inform and work with the committee members in advance.
Too many groups require more work, time and effort to coordinated and bring outcomes. Our intention is to concentrate on a specific topic, rather than a broader set and be more strategic on the tasks and contributions that each working group can bring. We believe this will be a better way to achieve our goals.
Gaia- X needs technical contributors (projects, implementations) and document contributors (working groups) for every user scenario. However, there were no specification owners or open-source projects to implement some of Gaia- X’s features to enable user scenarios. The new structure will allow a different approach.
Content needs to be split and addressed to the right target personas. Each working group will have specific documents to enable their input, in order to avoid redundant or repetitive efforts with unclear intellectual property rights.
Finally, Gaia- X Lab is exploring new ways to increase proof of concept, implementations that prove our specifications are correct.
Technical Committee’s New Rules
============================
These changes will allow us to reach our goals and work in a streamlined way.
The three rules of the new Technical Committee organisation are:
-Each working group must have one clearly identified document to contribute to
-Each document must target one type of persona
-Each document must have one working group owner.
Gaia-X Architecture document:
- Content: functional description of the architecture, services, and of the operating model
- Target personas: Solution Architect, Enterprise Architect
- Technical Committees: WG Architecture(owner) + SubWG Identity & Trust (contributor) + SubWG Service Composition + SubWG Service Description Lifecycle
Gaia-X Technical specification (formerly GXFS specs + AoS):
- Content: technical specification of services with API and Data models
- Target personas: Lead Tech, Developers, Project Manager
- Technical Committee: WG Federation Services
Gaia-X Compliance Rulebook:
- Content: list of Gaia-X rules and mandatory technical specifications
- Target personas: Lead Tech, Program Manager
- TBD Committee: WG Compliance
Gaia-X Label Rulebook:
- Content: the matrix of label rules and associated trusted source of information for verification.
- Target personas: Business Manager, Compliance Manager, Lawyer
- Policy Rules Committee: WG Label
Gaia-X Service characteristics:
- Content: 3-level taxonomy of services with commonly used characteristics to compute a composability score between services. Composability in this case, refers to more composable system allows different elements to work together in different combinations.
- Target personas: Program and Business manager
- Technical Committee: WG Service Characteristics
Gaia-X Glossary:
- Content: general cross-committee glossary
- Target personas: everyone
- Technical Committee
TOOLS: Service Desk Launch
============================
Our new Service Desk will allow Gaia-X members and the broader community to interact with the Gaia-X AISBL and the technical working groups.
The Service Desk is accessible here:
https://gaia-x.atlassian.net/servicedesk/customer/user/login?destination=portals
It is required that the User registers on the Service Desk via a personal or business email.
Once registered, the User will be able to submit two types of requests:
☑️ Functional: to submit issues, requirements or requests that are related to the technical specification activities currently going on at Gaia-X, or
☑️ Non-Functional: for any other non-technical requests, issues, queries, or clarifications that may be needed.
All requests submitted by the User will be viewable in status, feedback, further clarifications can be requested etc., via the ‘Request’ button on the top right corner of the browser window. if a request is not applicable may also be, in extreme cases, rejected by our management team.
The user must fill in a few self-explanatory text fields to describe the request better. The more information is submitted, the clearer the request will be.
GXFS
===========================
GXFS becomes an essential part of the TC reshape. Therefore, working groups are expected and must take the responsibility to contribute to version 2.0 of GXFS specifications.
GXFS specifications version 1.0 was created as an accelerator to kickstart the GXFS toolbox implementation before the association was even created. Therefore, the needs and scope have changed, and the specifications need to evolve to give maturity to the project.
GXFS toolbox is a set of software components, source code, that is being developed inside the Eclipse project. Some of the advantages of using the Eclipse framework are, using a well-known operating model and having better visibility and attraction among the developer community.
The GXFS-DE and GXFS-FR funded projects contribute to that toolbox working on one reference implementation. The entire community and lighthouse projects are invited to contribute to this implementation as well.
Note that updates about the topics just explained can be found on the latest version of the Mission document.
Thank you for reading.
