Code change:
3.1. <del> A certain software component product is created and packaged by a Supplier.  The package by itself does not include a proof of authenticity.  A signing authority is tasked with adding a proof of authenticity.  Trustworthiness has to be established from the Supplier towards the Distributor - and vice versa.  The mutual trustworthiness relationship between Supplier and Distributor is established per each individual software component package. </del> <ins> Consumers wish to verify the authenticity and integrity of software they use before installation.  To do this today, they rely on the digital signature of the software.  This can be misleading, however, as there is no guarantee that the certificate used to sign the software is authorized by the Supplier for signing.  For example, a malicious actor may obtain a signing certificate from a reputable organization and use that certificate to sign malicious software. The consumer, believing the software originated from the reputable organization, would then install malicious software. </ins> <del> A consumer of a released software wants: </del> <ins> A consumer of software wants: </ins> <del> to understand and verify that an actual trustworthiness relationship exists between the Supplier of a certain software component package and the Distributor of that software component package. </del> <ins> to verify the authenticity and integrity of software they use before installation. </ins> There is no standardized way to: <del> enable the consumer to verify that a trustworthiness relationship for a certain software component package exists and is still valid. </del> <ins> enable the consumer to verify that software originated from a 'duly authorized signing party' on behalf of the Supplier. </ins> 3.2. <del> Authoritative entities, such as auditing or code-review companies, certification entities or government bodies, continuously produce statements about software products and identifiable software components.  Such statements can vouch for the trustworthiness of a software product or the lack thereof.  Consumers of these statements include entities, such as distributing entities, as well as end users.  There can be one or more entities that produce statements relevant to one or more of these consumer groups.  Discovery of all sources of statements and/or the identity of authoritative entities creates significant cost not all consumer groups can afford.  Some authoritative entities actively do not acknowledge other authoritative entities that highlight a lack of trustworthiness of certain released software products.  In the end, identifying all relevant statements from multiple sources typically ends up to be a responsibility of the consumer. A consumer of released software wants: </del> <ins> In IT industry it is a common practice that once a software product is released, it is evaluated on various aspects.  For example, an auditing company, a code review company or a government body will examine the software product and issue authoritative reports about the product.  The end users (consumers or distribution entities) use these report to make an accurate assessment as to whether the software product is deemed fit to use. There are multiple such authoritative bodies that make such assessments.  There is no assurance that all the bodies may be aware of statements from other authoritative entities or actively acknowledge them.  Discovery of all sources of such reports and/or identity of the authoritaitve bodies adds a significant cost to the end user or consumer of the product. A consumer of released software component wants: </ins> to offload the burden of identifying all relevant authoritative <del> entities to an entity who does this on their behalf </del> <ins> entities to an entity who does it on their behalf </ins> to offload the burden to filter from and select all statements <del> that are applicable to the released software product to an entity who does this on their behalf </del> <ins> that are applicable to a particular release of a multi release software product, to an entity who does this on their behalf </ins> <del> to make informed decisions on which authoritative entities to </del> <ins> to make an informed decisions on which authoritative entities to </ins> believe based on the best visibility of all authoritative entities possible There is no standardized way to: aggregate large numbers of related statements in one place and <del> discover them there </del> <ins> discover them </ins> referencing other statements via a statement

Related discussion:
text: NAME the revisions seem to place greater emphasis on package managers, removing the original intent. The original intent was much broader and could be applied to a wide swath of software distribution, i.e. GitHub, app stores, and package manager repos.
Sure, we can broaden the scope. Not a problem!
We had a detail discussion about this between me and Henk. Basically, I was all for the support of going to depict a real world example for each of the situation. However, this makes the document excessively long and verbose. We should make a judgment as a team as to: Where should the Use Case document reside ? Some members feel within Arch. Document, some feel as a separate RFC. Given the number of scenarios, should we abstract it to generic use case or we depict a specific example, next to each of them ? Is too long a document (when a separate RFC) acceptable to the group ?
NAME NAME NAME I have redone the PR post our meeting today. Please have a look..
This has been resolved now!
great improvements