Align asynchronous response with CloudEvents format to ensure compliance with Commonalities r3.3

[albertoramosmonagas]

Problem description

The current asynchronous response mechanism in Population Density Data does not follow the CloudEvents delivery format as required by CAMARA Commonalities r3.3. Instead, it uses a custom JSON structure (application/json), which is inconsistent with the agreed CAMARA standard for asynchronous responses and notifications.

This creates a risk of fragmentation, as API consumers integrating multiple CAMARA APIs would need to implement different delivery models.

Expected behavior

• The asynchronous response should use CloudEvents format (application/cloudevents+json) as the delivery mechanism.
• The payload of the asynchronous response should be wrapped inside the data field of a CloudEvent.
• All required CloudEvent attributes (e.g. id, source, specversion, type, datacontenttype, time) should be present.
• Event type should follow the CAMARA naming conventions, e.g. org.camaraproject.population-density-data-v0.population-density-async.

Alternative solution

No alternative solution is proposed. Alignment with CloudEvents is mandatory per Commonalities, but not blocking to the Fall25.

Additional context

• The current design was already merged and passed review.
• During the RC review of PredictiveConnectivityData, the same issue was identified. Both APIs need to be aligned.
• Agreement is to keep the current Fall’25 release as is, and to correct this post-Fall’25.
• The correction will be delivered as v0.2.0, following the dual-phase model, to ensure consistent compliance across APIs.

[patrice-conil]

An issue is open in Commonalities to deal with this point see #533