How to respond to incorrect security codes

[emiltin]

If a command cannot be exectured, the normal behaviour is to send back the current values.
But if a command include incorrect security codes, it's not a good idea to return the correct codes.

We should somehow clarify or allow this in the core spec, although security codes is specific to the TLC sxl.

Previous discussion:
rsmp-nordic/rsmp#47

Or we wait until a possible v4 provides a new security model.

[otterdahl]

We've defined how to handle this is in TLC: https://rsmp-nordic.github.io/rsmp_specifications/rsmp_sxl_traffic_lights/1.2/security_codes.html

[emiltin]

To clarify, security codes is not a concept in core, but is specific to the TLC SXL. But not sending back the current values is not consistent with the current core spec.

[emiltin]

Another option would be to remove security codes from the TLC SXL. This would not require any change to core.

[emiltin]

Security codes is not secure, but rather just a way to check that you're sending a command to the right controller. They're also send in cleartext.

Proposal is to handle this in the TLC SXL:

1. Redefine this to a "control" code, and not as sensitive info.
2. Remove the section in the TLC SXL on security codes, since they override the core mechanism of command responses: https://rsmp-nordic.github.io/rsmp_sxl_traffic_lights/1.2.1/security_codes.html?highlight=security. The implication would be that the correct security code is returned in the command response. This should be ok if it's not considered sensitive info anymore.
3. We should remove these security attributes in an upcoming major version and replace them with a better more secure model of authentication and authorization in the core spec.