[Help needed] CallbackAddress clarification

[IgorBalog-Eng]

In several CN request messages it is defined mandatory field called callbackAddress, like

"dspace:callbackAddress": "https://..."

My question is: is this value defined somewhere by the specification or this is left to the connector implementation, and receiver will use value provided, and send response to that address, without any processing.

For example: if connector receives dspace:ContractRequestMessage with callbackAddress=https://igor.connector/listen/response this means that receiving connector will return response to https://igor.connector/listen/response This url is not defined anywhere in the specification. It is up to the implementation of the connector to provide valid logic for processing response under this API.

Why this ask for help: https://docs.internationaldataspaces.org/ids-knowledgebase/v/dataspace-protocol/contract-negotiation/contract.negotiation.binding.https#id-2.2-the-negotiations-request-endpoint-provider-side says: Callback messages will be sent to paths under the base URL as described by this specification.

If added here Callback request message will be sent ... this means (IMHO) that callback is referred only in Prerequisite section scope - for receiving requests, both on provider and consumer side. callbackAddress will be used as-is, without any url replacing.

Thanks

[IgorBalog-Eng]

After brainstorm within the teams, can someone verify that this is desired behavior? For simplicity, only messages/endpoints with callbackAddress are listed blow.

From specification

PROVIDER Section 2.2.1 https://provider.com/negotiations/request request: ContractRequestMessage * response: ContractNegotiation callbackAddress: used to send next message in the flow, depending on the decision: ContractAgreementMessage, ContractOfferMessage or ContractNegotiationTerminationMessage

Section 2.3.1 https://provider.com/negotiations/:providerPid/request request: ContractRequestMessage * response: 200 OK - no body callbackAddress: used to send next message in the flow, depending on the decision: ContractAgreementMessage, ContractOfferMessage or ContractNegotiationTerminationMessage

CONSUMER Section 3.2.1 https://consumer.com/negotiations/offers request: ContractOfferMessage * response: ContractNegotiation callbackAddress: used to send next message in the flow, depending on the decision: ContractAgreementMessage, ContractOfferMessage or ContractNegotiationTerminationMessage

Section 3.3.1 https://consumer.com/:callback/negotiations/:consumerPid/offers request: ContractOfferMessage * response: 200 OK, no body specified callbackAddress: used to send next message in the flow, depending on the decision: ContractAgreementMessage, ContractOfferMessage or ContractNegotiationTerminationMessage

Section 3.4.1 https://consumer.com/:callback/negotiations/:consumerPid/agreement request: ContractAgreementMessage * response: 200 OK, no body specified callbackAddress: used to send next message in the flow, depending on the decision: ContractVerifiedMessage or ContractNegotiationTerminationMessage

[matgnt]

Hi @IgorBalog-Eng not sure if I understood the question. Does this explanation help?

All callback paths are relative to the callbackAddress base URL specified in the Contract Request Message that initiated a CN. For example, if the callbackAddress is specified as https://consumer.com/callback and a callback path binding is negotiations/:consumerPid/offers, the resolved URL will be https://consumer.com/callback/negotiations/:consumerPid/offers.

https://docs.internationaldataspaces.org/ids-knowledgebase/v/dataspace-protocol/contract-negotiation/contract.negotiation.binding.https#id-3.1-prerequisites

Also the table here should help: https://docs.internationaldataspaces.org/ids-knowledgebase/v/dataspace-protocol/contract-negotiation/contract.negotiation.binding.https#id-3-consumer-callback-path-bindings

-- Matthias Binzer

[IgorBalog-Eng]

Hello @matgnt There was misunderstanding (lost in translation or overthinking) from our side, when callbackAddress are mentioned. We were thinking that callbackAddress were used to send response (ContractNegotiation in case of ContractRequestMessage request send by consumer) and such requests/responses are async, and there are no endpoints defined to receive such document/object.

But it was "different": requests are synchronous, sending response ContractNegotiation, and once decision is made what to do with ContractRequestMessage, next message in flow will be sent to callback binding (accepting propper message, Agreement, Offer or Termination) in combination with callbackAddress from CRM. This is just one simple example, but logic applies to other decision making requests, that does not need prompt decision.

I cannot promise but I will try to update existing negotiation diagram with callback endpoints, and share it with community (if it adds value, we can keep it, otherwise we learned something)

[matgnt]

yes, correct, the contract request is a http request/response with 200 OK and THEN, the async part is a completely separate http request/response from the provider to the (consumer's) callbackAddress... and so on...

Sounds to me like we could close the issue.

-- Matthias Binzer

[IgorBalog-Eng]

Closing issue. Clarification of help requested in comments