How the provider could define a backchannel for an asset

[ndr-brt]

Currently the decision about setting a backchannel during a transfer stands on the consumer side, by adding the -backchannelType suffix in the transferType, but that should be a provider decision.

A proposal could be to have the provider being able to define this in the asset creation, so that in the catalog the backchannel type will be already visible by the consumer.

any thoughts?

[jimmarino]

This was already defined in the DR a while back. Backchannels must always be decided by the provider.

[ndr-brt]

yes, but that's not the current implementation and I think we should track this into an issue, to prevent forgetfulness :)

[jimmarino]

Yes then we should definitely fix it.

[rafaelmag110]

Not only that, but from my understanding of the concept document, the provider would have flexibility in deciding the type of response channel for each asset it offers. This flexibility would be given in the form of additional details for the asset data address, where even a different response channel type could be used.

i.e. the following pseudo json-ld (sorry for the lack of coherence. Its just for explanation purposes)

{
"assetId":"assetX"
"dataAddress":{
        "type":"HttpData"
        "baseUrl":"https://mock.com"
    }
"responseChannelDataAddress":{
        "type": "Kafka"
        "kafkaBroker":"mock.broker.domain"
    }
}

[jimmarino]

Kind of, but the backchannel needs to be specifically advertised as part of the distribution format, not arbitrarily chosen later. The formats can be dynamically generated by introspecting the data address type.