You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently for out going messages a connector takes the counterPartyAddress and append the path based on the chosen dsp protocol version which is configured in the connector. This might not be the case when communicating with a different dsp implementation which might expose protocol version under different paths.
Since EDC now expose the management api for fetching supported DSP version from a counter party we should let the users decide the base path of the dsp version (counterPartyAddress + dsp version path) directly in input, without automatically infer that.
Meanwhile for the callbackAddress which currently comes from ProtocolWebhook should automatically infer and append ther dsp version path based on the connector supported version in the ProtocolVersionRegistry
To keep the current behavior we might introduce a configuration flag which should be disable by default.
Which Areas Would Be Affected?
dsp
Why Is the Feature Desired?
interoperability
The text was updated successfully, but these errors were encountered:
Feature Request
Currently for out going messages a connector takes the
counterPartyAddress
and append the path based on the chosen dsp protocol version which is configured in the connector. This might not be the case when communicating with a different dsp implementation which might expose protocol version under different paths.Since EDC now expose the management api for fetching supported DSP version from a counter party we should let the users decide the base path of the dsp version (counterPartyAddress + dsp version path) directly in input, without automatically infer that.
Meanwhile for the
callbackAddress
which currently comes fromProtocolWebhook
should automatically infer and append ther dsp version path based on the connector supported version in theProtocolVersionRegistry
To keep the current behavior we might introduce a configuration flag which should be disable by default.
Which Areas Would Be Affected?
dsp
Why Is the Feature Desired?
interoperability
The text was updated successfully, but these errors were encountered: