search

International-Data-Spaces-Association / InformationModel

The Information Model of the International Data Spaces implements the IDS reference architecture as an extensible, machine readable and technology independent data model.
Apache License 2.0
64 stars 37 forks source link

Requirement for callback URLs as part of every IDS request message to support asynchronous communication #495

Closed alexandrudanciu closed 2 years ago

alexandrudanciu commented 3 years ago

This is a follow-up on the issue https://github.com/International-Data-Spaces-Association/IDS-G-pre/issues/49

Dear IDSA community,

While assessing the possibility of implementing a fully asynchronous communication between two IDS connectors, the inability of specifying callback URLs was identified as a possible show stopper. Please find a detailed description below.

Situation: For implementing a completely asynchronous communication between two connectors, instead of replying to request messages with a response message, a MessageProcessedNotificationMessage must be returned.

The actual response message must be dispatched independently to the endpoint of the initiating connector. As a prerequisite, a callback URL must be provided by the initiating connector.

Complication: Based on our current knowledge, only a few message types and IDS protocols support the specification of callback URLs (e.g., ids:AccessTokenRequest-Message).

Resolution: Could you please confirm our current assumptions? If true, would it be possible to extend the IDS Info Model for supporting this requirement?

Best Regards Alexandru Danciu

HaydarAk commented 3 years ago

Could you please confirm our current assumptions?

Correct. We have no callback URI structures inside our ids:Message. Thanks for your input. We'll may consider that as part of our next releases.

Have to look into that in detail with my colleagues.

sebbader commented 2 years ago

Hello @alexandrudanciu, you have a point here. I guess we can add an optional attribute to the ids:Message class to allow callbacks. @HaydarAk @changqin26 can you make a quick suggestion?

changqin26 commented 2 years ago

ids:callbackURL a owl:DatatypeProperty; rdfs:label "callback URL"@en; rdfs:comment "A callback URL must be provided by the initiating connector "@en; rdfs:domain ids:ResponseMessage ; rdfs:range xsd:anyURI ; @alexandrudanciu , @HaydarAk Do you think this proposal fits the requirement?

alexandrudanciu commented 2 years ago

Hi @changqin26 Thank you for the proposal.

I am not sure if the new model suggest that only async ids:messages are allowed now, or if also sync messages would be possible (implied by an empty callbackURL).

juliapampus commented 2 years ago

rdfs:domain ids:ResponseMessage ;

@changqin26 Does this line mean that this will only be added to ResponseMessages? Although the description says that this is send by the initiating participant? However, could we add this callback address to the ids:Message in general? Trying to cover asynchronous use cases we have not in mind yet.

xsd:anyURI

Furthermore, as this may not be a URL but any kind of address information for an abitrary system, maybe we could use a string?

As a result, I would call the attribute callbackAddress not url.