Code change:
3.7. <del> 3.7.1. </del> Firmware is a critical component for successful execution of any constrained IoT device.  It is often the bedrock on which the <del> security story of the devices it powers. Personal health monitoring devices, i.e., eHealth devices, are generally battery driven and offer health telemetry monitoring, such as temperature, blood pressure, and pulse rate.  These devices typically connect to the Internet through an intermediary base station using wireless technologies.  Through this connection, the telemetry data and analytics transfer, and devices receive firmware updates when published by the vendor.  The public network, open distribution system, and firmware update process create several security challenges. </del> <ins> security story of the devices it powers.  For example, personal health monitoring devices (eHealth devices) are generally battery driven and offer health telemetry monitoring, such as temperature, blood pressure, and pulse rate.  These devices typically connect to the Internet through an intermediary base station using wireless technologies.  Through this connection, the telemetry data and analytics transfer, and devices receive firmware updates when published by the vendor.  The public network, open distribution system, and firmware update process create several security challenges. Consumers and other interested parties of a firmware update ecosystem wants: to know that the received firmware for system update is not faulty or malicious to know if the signing identity used to assert the authenticity of the firmware is somehow used to sign unintended updates to ascertain that the released firmware is not subverted or compromised due to an insider risk - be it malicious or otherwise to confirm that the publishers know if their deliverable has been compromised.  Can they trust their key protection or audit logging? </ins> <del> Today, the best-in-class firmware vendors who supply the firmware also provide an update framework, which verifies the integrity and authenticity of firmware updates before allowing installation. </del> <ins> to know how the update client on an instance of a health monitoring system discerns a general update from one specially crafted for just a small subset of a fleet of devices </ins> <del> The various stake holders of a firmware update system wants to ascertain: </del> <ins> There is no standardized way to: </ins> <del> How does the client applying the firmware update on the system know that the received firmware is not faulty or malicious? </del> <ins> provide an update framework that allows validation of authenticity of firmware revisions </ins> <del> What if the signing identity used to assert the authenticity of the firmware is somehow used to sign unintended updates? </del> <ins> to verify that the firmware update seen by a single device, is indeed the same as seen by all the devices. </ins> <del> How can one ascertain that the released firmware is not subverted or compromised due to an insider risk - be it malicious or otherwise? </del> <ins> reliably discern an update that has been signed by the appropriate and intended signing identity </ins> <del> How does the publisher even know that their deliverable has been compromised?  Can they trust their key protection or audit logging? How does the update client on an instance of a health monitoring system know that they have been given the same update as all other devices or one specially crafted for just a small subset of a fleet of devices? </del> <ins> Make an informed judgement on all available information about firmware at the install time.  For example, the firmware is still in a good state or otherwise? </ins> 3.8. Software Integration is a complex activity.  This typically involves getting various software components from multiple suppliers and producing an integrated package deployed as part of device assembly. <ins> For example, car manufacturers source integrated software for their autonomous vehicles from third parties that integrates software components from various sources.  Integration complexity creates a higher risk of security vulnerabilities to the delivered software. </ins> <del> Car manufacturers source integrated software for their autonomous vehicles from third parties that integrates software components from various sources.  Integration complexity creates a higher risk of security vulnerabilities to the delivered software. 3.8.1. While the software runs on the automated vehicle, periodic vulnerability scanning software detects a known security issue with one component.  End User gets a "Warning Indicator" on the dashboard.  As a result it reports the problem to the car manufacturer.  It is then subsequently notified to the integrator. Integrator analysis leads to a suspected issue with the supplied Operating System (OS) software from an Independent Software Vendor (ISV).  It demands specific environment and architectural details associated with the built OS binary to ascertain that the software was produced without tampering by Vendor </del> <ins> Consumer of an integrated software wants: </ins> <del> Unfortunately, there is no way for the integrator to know if the binary was compromised, so the integrator is concerned they may have delivered malware unknowingly to their customers. </del> <ins> all components presents in a software product listed, and the ability to identify and retrieve them from a secure and tamperproof location </ins> <del> ISV attempts to show that it did all the steps correctly.  It does disclose information about the binary they delivered.  In addition, they also reveal their build environment and the architecture they used during the build. </del> <ins> to receive an alert when a vulnerability scan detects a known security issue on a running software component </ins> <del> However, there are no "Verifiable Proofs" of the statement made by ISV.  All the stakeholders, in the ecosystem (end user, car manufacturer and the integrator) has to trust without any ability to verify the claims made by the ISV. </del> <ins> verifiable proofs on build process and build environment with all supplier tiers to ensure end to end build quality and security </ins> <del> This eventually leads to a loss of reputation and company closure for Vendor OS-X. 4. Consumers want to verify the authenticity and integrity of software they use before installation (4.1.1) Consumers want to obtain statements from producers and third- parties related to the software product in a timely and unambiguous fashion (4.2.1) Consumers want to attribute statements to an authoritative issuer (4.2.2) Consumers want to associate statements with other statements in a meaningful manner (4.2.3) Consumers want to consistently, efficiently, and homogeneously check the authenticity of statements (4.2.4) Consumers want to understand if a particular provider is actually the original provider or a promoter (4.3.1) Consumers want to know if and how the source, or resulting binary, of a promoted software component differs from the original software component (4.3.2) </del> <ins> There is no standardized way to: </ins> <del> Consumers want to check the provenance and history of a software component's source back to its origin (4.3.3) </del> <ins> provide a tiered and transparent framework that allows for verification of integrity and authenticity of the integrated software at both component and product level before installation </ins> <del> Consumers want to assess whether to trust a promoter or not (4.3.4) </del> <ins> notify software integrators of vulnerabilities identified during security scans of running software </ins> <del> Consumers and other stakeholders in the system wants to verify the claims made by a software supplier by recreating the build environment to ascertain that the delivered binary is precisely the same one as claimed by the supplier </del> <ins> provide valid annotations on build integrity to ensure conformance </ins>

Related discussion:
text: Updated firmware and Software integrator use case to the same format as the ones above.
Please add "and is still valid" - see new proposed langauge enable the consumer to verify that software originated from a 'duly authorized signing party' on behalf of the Supplier, and is still valid
+1 to this change
Closing as been addressed now!
I have no concerns with the revised language for 3.1. One minor nit on 3.2 to be consistent with the use case title REPLACE: A consumer of released software component wants: WITH A consumer of released software product wants:
LGTM
This issue has been resolved in the above PR.