Change:
3.9. <del> A device may have many modules that require updating individually. It may also need to trust several actors in order to authorize an update.  These actors might include the following (this is not a comprehensive list). These actors exert their authority on the device by making claims (as in claims). </del> <ins> When a device obtains a monolithic firmware image from a single author without any additional approval steps then the authorization flow is relatively simple.  There are, however, other cases where more complex policy decisions need to be made before updating a device. </ins> <del> For example, a firmware author may not have the authority to install firmware on a device in critical infrastructure without the authorization of a device operator.  In this case, the device may be programmed to reject firmware updates unless they are signed both by the firmware author and by the device operator.  To facilitate complex use-cases such as this, updates require several claims. </del> <ins> In this architecture the authorization policy is separated from the underlying communication architecture.  This is accomplished by separating the entities from their permissions.  For example, an author may not have the authority to install a firmware image on a device in critical infrastructure without the authorization of a device operator.  In this case, the device may be programmed to reject firmware updates unless they are signed both by the firmware author and by the device operator. </ins> <del> Alternatively, a device may trust precisely one authority, which does all permission management and coordination.  Effectively, the authority allows the device to offload complex permissions calculations for the device. </del> <ins> Alternatively, a device may trust precisely one entity, which does all permission management and coordination.  This entity allows the device to offload complex permissions calculations for the device. </ins> 3.10. There are three broad classifications of update operating modes. <del> Self initiated updates take the form of a proactive IoT device that checks for updates.  Third-party initiated updates are triggered by an actor other than the IoT device, be it a server, a peer, or a user.  Hybrid updates are those that require agreement from both the target IoT device and another actor. Third-party initiated updates are important to consider because timing of updates may need to be tightly controlled in some high- reliability environments. An IoT device goes through several steps in the course of an update, each of which can be self-initiated or third-party initiated, or hybrid.  An IoT device may go through the following steps, though this is not a comprehensive list. The notification step consists informing an IoT device that an update is available.  This can be accomplished via polling (self-initiated), push notifications (third-party initiated), or more complex mechanisms. The pre-authorisation step involves verifying the update authority and making a determination that the device is prepared to initiate the fetching and processing of updates.  If the device has all information that is necessary to make this determination, then the pre-authorisation may be self-initiated.  However, the device can wait for instruction to begin (third-party initiated).  Hybrid approaches are possible as well. </del> <ins> Client-initiated Update Server-initiated Update Hybrid Update Client-initiated updates take the form of a communicator on a device proactively checking for new firmware imagines provided by firmware servers. Server-initiated updates are important to consider because timing of updates may need to be tightly controlled in some high- reliability environments.  In this case the communicator, potentially in coordination with the status tracker, determines what devices qualify for a firmware update.  Once those devices have been selected the firmware server distributes updates to those devices. Note: This assumes that the firmware server is able to reach the device, which may require devices to keep reachability information at the communicator and / or at the firmware server up-to-date.  This may also require keeping state at NATs and stateful packet filtering firewalls alive. Hybrid updates are those that require an interaction between the device and the firmware server / communicator.  The communicator pushes notifications of availability of an update to the device, and the device then downloads the image from the firmware server when it wants. An alternative approach is to consider the steps a device has to go through in the course of an update: Notification Pre-authorisation Dependency resolution Download Installation The notification step consists of the communicator informing the device that an update is available.  This can be accomplished via polling (client-initiated), push notifications (server-initiated), or more complex mechanisms. The pre-authorisation step involves verifying whether the entity signing the manifest is indeed authorized to perform an update.  The device must also determine whether it should fetching and processing of the firmware image (unless it has been attached already to the manifest itself). </ins> A dependency resolution phase is needed when more than one component can be updated or when a differential update is used.  The necessary dependencies must be available prior to installation. The download step is the process of acquiring a local copy of the <del> payload.  When the download is self-initiated, this means that the IoT device chooses when a download occurs and initiates the download process.  When a download is third-party initiated, this means that either the remote service tells the IoT device when to download or that it initiates the transfer directly to the IoT device.  For example, a download from an HTTP server is initiated locally.  A transfer to a LwM2M Firmware Update resource LwM2M is initiated remotely. </del> <ins> firmware image.  When the download is client-initiated, this means that the device chooses when a download occurs and initiates the download process.  When a download is server-party initiated, this means that either the communicator / firmware server tells the device when to download or that it initiates the transfer directly to the device.  For example, a download from an HTTP-based firmware server is client-initiated.  A transfer to a LwM2M Firmware Update resource LwM2M is server-initiated. If the Device has downloaded a new firmware image and is ready to install it it may need to wait for a trigger from a Communicator to install the firmware update, may trigger the update automatically, or may go through a more complex decision making process to determine the appropriate timing for an update (such as delaying the update process to a later time when end users are less impacted by the update process). </ins> Installation is the act of processing the payload into a format that <del> the IoT device can recognise. </del> <ins> the IoT device can recognise and the bootloader is responsible for then booting from the newly installed firmware image. </ins> <del> Each of these steps may require different permissions expressed in claims and may be implemented in a variety of ways. </del> <ins> Each of these steps may require different permissions. </ins> 4. <del> When a simple set of permissions fails to encapsulate the rules required for a device to make decisions about firmware, claims can be used instead.  Claims represent a form of policy.  Several claims can be used together, when multiple actors should have the rights to set policies. Some example claims are: </del> <ins> Claims in the manifest offer a way to convey instructions to a device that impact the firmware update process.  To have any value the manifest containing those claims must be authenticated and integrity protected.  The credential used to must be directly or indirectly related to the trust anchor installed at the device by the Trust Provisioning Authority. </ins> <del> Trust the actor identified by the referenced public key. Trust the actor with access to the referenced shared secret (MAC). Three actors are trusted identified by their public keys. Signatures from at least two of these actors are required to trust a manifest. The actor identified by the referenced public key is authorized to create secondary policies The baseline claims for all manifests are described in SUIT-IM.  In summary, they are: </del> <ins> The baseline claims for all manifests are described in I-D.ietf-suit- information-model.  For example, there are: </ins> Do not install firmware with earlier metadata than the current metadata.

Discussion:
Added David Brown as co-author Added further terms Updated text about permissions Re-wrote text about operating modes Editorial changes (including formatting) Revised section about claims Added new architecture figure Reworked security description Included device firmware update examples provided by David. Updated example flow (and included bootloader)