Draft: draft-ietf-sacm-coswid

Commentary: Addressed comments from Alex , Ira and Carsten . 
 I agree with all of  's comments , which are not addressed by this current merge and have to be addressed after merging . There are some new rage definitions for values , e.g. -256 - ( if I remember correctly ) these can be include in the CDDL specification with controls . Text improvement is significant and strongly accepted .
Paragraph (version A):
typical SWID tag.  This reduction is enabled through the use of CBOR,
which maps the human-readable labels of SWID data items to more
concise integer labels (indices).  The use of CBOR to express SWID
information in CoSWID tags allows both CoSWID and SWID tags to be
part of an enterprise security solution for a wider range of
endpoints and environments.
Paragraph (version B):
typical SWID tag.  This reduction is enabled through the use of the
Concise Binary Object Representation (CBOR) RFC7049, which maps the
human-readable labels of SWID data items to more concise integer
labels (indices).  The use of CBOR to express SWID information in
CoSWID tags allows both CoSWID and SWID tags to be part of an
enterprise security solution for a wider range of endpoints and
environments.
Paragraph (version A):
This document defines the CoSWID tag format, which is based on the
Concise Binary Object Representation (CBOR) RFC7049.  CBOR-based
CoSWID tags offer a more concise representation of SWID information
as compared to the XML-based SWID tag representation in ISO-
19770-2:2015.  The structure of a CoSWID is described via the Concise
Data Definition Language (CDDL) RFC8610.  The resulting CoSWID data
definition is aligned to the information able to be expressed with
the XML schema definition of ISO-19770-2:2015 SWID.  This alignment
allows both SWID and CoSWID tags to represent a common set of
software component information and allows CoSWID tags to support the
same uses as a SWID tag.  To achieve this end, the CDDL
representation includes every SWID tag field and attribute.
Paragraph (version B):
This document defines the CoSWID tag format, which is based on CBOR.
CBOR-based CoSWID tags offer a more concise representation of SWID
information as compared to the XML-based SWID tag representation in
ISO-19770-2:2015.  The structure of a CoSWID is described via the
Concise Data Definition Language (CDDL) RFC8610.  The resulting
CoSWID data definition is aligned to the information able to be
expressed with the XML schema definition of ISO-19770-2:2015 SWID.
This alignment allows both SWID and CoSWID tags to represent a common
set of software component information and allows CoSWID tags to
support the same uses as a SWID tag.  To achieve this end, the CDDL
representation includes every SWID tag field and attribute.
Paragraph (version A):
Note that sometimes CoSWID CDDL attribute names show greater
variation than the described notation change relative to their
corresponding SWID XML Schema attributes.  This is done when the
change improves clarity in the specification.  For example the "name"
and "version" SWID fields corresponds to the "software-name" and
"software-version" CoSWID fields, respectively.  As such, it is not
always possible to mechanically translate between corresponding
attribute names in the two formats.
Paragraph (version B):
In most cases, mapping attribute names between SWID and CoSWID can be
done automatically by converting between CamelCase and KebabCase
attribute names.  However, some CoSWID CDDL attribute names show
greater variation relative to their corresponding SWID XML Schema
attributes.  This is done when the change improves clarity in the
specification.  For example the "name" and "version" SWID fields
corresponds to the "software-name" and "software-version" CoSWID
fields, respectively.  As such, it is not always possible to
mechanically translate between corresponding attribute names in the
two formats.  In such cases, a manual mapping will need to be used.
Paragraph (version A):
The CDDL rule above allows either a single data item or an array of 2
or more data values to be provided.  When a singleton data value is
provided, the CBOR markers for the array, array length, and stop
point are not needed saving bytes.  When two or more data values are
provided, these values are encoded as an array.  This modeling
pattern is used frequently in the CoSWID CDDL data definition to
allow for more efficient encoding of singleton values.
Paragraph (version B):
The CDDL rule above allows either a single data item or an array of 2
or more data values to be provided.  When a singleton data value is
provided, the CBOR markers for the array, array length, and stop
point are not needed, saving bytes.  When two or more data values are
provided, these values are encoded as an array.  This modeling
pattern is used frequently in the CoSWID CDDL data definition to
allow for more efficient encoding of singleton values.
Paragraph (version A):
The explicit definition of types for attributes that are typically
stored in the "any attribute" of an ISO-19770-2:2015 in XML
representation.  These are covered in model-global-attributes.
Paragraph (version B):
The CDDL "text" type is represented in CBOR as a major type 3, which
represents "a string of Unicode characters that [are] encoded as
UTF-8 RFC3629" (see RFC7049 section 2.1).  Thus both SWID and CoSWID
use UTF-8 for the encoding of characters in text strings.
Paragraph (version B):
To ensure that UTF-8 character strings are able to be encodes/decoded
and exchanged interoperably, text strings in CoSWID MUST be encoded
consistent with the Net-Unicode definition defined in RFC5198.
Paragraph (version B):
All names registered with IANA according to requirements in section
iana-value-registries also need to be valid according to the XML
Schema NMToken data type (see W3C.REC-xmlschema-2-20041028 section
3.3.4) to ensure compatibility with the SWID specification where
these names are used.
Paragraph (version B):
The explicit definition of types for attributes that are typically
represented in the "any attribute" of some XML elements in the
ISO-19770-2:2015 XML representation.  These are covered in model-
global-attributes.
Paragraph (version A):
tag-id (index 0): A textual identifier uniquely referencing a
software component.  The tag identifier MUST be globally unique.
There are no strict guidelines on how this identifier is
structured, but examples include a 16 byte GUID (e.g.  class 4
UUID) RFC4122, or a text string appended to a DNS domain name to
ensure uniqueness across organizations.
Paragraph (version B):
tag-id (index 0): A 16 byte binary string or textual identifier
uniquely referencing a software component.  The tag identifier
MUST be globally unique.  If represented as a 16 byte binary
string, the identifier MUST be a valid universally unique
identifier as defined by RFC4122.  There are no strict guidelines
on how this identifier is structured, but examples include a 16
byte GUID (e.g.  class 4 UUID) RFC4122, or a text string appended
to a DNS domain name to ensure uniqueness across organizations.
Paragraph (version A):
version-scheme (index 14): An 8-bit integer or textual value
representing the versioning scheme used for the software-version
item.  If an integer value is used it MUST be a value from the
SWID/CoSWID Version Scheme Value Registry (see section iana-
version-scheme or a value in the private use range: 32768-65535.
Paragraph (version A):
An initial set of version-scheme index and text values are defined in
indexed-version-scheme, and are based on the version-scheme values
defined in SWID.  These pre-defined version-scheme values are
registered with IANA in the "SWID/CoSWID Version Scheme Value"
registry iana-version-scheme.  The values in this registry will
likely be expanded in the future.
Paragraph (version A):
The index (preferred) or string value of a role from the IANA in
the "SWID/CoSWID Version Scheme Value" registry.
Paragraph (version A):
An index value in the range 32768 through 65535, to indicate that
a private use index value is used.
Paragraph (version A):
A string value prefixed with "x_", to indicate that a private use
string value is used.
Paragraph (version B):
version-scheme (index 14): An integer or textual value
representing the versioning scheme used for the software-version
item.  If an integer value is used it MUST be an index value in
the range -256 to 65535.  Integer values in the range -256 to -1
are reserved for testing and use in closed environments (see
section iana-private-use).  Integer values in the range 0 to 65535
correspond to registered entries in the IANA "SWID/CoSWID Version
Scheme Value" registry (see section iana-version-scheme.  If a
string value is used it MUST be a private use name as defined in
section iana-private-use.  String values based on a Version Scheme
Name from the IANA "SWID/CoSWID Version Scheme Value" registry
MUST NOT be used, as these values are less concise than their
index value equivalent.
Paragraph (version A):
If the patch item is set to "true", the tag SHOULD contain at
least one link item with both the rel(ation) item value of
"patches" and an href item specifying an association with the
software that was patched.
Paragraph (version B):
If the patch item is set to "true", the tag SHOULD contain at
least one link item (see section model-link) with both the
rel(ation) item value of "patches" and an href item specifying an
association with the software that was patched.
Paragraph (version A):
role (index 33): The relationship(s) between the entity, and this
tag or the referenced software component.  Use of index values
instead of text for these pre-defined roles allows a CoSWID to be
more concise.
Paragraph (version A):
An initial set of role index and text values are defined in
indexed-entity-role, and are based on the roles defined in SWID.
These pre-defined roles are registered with IANA in the "SWID/
CoSWID Entity Role Value" registry iana-entity-role.  The values
in this registry will likely be expanded in the future.
Paragraph (version A):
The index (preferred) or string value of a role from the IANA
in the "SWID/CoSWID Entity Role Value" registry.
Paragraph (version B):
role (index 33): An integer or textual value representing the
relationship(s) between the entity, and this tag or the referenced
software component.  If an integer value is used it MUST be an
index value in the range -256 to 255.  Integer values in the range
-256 to -1 are reserved for testing and use in closed environments
(see section iana-private-use).  Integer values in the range 0 to
255 correspond to registered entries in the IANA "SWID/CoSWID
Entity Role Value" registry (see section iana-entity-role.  If a
string value is used it MUST be a private use name as defined in
section iana-private-use.  String values based on a Role Name from
the IANA "SWID/CoSWID Entity Role Value" registry MUST NOT be
used, as these values are less concise than their index value
equivalent.
Paragraph (version A):
a URI with "swid:" as the scheme, which refers to another SWID
or CoSWID by tag-id.  This URI would need to be resolved in the
context of the endpoint by software that can lookup other SWID
or CoSWID tags.  For example, "swid:2df9de35-0aff-
4a86-ace6-f7dddd1ade4c" references the tag with the tag-id
value "2df9de35-0aff-4a86-ace6-f7dddd1ade4c".
Paragraph (version B):
a URI with "swid:" as the scheme refers to another SWID or
CoSWID by the referenced tag's tag-id.  This URI needs to be
resolved in the context of the endpoint by software that can
lookup other SWID or CoSWID tags.  For example, "swid:2df9de35-
0aff-4a86-ace6-f7dddd1ade4c" references the tag with the tag-id
value "2df9de35-0aff-4a86-ace6-f7dddd1ade4c".
Paragraph (version A):
ownership (index 39): Used when the "href" item references another
software component to indicate the degree of ownership between the
software component referenced by the COSWID tag and the software
component referenced by the link.
Paragraph (version A):
An initial set of ownership index and text values are defined in
indexed-link-ownership, and are based on the ownership values
defined in SWID.  These pre-defined ownership values are
registered with IANA in the "SWID/CoSWID Link Ownership Value"
registry iana-link-ownership.  The values in this registry will
likely be expanded in the future.
Paragraph (version A):
The index (preferred) or string value of a role from the IANA
in the "SWID/CoSWID Link Ownership Value" registry.
Paragraph (version A):
rel (index 40): Identifies the relationship between this CoSWID
and the target resource indicated by the "href" item.
Paragraph (version A):
An initial set of rel index and text values are defined in
indexed-link-rel, and are based on the rel values defined in SWID.
These pre-defined rel values are registered with IANA in the
"SWID/CoSWID Link Relationship Value" registry iana-link-rel.  The
values in this registry will likely be expanded in the future.
Paragraph (version A):
The index (preferred) or string value of a role from the IANA
in the "SWID/CoSWID Link Relationship Value" registry.
Paragraph (version A):
A string value, as defined by RFC8288, corresponding to a
"Relation Name" from the IANA "Link Relation Types" registry:
https://www.iana.org/assignments/link-relations/link-
relations.xhtml.  When a string value defined in the IANA
"SWID/CoSWID Link Relationship Value" registry matches a
Relation Name defined in the IANA "Link Relation Types"
registry, the value in the IANA "SWID/CoSWID Link Relationship
Value" registry MUST be used instead, as this relationship has
a specialized meaning in the context of a SWID/CoSWID tag.
Paragraph (version B):
ownership (index 39): An integer or textual value used when the
"href" item references another software component to indicate the
degree of ownership between the software component referenced by
the COSWID tag and the software component referenced by the link.
If an integer value is used it MUST be an index value in the range
-256 to 255.  Integer values in the range -256 to -1 are reserved
for testing and use in closed environments (see section iana-
private-use).  Integer values in the range 0 to 255 correspond to
registered entries in the IANA "SWID/CoSWID Link Ownership Value"
registry (see section iana-link-ownership.  If a string value is
used it MUST be a private use name as defined in section iana-
private-use.  String values based on a Ownership Type Name from
the IANA "SWID/CoSWID Link Ownership Value" registry MUST NOT be
used, as these values are less concise than their index value
equivalent.
Paragraph (version B):
rel (index 40): An integer or textual value that identifies the
relationship between this CoSWID and the target resource
identified by the "href" item.  If an integer value is used it
MUST be an index value in the range -256 to 65535.  Integer values
in the range -256 to -1 are reserved for testing and use in closed
environments (see section iana-private-use).  Integer values in
the range 0 to 65535 correspond to registered entries in the IANA
"SWID/CoSWID Link Relationship Value" registry (see section iana-
link-rel.  If a string value is used it MUST be either a private
use name as defined in section iana-private-use or a "Relation
Name" from the IANA "Link Relation Types" registry:
https://www.iana.org/assignments/link-relations/link-
relations.xhtml as defined by RFC8288.  When a string value
defined in the IANA "SWID/CoSWID Link Relationship Value" registry
matches a Relation Name defined in the IANA "Link Relation Types"
registry, the index value in the IANA "SWID/CoSWID Link
Relationship Value" registry MUST be used instead, as this
relationship has a specialized meaning in the context of a SWID/
CoSWID tag.  String values based on a Relationship Type Name from
the IANA "SWID/CoSWID Link Relationship Value" registry MUST NOT
be used, as these values are less concise than their index value
equivalent.
Paragraph (version A):
use (index 42): Determines if the referenced software component
has to be installed before installing the software component
identified by the tag.
Paragraph (version A):
An initial set of use index and text values are defined in
indexed-link-use, and are based on the use values defined in SWID.
These pre-defined use values are registered with IANA in the
"SWID/CoSWID Link Use Value" registry iana-link-use.  The values
in this registry will likely be expanded in the future.
Paragraph (version A):
The index (preferred) or string value of a role from the IANA
in the "SWID/CoSWID Link Use Value" registry.
Paragraph (version B):
use (index 42): An integer or textual value used to determine if
the referenced software component has to be installed before
installing the software component identified by the COSWID tag.
If an integer value is used it MUST be an index value in the range
-256 to 255.  Integer values in the range -256 to -1 are reserved
for testing and use in closed environments (see section iana-
private-use).  Integer values in the range 0 to 255 correspond to
registered entries in the IANA "Link Use Value Value" registry
(see section iana-link-use.  If a string value is used it MUST be
a private use name as defined in section iana-private-use.  String
values based on an Link Use Type Name from the IANA "SWID/CoSWID
Link Use Value" registry MUST NOT be used, as these values are
less concise than their index value equivalent.
Paragraph (version A):
description (index 46): A textual value that provides a detailed
description of the software component.  This value MAY be multiple
sentences.
Paragraph (version A):
edition (index 47): A textual value indicating that the software
component represents a functional variation of the code base used
to support multiple software components.  For examplem, this item
can be used to differentiate enterprise, standard, or professional
variants of a software component.
Paragraph (version B):
description (index 46): A textual value that provides a detailed
description of the software component.  This value MAY be multiple
paragraphs seperated by CR LF characters as described by RFC5198.
Paragraph (version B):
edition (index 47): A textual value indicating that the software
component represents a functional variation of the code base used
to support multiple software components.  For example, this item
can be used to differentiate enterprise, standard, or professional
variants of a software component.
Paragraph (version A):
unspsc-code (index 56): An 8 digit UNSPSC classification code for
the software component.  For more information see,
http://www.unspsc.org/.
Paragraph (version B):
unspsc-code (index 56): An 8 digit UNSPSC classification code for
the software component.  For more information see
https://www.unspsc.org/.
Paragraph (version A):
path-elements (index 26): This group allows a heirarchy of
directory and file items to be defined in payload or evidence
items.
Paragraph (version B):
path-elements (index 26): This group allows a hierarchy of
directory and file items to be defined in payload or evidence
items.
Paragraph (version A):
The values above are registered in the IANA "SWID/CoSWID Version
Scheme Value" registry defined in section iana-version-scheme.
Additional values will likely be registered over time in this
registry.  Additionally, the index values 32768 through 65535 and the
name prefix "x_" have been reserved for private use.
Paragraph (version B):
The values above are registered in the IANA "SWID/CoSWID Version
Scheme Value" registry defined in section iana-version-scheme.
Additional entries will likely be registered over time in this
registry.
Paragraph (version B):
"decimal" and "multipartnumeric" partially overlap in their value
space when a value matches a decimal number . When a corresponding
software-version item's value falls within this overlapping value
space, the "decimal" version scheme SHOULD be used.
Paragraph (version B):
"multipartnumeric" and "semver" partially overlap in their value
space when a "multipartnumeric" value matches the semantic
versioning syntax.  When a corresponding software-version item's
value falls within this overlapping value space, the "semver"
version scheme SHOULD be used.
Paragraph (version B):
"alphanumeric" and other version schemes might overlap in their
value space.  When a corresponding software-version item's value
falls within this overlapping value space, the other version
scheme SHOULD be used instead of "alphanumeric".
Paragraph (version A):
This document uses unsigned 16-bit index values to represent version-
scheme item values.  The initial set of version-scheme values are
derived from the textual version scheme names defined in the ISO/IEC
19770-2:2015 specification SWID.
Paragraph (version A):
Initial registrations for the "SWID/CoSWID Version Scheme Value"
registry are provided below.  Assignments consist of an integer Index
value, the Version Scheme Name, and a reference to the defining
specification.
Paragraph (version A):
This document uses unsigned 8-bit index values to represent entity-
entry role item values.  The initial set of Entity roles are derived
from the textual role names defined in the ISO/IEC 19770-2:2015
specification SWID.
Paragraph (version A):
Initial registrations for the "SWID/CoSWID Entity Role Value"
registry are provided below.  Assignments consist of an integer Index
value, a Role Name, and a reference to the defining specification.
Paragraph (version A):
This document uses unsigned 8-bit index values to represent link-
entry ownership item values.  The initial set of Link ownership
values are derived from the textual ownership names defined in the
ISO/IEC 19770-2:2015 specification SWID.
Paragraph (version A):
Initial registrations for the "SWID/CoSWID Link Ownership Value"
registry are provided below.  Assignments consist of an integer Index
value, an Ownership Type Name, and a reference to the defining
specification.
Paragraph (version A):
This document uses unsigned 16-bit index values to represent link-
entry rel item values.  The initial set of rel values are derived
from the textual rel names defined in the ISO/IEC 19770-2:2015
specification SWID.
Paragraph (version A):
Initial registrations for the "SWID/CoSWID Link Relationship Value"
registry are provided below.  Assignments consist of an integer Index
value, the Relationship Type Name, and a reference to the defining
specification.
Paragraph (version A):
This document uses unsigned 8-bit index values to represent link-
entry use item values.  The initial set of Link use values are
derived from the textual names defined in the ISO/IEC 19770-2:2015
specification SWID.
Paragraph (version A):
Initial registrations for the "SWID/CoSWID Entity Role Value"
registry are provided below.  Assignments consist of an integer Index
value, the Link Use Type Name, and a reference to the defining
specification.
Paragraph (version B):
The following registries allow for the registration of index values
and names.  New registrations will be permitted through either the
Standards Action policy or the Specification Required policy BCP26.
The latter SHOULD be used only for registrations requested by SDOs
outside the IETF.  New index values will be provided on a First Come
First Served as defined by BCP26.
Paragraph (version B):
The following registries also reserve the integer-based index values
in the range of -1 to -256 for private use as defined by BCP26 in
section 4.1.  This allows values -1 to -24 to be expressed as a
single uint_8t in CBOR, and values -25 to -256 to be expressed using
an additional uint_8t in CBOR.
Paragraph (version B):
The integer-based index values in the private use range (-1 to -256)
are intended for testing purposes and closed environments; values in
other ranges SHOULD NOT be assigned for testing.
Paragraph (version B):
Where "domain.prefix" MUST be a valid Internationalized Domain Name
as defined by RFC5892, and "name" MUST be a unique name within the
namespace defined by the "domain.prefix".  Use of a prefix in this
way allows for a name to be used initially in the private use range,
and to be registered at a future point in time.  This is consistent
with the guidance in BCP178.
Paragraph (version B):
The requesting specification MUST provide a clear semantic
definition for the new entry.  This definition MUST clearly
differentiate the requested entry from other previously registered
entries.
Paragraph (version B):
The requesting specification MUST describe the intended use of the
entry, including any co-constraints that exist between the use of
the entry's index value or name, and other values defined within
the SWID/CoSWID model.
Paragraph (version B):
Index values and names outside the private use space MUST NOT be
used without registration.  This is considered squatting and
SHOULD be avoided.  Designated experts MUST ensure that reviewed
specifications register all appropriate index values and names.
Paragraph (version B):
Standards track documents MAY include entries registered in the
range reserved for entries under the Specification Required
policy.  This can occur when a standards track document provides
further guidance on the use of index values and names that are in
common use, but were not registered with IANA.  This situation
SHOULD be avoided.
Paragraph (version B):
All registered names MUST be valid according to the XML Schema
NMTOKEN data type (see W3C.REC-xmlschema-2-20041028 section
3.3.4).  This ensures that registered names are compatible with
the SWID format SWID where they are used.
Paragraph (version B):
Registration of vanity names SHOULD be discouraged.  The
requesting specification MUST provide a description of how a
requested name will allow for use by multiple stakeholders.
Paragraph (version B):
This document defines a new a new registry titled "SWID/CoSWID
Version Scheme Values".  This registry provides index values for use
as version-scheme item values in this document and version scheme
names for use in SWID.
Paragraph (version B):
Assignments MUST consist of an integer Index value, the Version
Scheme Name, and a reference to the defining specification.
Paragraph (version B):
Initial registrations for the "SWID/CoSWID Version Scheme Value"
registry are provided below, which are derived from the textual
version scheme names defined in SWID.
Paragraph (version B):
Designated experts MUST also ensure that newly requested entries
define a value space for the corresponding version item that is
unique from other previously registered entries.  Note: The inital
registrations violate this requirement, but are included for
backwards compatibility with SWID.  Guidelines on how to deconflict
these value spaces are defined in section indexed-version-scheme.
Paragraph (version B):
This document defines a new a new registry titled "SWID/CoSWID Entity
Role Values".  This registry provides index values for use as entity-
entry role item values in this document and entity role names for use
in SWID.
Paragraph (version B):
Assignments consist of an integer Index value, a Role Name, and a
reference to the defining specification.
Paragraph (version B):
Initial registrations for the "SWID/CoSWID Entity Role Value"
registry are provided below, which are derived from the textual
entity role names defined in SWID.
Paragraph (version B):
This document defines a new a new registry titled "SWID/CoSWID Link
Ownership Values".  This registry provides index values for use as
link-entry ownership item values in this document and link ownership
names for use in SWID.
Paragraph (version B):
Assignments consist of an integer Index value, an Ownership Type
Name, and a reference to the defining specification.
Paragraph (version B):
Initial registrations for the "SWID/CoSWID Link Ownership Value"
registry are provided below, which are derived from the textual
entity role names defined in SWID.
Paragraph (version B):
This document defines a new a new registry titled "SWID/CoSWID Link
Relationship Values".  This registry provides index values for use as
link-entry rel item values in this document and link ownership names
for use in SWID.
Paragraph (version B):
Assignments consist of an integer Index value, the Relationship Type
Name, and a reference to the defining specification.
Paragraph (version B):
Initial registrations for the "SWID/CoSWID Link Relationship Value"
registry are provided below, which are derived from the link
relationship values defined in SWID.
Paragraph (version B):
Designated experts MUST also ensure that a newly requested entry
documents the URI schemes allowed to be used in an href associated
with the link relationship and the expected resolution behavior of
these URI schemes.  This will help to ensure that SWID/CoSWID
applications are able to interoperate when resolving resources
referenced by a link of a given type.
Paragraph (version B):
This document defines a new a new registry titled "SWID/CoSWID Link
Use Values".  This registry provides index values for use as link-
entry use item values in this document and link use names for use in
SWID.
Paragraph (version B):
Assignments consist of an integer Index value, the Link Use Type
Name, and a reference to the defining specification.
Paragraph (version B):
Initial registrations for the "SWID/CoSWID Link Use Value" registry
are provided below, which are derived from the link relationship
values defined in SWID.
Paragraph (version B):
The ISO 19770-2:2015 SWID specification describes use of the "swid"
and "swidpath" URI schemes, which are currently in use in
implementations.  This document continues this use for CoSWID.  The
following subsections provide registrations for these schemes in to
ensure that a permanent registration exists for these schemes that is
suitable for use in the SWID and CoSWID specifications.
Paragraph (version B):
SWID or CoSWID by the referenced tag's tag-id.  This URI needs to be
resolved in the context of the endpoint by software that can lookup
other SWID or CoSWID tags.  For example, "swid:2df9de35-0aff-
4a86-ace6-f7dddd1ade4c" references the tag with the tag-id value
"2df9de35-0aff-4a86-ace6-f7dddd1ade4c".
Paragraph (version B):
There is a need for a scheme name that can be used in URIs that point
to a specific SWID/CoSWID tag by that tag's tag-id, such as the use
of the link entry as described in section model-link) of this
document.  Since this scheme is used in a standards track document
and an ISO standard, this scheme needs to be used without fear of
conflicts with current or future actual schemes.  The scheme "swid"
is hereby registered as a 'permanent' scheme for that purpose.
Paragraph (version B):
Scheme syntax: The scheme speific part consists of a SWID or CoSWID
tag's tag-id that is URI encoded according to RFC3986 section 2.1.
For example, <swid:2df9de35-0aff-4a86-ace6-f7dddd1ade4c> is valid.
Paragraph (version B):
Scheme semantics: URIs in the "swid" scheme are to be used to
reference a SWID or CoSWID tag by its tag-id.  A tag-id referenced in
this way can be used to indentify the tag resource in the context of
where it is referenced from.  For example, when a tag is installed on
a given device, that tag can reference related tags on the same
device using this URI scheme.
Paragraph (version B):
There is a need for a scheme name that can be used in URIs to
indentify a collection of specific SWID/CoSWID tags with data
elements that match an XPath expression, such as the use of the link
entry as described in section model-link) of this document.  Since
this scheme is used in a standards track document and an ISO
standard, this scheme needs to be used without fear of conflicts with
current or future actual schemes.  The scheme "swidpath" is hereby
registered as a 'permanent' scheme for that purpose.
Paragraph (version B):
Scheme syntax: The scheme speific part consists of an XPath
expression as defined by W3C.REC-xpath20-20101214.  The included
XPath expression will be URI encoded according to RFC3986 section
2.1.
Paragraph (version B):
Scheme semantics: URIs in the "swidpath" scheme are to be used
specify the data that must be found in a given SWID/CoSWID tag for
that tag to be considered a matching tag to be included in the
identified tag collection.  Tags to be evaluated include all tags in
the context of where the tag is referenced from.  For example, when a
tag is installed on a given device, that tag can reference related
tags on the same device using this URI scheme.  A tag is matching if
the XPath evaluation result value has an effective boolean value of
"true" according to W3C.REC-xpath20-20101214 section 2.4.3.  rence
related tags on the same device using this URI scheme.
Paragraph (version B):
Where TAG_CREATOR_REGID is the reg-id ietm value of the tag's entity
item having the role value of 1 (corresponding to "tag creator"), and
the UNIQUE_ID is the same tag's tag-id item.  If the tag-id item's
value is expressed as a 16 byte binary string, the the UNIQUE_ID MUST
be represented using the UUID string representation defined in
RFC4122 including the "urn:uuid:" prefix.
Paragraph (version B):
The TAG_CREATOR_REGID and the UNIQUE_ID are connected with a double
underscore (_), without any other connecting character or whitespace.
Paragraph (version A):
A signed SWID/CoSWID tag whose signature has been validated can be
relied upon to be unchanged since it was signed.  If the SWID/CoSWID
tag was created by the software provider, is signed, and the software
provider can be authenticated as the originator of the signature,
then the tag can be considered authoritative.  In this way, an
authoritative SWID/CoSWID tag contains information about a software
component provided by the maintainer of the software component, who
is expected to be an expert in their own software.  Thus,
authoritative SWID/CoSWID tags can be trusted to represent
authoritative information about the software component.  Having an
authoritative SWID/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.  By
contrast, the data contained in unsigned tags cannot be trusted to be
unmodified.
Paragraph (version B):
A tag is cnsidered "authoritative" if the SWID/CoSWID tag was created
by the software provider.  An authoritative SWID/CoSWID tag contains
information about a software component provided by the maintainer of
the software component, who is expected to be an expert in their own
software.  Thus, authoritative SWID/CoSWID tags can be trusted to
represent authoritative information about the software component.
Paragraph (version B):
A signed SWID/CoSWID tag (see appendix-cose) whose signature has been
validated can be relied upon to be unchanged since it was signed.  By
contrast, the data contained in unsigned o tags cannot be trusted to
be unmodified.
Paragraph (version B):
When an authoritative tag is signed, the software provider can be
authenticated as the originator of the signature.  Having a signed
authoritative SWID/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.
Paragraph (version B):
This document draws heavily on the concepts defined in the ISO/IEC
19770-2:2015 specification.  The authors of this document are
greatful for the prior work of the 19770-2 contributors.
Paragraph (version B):
We are also grateful to the careful reviews provided by ...