Draft: draft-ietf-sacm-coswid

Commentary: There still might be a few cases left , where the value is text , but semantically it is a type - choice / enumeration . This should be double checked before meeting 102 . 
 Used role ( label 33 ) & rel ( label 40 ) as proposal by example . The roles & rels type - choices still require an extension - point , I assume . media ( label 10 ) is currently a text value with a semantic that is a tad bit more complex than a type - choice : " EXPRESSION [ [ OPERATOR ] [ EXPRESSION ] ... ] " , where EXPRESSION can be a simple type - choice .... or ... " ( [ PREFIX-]ENVIRONMENT.ATTRIBUTE : VALUE ) " ... and so on and on .... I propose to deal with .... that in cddl , too . Also , the definition of rel seems to be wrong at the moment , as every SWID enumeration is actually NOT defined in This needs fixing . 
 Addressed ( with the exception of ) . Leaving this open to be closed at SACM WG session in BKK . 
 Some cardinalities are out - of - sync . These need to be reviewed and synced up . 
 Yes :-) , the current ISO text , and the actual intend the ISO spec authors wanted to convey have to be assessed and aligned in the final draft . We are close , but I might have introduced a " wishful - thinking " error wrt to payload & evidence quantities in the current CDDL . The editors should resolve this as soon as possible and provide a candidate for final draft for the next meeting ( 102 ) . 
 Every obvious cardinality error seems to be fixed now . Did I miss something ? 
 Leaving this open to be closed at SACM WG session in BKK . 
 Addressed
Paragraph (version A):
Size comparisons between XML SWID and CoSWID mainly depend on domain-
specific applications and the complexity of attributes used in
instances.  While the values stored in CoSWID are often unchanged and
therefore not reduced in size compared to an XML SWID, the
scaffolding that the CoSWID encoding represents is significantly
smaller by taking up 10 percent or less in size.  This effect is
visible in instances sizes, which can benefit from a 50 percent to 85
percent reduction of size in generic usage scenarios.  Additional
size reduction is enabled with respect to the memory footprint of XML
parsing/validation as well as the reduction of stack sizes where XML
processing is now obsolete.
Paragraph (version B):
Size comparisons between XML SWID and CoSWID mainly depend on domain-
specific applications and the complexity of attributes used in
instances.  While the values stored in CoSWID are often unchanged and
therefore not reduced in size compared to an XML SWID, the
scaffolding that the CoSWID encoding represents is significantly
smaller by taking up 10 percent or less in size.  This effect is
visible in representation sizes, which in early experiments benefited
from a 50 percent to 85 percent reduction in generic usage scenarios.
Additional size reduction is enabled with respect to the memory
footprint of XML parsing/validation.
Paragraph (version A):
In a CoSWID, the human-readable labels of SWID data items are
replaced with more concise integer labels (indices).  This approach
allows SWID and CoSWID to share a common implicit information model,
with CoSWID providing an alternate data model RFC3444.  While SWID
and CoSWID are intended to share the same implicit information model,
this specification does not define this information model, or a
mapping between the the two data formats.  While an attempt to align
SWID and CoSWID tags has been made here, future revisions of ISO/IEC
19770-2:2015 or this specification might cause this implicit
information model to diverge, since these specifications are
maintained by different standards groups.
Paragraph (version B):
In a CoSWID, the human-readable labels of SWID data items are
replaced with more concise integer labels (indices).  This approach
allows SWID and CoSWID to share a common implicit information model,
with CoSWID providing an alternate data model RFC3444.  While SWID
and CoSWID are intended to share the same implicit information model,
this specification does not define this information model, or a
mapping between the two data formats.  While an attempt to align SWID
and CoSWID tags has been made here, future revisions of ISO/IEC
19770-2:2015 or this specification might cause this implicit
information model to diverge, since these specifications are
maintained by different standards groups.
Paragraph (version A):
Corpus, primary, and patch tags have similar functions in that
they describe the existence and/or presence of different types of
software components (e.g., software installers, software
installations, software patches), and, potentially, different
states of these software components.  Supplemental tags have the
same structure as other tags, but are used to provide information
not contained in the referenced corpus, primary, and patch tags.
All four tag types come into play at various points in the
software lifecycle and support software management processes that
depend on the ability to accurately determine where each software
component is in its lifecycle.
Paragraph (version A):
fig-lifecycle illustrates the steps in the software lifecycle and
the relationships among those lifecycle events supported by the
four types of SWID and CoSWID tags.  A detailed description of the
four tags types is provided in model-concise-swid-tag.  The figure
identifies the types of tags that are used in each lifecycle
event.
Paragraph (version A):
Software Deployment.  Before the software component is
installed (i.e., pre-installation), and while the product is
being deployed, a corpus tag provides information about the
installation files and distribution media (e.g., CD/DVD,
distribution package).
Paragraph (version A):
Software Installation.  A primary tag will be installed with
the software component (or subsequently created) to uniquely
identify and describe the software component.  Supplemental
tags are created to augment primary tags with additional site-
specific or extended information.  While not illustrated in the
figure, patch tags can also be installed during software
installation to provide information about software fixes
deployed along with the base software installation.
Paragraph (version A):
Software Patching.  A new patch tag is provided, when a patch
is applied to the software component, supplying details about
the patch and its dependencies.  While not illustrated in the
figure, a corpus tag can also provide information about the
patch installer and patching dependencies that need to be
installed before the patch.
Paragraph (version A):
Software Upgrading.  As a software component is upgraded to a
new version, new primary and supplemental tags replace existing
tags, enabling timely and accurate tracking of updates to
software inventory.  While not illustrated in the figure, a
corpus tag can also provide information about the upgrade
installer and dependencies that need to be installed before the
upgrade.
Paragraph (version A):
Software Removal.  Upon removal of the software component,
relevant SWID tags are removed.  This removal event can trigger
timely updates to software inventory reflecting the removal of
the product and any associated patch or supplemental tags.
Paragraph (version A):
This section describes the conventions by which a CoSWID is
represented in the CDDL structure.  The CamelCase CamelCase notation
used in the XML schema definition is changed to a hyphen-separated
notation KebabCase (e.g.  ResourceCollection is named resource-
collection) in the CoSWID CDDL specification.  This deviation from
the original notation used in the XML representation reduces
ambiguity when referencing certain attributes in corresponding
textual descriptions.  An attribute referred to by its name in
CamelCase notation explicitly relates to XML SWID tags; an attribute
referred to by its name in KebabCase notation explicitly relates to
CBOR CoSWID tags.  This approach simplifies the composition of
further work that reference both XML SWID and CBOR CoSWID documents.
Paragraph (version B):
This section describes the conventions by which a CoSWID is
represented in the CDDL structure.  The CamelCase CamelCase notation
used in the XML schema definition is changed to a hyphen-separated
notation KebabCase (e.g., ResourceCollection is named resource-
collection) in the CoSWID CDDL specification.  This deviation from
the original notation used in the XML representation reduces
ambiguity when referencing certain attributes in corresponding
textual descriptions.  An attribute referred to by its name in
CamelCase notation explicitly relates to XML SWID tags; an attribute
referred to by its name in KebabCase notation explicitly relates to
CBOR CoSWID tags.  This approach simplifies the composition of
further work that reference both XML SWID and CBOR CoSWID documents.
Paragraph (version A):
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
CoSWID 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.
These cases are specifically noted in this and subsequent sections
using an W3C.REC-xpath20-20101214 where a manual mapping is needed.
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
CoSWID 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.
XPath expressions W3C.REC-xpath20-20101214 need to use SWID names,
see uri-scheme-swidpath.
Paragraph (version A):
Through use of CDDL-based integer labels, CoSWID allows for future
expansion in subsequent revisions of this specification and through
extensions (see model-extension).  New constructs can be associated
with a new integer index.  A deprecated construct can be replaced by
a new construct with a new integer index.  An implementation can use
these integer indexes to identify the construct to parse.  The CoSWID
Items registry, defined in iana-coswid-items, is used to ensure that
new constructs are assigned a unique index value on a first-come,
first-served basis.  This approach avoids the need to have an
explicit CoSWID version.
Paragraph (version B):
Through use of CDDL-based integer labels, CoSWID allows for future
expansion in subsequent revisions of this specification and through
extensions (see model-extension).  New constructs can be associated
with a new integer index.  A deprecated construct can be replaced by
a new construct with a new integer index.  An implementation can use
these integer indexes to identify the construct to parse.  The CoSWID
Items registry, defined in iana-coswid-items, is used to ensure that
new constructs are assigned a unique index value.  This approach
avoids the need to have an explicit CoSWID version.
Paragraph (version B):
In a number of places, the value encoding admits both integer values
and text strings.  The integer values are defined in a registry
specific to the kind of value; the text values are not intended for
interchange and exclusively meant for private use as defined in iana-
private-use.  Encoders SHOULD NOT use string values based on the
names registered in the registry, as these values are less concise
than their index value equivalent; a decoder MUST however be prepared
to accept text strings that are not specified in this document (and
ignore the construct if that string is unknown).  In the rest of the
document, we call this an "integer label with text escape".
Paragraph (version A):
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 Section 3.1 of RFC8949).  Thus both SWID and
CoSWID use UTF-8 for the encoding of characters in text strings.
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 RFC8949).  Thus both SWID and CoSWID use UTF-8
for the encoding of characters in text strings.
Paragraph (version A):
tag-id (index 0): A 16 byte binary string or textual identifier
uniquely referencing a software component.  The tag identifier
MUST be globally unique.  Failure to ensure global uniqueness can
create ambiguity in tag use since the tag-id serves as the global
key for matching and lookups.  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):
tag-version (index 12): An integer value that indicate the
specific release revision of the tag.  Typically, the initial
value of this field is set to 0 and the value is monotonically
increased for subsequent tags produced for the same software
component release.  This value allows a CoSWID tag producer to
correct an incorrect tag previously released without indicating a
change to the underlying software component the tag represents.
For example, the tag version could be changed to add new metadata,
to correct a broken link, to add a missing payload entry, etc.
When producing a revised tag, the new tag-version value MUST be
greater than the old tag-version value.
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.  Failure to ensure global uniqueness can
create ambiguity in tag use since the tag-id serves as the global
key for matching and lookups.  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 B):
tag-version (index 12): An integer value that indicate the
specific release revision of the tag.  Typically, the initial
value of this field is set to 0 and the value is increased for
subsequent tags produced for the same software component release.
This value allows a CoSWID tag producer to correct an incorrect
tag previously released without indicating a change to the
underlying software component the tag represents.  For example,
the tag version could be changed to add new metadata, to correct a
broken link, to add a missing payload entry, etc.  When producing
a revised tag, the new tag-version value MUST be greater than the
old tag-version value.
Paragraph (version A):
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 iana-
private-use).  Integer values in the range 0 to 65535 correspond
to registered entries in the IANA "Software Tag Version Scheme
Values" registry (see iana-version-scheme.  If a string value is
used it MUST be a private use name as defined in iana-private-use.
String values based on a Version Scheme Name from the IANA
"Software Tag Version Scheme Values" registry MUST NOT be used, as
these values are less concise than their index value equivalent.
Paragraph (version A):
media (index 10): This text value is a hint to the tag consumer to
understand what target platform this tag applies to.  This item
item MUST be formatted as a query as defined by the W3C Media
Queries Recommendation (see W3C.REC-css3-mediaqueries-20120619).
Support for media queries are included here for interoperability
with SWID, which does not provide any further requirements for
media query use.  Thus, this specification does not clarify how a
media query is to be used for a CoSWID.
Paragraph (version B):
version-scheme (index 14): An integer or textual value
representing the versioning scheme used for the software-version
item, as an integer label with text escape (data-def, for the
"Version Scheme" registry indexed-version-scheme.  . 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 iana-private-use).
Integer values in the range 0 to 65535 correspond to registered
entries in the IANA "Software Tag Version Scheme Values" registry
(see iana-version-scheme.
Paragraph (version B):
media (index 10): This text value is a hint to the tag consumer to
understand what target platform this tag applies to.  This item
MUST be formatted as a query as defined by the W3C Media Queries
Recommendation (see W3C.REC-css3-mediaqueries-20120619).  Support
for media queries are included here for interoperability with
SWID, which does not provide any further requirements for media
query use.  Thus, this specification does not clarify how a media
query is to be used for a CoSWID.
Paragraph (version A):
link (index 4): Provides a means to establish relationship arcs
between the tag and another items.  A given link can be used to
establish the relationship between tags or to reference another
resource that is related to the CoSWID tag, e.g.  vulnerability
database association, ROLIE feed RFC8322, MUD resource RFC8520,
software download location, etc).  This is modeled after the HTML
"link" element.  Described in model-link.
Paragraph (version B):
link (index 4): Provides a means to establish relationship arcs
between the tag and another items.  A given link can be used to
establish the relationship between tags or to reference another
resource that is related to the CoSWID tag, e.g., vulnerability
database association, ROLIE feed RFC8322, MUD resource RFC8520,
software download location, etc).  This is modeled after the HTML
"link" element.  Described in model-link.
Paragraph (version A):
payload (index 6): This item represents a collection of software
artifacts (described by child items) that compose the target
software.  For example, these artifacts could be the files
included with an installer for a corpus tag or installed on an
endpoint when the software component is installed for a primary or
patch tag.  The artifacts listed in a payload may be a superset of
the software artifacts that are actually installed.  Based on user
selections at install time, an installation might not include
every artifact that could be created or executed on the endpoint
when the software component is installed or run.  Described in
model-payload.
Paragraph (version A):
evidence (index 3): This item can be used to record the results of
a software discovery process used to identify untagged software on
an endpoint or to represent indicators for why software is
believed to be installed on the endpoint.  In either case, a
CoSWID tag can be created by the tool performing an analysis of
the software components installed on the endpoint.  Described in
model-evidence.
Paragraph (version B):
payload (index 6): This item represents a collection of software
artifacts (described by child items) that compose the target
software.  For example, these artifacts could be the files
included with an installer for a corpus tag or installed on an
endpoint when the software component is installed for a primary or
patch tag.  The artifacts listed in a payload may be a superset of
the software artifacts that are actually installed.  Based on user
selections at install time, an installation might not include
every artifact that could be created or executed on the endpoint
when the software component is installed or run.  This item is
mutually exclusive to evidence, as payload can only be provided by
an external entity.  Described in model-payload.
Paragraph (version B):
evidence (index 3): This item can be used to record the results of
a software discovery process used to identify untagged software on
an endpoint or to represent indicators for why software is
believed to be installed on the endpoint.  In either case, a
CoSWID tag can be created by the tool performing an analysis of
the software components installed on the endpoint.  This item is
mutually exclusive to payload, as evidence is always generated on
the target device ad-hoc.  Described in model-evidence.
Paragraph (version A):
The following co-constraints apply to the information provided in the
concise-swid-tag group.
Paragraph (version A):
If the patch item is set to "true", the tag SHOULD contain at
least one link item (see model-link) with both the rel item value
of "patches" and an href item specifying an association with the
software that was patched.
Paragraph (version A):
If the supplemental item is set to "true", the tag SHOULD contain
at least one link item with both the rel item value of
"supplemental" and an href item specifying an association with the
software that is supplemented.
Paragraph (version B):
The following co-constraints apply to the information provided in the
concise-swid-tag group.  If any of these constraint is not met, a
signed tag cannot be used anymore as a signed statement.
Paragraph (version B):
If the patch item is set to "true", the tag SHOULD contain at
least one link item (see model-link) with both the rel item value
of "patches" and an href item specifying an association with the
software that was patched.  Without at least one link item the
target of the patch cannot be identified and the patch tag cannot
be applied without external context.
Paragraph (version B):
If the supplemental item is set to "true", the tag SHOULD contain
at least one link item with both the rel item value of
"supplemental" and an href item specifying an association with the
software that is supplemented.  Without at least one link item the
target of supplement tag cannot be identified and the patch tag
cannot be applied without external context.
Paragraph (version A):
reg-id (index 32): The registration id value is intended to
uniquely identify a naming authority in a given scope (e.g.
global, organization, vendor, customer, administrative domain,
etc.) for the referenced entity.  The value of a registration ID
MUST be a RFC 3986 URI.  The scope will usually be the scope of an
organization.
Paragraph (version A):
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 iana-private-use).  Integer values in the range 0 to 255
correspond to registered entries in the IANA "Software Tag Entity
Role Values" registry (see iana-entity-role.  If a string value is
used it MUST be a private use name as defined in iana-private-use.
String values based on a Role Name from the IANA "Software Tag
Entity Role Values" registry MUST NOT be used, as these values are
less concise than their index value equivalent.
Paragraph (version B):
reg-id (index 32): The registration id value is intended to
uniquely identify a naming authority in a given scope (e.g.,
global, organization, vendor, customer, administrative domain,
etc.) for the referenced entity.  The value of a registration ID
MUST be a RFC 3986 URI; it is not intended to be dereferenced.
The scope will usually be the scope of an organization.
Paragraph (version B):
role (index 33): An integer or textual value (integer label with
text escape, see data-def) 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 iana-
private-use).  Integer values in the range 0 to 255 correspond to
registered entries in the IANA "Software Tag Entity Role Values"
registry (see iana-entity-role.
Paragraph (version A):
artifact (index: 37): To be used with rel="installation-media",
this item's value provides the path to the installer executable or
script that can be run to launch the referenced installation.
Links with the same artifact name MUST be considered mirrors of
each other, allowing the installation media to be acquired from
any of the described sources.
Paragraph (version A):
If no URI scheme is provided, then the URI-reference is a
relative reference relative to the URI of the CoSWID tag.  For
example, "./folder/supplemental.coswid".
Paragraph (version B):
artifact (index: 37): To be used with rel="installation-media",
this item's value provides the absolute filesystem path to the
installer executable or script that can be run to launch the
referenced installation.  [FIXME] Links with the same artifact
name MUST be considered mirrors of each other, allowing the
installation media to be acquired from any of the described
sources.
Paragraph (version B):
If no URI scheme is provided, then the URI-reference is a
relative reference relative to the base URI of the CoSWID tag,
i.e., the URI under which the CoSWID tag was provided.  For
example, "./folder/supplemental.coswid".
Paragraph (version A):
a URI with "swidpath:" as the scheme, which refers to another
software tag via an XPATH query W3C.REC-xpath20-20101214.  This
scheme is provided for compatibility with SWID.  This
specification does not define how to resolve an XPATH query in
the context of CBOR.
Paragraph (version B):
a URI with "swidpath:" as the scheme, which refers to another
software tag via an XPATH query W3C.REC-xpath20-20101214 that
matches items in that tag (uri-scheme-swidpath).  This scheme
is provided for compatibility with SWID.  This specification
does not define how to resolve an XPATH query in the context of
CBOR, see uri-scheme-swidpath.
Paragraph (version B):
ownership (index 39): An integer or textual value (integer label
with text escape, see data-def, for the "Software Tag Link
Ownership Values" registry indexed-link-ownership) 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 iana-private-use).
Integer values in the range 0 to 255 correspond to registered
entries in the "Software Tag Link Ownership Values" registry.
Paragraph (version A):
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 iana-private-use).
Integer values in the range 0 to 255 correspond to registered
entries in the IANA "Software Tag Link Ownership Values" registry
(see iana-link-ownership.  If a string value is used it MUST be a
private use name as defined in iana-private-use.  String values
based on a Ownership Type Name from the IANA "Software Tag Link
Ownership Values" registry MUST NOT be used, as these values are
less concise than their index value equivalent.
Paragraph (version B):
entries in the "Software Tag Link Ownership Values" registry.
Paragraph (version A):
CoSWID tag.  String values based on a Relationship Type Name from
the IANA "Software Tag Link Relationship Values" registry MUST NOT
be used, as these values are less concise than their index value
equivalent.
Paragraph (version A):
media-type (index 41): A link can point to arbitrary resources on
the endpoint, local network, or Internet using the href item.  Use
of this item supplies the resource consumer with a hint of what
type of resource to expect.  Media types are identified by
referencing a "Name" from the IANA "Media Types" registry:
http://www.iana.org/assignments/media-types/media-types.xhtml.
This item maps to '/SoftwareIdentity/Link/@type' in SWID.
Paragraph (version A):
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 iana-private-use).
Integer values in the range 0 to 255 correspond to registered
entries in the IANA "Link Use Values" registry (see iana-link-use.
If a string value is used it MUST be a private use name as defined
in iana-private-use.  String values based on an Link Use Type Name
from the IANA "Software Tag Link Use Values" registry MUST NOT be
used, as these values are less concise than their index value
equivalent.
Paragraph (version B):
CoSWID tag.  String values correspond to registered entries in the
"Software Tag Link Relationship Values" registry.
Paragraph (version B):
use (index 42): An integer or textual value (integer label with
text escape, see data-def, for the "Software Tag Link Link
Relationship Values" registry indexed-link-ownership) 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 iana-
private-use).  Integer values in the range 0 to 255 correspond to
registered entries in the IANA "Link Use Values" registry (see
iana-link-use.  If a string value is used it MUST be a private use
name as defined in iana-private-use.  String values correspond to
registered entries in the "Software Tag Link Use Values" registry.
Paragraph (version A):
activation-status (index 43): A textual value that identifies how
the software component has been activated, which might relate to
specific terms and conditions for its use (e.g.  Trial,
Serialized, Licensed, Unlicensed, etc) and relate to an
entitlement.  This attribute is typically used in supplemental
tags as it contains information that might be selected during a
specific install.
Paragraph (version B):
activation-status (index 43): A textual value that identifies how
the software component has been activated, which might relate to
specific terms and conditions for its use (e.g., Trial,
Serialized, Licensed, Unlicensed, etc) and relate to an
entitlement.  This attribute is typically used in supplemental
tags as it contains information that might be selected during a
specific install.
Paragraph (version A):
channel-type (index 44): A textual value that identifies which
sales, licensing, or marketing channel the software component has
been targeted for (e.g.  Volume, Retail, OEM, Academic, etc).
This attribute is typically used in supplemental tags as it
contains information that might be selected during a specific
install.
Paragraph (version B):
channel-type (index 44): A textual value that identifies which
sales, licensing, or marketing channel the software component has
been targeted for (e.g., Volume, Retail, OEM, Academic, etc).
This attribute is typically used in supplemental tags as it
contains information that might be selected during a specific
install.
Paragraph (version A):
colloquial-version (index 45): A textual value for the software
component's informal or colloquial version.  Examples may include
a year value, a major version number, or similar value that are
used to identify a group of specific software component releases
that are part of the same release/support cycle.  This version can
be the same through multiple releases of a software component,
while the software-version specified in the concise-swid-tag group
is much more specific and will change for each software component
release.  This version is intended to be used for string
comparison only and is not intended to be used to determine if a
specific value is earlier or later in a sequence.
Paragraph (version B):
colloquial-version (index 45): A textual value for the software
component's informal or colloquial version.  Examples may include
a year value, a major version number, or similar value that are
used to identify a group of specific software component releases
that are part of the same release/support cycle.  This version can
be the same through multiple releases of a software component,
while the software-version specified in the concise-swid-tag group
is much more specific and will change for each software component
release.  This version is intended to be used for string
comparison (byte-by-byte) only and is not intended to be used to
determine if a specific value is earlier or later in a sequence.
Paragraph (version A):
The number used as a value for hash-alg-id is an integer-based hash
algorithm identifier who's value MUST refer to an ID in the IANA
"Named Information Hash Algorithm Registry" IANA.named-information
with a Status of "current"; other hash algorithms MUST NOT be used.
If the hash-alg-id is not known, then the integer value "0" MUST be
used.  This ensures parity between the SWID tag specification SWID,
which does not allow an algorithm to be identified for this field.
Paragraph (version B):
The number used as a value for hash-alg-id is an integer-based hash
algorithm identifier who's value MUST refer to an ID in the IANA
"Named Information Hash Algorithm Registry" IANA.named-information
with a Status of "current" (at the time the generator software was
built or later); other hash algorithms MUST NOT be used.  If the
hash-alg-id is not known, then the integer value "0" MUST be used.
This allows for conversion from ISO SWID tags SWID, which do not
allow an algorithm to be identified for this field.
Paragraph (version A):
file-version (index 21): The file's version as reported by
querying information on the file from the operating system.  This
item maps to '/SoftwareIdentity/(Payload|Evidence)/File/@version'
in SWID.
Paragraph (version B):
file-version (index 21): The file's version as reported by
querying information on the file from the operating system (if
available).  This item maps to
'/SoftwareIdentity/(Payload|Evidence)/File/@version' in SWID.
Paragraph (version A):
location (index 23): The filesystem path where a file is expected
to be located when installed or copied.  The location MUST be
either relative to the location of the parent directory item
(preferred) or relative to the location of the CoSWID tag if no
parent is defined.  The location MUST NOT include a file's name,
which is provided by the fs-name item.
Paragraph (version B):
location (index 23): The filesystem path where a file is expected
to be located when installed or copied.  The location MUST be
either relative to the location of the parent directory item
(preferred), or relative to the location of the CoSWID tag (as
indicated in the location value in the evidence entry map) if no
parent is defined.  The location MUST NOT include a file's name,
which is provided by the fs-name item.
Paragraph (version A):
type (index 29): A string indicating the type of resource.
Paragraph (version B):
type (index 29): A human-readable string indicating the type of
resource.
Paragraph (version A):
The following table contains a set of values for use in the concise-
swid-tag group's version-scheme item.  These values match the version
schemes defined in the ISO/IEC 19770-2:2015 SWID specification.
Index value indicates the value to use as the version-scheme item's
value.  The Version Scheme Name provides human-readable text for the
value.  The Definition describes the syntax of allowed values for
each entry.
Paragraph (version A):
"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 A):
"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 A):
"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 B):
This section defines a number of kinds of indexed label values that
are maintained in a registry each (iana).  These values are
represented as positive integers.  In each registry, the value 0 is
marked as Reserved.
Paragraph (version B):
The following table contains a set of values for use in the concise-
swid-tag group's version-scheme item.  Version Scheme Name strings
match the version schemes defined in the ISO/IEC 19770-2:2015 SWID
specification.  Index value indicates the value to use as the
version-scheme item's value.  The Version Scheme Name provides human-
readable text for the value.  The Definition describes the syntax of
allowed values for each entry.
Paragraph (version B):
multipartnumeric and the numbers part of multipartnumeric+suffix are
interpreted as a sequence of numbers and are sorted in
lexicographical order by these numbers (i.e., not by the digits in
the numbers) and then the textual suffix (for
multipartnumeric+suffix).  Alphanumeric strings are sorted
lexicographically as character strings.  Decimal version numbers are
interpreted as a single floating point number (e.g., 1.25 is less
than 1.3).
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 assumed.
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 assumed.
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 assumed instead of "alphanumeric".
Paragraph (version B):
Note that these heuristics are imperfect and can guess wrong, which
is the reason the version-scheme item SHOULD be included by the
producer.
Paragraph (version A):
There is a need for a scheme name that can be used in URIs that point
to a specific software tag by that tag's tag-id, such as the use of
the link entry as described in model-link) of this document.  Since
this scheme is used both 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.  In swid-reg, the scheme "swid" is
registered as a 'permanent' scheme for that purpose.
Paragraph (version B):
There is a need for a scheme name that can be used in URIs that point
to a specific software tag by that tag's tag-id, such as the use of
the link entry as described in model-link.  Since this scheme is used
both 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.  In swid-reg, the scheme "swid" is registered as a
'permanent' scheme for that purpose.
Paragraph (version A):
There is a need for a scheme name that can be used in URIs to
identify a collection of specific software tags with data elements
that match an XPath expression, such as the use of the link entry as
described in model-link) of this document.  Since this scheme is used
both 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.  In swidpath-reg, the scheme "swidpath" is hereby
registered as a 'permanent' scheme for that purpose.
Paragraph (version A):
URIs specifying the "swidpath" scheme are used to reference the data
that must be found in a given software 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 a URI with this scheme.
Paragraph (version A):
For URIs that use the "swidpath" scheme, the requirements apply.
Paragraph (version A):
The scheme specific part MUST be 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 A):
This XPath is evaluated over SWID or CoSWID tags found on a system.
A given tag MUST be considered a match if the XPath evaluation result
value has an effective boolean value of "true" according to W3C.REC-
xpath20-20101214 Section 2.4.3.
Paragraph (version B):
There is a need for a scheme name that can be used in URIs to
identify a collection of specific software tags with data elements
that match an XPath expression, such as the use of the link entry as
described in model-link.  The scheme named "swidpath" is used for
this purpose in SWID, but not registered.  To enable usage without
fear of conflicts with current or future actual schemes, the present
document registers it as a 'permanent' scheme for that purpose (see
swidpath-reg).
Paragraph (version B):
URIs specifying the "swidpath" scheme are used to filter tags out of
a base collection, so that matching tags are included in the
identified tag collection.  The XPath expression W3C.REC-
xpath20-20101214 references the data that must be found in a given
software tag out of base collection for that tag to be considered a
matching tag.  Tags to be evaluated (the base collection) include all
tags in the context of where the "swidpath URI" 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 a URI with this
scheme.
Paragraph (version B):
The scheme specific part MUST be 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):
This XPath is evaluated over SWID tags, or COSWID tags transformed
into SWID tags, found on a system.  A given tag MUST be considered
a match if the XPath evaluation result value has an effective
boolean value of "true" according to W3C.REC-xpath20-20101214
Section 2.4.3.
Paragraph (version A):
The following registries allow for the registration of index values
and names.  New registrations will be permitted through either a
Standards Action with Expert Review policy or a Specification
Required policy BCP26.  New index values will be provided on a First
Come First Served as defined by BCP26.
Paragraph (version B):
The following registries allow for the registration of index values
and names.  New registrations will be permitted through either a
Standards Action with Expert Review policy or a Specification
Required policy BCP26.
Paragraph (version A):
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):
Where both "domainprefix" and "name" MUST each be either an NR-LDH
label or a U-label as defined by RFC5890, and "name" also MUST be a
unique name within the namespace defined by the "domainprefix".  Use
of a prefix in this way allows for a name to be used in the private
use range.  This is consistent with the guidance in BCP178.
Paragraph (version A):
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 initial
registrations violate this requirement, but are included for
backwards compatibility with SWID.  Guidelines on how to deconflict
these value spaces are defined in indexed-version-scheme.
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 initial
registrations violate this requirement, but are included for
backwards compatibility with SWID.  See also indexed-version-scheme.
Paragraph (version A):
Fragment identifier considerations: Fragment identification for
application/swid+cbor is supported by using fragment identifiers as
specified by Section 9.5 of RFC8949.
Paragraph (version B):
Fragment identifier considerations: Fragment identification for
application/swid+cbor is supported by using fragment identifiers as
specified by RFC8949.
Paragraph (version A):
Applications that require Software-IDs (SWIDs) or Concise
Software-IDs (CoSWIDs); see uri-scheme-swid of RFC-AAAA.
Paragraph (version A):
Applications that require Software-IDs (SWIDs) or Concise
Software-IDs (CoSWIDs); see uri-scheme-swidpath of RFC-AAAA.
Paragraph (version A):
Where TAG_CREATOR_REGID is the reg-id item 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 UNIQUE_ID MUST be
represented using the UUID string representation defined in RFC4122
including the "urn:uuid:" prefix.
Paragraph (version B):
Where TAG_CREATOR_REGID is the reg-id item 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 UNIQUE_ID MUST be
represented using the UUID string representation defined in RFC4122
including the "urn:uuid:" prefix.
Paragraph (version A):
Signing CoSWID tags follows the procedures defined in CBOR Object
Signing and Encryption RFC8152.  A CoSWID tag MUST be wrapped in a
COSE Single Signer Data Object (COSE_Sign1) that contains a single
signature and MUST be signed by the tag creator.  The following CDDL
specification defines a restrictive subset of COSE header parameters
that MUST be used in the protected header.
Paragraph (version A):
The COSE_Sign structure that allows for more than one signature to be
applied to a CoSWID tag MAY be used.  The corresponding usage
scenarios are domain-specific and require well-specified application
guidance.
Paragraph (version B):
Signing CoSWID tags follows the procedures defined in CBOR Object
Signing and Encryption RFC8152.  A CoSWID tag MUST be wrapped in a
COSE Signature structure, either COSE_Sign1 or COSE_Sign.  In the
first case, a Single Signer Data Object (COSE_Sign1) contains a
single signature and MUST be signed by the tag creator.  The
following CDDL specification defines a restrictive subset of COSE
header parameters that MUST be used in the protected header in this
case.
Paragraph (version B):
The COSE_Sign structure allows for more than one signature, one of
which MUST be issued by the tag creator, to be applied to a CoSWID
tag and MAY be used.  The corresponding usage scenarios are domain-
specific and require well-specified application guidance.
Paragraph (version A):
A CoSWID SHOULD be signed, using the above mechanism, to protect the
integrity of the CoSWID tag.  See the security considerations (in
sec-sec) for more information on why a signed CoSWID is valuable in
most cases.
Paragraph (version B):
A CoSWID MUST be signed, using the above mechanism, to protect the
integrity of the CoSWID tag.  See the security considerations (in
sec-sec) for more information on why a signed CoSWID is valuable in
most cases.
Paragraph (version B):
This specification makes use of relative paths (e.g., filesystem
paths) in several places.  A signed COSWID tag cannot make use of
these to derive information that is considered to be covered under
the signature.  Typically, relative file system paths will be used to
identify targets for an installation, not sources of tag information.
Paragraph (version A):
Added a set of expert review guidelines for new IANA registries
created by this document.
Paragraph (version B):
Added a set of expert review criteria for new IANA registries
created by this document.