Original text:
A tag is considered "authoritative" if the CoSWID tag was created by the software provider.  An authoritative CoSWID tag contains <del> information about a software component provided by the maintainer of </del>  the software component, who is expected to be an expert in their own <del> software.  Thus, authoritative CoSWID tags can be trusted to represent authoritative information about the software component. </del>  A signed CoSWID tag (see coswid-cose) whose signature has been validated can be relied upon to be unchanged since it was signed.  By <del> contrast, the data contained in unsigned tags cannot be trusted to be unmodified. When an authoritative tag is signed, the software provider can be authenticated as the originator of the signature.  A trustworthy association between the signature and the originator of the signature can be established via trust anchors.  A certification path between a trust anchor and a certificate including a pub-key enabling the validation of a tag signature can realize the assessment of trustworthiness of an authoritative tag.  Having a signed authoritative CoSWID tag can be useful when the information in the tag needs to be trusted, such as when the tag is being used to convey reference integrity measurements for software components. </del>  CoSWID tags are intended to contain public information about software components and, as such, the contents of a CoSWID tag does not need

Reviewer comments:
Addressed the following comments: [Per IETF 110] Add text on the order of native CDDL approach for handling version is used. If a future version of SWID is published which alters the semantics of exists fields, a future version of CoSWID SHOULD (MUST?) use a different tag to represent it. [daw: A new paragraph was added to section 2 detailing how index values are used to support revisions and extensions.] [Per IETF 110] see -16. Use ISO SWID reference for the IANA registry and if desired, used [SEMVER] as an informal reference in the text [daw: This has been done in section 4.1.] [daw: The FIXME markers have been replaced with actual text.] [daw: Section 7 now details the construction of a signed CoSWID. A SHOULD sign requirement was also added to section 7.] [Per IETF 110] We discussed adding language on the order of "This document specifies a data format and an associated integrity mechanism agnostic of a deployment. Application which choose to use CoSWID will need to specify explicit guidance which security properties are needed and under which circumstances." > ** [-15] Section 6. Per "When an authoritative tag is signed, the software [daw: Authenticating the signer is the software provider will require a match between a CoSWID entity and the signer. We are working out a means to do this.] 2 [daw: Not sure which tags this applies to? Signing? All of section 2?] [daw: done.] [daw: This confusing text has been removed.] [daw: done.] [daw: We added a note about this.] [daw: Done.] [daw: Added signature validation as a way.] Regards, Roman

Revised text:
A tag is considered "authoritative" if the CoSWID tag was created by the software provider.  An authoritative CoSWID tag contains  <ins> information about a software component provided by the supplier of </ins> the software component, who is expected to be an expert in their own  <ins> software.  Thus, authoritative CoSWID tags can represent authoritative information about the software component.  The degree to which this information can be trusted depends on the tag's chain of custody and the ability to verify a signature provided by the supplier if present in the CoSWID tag.  The provisioning and validation of CoSWID tags are handled by local policy and is outside the scope of this document. </ins> A signed CoSWID tag (see coswid-cose) whose signature has been validated can be relied upon to be unchanged since it was signed.  By  <ins> contrast, the data contained in unsigned tags can be altered by any user or process with write-access to the tag.  To support signature validation, there is the need associate the right key with the software provider or party originating the signature.  This operation is application specific and needs to be addressed by the application or a user of the application; a specific approach for which is out- of-scope for this document. When an authoritative tag is signed, the originator of the signature can be verified.  A trustworthy association between the signature and the originator of the signature can be established via trust anchors. A certification path between a trust anchor and a certificate including a public key enabling the validation of a tag signature can realize the assessment of trustworthiness of an authoritative tag. Verifying that the software provider is the signer is a different matter.  This requires an association between the signature and the tag's entity item associated corresponding to the software provider. No mechanism is defined in this draft to make this association; therefore, this association will need to be handled by local policy. </ins> CoSWID tags are intended to contain public information about software components and, as such, the contents of a CoSWID tag does not need