Flexibility for implementations that are targeting specific environments

[athoelke]

Some uses for the Firmware Update API have been identified that would benefit from some relaxations in the required implementation of some of the API functions, as described in 5.2.1 Required Functions.

For example, the FWU API is used for a subset of the components within an existing firmware update system. The existing framework has no procedural mechanism to abort a partially completed update, but will reset the system in such a situation and expect that the reboot will remove any partially downloaded firmware images. This is like a FWU 1.0 model with volatile staging (see Figure 12 in §C.2), but where the cancel operation will never be called by the Update client, and the reject operation is only ever used from TRIAL state, not from STAGED.

If the deployment environment will never use psa_fwu_cancel(), or call psa_fwu_reject() from STAGED - could the specification be relaxed to permit an implementation to not support those transitions, and return PSA_ERROR_NOT_SUPPORTED?