Blogpost "Demystifying Gaia-X Credentials" #952
Comments
anjastrunk
changed the title
How to locally preview changes to https://github.com/SovereignCloudStack/website/Start in the repository on your branch:
Step 6 will take some time at first (several minutes) but will live-reload on changes afterwards which will take less than a minute each. |
Things to clarify for the blog postI need to answer some open questions resulting from my experiments with Credential compliance in SovereignCloudStack/gx-credential-generator#70 (comment)
Answers
Yes this works. However, the
So far, I haven't been able to find a documented statement on this but several resources strongly hint at it being something the provider is issuing itself:
There is a figure in the API Readme of the Compliance Service that lists LRN, LegalParticipant and Terms & Conditions as parts of the VP. The Participant seems to represent and be signed by the provider itself, it does not seem to be a 3rd party. Based on live testing the Compliance API:
It seems that there is no strict set of mandatory/minimum contents of a VP other than any of the possible content VCs having to adhere to their individual schema (e.g. Participant including the LRN).
??? |
Why are VCs self-signed by the provider?Intuitively I'd think that claims made by the provider would need to be verified by a 3rd party in order to have any value. As Anja already pointed out in SovereignCloudStack/gx-credential-generator#70, the Gaia-X Credentials seem to be defined as special Verifiable Credentials where the issuer is the holder itself1:
However, the official glossary entry2 does not mention this detail. ¹ Note: an older version of the architecture document3 stated "Each Gaia-X entity makes Claims, which are validated and signed by 3rd parties." which has been removed from the newer version1. Footnotes |
Open QuestionsHashed Terms & ConditionsThe documentation about Issuer Participants states:
This isn't accounted for in the gaia-x-101.ipynb example where the T&Cs are encoded in a verbatim fashion. As the documentation uses the "shall" keyword this doesn't sound like a strict requirement though. The Compliance Service API is fine with the non-hashed version currently. What should we do in the blog post? LRN ReferenceThe gaia-x-101.ipynb uses a LRN VC template which encodes a direct {
"@context": [
"https://registry.lab.gaia-x.eu/development/api/trusted-shape-registry/v1/shapes/jsonld/participant"
],
"type": "gx:legalRegistrationNumber",
"id": "https://bakeup.io/lrn.json#cs",
"gx:vatID": "..."
}In contrast, the Notary API docs suggest a DID reference: {
"@context": [
"https://registry.lab.gaia-x.eu/development/api/trusted-shape-registry/v1/shapes/jsonld/participant"
],
"type": "gx:legalRegistrationNumber",
"id": "did:web:gaia-x.eu:legalRegistrationNumber.json",
"gx:vatID": "FR79537407926"
}Should we promote the DID reference and hosting of the LRN within |
VC standard version v1.0 imposes
As ICAM changes from VC model v1 to v2 in Loire release, I suggest we promote URL, not DID to be compliant with Gaia-X Loire release coming in November '24 latest. |
We have to look carefully on the versions of Gaia-X documents. The current version is Tagus. Tagus refers to Trust Framework 22.11, which uses verbatim encoded Terms- and Conditions. That's why Compliance service is fine without hash. In Loire release, there will be a conjunction of Trust Framework document and Policy Rules Conformity Document. The new document is called Gaia-X Compliance Document. It Gaia-X Compliance Document. points out
Hence, Loire release requires a hash. And you arr right, keyword "shall" sound wrong. IMO, signing Gaia-X terms and conditions is a strict requirement. I opened an issue, to clarify this. See https://gitlab.com/gaia-x/policy-rules-committee/compliance-document/-/merge_requests/258 As there is no fix release date for Loire, I suggest to use guidelines in Tagus release, i.e. using verbatim terms and conditions. |
Thank you. I researched this a bit more in SovereignCloudStack/gx-credential-generator#70 (comment) because even if the format is clear, the purpose (to me) is not. I failed to figure out the intended workflow and created an issue requesting clarification at Gaia-X. |
In general, it's up to the verifier of a VC, which issuer he threats as is truth-worthy. This is also the case in context of Gaia-X. However, Gaia-X is operationalized by GXDCH and dictates in Trust Framework (Tagus release) and Compliance Document](https://gaia-x.gitlab.io/policy-rules-committee/compliance-document) rules to be Gaia-X compliant. This rules are checked by Gaia-X Compliance Service as part of GXDCH. And you are right, there is an official statement missing, who acts as trustworthy issuer for which property. I opened an issue for clarification, see Compliance Service ä67https://gitlab.com/gaia-x/lab/compliance/gx-compliance/-/issues/67
There is a strict set of mandatory attributes in (Trust Framework for Tagus release and Compliance Document for Loire release. There is no strict rule for the number of VCs within a VP, however to be Gaia-X compliant, all mandatory attributes must be part (as VC) in VP. That's why VP only containing the Participant fails, as registration number is a mandatory attribute.
According to ICAM Tagus Release and ICAM Loire Release |
Credential FormatGaia-X regulates descriptions of CSPs and services as Gaia-X Credentials. The credential format is defined in Identity, Credential and Access Management Document. The current release in Tagus. The next release is Loire, but has no official release date. The format of Gaia-X Credentials follows the W3C Verifiable Credentials Data Model v1.1, with some limitations:
In general, section on Credential Format seems to be unsorted with contradicting information. Is tried to sort this out and provided an MR in order to verify my findings. |
Thank you! I added this information to a new introductory section called "Terminology" explaining the relationship between VCs, VPs, Self-Descriptions and Gaia-X Credentials. |
According to my testing, simply linking the LRN VC in the Participant VC (under its It only worked when the Maybe there is some identifier reference magic that can cross-reference VCs within the same VP for this exact property but I wasn't able to find any. So for the time being I must assume that the LRN VC has to be publicly hosted and linked for the Participant VC, which is referencing it, to work. |
|
The local preview instructions from #952 (comment) do not work anymore. After a bit of fiddling I was able to adapt the process to the latest changes: sudo docker build -f Containerfile.jekyll-action -t scs-website-jekyll-action .sudo docker run -it --rm -p 4000:4000 \
--network host \
-e TARGET_UID="$(id -u)" -e TARGET_GID="$(id -g)" \
-e LC_ALL=C.UTF-8 \
-e LANG=C.UTF-8 \
-e USER_ID="$(id -u)" \
--entrypoint /bin/bash \
-v $(pwd):/srv/jekyll scs-website-jekyll-actionIn the running container execute: mkdir -p /tmp/jekyll-build
mkdir -p /tmp/jekyll-vendor
bundle config path "/tmp/jekyll-vendor/vendor/bundle"
bundle config set force_ruby_platform true
cd /srv/jekyll
bundle install
bundle exec jekyll serve config _config.yml,_config.dev.yml \
--source /srv/jekyll --destination /tmp/jekyll-build \
--incremental --host 0.0.0.0You can then open http://0.0.0.0:4000 in the browser. Note: The |
Write a blog post, which gives a deep insight into Gaia-X Credentials, what they are and how they can be ensure digital sovereignty and trust in Gaia-X ecosystems. Introduce SCS Gaia-X Credential generator and how this tool can be used, to generate compliant Gaia-X Credentials for SCS clouds.
The text was updated successfully, but these errors were encountered: