In reply to @lauresha:matrix.org
Dear all, looking forward seeing many of you in our upcoming workshop , In Frankfurt :) For the ones that are not updated: all information, program and registration available here: https://lnkd.in/efP8uBgf

In reply to @yannickbidois:matrix.org
lauresha: Looking forward to this workshop folks!

Good afternoon XFSC Community,

At the beginning of this week Pierre Gronlier shared a set of questions in order to collect some requirements for the Credential Event Service from its potential users. Since I know that some members of this chat are currently involved in discussions regarding the CES (e.g. Fabian Scheidt lenasauermann robertschubert Maharshi Suchaklangec ) I wanted to share the questions here with you:

"""
I would like to get your requirements, as potential users of that service, on the following points:

#1 Should the service stay publicly open (no onboarding required) and freely accessible for publication (pull/GET)?
Yes/maybe/no and why

#2 Should the service stay publicly open (no onboarding required) and freely accessible for consumption (push/POST)?
Yes/maybe/no and why

#3 Should the service ensuring consistency of the published information ? (At a given time, should 2 users, independently of their location on Earth and network connection pull the same information from the service.)
Yes/maybe/no and why

#4 Should the service always be available (excluding downtime for maintenance), or is it ok for the service to be unavailable for a period of time to synchronise its content ?
Yes/maybe/no and why

#5 Should the service be limited to push/pull Gaia-X Compliance credential only or should it support any valid credential ?
Yes/maybe/no and why

#6 Insert here additional functional requirements.

This work will be tracked here https://gaia-x.atlassian.net/browse/GXTCR-9

A future thread will be triggered for Catalogue functional requirements.
"""

Please note: the CES does not transmit actual data in credentials, but only the IDs of credentials.

So if anyone has any input regarding current or future requirements for the CES please comment them here, I will then collect all feedback. Thanks!

Good afternoon XFSC Community,

At the beginning of this week Pierre Gronlier shared a set of questions in order to collect some requirements for the Credential Event Service from its potential users. Since I know that some members of this chat are currently involved in discussions regarding the CES (e.g. Fabian Scheidt lenasauermann robertschubert Maharshi Suchaklangec ) I wanted to share the questions here with you:

"""
I would like to get your requirements, as potential users of that service, on the following points:

#1 Should the service stay publicly open (no onboarding required) and freely accessible for publication (pull/GET)?
Yes/maybe/no and why

#2 Should the service stay publicly open (no onboarding required) and freely accessible for consumption (push/POST)?
Yes/maybe/no and why

#3 Should the service ensuring consistency of the published information ? (At a given time, should 2 users, independently of their location on Earth and network connection pull the same information from the service.)
Yes/maybe/no and why

#4 Should the service always be available (excluding downtime for maintenance), or is it ok for the service to be unavailable for a period of time to synchronise its content ?
Yes/maybe/no and why

#5 Should the service be limited to push/pull Gaia-X Compliance credential only or should it support any valid credential ?
Yes/maybe/no and why

#6 Insert here additional functional requirements.
"""

Please note: the CES does not transmit actual data in credentials, but only the IDs of credentials.

So if anyone has any input regarding current or future requirements for the CES please comment them here, I will then collect all feedback. Thanks!

#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).

#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.

#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.

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:

1. POST to CES happens from wizard application of Exercise 1.

2. As informed in the workshop, the Catalog in exercise 2 is just a basic application. And so it does not support the Service Offerings that does not follow the request response parameters from Exercise 1. So it was developed tightly coupled with the Wizard in exercise 1.

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.

1. Yes currently it is supporting only the ingestion of Service Offering .

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.