Discuss data minimization for geofencing event

[bigludo7]

Problem description
Following issue camaraproject/Commonalities#295 raised by @shilpa-padgaonkar in commonalities, I open this issue to discuss specifically about data minimization for the geofencing event. The device identifier in subscription is out of the scope of this discussion/issue as tackled globally in Commonalities.

Possible evolution
As of now we send back in each geofencing event in the data structure the following information:

• subscriptionId
• device with the identifier provided in the subscription
• area (areatype, center, radius, .... could differ depending on the area type)

(the other attributes are coming from the cloud event specification and are out of the scope of the discussion)

I saw 3 proposals - looking for your feedback - there are perhaps other options

1. We did not change anything here
2. We remove device identifier & area. We send back only the subscriptionId. If the API consumer did not stored the information has to make a GET /subscriptions/{subscriptionId} to get the information
3. We add in the subscriptions a capability for the API consumer to indicate if the device & area information must be part of the event (example lightEventmode - if set to yes, only subscriptionId is send back, if set to no we send same info as of today.

From RSE perspective I'm a bit uncomfortable with option 2 that will trigger additionnal API calls
Option 3 needs to be discussed in Commonalities.

Alternative solution

Additional context

[alpaycetin74]

Option 2 is reasonable under the assumption that the client should already know & store what they requested. In that case it should not trigger more API calls to GET the data.
Having said that, for instance in QoD API the session creation response includes the request parameters as well. So if option 2 is to be followed, it should be followed across all similar APIs to ensure consistent format.