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.