Draft: draft-ietf-sacm-coswid

Commentary: … CDDL . Performed a final editorial pass of the document , clarifying language , making term use more consistent , fixing references , and replacing lowercase RFC2119 keywords . Added table with semantics for the link ownership item .
Paragraph (version A):
While there are very few required fields in SWID tags, there are many
optional fields that support different use scenarios.  While a SWID
tag consisting of only required fields might be a few hundred bytes
in size, a tag containing many of the optional fields can be many
orders of magnitude larger.  Thus, real-world instances of SWID tags
can be fairly large, and the communication of SWID tags in use-
applications such as those described earlier can cause a large amount
of data to be transported.  This can be larger than acceptable for
constrained devices and networks.  Concise SWID (CoSWID) tags
significantly reduce the amount of data transported as compared to a
typical SWID tag.  This reduction is enabled through the use of CBOR,
which maps the human-readable labels of SWID data 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):
While there are very few required fields in SWID tags, there are many
optional fields that support different use scenarios.  A SWID tag
consisting of only required fields might be a few hundred bytes in
size; however, a tag containing many of the optional fields can be
many orders of magnitude larger.  Thus, real-world instances of SWID
tags can be fairly large, and the communication of SWID tags in use-
applications such as those described earlier can cause a large amount
of data to be transported.  This can be larger than acceptable for
constrained devices and networks.  Concise SWID (CoSWID) tags
significantly reduce the amount of data transported as compared to 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 A):
The following is an excerpt (with some modifications and reordering)
from NIST Interagency Report (NISTIR) 8060: Guidelines for the
Creation of Interoperable SWID Tags SWID-GUIDANCE, which describes
the tag types used within the lifecycle defined in ISO-19770-2:2015.
This information is included here to provide a succinct description
of the use of CoSWIDs in the software lifecycle.  Understanding the
use of CoSWIDs in the software lifecycle provides a basis for
understanding the information provided in a CoSWID and the associated
semantics of this information.
Paragraph (version A):
The SWID specification defines four types of SWID tags: primary,
patch, corpus, and supplemental.
Paragraph (version B):
The SWID specification and supporting guidance provided in NIST
Internal Report (NISTIR) 8060: Guidelines for the Creation of
Interoperable SWID Tags SWID-GUIDANCE defines four types of SWID
tags: primary, patch, corpus, and supplemental.
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 may also be installed during software
installation to provide information about software fixes
deployed along with the base software installation.
Paragraph (version B):
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):
Each of the different SWID and CoSWID tag types provide different
sets of information.  For example, a "corpus tag" is used to describe
a software component's installation image on an installation media,
while a "patch tag" is meant to describe a patch that modifies some
other software component.
Paragraph (version A):
This document defines the CoSWID format, a more concise
representation of SWID information in the Concise Binary Object
Representation (CBOR) RFC7049.  The structure of a CoSWID is
described via the Concise Data Definition Language (CDDL) I-D.ietf-
cbor-cddl.  The resulting CoSWID data definition is aligned in the
information able to be expressed with the XML schema definition of
ISO-19770-2:2015 SWID.  The vocabulary, i.e., the CDDL names of the
types and members used in the CoSWID data definition, are mapped to
more concise labels represented as small integer values.  The names
used in the CDDL data definition and the mapping to the CBOR
representation using integer labels is based on the vocabulary of the
XML attribute and element names defined in ISO/IEC 19770-2:2015.
Paragraph (version B):
Understanding the use of CoSWIDs in the software lifecycle provides a
basis for understanding the information provided in a CoSWID and the
associated semantics of this information.  Each of the different SWID
and CoSWID tag types provide different sets of information.  For
example, a "corpus tag" is used to describe a software component's
installation image on an installation media, while a "patch tag" is
meant to describe a patch that modifies some other software
component.
Paragraph (version B):
This document defines the CoSWID tag format, a more concise
representation of SWID information in the Concise Binary Object
Representation (CBOR) RFC7049.  The structure of a CoSWID is
described via the Concise Data Definition Language (CDDL) I-D.ietf-
cbor-cddl.  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 SWID information and to support all
SWID tag use cases.  To achieve this end, the CDDL representation
includes every SWID tag field and attribute.
Paragraph (version B):
The vocabulary, i.e., the CDDL names of the types and members used in
the CoSWID data definition, are mapped to more concise labels
represented as small integer values.  The names used in the CDDL data
definition and the mapping to the CBOR representation using integer
labels is based on the vocabulary of the XML attribute and element
names defined in ISO/IEC 19770-2:2015.
Paragraph (version A):
The following is a CDDL representation for a CoSWID tag.  This CDDL
representation is intended to be parallel to the XML schema
definition in the ISO/IEC 19770-2:2015 SWID specification, allowing
both SWID and CoSWID tags to represent a common set of SWID
information and to support all SWID tag use cases.  To achieve this
end, the CDDL representation includes every SWID tag field and
attribute.  The CamelCase notation used in the XML schema definition
is changed to a hyphen-separated notation (e.g.  ResourceCollection
is named resource-collection) in the CoSWID data definition.  This
deviation from the original notation used in the XML representation
reduces ambiguity when referencing certain attributes in
corresponding textual descriptions.  An attribute referred by its
name in CamelCase notation explicitly relates to XML SWID tags, an
attribute referred by its name in hyphen-separated notation
explicitly relates to CoSWID tags.  This approach simplifies the
composition of further work that reference both XML SWID and CoSWID
documents.
Paragraph (version A):
Human-readable names of members in the CDDL data definition are
mapped to integer indices via a block of rules at the bottom of the
definition.  The 67 character strings of the SWID vocabulary that
would have to be stored or transported in full if using the original
vocabulary are replaced.
Paragraph (version B):
The following is a CDDL representation for a CoSWID tag.  The
CamelCase notation used in the XML schema definition is changed to a
hyphen-separated notation (e.g.  ResourceCollection is named
resource-collection) in the CoSWID data definition.  This deviation
from the original notation used in the XML representation reduces
ambiguity when referencing certain attributes in corresponding
textual descriptions.  An attribute referred by its name in CamelCase
notation explicitly relates to XML SWID tags, an attribute referred
by its name in hyphen-separated notation explicitly relates to CoSWID
tags.  This approach simplifies the composition of further work that
reference both XML SWID and CoSWID documents.
Paragraph (version B):
Human-readable names of members in the CDDL data definition are
mapped to integer indices via a block of rules at the bottom of the
definition.  The 57 character strings of the SWID vocabulary that
would have to be stored or transported in full if using the original
vocabulary are replaced.
Paragraph (version A):
The CDDL above allows for a more efficient CBOR encoding of the data
when a single value is used by avoiding the need to first encode the
array.  An array is used for two or more values.  This modeling
pattern is used frequently in the CoSWID CDDL data definition in such
cases.
Paragraph (version B):
The CDDL above allows for a more efficient CBOR encoding of the data
when a single value is used by avoiding the need to first encode the
array.  Conversely, an array is used for two or more values.  This
modeling pattern is used frequently in the CoSWID CDDL data
definition in such cases.
Paragraph (version A):
The inclusion of extension points in the CoSWID data definition
using CDDL sockets (see I-D.ietf-cbor-cddl section 3.9).  These
extension points allow for well-formed extensions to be defined in
additional CDDL descriptions that support additional uses of
CoSWID tags that go beyond the original scope of ISO-19770-2:2015
tags.  The following extension points are defined in this
document, which allow the addition of new information structures
to their respective object.
Paragraph (version A):
The CoSWID Items Registry defined in iana-coswid-items provides a
registration mechanism for new items, and associated index values,
added to the CoSWID model through the use of the CDDL sockets
described above.  This registration mechanism will provide for well-
known index values for CoSWID extensions, allowing these index values
to be recognized by implementations supporting a given extension.
Paragraph (version A):
The following describes each child item of the concise-software-
identity object model.
Paragraph (version A):
tag-id (label 0): An textual identifier uniquely referencing a
(composite) 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):
The inclusion of extension points in the CoSWID data definition
using CDDL sockets (see I-D.ietf-cbor-cddl section 3.9).  The use
of CDDL sockets allow for well-formed extensions to be defined in
supplementary CDDL descriptions that support additional uses of
CoSWID tags that go beyond the original scope of ISO-19770-2:2015
tags.  This extension mechanism can also be used to update the
CoSWID format as revisions to ISO-19770-2 are published.
Paragraph (version B):
The following CDDL sockets are defined in this document, which allow
the addition of new information structures to their respective CDDL
groups.
Paragraph (version B):
The CoSWID Items Registry defined in iana-coswid-items provides a
registration mechanism allowing new items, and their associated index
values, to be added to the CoSWID model through the use of the CDDL
sockets described above.  This registration mechanism will provide
for well-known index values for data items in CoSWID extensions,
allowing these index values to be recognized by implementations
supporting a given extension.
Paragraph (version B):
The following describes each child item of the concise-swid-tag
group.
Paragraph (version B):
tag-id (label 0): A textual identifier uniquely referencing a
(composite) 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 A):
tag-version (label 12): An integer value that indicates if a
specific release of a software component has more than one tag
that can represent that specific release.  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 item is used when a CoSWID tag producer
creates and releases an incorrect tag that they subsequently want
to fix, but no underlying changes have been made to the product
the CoSWID tag represents.  This could happen if, for example, a
patch is distributed that has a link reference that does not cover
all the various software releases it can patch.  A newer CoSWID
tag for that patch can be generated and the tag-version value
incremented to indicate that the data has been updated.
Paragraph (version B):
tag-version (label 12): An integer value that indicates if a
specific release of a software component has more than one tag
that can represent that specific release.  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 is changed when a CoSWID tag
producer creates and releases an incorrect tag that they
subsequently want to fix, but no underlying changes have been made
to the product the CoSWID tag represents.  This could happen if,
for example, a patch is distributed that has a link reference that
does not cover all the various software releases it can patch.  A
newer CoSWID tag for that patch can be generated and the tag-
version value incremented to indicate that the data has been
updated.
Paragraph (version A):
patch (label 9): A boolean value that indicates if the tag
identifies and describes an installed patch which has made
incremental changes to a software component installed on a
computing device.  Typically, an installed patch has made a set of
file modifications to pre-installed software, and does not alter
the version number or the descriptive metadata of an installed
software component.  If a CoSWID tag is for a patch, it MUST
contain the patch item and its value MUST be set to "true".  If
not provided the default value MUST be considered "false".
Paragraph (version B):
patch (label 9): A boolean value that indicates if the tag
identifies and describes an installed patch which has made
incremental changes to a software component installed on a
computing device.  Typically, an installed patch has made a set of
file modifications to pre-installed software, and does not alter
the version number or the descriptive metadata of an installed
software component.  If a CoSWID tag is for a patch, the patch
item MUST be set to "true".  If not provided the default value
MUST be considered "false".
Paragraph (version A):
supplemental (label 11): A boolean value that indicates if the tag
is providing additional information to be associated with another
referenced SWID or CoSWID tag.  Tags using this item help to
ensure that primary and patch tags provided by a software provider
are not modified by software management tools, while allowing
these tools to provide their own software metadata for a software
component.  If a CoSWID tag is a supplemental tag, it MUST contain
the supplemental item and its value MUST be set to "true".  If not
provided the default value MUST be considered "false".
Paragraph (version B):
supplemental (label 11): A boolean value that indicates if the tag
is providing additional information to be associated with another
referenced SWID or CoSWID tag.  Tags using this item help to
ensure that primary and patch tags provided by a software provider
are not modified by software management tools, while allowing
these tools to provide their own software metadata for a software
component.  If a CoSWID tag is a supplemental tag, the
supplemental item MUST be set to "true".  If not provided the
default value MUST be considered "false".
Paragraph (version A):
software-version (label 13): A textual value representing the
specific underlying release or development version of the software
component.
Paragraph (version A):
version-scheme (label 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
registry (see section iana-version-scheme or a value in the
private use range: 32768-65535.
Paragraph (version A):
media (label 10): This text value is a hint to the tag consumer to
understand what this tag applies to.  This item represents a query
as defined by the W3C Media Queries Recommendation (see W3C.REC-
css3-mediaqueries-20120619).  A hint to the consumer of the link
to what the target item is applicable for.
Paragraph (version B):
software-version (label 13): A textual value representing the
specific release or development version of the software component.
Paragraph (version B):
version-scheme (label 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 Schema Values Registry (see section iana-
version-scheme or a value in the private use range: 32768-65535.
Paragraph (version B):
media (label 10): This text value is a hint to the tag consumer to
understand what this tag applies to.  This item represents a query
as defined by the W3C Media Queries Recommendation (see W3C.REC-
css3-mediaqueries-20120619).
Paragraph (version A):
entity (label 2): Provides information about one or more
organizations related to the software component referenced by this
CoSWID tag.  Described in model-entity.
Paragraph (version B):
entity (label 2): Provides information about one or more
organizations related to the CoSWID tag or the software component
referenced by this CoSWID tag.  Described in model-entity.
Paragraph (version A):
payload (label 6): This item represents the software artifacts
that may be installed on an endpoint when the software component
is installed.  Note that the payload may represent a superset of
the software artifacts installed.  Based on user selections at
install time, an installation may not include every artifact that
could be created or executed on the endpoint when the software
component is installed (i.e. if a particular optional sub-
component is not installed, the files associated with that
software component may be included in payload, but not installed
in the system entity).  Described in model-payload.
Paragraph (version A):
evidence-entry (label 3): This item is used to provide results
from a scan of a system where software that does not have a CoSWID
tag is discovered.  In such a case, a CoSWID tag may be created by
the discovery process when the endpoint is scanned.  This item
represents evidence for why software is believed to be installed
on the endpoint.  Described in model-evidence.
Paragraph (version A):
The following co-constraints apply to the information provided by a
concise-software-identity Object.
Paragraph (version B):
payload (label 6): This item represents the software artifacts
that compose the target software.  For example, 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.  Note that the payload can represent a superset of the
software artifacts 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 (i.e. if a particular optional sub-component is not
installed, the files associated with that software component might
be included in payload, but not installed on the endpoint).
Described in model-payload.
Paragraph (version B):
evidence-entry (label 3): This item is used to provide results
from a scan of a system where software that does not have a CoSWID
tag is discovered.  In such a case, a CoSWID tag can be created by
the discovery process when the endpoint is scanned.  This item
represents evidence for why software is believed to be installed
on the endpoint.  Described in model-evidence.
Paragraph (version B):
The following co-constraints apply to the information provided by in
the concise-swid-tag group.
Paragraph (version A):
lang (index 15): A textual language tag that conforms with IANA
Language Subtag Registry RFC5646.
Paragraph (version B):
lang (index 15): A textual language tag that conforms with IANA
"Language Subtag Registry" RFC5646.  The context of the specified
language applies to all sibling and descendant textual values,
unless a descendant object has defined a different language tag.
Thus, a new context is established when a descendant object
redefines a new language tag.  All textual values within a given
context MUST be considered expressed in the specified language.
Paragraph (version A):
entity-name (index 32): The text-string name of the organization
claiming a particular role in the CoSWID tag.
Paragraph (version A):
reg-id (index 32): The registration id is intended to uniquely
identify a naming authority in a given scope (e.g. global,
organization, vendor, customer, administrative domain, etc.) for
the referenced naming authority.  The value of an registration ID
MUST be a RFC 3986 URI.  The scope SHOULD be the scope of an
organization.  In a given scope, the registration id MUST be used
consistently.
Paragraph (version A):
role (index 33): The relationship(s) between this organization and
this tag.  The role of an entity MAY include any role value, but
the pre-defined roles include: "aggregator", "distributor",
"licensor", "software-creator", and "tag-creator".  These pre-
defined role index and text values are defined in indexed-entity-
role.  Use of index values instead of text for these pre-defined
roles allows a CoSWID to be more concise.
Paragraph (version A):
thumbprint (index 34): The value of the thumbprint item provides
an integer-based hash algorithm identifier (hash-alg-id) and a
byte string value (hash-value) that contains the corresponding
hash value (i.e. the thumbprint) of the signing entities
certificate(s).  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.  See model-hash-entry for more details
on the use of the hash-entry data structure.
Paragraph (version B):
entity-name (index 32): The text-string name of the organization
claiming a particular role, specified by the role item, in the
CoSWID tag.
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 an registration ID
MUST be a RFC 3986 URI.  The scope SHOULD be the scope of an
organization.  In a given scope, the registration id MUST be used
consistently for CoSWID tag production.
Paragraph (version B):
role (index 33): The relationship(s) between this organization and
this tag or the referenced software component.  The role of an
entity MAY include any role value, but the pre-defined roles
include: "aggregator", "distributor", "licensor", "software-
creator", and "tag-creator".  All pre-defined role index and text
values are defined in the IANA "SWID/CoSWID Entity Role Values"
registry indexed-entity-role.  Use of index values instead of text
for these pre-defined roles allows a CoSWID to be more concise.
Paragraph (version B):
An entity item SHOULD be provided with the role of "software-
creator" for every CoSWID tag, if this information is known to the
tag creator.  This indicates the organization that created the
referenced software component.
Paragraph (version B):
thumbprint (index 34): The value of the thumbprint item provides
an integer-based hash algorithm identifier (hash-alg-id) and a
byte string value (hash-value) that contains the corresponding
hash value (i.e. the thumbprint) of the signing entity's public
key certificate.  This provides an indicator of which entity
signed the CoSWID tag, which will typically be the tag creator.
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.  See model-hash-entry for more details on the use of the
hash-entry data structure.
Paragraph (version A):
artifact (index: 37): For installation media (rel="installation-
media"), this item value indicates the path of the installer
executable or script that can be run to launch the referenced
installation.  Items with the same artifact name should be
considered mirrors of each other, allowing the installation media
to be downloaded from any of the described sources.
Paragraph (version B):
artifact (index: 37): For installation media (rel="installation-
media"), this item value indicates the path of the installer
executable or script that can be run to launch the referenced
installation.  Links with the same artifact name SHOULD be
considered mirrors of each other, allowing the installation media
to be acquired from any of the described sources.
Paragraph (version A):
media (index 10): See media defined in model-concise-software-
identity.
Paragraph (version A):
rel (index 40): The relationship between this CoSWID and the
target file.  Relationships can be identified by referencing the
IANA registration library: https://www.iana.org/assignments/link-
relations/link-relations.xhtml.
Paragraph (version A):
media-type (index 41): The IANA MediaType for the target resource;
this provides the consumer with a hint of what type of resource to
expect.  See http://www.iana.org/assignments/media-types/media-
types.xhtml for more details.
Paragraph (version A):
activation-status (index 43): Identification of the activation
status of this software title (e.g.  Trial, Serialized, Licensed,
Unlicensed, etc).  Typically, this is used in supplemental tags.
Paragraph (version A):
channel-type (index 44): Provides information on which channel
this particular software was targeted for (e.g.  Volume, Retail,
OEM, Academic, etc).  Typically used in supplemental tags.
Paragraph (version A):
colloquial-version (index 45): The informal or colloquial version
of the product (i.e. 2013).  Note that this version may be the
same through multiple releases of a software component where the
version specified in entity is much more specific and will change
for each software release.
Paragraph (version A):
Note that this representation of version is typically used to
identify a group of specific software releases that are part of
the same release/support infrastructure (i.e.  Fabrikam Office
2013).  This version is used for string comparisons only and is
not compared to be an earlier or later release (that is done via
the concise-software-identity object's software-version item).
Paragraph (version A):
description (index 46): A longer, detailed description of the
software.  This description can be multiple sentences
(differentiated from summary, which is a very short, one-sentence
description).
Paragraph (version A):
edition (index 47): The variation of the product (Extended,
Enterprise, Professional, Standard, etc).
Paragraph (version A):
entitlement-data-required (index 48): An indicator to determine if
there should be accompanying proof of entitlement when a software
license reconciliation is completed.
Paragraph (version A):
entitlement-key (index 49): A vendor-specific textual key that can
be used to reconcile the validity of an entitlement. (e.g. serial
number, product or license key).
Paragraph (version A):
generator (index 50): The name of the software tool that created a
CoSWID tag.  This item is typically used if tags are created on
the fly or via a catalog-based analysis for data found on an
endpoint.
Paragraph (version A):
persistent-id (index 51): A GUID used to represent products
installed where the products are related, but may be different
versions.
Paragraph (version A):
product-family (index 53): The overall product family this
software belongs to.  Product family is not used to identify that
a product is part of a suite, but is instead used when a set of
products that are all related may be installed on multiple
different endpoints.  For example, an enterprise backup system may
consist of a backup services, multiple different backup services
that support mail services, databases and ERP systems, as well as
individual software components that backup client system entities.
In such an usage scenario, all software components that are part
of the backup system would have the same product-family name so
they can be grouped together in respect to reporting systems.
Paragraph (version A):
revision (index 54): The informal or colloquial representation of
the sub-version of the given product (ie, SP1, R2, RC1, Beta 2,
etc).  Note that the version item will provide very exact version
details, while the revision is intended for use in environments
where reporting on the informal or colloquial representation of
the software is important (for example, if for a certain business
process, an organization recognizes that it must have, for example
"ServicePack 1" or later of a specific product installed on all
devices, they can use the revision data value to quickly identify
any devices that do not meet this requirement).
Paragraph (version B):
media (index 10): A hint to the consumer of the link to what the
target item is applicable for.  This item represents a query as
defined by the W3C Media Queries Recommendation (see W3C.REC-css3-
mediaqueries-20120619).  See also media defined in model-concise-
swid-tag.
Paragraph (version B):
ownership (index 39): Determines the relative strength of
ownership between the software component referenced by the COSWID
tag and the software component referenced by the link.  Valid
enumerations are: abandon, private, shared.
Paragraph (version B):
rel (index 40): The relationship between this CoSWID and the
target resource as defined by RFC8288.  Relationships can be
identified by referencing a "Relation Name" from the IANA "Link
Relation Types" registry: https://www.iana.org/assignments/link-
relations/link-relations.xhtml.
Paragraph (version B):
media-type (index 41): The media type for the target resource.
This provides the 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.
Paragraph (version B):
activation-status (index 43): A textual value that identifies the
activation status of this software title (e.g.  Trial, Serialized,
Licensed, Unlicensed, etc).  Typically, this is used in
supplemental tags.
Paragraph (version B):
channel-type (index 44): A textual value that provides information
on which channel this particular software was targeted for (e.g.
Volume, Retail, OEM, Academic, etc).  Typically used in
supplemental tags.
Paragraph (version B):
colloquial-version (index 45): A textual value for an informal or
colloquial version of the product (i.e. 2013).  Note that 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 release.  This representation of version is typically
used to identify a group of specific software releases that are
part of the same release/support infrastructure (i.e.  Fabrikam
Office 2013).  This version is used for string comparisons only
and is not compared to be an earlier or later release (that is
done via the concise-swid-tag group's software-version item).
Paragraph (version B):
description (index 46): A longer, detailed textual description of
the software.  This description can be multiple sentences
(differentiated from summary, which is a very short, one-sentence
description).
Paragraph (version B):
edition (index 47): A textual value indicating the variation of
the product (e.g., Extended, Enterprise, Professional, Standard,
etc).
Paragraph (version B):
entitlement-data-required (index 48): A boolean indicator to
determine if accompanying proof of entitlement is needed when a
software license reconciliation is completed.
Paragraph (version B):
entitlement-key (index 49): A vendor-specific textual key that can
be used to reconcile the validity of an entitlement. (e.g., serial
number, product or license key).
Paragraph (version B):
generator (index 50): The name of the software tool that created
the CoSWID tag.
Paragraph (version B):
persistent-id (index 51): A GUID used to represent products
installed where the products are related, but can be different
versions.
Paragraph (version B):
product-family (index 53): A textual value indicating the overall
product family this software belongs to.  Product family is not
used to identify that a product is part of a suite, but is instead
used when a set of products that are all related can be installed
on multiple different endpoints.  For example, an enterprise
backup system can consist of a backup services, multiple different
backup services that support mail services, databases and ERP
systems, as well as individual software components that backup
client system entities.  In such an usage scenario, all software
components that are part of the backup system would have the same
product-family name so they can be grouped together in respect to
reporting systems.
Paragraph (version B):
revision (index 54): A textual value indicating the informal or
colloquial representation of the sub-version of the given product
(ie, SP1, R2, RC1, Beta 2, etc).  Note that the software-version
specified in the concise-swid-tag group will provide very exact
version details.  Conversely, the revision item is intended for
use in environments where reporting on the informal or colloquial
representation of the software is important.  For example, when an
organization needs "ServicePack 1" or later of a specific product
installed on all devices, they can use the revision data value to
quickly identify any devices that do not meet this requirement.
Paragraph (version A):
CoSWID add explicit support for the representation of hash entries
using algorithms that are registered at the Named Information Hash
Algorithm Registry via the hash-entry member (label 58).
Paragraph (version A):
The number used as a value for hash-alg-id MUST refer an ID in the
Named Information Hash Algorithm Registry (see
https://www.iana.org/assignments/named-information/named-
information.xhtml); other hash algorithms MUST NOT be used.  The
hash-value MUST represent the raw hash value of the hashed resource
generated using the hash algorithm indicated by the hash-alg-id.
Paragraph (version B):
CoSWID adds explicit support for the representation of hash entries
using algorithms that are registered in the IANA "Named Information
Hash Algorithm Registry" using the hash-entry member (label 58).
Paragraph (version B):
The number used as a value for hash-alg-id MUST refer an ID in the
"Named Information Hash Algorithm Registry" (see
https://www.iana.org/assignments/named-information/named-
information.xhtml); other hash algorithms MUST NOT be used.  The
hash-value MUST represent the raw hash value of the hashed resource
generated using the hash algorithm indicated by the hash-alg-id.
Paragraph (version A):
A list of items both used in evidence (discovered by an inventory
process) and payload (installed in a system entity) content of a
CoSWID tag document to structure and differentiate the content of
specific CoSWID tag types.  Potential content includes directories,
files, processes, resources or firmwares.
Paragraph (version A):
filesystem-item: A list of items both used in representing the
nodes of a file-system hierarchy, i.e. directory items that allow
one or more directories to be defined in the file structure, and
file items that allow one or more files to be specified for a
given location.
Paragraph (version A):
directory-entry (index 16): A directory item allows one or more
directories to be defined in the file structure.
Paragraph (version A):
file-entry (index 17): A file element that allows one or more
files to be specified for a given location.
Paragraph (version A):
process-entry (index 18): Provides process (software component in
execution) information for data that will show up in a devices
process table.
Paragraph (version A):
resource-entry (index 19): A set of items that can be used to
provide arbitrary resource information about an application
installed on a system entity, or evidence collected from a system
entity.
Paragraph (version A):
size (index 20): The file size in bytes of the file.
Paragraph (version A):
key (index 22): Files that are considered important or required
for the use of a software component.  Typical key files would be
those which, if not available on a system entity, would cause the
software component not to execute or function properly.  Key files
will typically be used to validate that a software component
referenced by the CoSWID tag document is actually installed on a
specific system entity.
Paragraph (version A):
location (index 23): The directory or location where a file was
found or can expected to be located.  This text-string is intended
to include the filename itself.  This SHOULD be the relative path
from the location represented by the root item.
Paragraph (version B):
A list of items both used in evidence (created by a software
discovery process) and payload (installed in an endpoint) content of
a CoSWID tag document to structure and differentiate the content of
specific CoSWID tag types.  Potential content includes directories,
files, processes, or resources.
Paragraph (version B):
filesystem-item: A list of items both used in representing the
nodes of a file-system hierarchy (i.e., directory items that allow
one or more directories to be defined in the file structure), and
file items that allow one or more files to be specified for a
given location.
Paragraph (version B):
directory (index 16): A directory item allows one or more
directories to be defined in the file structure.
Paragraph (version B):
file (index 17): A file item that allows one or more files to be
specified for a given location.
Paragraph (version B):
process (index 18): Provides process (software component in
execution) information for data that will show up in a devices
process list.
Paragraph (version B):
resource (index 19): A set of items that can be used to provide
arbitrary resource information about an application installed on
in endpoint, or evidence collected from an endpoint.
Paragraph (version B):
size (index 20): The size of the file in bytes.
Paragraph (version B):
key (index 22): A boolean indicator for when files or directories
are considered important or required for the use of the software
component referenced by the CoSWID.  Typical key files or
directories would be those which, if not available on an endpoint,
would cause the software component not to execute or function
properly.  Key files or directories will typically be used to
validate that the software component referenced by the CoSWID tag
is actually installed on a specific endpoint.
Paragraph (version B):
location (index 23): The location where a file was found or can
expected to be located.  This text-string is intended to include
the filename itself.  This SHOULD be the relative path from the
location represented by the root item or if the root item is
omitted be relative to the location of the CoSWID tag.
Paragraph (version A):
path-elements (index 26): Provides the ability to apply a
directory structure to the path expressions for files defined in a
payload or evidence item.
Paragraph (version A):
process-name (index 27): The process name as it will be found in
the system entity's process table.
Paragraph (version B):
path-elements (index 26): This group provides the ability to apply
a directory structure to the path expressions for files defined in
a payload or evidence items.
Paragraph (version B):
process-name (index 27): The process name as it will be found in
the endpoints's process table.
Paragraph (version A):
device-id (index 36): A text-string identifier for a device
evidence was gathered from.
Paragraph (version B):
device-id (index 36): A textual identifier for a device evidence
was gathered from.
Paragraph (version A):
The operational model for SWID and CoSWID tags was introduced in
intro-lifecycle.  The following additional rules apply to the use of
CoSWID tags to ensure that created tags properly implement this
lifecycle.
Paragraph (version A):
The following rules can be used to determine the type of a CoSWID
tag.
Paragraph (version A):
Patch Tag: A CoSWID tag MUST be considered a patch tag if the
patch item is "true" and the corpus item is "false".
Paragraph (version A):
A tag that does not match one of the above rules MUST be considered
an invalid, unsupported tag type.
Paragraph (version A):
The following table contains an initial set of values for use in the
version-scheme item for the version schemes defined in the ISO/IEC
19770-2:2015 SWID specification.  Index value in parens indicates the
index value to use in the version-scheme item.
Paragraph (version A):
The values above are registered in the "SWID/CoSWID Version Schema
Values" registry defined in section iana-version-scheme.  Additional
valid values will likely be registered over time in this registry.
Additionally, the index values 32768 through 65535 have been reserved
for private use.
Paragraph (version A):
The following table indicates the index value to use for the entity
roles defined in the ISO/IEC 19770-2:2015 SWID specification.
Paragraph (version A):
The values above are registered in the "SWID/CoSWID Entity Role
Values" registry defined in section iana-entity-role.  Additional
valid values will likely be registered over time.  Additionally, the
index values 128 through 255 have been reserved for private use.
Paragraph (version A):
The following table indicates the index value to use for the link use
item (see model-link), which is also defined in the ISO/IEC
19770-2:2015 SWID specification.
Paragraph (version A):
The values above are registered in the "SWID/CoSWID Link Use Values"
registry defined in section iana-link-use.  Additional valid values
will likely be registered over time.  Additionally, the index values
128 through 255 have been reserved for private use.
Paragraph (version B):
The operational model for SWID and CoSWID tags was introduced in
intro-lifecycle, which described four different CoSWID tag types.
The following additional rules apply to the use of CoSWID tags to
ensure that created tags properly identify the tag type.
Paragraph (version B):
The first matching rule MUST determine the type of the CoSWID tag.
Paragraph (version B):
Patch Tag: A CoSWID tag MUST be considered a patch tag if the
patch item is "true".
Paragraph (version B):
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 B):
The values above are registered in the IANA "SWID/CoSWID Version
Schema Values" registry defined in section iana-version-scheme.
Additional entires will likely be registered over time in this
registry.  Additionally, the index values 32768 through 65535 have
been reserved for private use.
Paragraph (version B):
The following table indicates the index value to use for the entity-
entry group's role item (see model-entity).  These values match the
entity roles defined in the ISO/IEC 19770-2:2015 SWID specification.
Index value indicates the value to use as the role item's value.  The
Role Name provides human-readable text for the value.  The Definition
describes the semantic meaning of each entry.
Paragraph (version B):
The values above are registered in the IANA "SWID/CoSWID Entity Role
Values" registry defined in section iana-entity-role.  Additional
valid values will likely be registered over time.  Additionally, the
index values 128 through 255 have been reserved for private use.
Paragraph (version B):
The following table indicates the index value to use for the link-
entry group's use item (see model-link).  These values match the link
use values defined in the ISO/IEC 19770-2:2015 SWID specification.
Index value indicates the value to use as the link-entry group use
item's value.  The Use Type provides human-readable text for the
value.  The Definition describes the semantic meaning of each entry.
Paragraph (version B):
The values above are registered in the IANA "SWID/CoSWID Link Use
Values" registry defined in section iana-link-use.  Additional valid
values will likely be registered over time.  Additionally, the index
values 128 through 255 have been reserved for private use.
Paragraph (version A):
Initial registrations for the CoSWID Items Registry are provided
below.  Assignments consist of an integer index value, the item name,
and a reference to the defining specification.
Paragraph (version B):
Initial registrations for the "CoSWID Items" registry are provided
below.  Assignments consist of an integer index value, the item name,
and a reference to the defining specification.
Paragraph (version A):
Initial registrations for the SWID/CoSWID Version Schema Values
registry are provided below.  Assignments 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 Schema Values"
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):
Initial registrations for the SWID/CoSWID Entity Role Values registry
are provided below.  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 Values"
registry are provided below.  Assignments consist of an integer index
value, a role name, and a reference to the defining specification.
Paragraph (version A):
Initial registrations for the SWID/CoSWID Entity Role Values registry
are provided below.  Assignments consist of an integer index value,
the link use name, and a reference to the defining specification.
Paragraph (version B):
Initial registrations for the "SWID/CoSWID Entity Role Values"
registry are provided below.  Assignments consist of an integer index
value, the link use name, and a reference to the defining
specification.
Paragraph (version B):
IANA is requested add the following to the IANA "Media Types"
registry.
Paragraph (version A):
SWID tags are designed to be easily added and removed from an
endpoint along with the installation or removal of software
components.  On endpoints where addition or removal of software
components is tightly controlled, the addition or removal of SWID
tags can be similarly controlled.  On more open systems, where many
users can manage the software inventory, SWID tags may be easier to
add or remove.  On such systems, it may be possible to add or remove
SWID tags in a way that does not reflect the actual presence or
absence of corresponding software components.  Similarly, not all
software products automatically install SWID tags, so products may be
present on an endpoint without providing a corresponding SWID tag.
As such, any collection of SWID tags cannot automatically be assumed
to represent either a complete or fully accurate representation of
the software inventory of the endpoint.  However, especially on
devices that more strictly control the ability to add or remove
applications, SWID tags are an easy way to provide an preliminary
understanding of that endpoint's software inventory.
Paragraph (version B):
SWID tags are designed to be easily added and removed from an
endpoint along with the installation or removal of software
components.  On endpoints where addition or removal of software
components is tightly controlled, the addition or removal of SWID
tags can be similarly controlled.  On more open systems, where many
users can manage the software inventory, SWID tags can be easier to
add or remove.  On such systems, it can be possible to add or remove
SWID tags in a way that does not reflect the actual presence or
absence of corresponding software components.  Similarly, not all
software products automatically install SWID tags, so products can be
present on an endpoint without providing a corresponding SWID tag.
As such, any collection of SWID tags cannot automatically be assumed
to represent either a complete or fully accurate representation of
the software inventory of the endpoint.  However, especially on
devices that more strictly control the ability to add or remove
applications, SWID tags are an easy way to provide an preliminary
understanding of that endpoint's software inventory.
Paragraph (version A):
Finally, both the ISO-19770-2:2015 XML schema definition and the
Concise SWID data definition allow for the construction of "infinite"
SWID tags or SWID tags that contain malicious content with the intent
if creating non-deterministic states during validation or processing
of SWID tags.  While software product vendors are unlikely to do
this, SWID tags can be created by any party and the SWID tags
collected from an endpoint could contain a mixture of vendor and non-
vendor created tags.  For this reason, tools that consume SWID tags
ought to treat the tag contents as potentially malicious and should
employ input sanitizing on the tags they ingest.
Paragraph (version B):
Finally, both the ISO-19770-2:2015 XML schema definition and the
Concise SWID data definition allow for the construction of "infinite"
SWID tags or SWID tags that contain malicious content with the intent
if creating non-deterministic states during validation or processing
of SWID tags.  While software product vendors are unlikely to do
this, SWID tags can be created by any party and the SWID tags
collected from an endpoint could contain a mixture of vendor and non-
vendor created tags.  For this reason, tools that consume SWID tags
ought to treat the tag contents as potentially malicious and employ
input sanitizing on the tags they ingest.
Paragraph (version B):
Added table with semantics for the link ownership item.
Paragraph (version B):
Clarified language, made term use more consistent, fixed
references, and replacing lowercase RFC2119 keywords.