 | GXFS -> XFSC Tech | 166 Members |
| Building better Self Sovereign Identity World with XFSC community. GXFS code base is moving to: https://gitlab.eclipse.org/eclipse/xfsc | 6 Servers |
| GXFS -> XFSC Tech | 166 Members |
| Building better Self Sovereign Identity World with XFSC community. GXFS code base is moving to: https://gitlab.eclipse.org/eclipse/xfsc | 6 Servers |
| Sender | Message | Time |
|---|---|---|
| 19 Jan 2024 | ||
 Fabian Scheidt | * #1 MAYBE. If we decide that CES should not only distribute compliance credentials, I think it's reasonable to add some sort of onboarding to avoid spam. This could be as simple as allowing submission from every issuer who has previously submitted a valid compliance credential. #2 YES, to make it easy to consume contents. #3 MAYBE. Eventual consistency is sufficient. In addition, the order of credential submissions does not matter. #4 YES, with eventual consistency without order, synchonization can happen in the background. #5 NO, it should support other credentials. Following the discussion in Issue 58 of the compliance service, compliance credentials will no longer be able to contain domain-specific additions. However, we do need domain-specific additions in our catalogues and don't want to introduce a secondary distribution mechanims, duplicating the CES functionality (or even replacing it). #6 We could think about adding some filter mechanism to only receive credentials that are interesting/relevant. | 16:00:46 |
| Fabian Scheidt | * #1 MAYBE. If we decide that CES should not only distribute compliance credentials, I think it's reasonable to add some sort of onboarding to avoid spam. This could be as simple as allowing submission from every issuer who has previously submitted a valid compliance credential. #2 YES, to make it easy to consume contents. #3 MAYBE. Eventual consistency is sufficient. In addition, the order of credential submissions does not matter. #4 YES, with eventual consistency without order, synchonization can happen in the background. #5 NO, it should support other credentials. Following the discussion in Issue 58 of the compliance service, compliance credentials will no longer be able to contain domain-specific additions. However, we do need domain-specific additions in our catalogues and don't want to introduce a secondary distribution mechanims, duplicating the CES functionality (or even replacing it). #6 We could think about adding some filter mechanism to only receive credentials that are interesting/relevant. | 16:02:29 |
| Fabian Scheidt | * #1 MAYBE. If we decide that CES should not only distribute compliance credentials, I think it's reasonable to add some sort of onboarding to avoid spam. This could be as simple as allowing submission from every issuer who has previously submitted a valid compliance credential. #2 YES, to make it easy to consume contents. #3 MAYBE. Eventual consistency is sufficient. In addition, the order of credential submissions does not matter. #4 YES, with eventual consistency without order, synchonization can happen in the background. #5 NO, it should support other credentials. Following the discussion in Issue 58 of the compliance service, compliance credentials will no longer be able to contain domain-specific additions. However, we do need domain-specific additions in our catalogues and don't want to introduce a secondary distribution mechanims, duplicating the CES functionality (or even replacing it). #6 We could think about adding some filter mechanism to only receive credentials that are interesting/relevant. | 16:02:47 |
 Kurt Garloff (back Oct 22) | #3 and #4 may need some trade-offs if we believe in the CAP theorem. I guess we could live with allowing slightly outdated data to be served should the network connectivity be struggling and thus live with eventual consistency. #1 and #2: I would not want to limit read access (get) except throttling to fend off DoS, but we will eventually have to control write access (put/post). | 19:04:44 |
 Kai Meinke (deltaDAO AG) | Which is the reason why DLT introduced write fees (protection) and archive/read only nodes for serving replicated data. | 19:16:16 |
| Kurt Garloff (back Oct 22) | Sounds like a reasonable approach to me. Unless the fees are high... | 19:43:20 |
| Kai Meinke (deltaDAO AG) | That is for the data space authority or the federators to decide, or through free auction. But I do not want to derail the topic. We'll be going for fees in Euro & cents now for our network. | 22:28:07 |
| 22 Jan 2024 | ||
 Marcel Ruland (Cofinity-X) | https://app.element.io/#/room/#GXFSTRAIN:matrix.org | 08:36:57 |
 lauresha | https://app.element.io/#/room/#GXFSTRAIN:matrix.org | 08:37:01 |
| Marcel Ruland (Cofinity-X) | * Workshop room link: https://app.element.io/#/room/#GXFSTRAIN:matrix.org | 08:37:11 |
| 23 Jan 2024 | ||
 urtza joined the room. | 15:03:39 | |
| urtza | Good afternoon, I am Urtza and I am work at Tecnalia. During these days I have been working on this workshop https://gitlab.eclipse.org/eclipse/xfsc/workshop/xfsc-tech-workshop-5. I have not deployed the entire infrastructure, I have taken the signer part from exercise 1 and the catalog from exercise 2. As a result of exercise 1, I obtain a Participant and a ServiceOffering compliance with Gaia-X. And as part of exercise 2, I see that the information related to the CES is loaded into a postgres database and then there is both a frontend on port 8081 and a Neo4j frontend. I have a series of questions about it that I cannot understand the connection between the output of exercise 1 and the connection with the catalog: 1.- Who makes a POST to the CES service, is it done somewhere in the code of exercise 1 or is it done manually by accessing the URL https://ces-development.lab.gaia-x.eu/q/swagger- ui/#/? 2.- In exercise 2, I see that there is a cron that is responsible for reviewing the information, a call is made to the service https://ces-development.lab.gaia-x.eu/credentials-events?page=0&size=20 to get that information and save it in Postgres table fed_cat -> ces_process_tracker? How is this process done? I have generated a compliance service and uploaded it to POST but I can't see it in the database, I don't know if I should wait longer or if it doesn't get it from the URL https://ces-development.lab.gaia-x.eu. 3.- And as last question, where the descriptor is imported into Neo4j, I understand that it will only ingest service offering. Thanks, Urtza | 15:17:53 |
| urtza | * Good afternoon, I am Urtza and I am work at Tecnalia. During these days I have been working on this workshop https://gitlab.eclipse.org/eclipse/xfsc/workshop/xfsc-tech-workshop-5. I have not deployed the entire infrastructure, I have taken the signer part from exercise 1 and the catalog from exercise 2. As a result of exercise 1, I obtain a Participant and a ServiceOffering compliance with Gaia-X. And as part of exercise 2, I see that the information related to the CES is loaded into a postgres database and then there is both a frontend on port 8081 and a Neo4j frontend. I have a series of questions about it that I cannot understand the connection between the output of exercise 1 and the connection with the catalog: 1.- Who makes a POST to the CES service, is it done somewhere in the code of exercise 1 or is it done manually by accessing the URL https://ces-development.lab.gaia-x.eu/q/swagger- ui/#/? or is it on another URL regarding ces? 2.- In exercise 2, I see that there is a cron that is responsible for reviewing the information, a call is made to the service https://ces-development.lab.gaia-x.eu/credentials-events?page=0&size=20 to get that information and save it in Postgres table fed_cat -> ces_process_tracker? How is this process done? I have generated a compliance service and uploaded it to POST but I can't see it in the database, I don't know if I should wait longer or if it doesn't get it from the URL https://ces-development.lab.gaia-x.eu. 3.- And as last question, where the descriptor is imported into Neo4j, I understand that it will only ingest service offering. Thanks, Urtza | 15:22:45 |
| urtza | * Good afternoon, I am Urtza and I am work at Tecnalia. During these days I have been working on this workshop https://gitlab.eclipse.org/eclipse/xfsc/workshop/xfsc-tech-workshop-5. I have not deployed the entire infrastructure, I have taken the signer part from exercise 1 and the catalog from exercise 2. As a result of exercise 1, I obtain a Participant and a ServiceOffering compliance with Gaia-X. And as part of exercise 2, I see that the information related to the CES is loaded into a postgres database and then there is both a frontend on port 8081 and a Neo4j frontend. I have a series of questions about it that I cannot understand the connection between the output of exercise 1 and the connection with the catalog: 1.- Who makes a POST to the CES service, is it done somewhere in the code of exercise 1 or is it done manually by accessing the URL https://ces-development.lab.gaia-x.eu/q/swagger- ui/#/? or is it on another URL regarding ces? 2.- In exercise 2, I see that there is a cron that is responsible for reviewing the information, a call is made to the service https://ces-development.lab.gaia-x.eu/credentials-events?page=0&size=20 to get that information and save it in Postgres table fed_cat -> ces_process_tracker? How is this process done? I have generated a compliance service and uploaded it to POST but I can't see it in the database, I don't know if I should wait longer or if it doesn't get it from the URL https://ces-development.lab.gaia-x.eu. 3.- And as last question, where the descriptor is imported into Neo4j, I understand that it will only ingest service offering. Thanks, Urtza | 15:23:10 |
| urtza changed their display name from urtain2022 to urtza. | 15:42:32 | |
| 24 Jan 2024 | ||
 @koedding:matrix.org joined the room. | 08:29:03 | |
| 25 Jan 2024 | ||
 Maharshi Suchak | hi Urtza, glad to know you are able to make your way through with the documentation and that too with modifications in it. And that also comes with need of some support :-) Here are the answers:
As a followup on that, we already have a task in Catalog Gitlab, to make it work with the Shapes and SHACL files of Gaia-X standards. When that is done, you will be able to see that service posted on your own in the Catalog - along with many other service offerings in CES.
In the community calls you will receive more updates on the the catalog being compatible with all the Gaia-X compliant verifiable credentials and more. | 12:15:24 |
| 26 Jan 2024 | ||
| urtza | Redacted or Malformed Event | 10:49:09 |
| urtza | In reply to @maharshisuchak:matrix.orgThanks for your answer. By not attending the workshop and not deploying the entire infrastructure, I collected the information about exercise 1 directly and cloned the main branch. I could see that it seemed strange to me that the code was from 9 months ago and the creation of the participant was not entirely correct, so I started to modify the code and obtain the VP of the participant correctly but I was missing the call to the CES. Seeing your answer, I already entered another directory of the "Cloud setup" workshop and via the instructions on cloning to the "gaia-x-update" branch, in that code I already see the call to CES. Sorry for the inconvenience caused and thank you for the information received in your response. | 10:50:47 |
| Maharshi Suchak | glad to know you could see the updates. Always happy to help :-) | 12:16:27 |
 Tim | Hello everyone, we've been facing persistent issues with the OCM and its connections to the PostgreSQL database. Our deployments span various infrastructures and involve different PostgreSQL versions. What's particularly perplexing is that we can successfully set up the OCM, and it typically operates smoothly for 1-3 days—handling connections, issuing VCs, and verification—only to suddenly cease functioning. This occurs without any changes in configuration. The root cause appears to be an abrupt loss of connection or access rights to the database. Most of our instances utilize a managed database, and unfortunately, we're unable to access the logs there. The puzzling aspect is the brief period during which everything works before coming to a halt. To address these issues, our usual remediation steps involve killing all OCM-related pods, clearing the database (including recreating schemas), and then continuing until the problem reoccurs. Any insights into what might be causing these errors or suggestions for a more effective resolution would be greatly appreciated. Of course, if anyone else has faced or is currently facing similar problems, we would love to hear about your experiences and solutions. Have a nice weekend. | 13:43:58 |
| 27 Jan 2024 | ||
 JustinAnthony | It could be that the database service used is not a "Reserved instance" or it has reached the IOPS limit (3200 max for example in Azure). Logs should be available at the service website "activity log" | 13:15:08 |
 schulzest | Tim: in the existing OCM v1, is a gap in the Storage Handling of Hyperledger Indy which results in inconsistencies from time to time. This is solved now in spec phase two in v2, please cross check this version to solve that long term | 21:17:46 |
| 29 Jan 2024 | ||
| Tim | thanks JustinAnthony we really have very very few transactions, and unfortunately, logs are at a very low level (basically no important information) from our service provider | 09:31:28 |
| Tim | * thanks JustinAnthony we really have very very few transactions, and unfortunately, logs are at a very low level (basically no important information) from our service provider, and it appears to happen as well on a local instance (really just for testing, very limited) | 09:32:01 |
| Tim | thanks schulzest , do you have by chance a reference ticket from Indy for the issue to dig deeper? Is it reallistic to happen every few days? | 09:33:21 |
| 1 Feb 2024 | ||
 marc.b | Hi everyone, project MERLOT created a Java-Spring based library to simplify interactions with the XFSC federated catalog as well as credential creation/signature: https://github.com/merlot-education/gxfscatalog-library . I think this might be particularly interesting for other Gaia-X related projects that might just be starting out with using the catalog. | 12:53:40 |
| Kai Meinke (deltaDAO AG) | I am not sure about the linked credential models linked in the repo description. I have seen the credential schemata with gax: in the linked library which would not work with the shapes in Gaia-X Digital Clearing Houses, see: https://registry.lab.gaia-x.eu/development/api/trusted-shape-registry/v1/shapes/jsonld/trustframework# Maybe I am looking at the wrong sources here? https://github.com/merlot-education/gxfscatalog-library/tree/main/src/main/java/eu/merloteducation/gxfscataloglibrary/models/selfdescriptions/gax | 18:53:44 |
| Kai Meinke (deltaDAO AG) | For example: gax-trust-framework:registrationNumber does not match the current framework. The registration number is given through a credential, not in the participant VC. | 18:54:52 |
| Kai Meinke (deltaDAO AG) | There is also no "legalForm" in Gaia-X participant credentials. | 18:55:35 |