Apikey on device level does only effect outgoing traffic

Hi,

It took me a while to figure this out, but I still don't see any reason for this design decision.
Please, help to understand.
As documented for changing the API key we have three options in the IoT-Agent:

1. adjust the default API key in the Agent (this is a global setting and not really interesting)
2. create a service_group (This will change the API key for all attached devices)
3. adjust the API key on the device level (This only adjusts the API key for the outgoing traffic (commands), for all incoming traffic the next level above is used)

The docs say only this, but it does not really help:

All the topics subscribed by the agent (to send measures, to configuration command retrieval or to get the results of commands) are prefixed with the agent procotol, /json in this case, followed by APIKey of the device group and the Device ID of the device involved in the interaction; i.e.: there is a different set of topics for each service (e.g: /json/FF957A98/MyDeviceId/attrs). The API Key is a secret identifier shared among all the devices of a service, and the DeviceID is an ID that uniquely identifies the device in a service. API Keys can be configured with the IoTA Configuration API or the public default API Key of the IoT Agent can be used in its stead. The Device ID must be provisioned in advance in the IoT Agent before information is sent. All topis published by the agent (to send a comamnd or to send configuration information) to a device are not prefixed by the protocol, in this case '/json', just include apikey and deviceid (e.g: /FF957A98/MyDeviceId/cmd and /FF957A98/MyDeviceId/configuration/values ).

I do not find it intuitive that the last option (device configuration) only affects the outgoing traffic.
I was thinking about for quite a while now, but this does not appear reasonable to me and it is definitely not what a user would expect. The lower level configuration (device) should always overwrite the level above.

Even from a security point of view, this does not have any advantages. Just think of a scenario where a service_group API key would be stolen. This would affect all other devices as well for incoming traffic. And you even have no chance to make it more secure based on the APIKEY only by using the device_id as well. However, the latter would make the APIKEY obsolete.

Hence, this should maybe be changed in the next version because it is quite annoying that you have to create a service_group even if you maybe have only one device in it.

Start by tracing how the IoT Agent resolves API keys for device and service_group configurations, and how it builds subscribed versus published topics. Confirm the intended precedence with the issue discussion; done means a device-level API key consistently governs incoming and outgoing traffic, with the relevant behavior documented and covered by tests.