• Software Inventory Management, representing a part of a Software Asset Management process [SAM], which requires an accurate list of discernible deployed software components.
• Vulnerability Assessment, which requires a semantic link between standardized vulnerability descriptions and software components installed on IT assets [X.1520].
• Remote Attestation, which requires a link between Reference Integrity Manifests (RIMs) and Attester-produced event logs that complement attestation evidence [RFC 9334].

Primary Tag:

A SWID or CoSWID tag that identifies and describes an installed software component on an endpoint. A primary tag is intended to be installed on an endpoint along with the corresponding software component.

Patch Tag:

A SWID or CoSWID tag that identifies and describes an installed patch that has made incremental changes to a software component installed on an endpoint. A patch tag is intended to be installed on an endpoint along with the corresponding software component patch.

Corpus Tag:

A SWID or CoSWID tag that identifies and describes an installable software component in its pre-installation state. A corpus tag can be used to represent metadata about an installation package or installer for a software component, a software update, or a patch.

Supplemental Tag:

A SWID or CoSWID tag that allows additional information to be associated with a referenced SWID tag. This allows tools and users to record their own metadata about a software component without modifying CoSWID primary or patch tags created by a software provider.

                                  +------------+
                                  v            |
Software      Software        Software     Software      Software
Deployment -> Installation -> Patching  -> Upgrading  -> Removal

Corpus        Primary         Primary      xPrimary      xPrimary
Supplemental  Supplemental    Supplemental xSupplemental xSupplemental
                              Patch        xPatch
                                           Primary
                                           Supplemental

• 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).

• 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.

  Software Patching:

  When a patch is applied to the software component, a new patch tag is provided, 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.

  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.

  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.

• The explicit definition of types for some attributes in the ISO-19770-2:2015 XML representation that are typically represented by the any-attribute item in the SWID model. These are covered in Section 2.5.
• The inclusion of extension points in the CoSWID specification using CDDL sockets (see Section 3.9 of RFC 8610). The use of CDDL sockets allows 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.

concise-swid-tag = {
  tag-id => text / bstr .size 16,
  tag-version => integer,
  ? corpus => bool,
  ? patch => bool,
  ? supplemental => bool,
  software-name => text,
  ? software-version => text,
  ? version-scheme => $version-scheme,
  ? media => text,
  ? software-meta => one-or-more<software-meta-entry>,
  entity => one-or-more<entity-entry>,
  ? link => one-or-more<link-entry>,
  ? payload-or-evidence,
  * $$coswid-extension,
  global-attributes,
}

payload-or-evidence //= ( payload => payload-entry )
payload-or-evidence //= ( evidence => evidence-entry )

tag-id = 0
software-name = 1
entity = 2
evidence = 3
link = 4
software-meta = 5
payload = 6
corpus = 8
patch = 9
media = 10
supplemental = 11
tag-version = 12
software-version = 13
version-scheme = 14

$version-scheme /= multipartnumeric
$version-scheme /= multipartnumeric-suffix
$version-scheme /= alphanumeric
$version-scheme /= decimal
$version-scheme /= semver
$version-scheme /= int / text
multipartnumeric = 1
multipartnumeric-suffix = 2
alphanumeric = 3
decimal = 4
semver = 16384

global-attributes:

A list of items, including an optional language definition to support theprocessing of text-string values and an unbounded set of any-attribute items. Described in Section 2.5.

tag-id (index 0):

A 16-byte binary string, or a textual identifier, uniquely referencing a software component. The tagidentifier 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 (UUID) as defined by [RFC 4122]. There are no strict guidelines onhow the identifier is structured, but examples include a 16-byte Globally Unique Identifier (GUID) (e.g.,class 4 UUID) [RFC 4122], or a DNS domain name followed by a "/" and a text string, where the domain name serves to ensure uniqueness across organizations.A textual tag-id value MUST NOT contain a sequence of two underscores ("__"). This is because a sequence of two underscores is used to separate the TAG_CREATOR_REGID value and UNIQUE_ID value in a Software Identifier and a sequence of two underscores in a tag-id value could create ambiguity when parsing this identifier. See Section 6.7.

software-name (index 1):

A textual item that provides the software component's name. This name is likely the same name that would appear in a package management tool. This item maps to '/SoftwareIdentity/@name' in [SWID].

entity (index 2):

Provides information about one or more organizations responsible for producing the CoSWID tag, and producing or releasing the software component referenced by thisCoSWID tag. Described in Section 2.6.

evidence (index 3):

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 Section 2.9.4.

link (index 4):

Provides a means to establish relationship arcs between the tag and another item. A given link can be used to establish the relationship between tags or to reference another resource that is related to theCoSWID tag, e.g.,vulnerability database association, Resource-Oriented Lightweight Information Exchange (ROLIE) Feed [RFC 8322], Manufacturer Usage Description (MUD) resource [RFC 8520], software download location, etc.).This is modeled after the HTML "link" element. Described in Section 2.7.

software-meta (index 5):

An open-ended map of key/value data pairs.A number of predefined keys can be used within this item providing forcommon usage and semantics across the industry. The use of this map allows any additionalattribute to be included in the tag. It is expected that industry groups will use a common set of attribute names to allow for interoperability within their communities. Described in Section 2.8. This item maps to '/SoftwareIdentity/Meta' in [SWID].

payload (index 6):

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 componentis 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 theendpoint 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 Section 2.9.3.

corpus (index 8):

A boolean value that indicates if the tag identifies and describes an installable software component in its pre-installation state. Installable software includes an installation package or installer for a software component, a software update, or a patch. If the CoSWID tag represents installable software, the corpus item MUST be set to "true". If not provided, the default value MUST be considered "false".

patch (index 9):

A boolean value that indicates if the tag identifies and describes an installed patch that has made incremental changes to a software component installed on an endpoint. 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". A patch item's value MUST NOT be set to "true" if the installation of the associated software package changes the version of a software component.

media (index 10):

A text value that provides a hint to the tag consumer to understand what target platform this tagapplies to. This item MUST be formatted as aquery as defined by the W3C "Media Queries Level 3" Recommendation (see [W3C.REC-mediaqueries-3-20220405]). Support for media queries is 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.

supplemental (index 11):

A boolean value that indicates if the tag is providing additional information to be associated with another referenced SWID or CoSWID tag. This allows tools and users to record their own metadata about a software component without modifying SWID primary or patch tags created by a software provider. 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".

tag-version (index 12):

An integer value that indicates 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.

software-version (index 13):

A textual value representing the specific release or development version of the software component. This item maps to '/SoftwareIdentity/@version' in [SWID].

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. For the "Version Scheme" values, see Section 4.1.If an integer value is used, it MUST be an index value in the range -256 to 65535. Integer values in the range -256 to -1 are reserved for testing and use in closed environments (see Section 6.2.2). Integer values in the range 0 to 65535 correspond to registered entries in the IANA "Software ID Version Scheme Values" registry (see Section 6.2.4).

$$coswid-extension:

A CDDL socket that is used to add new information structures to the concise-swid-tag root map. See Section 2.2.

• The patch and supplemental items MUST NOT both be set to "true".
• If the patch item is set to "true", the tag MUST contain at least one link item (see Section 2.7) 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.
• If all of the corpus, patch, and supplemental items are "false" or if the corpus item is set to "true", then a software-version item MUST be included with a value set to the version of the software component.

global-attributes = (
  ? lang => text,
  * any-attribute,
)

any-attribute = (
  label => one-or-more<text> / one-or-more<int>
)

label = text / int

lang (index 15):

A textual language tag thatconforms with the IANA "Language Subtag Registry" [RFC 5646]. 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.

any-attribute:

A sub-group that provides a means to include arbitrary informationvia label/index ("key") value pairs. Labels can be either a single integer or text string. Values can be a single integer, a text string, or an array of integers or text strings.

entity-entry = {
  entity-name => text,
  ? reg-id => any-uri,
  role => one-or-more<$role>,
  ? thumbprint => hash-entry,
  * $$entity-extension,
  global-attributes,
}

entity-name = 31
reg-id = 32
role = 33
thumbprint = 34

$role /= tag-creator
$role /= software-creator
$role /= aggregator
$role /= distributor
$role /= licensor
$role /= maintainer
$role /= int / text
tag-creator=1
software-creator=2
aggregator=3
distributor=4
licensor=5
maintainer=6

global-attributes:

The global-attributes group as described in Section 2.5.

entity-name (index 31):

The textual name of the organizational entity claiming the roles specified by the role item for the CoSWID tag. This item maps to '/SoftwareIdentity/Entity/@name' in [SWID].

reg-id (index 32):

Registration ID. This value is intended to uniquely identify a naming authority in agiven scope (e.g., global, organization, vendor, customer, administrative domain,etc.) for the referenced entity. The value of aregistration ID MUST be a URI as defined in [RFC 3986]; it is not intended to be dereferenced. The scope will usually be the scope of an organization.

role (index 33):

An integer or textual value (integer label with text escape; see Section 2) representing the relationship(s) between the entity and this tag or the referenced software component. If an integer value is used, it MUST be an index value in the range -256 to 255. Integer values in the range -256 to -1 are reserved for testing and use in closed environments (see Section 6.2.2). Integer values in the range 0 to 255 correspond to registered entries in the IANA "Software ID Entity Role Values" registry (see Section 6.2.5).

The following additional requirements exist for the use of the role item:

• An entity item MUST be provided with the role of "tag-creator" for every CoSWID tag. This indicates the organization that created the CoSWID tag.
• 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.

thumbprint (index 34):

Value that provides a hash (i.e., the thumbprint) of the signing entity's public key certificate. This item provides an indicator of which entity signed the CoSWID tag, which will typically be the tag creator. See Section 2.9.1 for more details on the use of the hash-entry data structure.

$$entity-extension:

A CDDL socket that can be used to extend the entity-entry group model. See Section 2.2.

link-entry = {
  ? artifact => text,
  href => any-uri,
  ? media => text,
  ? ownership => $ownership,
  rel => $rel,
  ? media-type => text,
  ? use => $use,
  * $$link-extension,
  global-attributes,
}

media = 10
artifact = 37
href = 38
ownership = 39
rel = 40
media-type = 41
use = 42

$ownership /= shared
$ownership /= private
$ownership /= abandon
$ownership /= int / text
abandon=1
private=2
shared=3

$rel /= ancestor
$rel /= component
$rel /= feature
$rel /= installationmedia
$rel /= packageinstaller
$rel /= parent
$rel /= patches
$rel /= requires
$rel /= see-also
$rel /= supersedes
$rel /= supplemental
$rel /= -256..65536 / text
ancestor=1
component=2
feature=3
installationmedia=4
packageinstaller=5
parent=6
patches=7
requires=8
see-also=9
supersedes=10
supplemental=11

$use /= optional
$use /= required
$use /= recommended
$use /= int / text
optional=1
required=2
recommended=3

global-attributes:

The global-attributes group as described in Section 2.5.

media (index 10):

A value that provides a hint to the consumer of the link so that the consumer understands what target platform the link is applicable to. This item represents aquery as defined by the W3C "Media Queries Level 3" Recommendation (see [W3C.REC-mediaqueries-3-20220405]). As highlighted in the definition of the media item provided in Section 2.3, support for media queries is 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.

artifact (index 37):

To be used with rel="installationmedia". This item's value provides the absolute filesystem 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.

href (index 38):

A URI-reference [RFC 3986] for the referenced resource. The href item's value can be, but is not limited to, the following (which is a slightly modified excerpt from [SWID]):

• If no URI scheme is provided, then the URI-reference is a relative reference to the base URI of the CoSWID tag, i.e., the URI under which the CoSWID tag was provided -- for example, "./folder/supplemental.coswid".
• This item can be a physical resource location with any acceptable URI scheme (e.g., <file://>, <http://>, <https://>, <ftp://>).
• A URI-like expression with "swid:" as the scheme refers to another SWID or CoSWID by the referenced tag's tag-id. This expression needs to be resolved in the context of the endpoint by software that can look up other SWID or CoSWID tags. For example, "swid:2df9de35-0aff-4a86-ace6-f7dddd1ade4c" references the tag with the tag-id value "2df9de35-0aff-4a86-ace6-f7dddd1ade4c". See Section 5.1 for guidance on the "swid" expressions.
• This item can be a URI-like expression 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 (Section 5.2). 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 Section 5.2 for guidance on the "swidpath" expressions.

ownership (index 39):

An integer or textual value (integer label with text escape; see Section 2). See Section 4.3 for the list of values available for this item. This item is used when the href item references another software component to indicate the degree of ownership between the software component referenced by the CoSWID tag and the software component referenced by the link. If an integer value is used, it MUST be an index value in the range -256 to 255. Integer values in the range -256 to -1 are reserved for testing and use in closed environments (see Section 6.2.2). Integer values in the range 0 to 255 correspond to registered entries in the "Software ID Link Ownership Values" registry.

rel (index 40):

An integer or textual value (integer label with text escape; see Section 2). See Section 4.4 for the list of values available for this item. This item identifies the relationship between this CoSWID and the target resource identified by the href item. If an integer value is used, it MUST be an index value in the range -256 to 65535. Integer values in the range -256 to -1 are reserved for testing and use in closed environments (see Section 6.2.2). Integer values in the range 0 to 65535 correspond to registered entries in the IANA "Software ID Link Relationship Values" registry (see Section 6.2.7). If a string value is used, it MUST be either a private use name as defined in Section 6.2.2 or a "Relation Name" from the IANA "Link Relation Types" registry (see <https://www.iana.org/assignments/link-relations/>) as defined by [RFC 8288]. When a string value defined in the IANA "Software ID Link Relationship Values" registry matches a Relation Name defined in the IANA "Link Relation Types" registry, the index value in the IANA "Software ID Link Relationship Values" registry MUST be used instead, as this relationship has a specialized meaning in the context of a CoSWID tag. String values correspond to registered entries in the "Software ID Link Relationship Values" registry.

media-type (index 41):

Supplies the resource consumer with a hint regarding what type of resource to expect. A link can point to arbitrary resources on the endpoint, local network, or Internet using the href item. (This is a hint: thereis no obligation for the server hosting the target of the URI to use theindicated media type when the URI is dereferenced.)Media types are identified by referencing a "Name" from the IANA "Media Types" registry (see <https://www.iana.org/assignments/media-types/>). This item maps to '/SoftwareIdentity/Link/@type' in [SWID].

use (index 42):

An integer or textual value (integer label with text escape; see Section 2). See Section 4.5 for the list of values available for this item. This item is used to determine if the referenced software component has to be installed before installing the software component identified by the CoSWID tag. If an integer value is used, it MUST be an index value in the range -256 to 255. Integer values in the range -256 to -1 are reserved for testing and use in closed environments (see Section 6.2.2). Integer values in the range 0 to 255 correspond to registered entries in the IANA "Software ID Link Use Values" registry (see Section 6.2.8). If a string value is used, it MUST be a private use name as defined in Section 6.2.2. String values correspond to registered entries in the "Software ID Link Use Values" registry.

$$link-extension:

A CDDL socket that can be used to extend the link-entry map model. See Section 2.2.

software-meta-entry = {
  ? activation-status => text,
  ? channel-type => text,
  ? colloquial-version => text,
  ? description => text,
  ? edition => text,
  ? entitlement-data-required => bool,
  ? entitlement-key => text,
  ? generator => text / bstr .size 16,
  ? persistent-id => text,
  ? product => text,
  ? product-family => text,
  ? revision => text,
  ? summary => text,
  ? unspsc-code => text,
  ? unspsc-version => text,
  * $$software-meta-extension,
  global-attributes,
}

activation-status = 43
channel-type = 44
colloquial-version = 45
description = 46
edition = 47
entitlement-data-required = 48
entitlement-key = 49
generator = 50
persistent-id = 51
product = 52
product-family = 53
revision = 54
summary = 55
unspsc-code = 56
unspsc-version = 57

global-attributes:

The global-attributes group as described in Section 2.5.

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.

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, original equipment manufacturer (OEM), academic, etc.). This attribute is typically used in supplemental tags, as it contains information that might be selected during a specific install.

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 a similar value 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.

description (index 46):

A textual value that provides a detailed description of the software component. This value MAY be multiple paragraphs separated by CR LF characters as described by [RFC 5198].

edition (index 47):

A textual value indicating that the software component represents a functional variation of the code base used to support multiple software components. For example, this item can be used to differentiate enterprise, standard, or professional variants of a software component.

entitlement-data-required (index 48):

A boolean value that can be used to determine if accompanying proof of entitlement is needed when a software license reconciliation process is performed.

entitlement-key (index 49):

A vendor-specific textual key that can be used to identify and establish a relationship to an entitlement. Examples of an entitlement-key might include a serial number, product key, or license key. For values that relate to a given software component install (e.g., license key), a supplemental tag will typically contain this information. In other cases, where a general-purpose key can be provided that applies to all possible installs of the software component on different endpoints, a primary tag will typically contain this information.Since CoSWID tags are not intended to contain confidential information, tag authors are advised not to record unprotected, private software license keys in this field.

generator (index 50):

The name (or tag-id) of the software component that created the CoSWID tag. If the generating software component has a SWID or CoSWID tag, then the tag-id for the generating software component SHOULD be provided.

persistent-id (index 51):

A globally unique identifier used to identify a set of software components that are related. Software components sharing the same persistent-id can be different versions. This item can be used to relate software components, released at different points in time or through different release channels, that may not be able to be related through the use of the link item.

product (index 52):

A basic name for the software component that can be common across multiple tagged software components (e.g., Apache HTTP daemon (HTTPD)).

product-family (index 53):

A textual value indicating the software components' overall product family. This should be used when multiple related software components form a larger capability that is installed on multiple different endpoints. For example, some software families may consist of a server, a client, and shared service components that are part of a larger capability. Email systems, enterprise applications, backup services, web conferencing, and similar capabilities are examples of families. The use of this item is not intended to represent groups of software that are bundled or installed together. The persistent-id or link items SHOULD be used to relate bundled software components.

revision (index 54):

A string value indicating an informal or colloquial release version of the software. This value can provide a different version value as compared to the software-version specified in the concise-swid-tag group. This is useful when one or more releases need to have an informal version label that differs from the specific exact version value specified by software-version. Examples can include SP1, RC1, Beta, etc.

summary (index 55):

A short description of the software component. This MUST be a single sentence suitable for display in a user interface.

unspsc-code (index 56):

An 8-digit United Nations Standard Products and Services Code (UNSPSC) classification code for the software component as defined by the UNSPSC [UNSPSC].

unspsc-version (index 57):

The UNSPSC version used to define the unspsc-code value.

$$software-meta-extension:

A CDDL socket that can be used to extend the software-meta-entry group model. See Section 2.2.

path-elements-group = ( ? directory => one-or-more<directory-entry>,
                        ? file => one-or-more<file-entry>,
                      )

resource-collection = (
  path-elements-group,
  ? process => one-or-more<process-entry>,
  ? resource => one-or-more<resource-entry>,
  * $$resource-collection-extension,
)

filesystem-item = (
  ? key => bool,
  ? location => text,
  fs-name => text,
  ? root => text,
)

file-entry = {
  filesystem-item,
  ? size => uint,
  ? file-version => text,
  ? hash => hash-entry,
  * $$file-extension,
  global-attributes,
}

directory-entry = {
  filesystem-item,
  ? path-elements => { path-elements-group },
  * $$directory-extension,
  global-attributes,
}

process-entry = {
  process-name => text,
  ? pid => integer,
  * $$process-extension,
  global-attributes,
}

resource-entry = {
  type => text,
  * $$resource-extension,
  global-attributes,
}

hash = 7
directory = 16
file = 17
process = 18
resource = 19
size = 20
file-version = 21
key = 22
location = 23
fs-name = 24
root = 25
path-elements = 26
process-name = 27
pid = 28
type = 29

filesystem-item:

A list of common items used for representing the filesystem root, relative location, name, and significance of a file or directory item.

global-attributes:

The global-attributes group as described in Section 2.5.

hash (index 7):

Value that provides a hash of a file. This item provides an integrity measurement with respect to a specific file. See Section 2.9.1 for more details on the use of the hash-entry data structure.

directory (index 16):

Item that allows child directory and file items to be defined within a directory hierarchy for the software component.

file (index 17):

Item that allows details about a file to be provided for the software component.

process (index 18):

Item that allows details to be provided about the runtime behavior of the software component, such as information that will appear in a process listing on an endpoint.

resource (index 19):

Item that can be used to provide details about an artifact or capability expected to be found on an endpoint or evidence collected related to the software component. This can be used to represent concepts not addressed directly by the directory, file, or process items. Examples include registry keys, bound ports, etc. The equivalent construct in [SWID] is currently underspecified. As a result, this item might be further defined through extensions in the future.

size (index 20):

The file's size in bytes.

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].

key (index 22):

A boolean value indicating if a file or directory is significant or required for the software component to execute or function properly. These are files or directories that can be used to affirmatively determine if the software component is installed on an endpoint.

location (index 23):

The filesystem path where a file is expected to be located when installed or copied. The location MUST be either an absolute path, a path relative to the path value included in the parent directory item (preferred), or a path 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.

fs-name (index 24):

The name of the directory or file without any path information. This aligns with a file "name" in [SWID]. This item maps to '/SoftwareIdentity/(Payload|Evidence)/(File|Directory)/@name' in [SWID].

root (index 25):

A host-specific name for the root of the filesystem. The location item is considered relative to this location if specified. If not provided, the value provided by the location item is expected to be relative to its parent or the location of the CoSWID tag if no parent is provided.

path-elements (index 26):

Group that allows a hierarchy of directory and file items to be defined in payload or evidence items. This is a construction within the CDDL definition of CoSWID to support shared syntax and does not appear in [SWID].

process-name (index 27):

The software component's process name as it will appear in an endpoint's process list. This aligns with a process "name" in [SWID]. This item maps to '/SoftwareIdentity/(Payload|Evidence)/Process/@name' in [SWID].

pid (index 28):

The process ID identified for a running instance of the software component in the endpoint's process list. This is used as part of the evidence item.

type (index 29):

A human-readable string indicating the type of resource.

$$resource-collection-extension:

A CDDL socket that can be used to extend the resource-collection group model. This can be used to add new specialized types of resources. See Section 2.2.

$$file-extension:

A CDDL socket that can be used to extend the file-entry group model. See Section 2.2.

$$directory-extension:

A CDDL socket that can be used to extend the directory-entry group model. See Section 2.2.

$$process-extension:

A CDDL socket that can be used to extend the process-entry group model. See Section 2.2.

$$resource-extension:

A CDDL socket that can be used to extend the resource-entry group model. See Section 2.2.

payload-entry = {
  resource-collection,
  * $$payload-extension,
  global-attributes,
}

global-attributes:

The global-attributes group as described in Section 2.5.

resource-collection:

The resource-collection group as described in Section 2.9.2.

$$payload-extension:

A CDDL socket that can be used to extend the payload-entry group model. See Section 2.2.

evidence-entry = {
  resource-collection,
  ? date => integer-time,
  ? device-id => text,
  ? location => text,
  * $$evidence-extension,
  global-attributes,
}

date = 35
device-id = 36

global-attributes:

The global-attributes group as described in Section 2.5.

resource-collection:

The resource-collection group as described in Section 2.9.2.

location (index 23):

The filesystem path of the location of the CoSWID tag generated as evidence. This path is always an absolute file path (unlike the value of a location item found within a filesystem-item as describedin Section 2.9.2, which can be either a relative path or an absolute path).

date (index 35):

The date and time the information was collected pertaining to the evidence item in epoch-based date/time format as specified in Section 3.4.2 of RFC 8949.

device-id (index 36):

The endpoint's string identifier from which the evidence was collected.

$$evidence-extension:

A CDDL socket that can be used to extend the evidence-entry group model. See Section 2.2.

Primary Tag:

A CoSWID tag MUST be considered a primary tag if the corpus, patch, and supplemental items are "false".

Supplemental Tag:

A CoSWID tag MUST be considered a supplemental tag if the supplemental item is set to "true".

Corpus Tag:

A CoSWID tag MUST be considered a corpus tag if the corpus item is "true".

Patch Tag:

A CoSWID tag MUST be considered a patch tag if the patch item is "true".

• "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, it is expected that the "decimal" version scheme is used.
• "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, it is expected that the "semver" version scheme is used.
• "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, it is expected that the other version scheme is used and "alphanumeric" is not used.

• 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 Section 2.1 of RFC 3986.
• 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.

• The requesting specification MUST provide a clear semantic definition for the new entry. This definition MUST clearly differentiate the requested entry from other previously registered entries.
• The requesting specification MUST describe the intended use of the entry, including any co-constraints that exist between (1) the use of the entry's index value or name and (2) other values defined within the SWID/CoSWID model.
• Index values and names outside the private use space MUST NOT be used without registration. This is considered "squatting" and MUST be avoided. Designated experts MUST ensure that reviewed specifications register all appropriate index values and names.
• Standards Track documents MAY include entries registered in the range reserved for entries under the Specification Required policy. This can occur when a Standards Track document provides further guidance on the use of index values and names that are in common use but were not registered with IANA. This situation SHOULD be avoided.
• All registered names MUST be valid according to the XML Schema NMTOKEN data type (see [W3C.REC-xmlschema-2-20041028], Section 3.3.4). This ensures that registered names are compatible with the SWID format [SWID] where they are used.
• Registration of vanity names SHOULD be discouraged. The requesting specification MUST provide a description of how a requested name will allow for use by multiple stakeholders.

Type name:

application

Subtype name:

swid+cbor

Required parameters:

none

Optional parameters:

none

Encoding considerations:

Binary (encoded as CBOR [RFC 8949]).See RFC 9393 for details.

Security considerations:

See Section 9 of RFC 9393.

Interoperability considerations:

Applications MAY ignore any keyvalue pairs that they do not understand. This allowsbackwards-compatible extensions to this specification.

Published specification:

RFC 9393

Applications that use this media type:

The type is used by softwareasset management systems and vulnerability assessment systems and is used inapplications that use remote integrity verification.

Fragment Identifier Considerations:

The syntax and semantics offragment identifiers specified for "application/swid+cbor" are as specifiedfor "application/cbor". (At publication of RFC 9393, there is nofragment identification syntax defined for "application/cbor".)

Additional information:

Magic number(s):

If tagged, the first five bytes in hex: da 53 57 49 44 (see Section 8 of RFC 9393).

File extension(s):

coswid

Macintosh file type code(s):

none

Macintosh Universal Type Identifier code:

org.ietf.coswidconforms to public.data.

Person & email address to contact for further information:

IESG <iesg@ietf.org>

Intended usage:

COMMON

Restrictions on usage:

none

Author:

Henk Birkholz <henk.birkholz@sit.fraunhofer.de>

Change controller:

IESG

Scheme name:

swid

Status:

Provisional

Applications/protocols that use this scheme name:

Applications that require Software IDs (SWIDs) or ConciseSoftware IDs (CoSWIDs); see Section 5.1 of RFC 9393.

Contact:

IETF Chair <chair@ietf.org>

Change controller:

IESG <iesg@ietf.org>

Reference:

Section 5.1 of RFC 9393

Scheme name:

swidpath

Status:

Provisional

Applications/protocols that use this scheme name:

Applications that require Software IDs (SWIDs) or ConciseSoftware IDs (CoSWIDs); see Section 5.2 of RFC 9393.

Contact:

IETF Chair <chair@ietf.org>

Change controller:

IESG <iesg@ietf.org>

Reference:

Section 5.2 of RFC 9393

Pen:

0

Integer:

2

Name:

Concise Software Identifier (CoSWID)

Reference:

RFC 9393

Deriving Software Identifiers:

A Software Identifier generated from a CoSWID tag is expressed as a concatenation of the form used in [RFC 5234] as follows --

TAG_CREATOR_REGID "_" "_" UNIQUE_ID

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 [RFC 4122], including the "urn:uuid:" prefix.

The TAG_CREATOR_REGID and the UNIQUE_ID are connected with a double underscore (_), without any other connecting character or whitespace.

• ensuring the integrity and authenticity of a CoSWID tag
• the application of CoSWID tags to address security challenges related to unmanaged or unpatched software
• reducing the potential for unintended disclosure of a device's software load

[BCP178]

P. Saint-Andre, D. Crocker, and M. Nottingham, "Deprecating the "X-" Prefix and Similar Constructs in Application Protocols", BCP 178, RFC 6648, DOI 10.17487/RFC6648, June 2012,
<https://www.rfc-editor.org/info/rfc6648>.

[BCP26]

M. Cotton, B. Leiba, and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.

[IANA.cbor-tags]

Internet Assigned Numbers Authority, "Concise Binary Object Representation (CBOR) Tags",
<https://www.iana.org/assignments/cbor-tags>.

[IANA.core-parameters]

Internet Assigned Numbers Authority, "Constrained RESTful Environments (CoRE) Parameters",
<https://www.iana.org/assignments/core-parameters>.

[IANA.media-types]

Internet Assigned Numbers Authority, "Media Types",
<https://www.iana.org/assignments/media-types>.

[IANA.named-information]

Internet Assigned Numbers Authority, "Named Information",
<https://www.iana.org/assignments/named-information>.

[IANA.pa-tnc-parameters]

Internet Assigned Numbers Authority, "Posture Attribute (PA) Protocol Compatible with Trusted Network Connect (TNC) Parameters",
<https://www.iana.org/assignments/pa-tnc-parameters>.

[IANA.uri-schemes]

Internet Assigned Numbers Authority, "Uniform Resource Identifier (URI) Schemes",
<https://www.iana.org/assignments/uri-schemes>.

[RFC2119]

S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.

[RFC3629]

F. Yergeau, "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003,
<https://www.rfc-editor.org/info/rfc3629>.

[RFC3986]

T. Berners-Lee, R. Fielding, and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>.

[RFC5198]

J. Klensin, and M. Padlipsky, "Unicode Format for Network Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008,
<https://www.rfc-editor.org/info/rfc5198>.

[RFC5234]

D. Crocker, and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>.

[RFC5646]

A. Phillips, and M. Davis, "Tags for Identifying Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, September 2009,
<https://www.rfc-editor.org/info/rfc5646>.

[RFC5890]

J. Klensin, "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, August 2010,
<https://www.rfc-editor.org/info/rfc5890>.

[RFC7252]

Z. Shelby, K. Hartke, and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014,
<https://www.rfc-editor.org/info/rfc7252>.

[RFC8174]

B. Leiba, "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017,
<https://www.rfc-editor.org/info/rfc8174>.

[RFC8288]

M. Nottingham, "Web Linking", RFC 8288, DOI 10.17487/RFC8288, October 2017,
<https://www.rfc-editor.org/info/rfc8288>.

[RFC8412]

C. Schmidt, D. Haynes, C. Coffin, D. Waltermire, and J. Fitzgerald-McKay, "Software Inventory Message and Attributes (SWIMA) for PA-TNC", RFC 8412, DOI 10.17487/RFC8412, July 2018,
<https://www.rfc-editor.org/info/rfc8412>.

[RFC8610]

H. Birkholz, C. Vigano, and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, June 2019,
<https://www.rfc-editor.org/info/rfc8610>.

[RFC8949]

C. Bormann, and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/info/rfc8949>.

[RFC9052]

J. Schaad, "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, DOI 10.17487/RFC9052, August 2022,
<https://www.rfc-editor.org/info/rfc9052>.

[RFC9338]

J. Schaad, "CBOR Object Signing and Encryption (COSE): Countersignatures", STD 96, RFC 9338, DOI 10.17487/RFC9338, December 2022,
<https://www.rfc-editor.org/info/rfc9338>.

[SAM]

"Information technology - IT asset management - Part 5: Overview and vocabulary", August 2015,
<https://www.iso.org/standard/68291.html>.

[SWID]

"Information technology - IT asset management - Part 2: Software identification tag", October 2015,
<https://www.iso.org/standard/65666.html>.

[UNSPSC]

"United Nations Standard Products and Services Code", 2022,
<https://www.unspsc.org/>.

[W3C.REC-mediaqueries-3-20220405]

, "Media Queries Level 3", April 2022,
<https://www.w3.org/TR/mediaqueries-3/>.

[W3C.REC-xmlschema-2-20041028]

, and , "XML Schema Part 2: Datatypes Second Edition", October 2004,
<https://www.w3.org/TR/2004/REC-xmlschema-2-20041028/>.

[W3C.REC-xpath20-20101214]

, , , , , , and , "XML Path Language (XPath) 2.0 (Second Edition)", December 2010,
<https://www.w3.org/TR/2010/REC-xpath20-20101214/>.

[CamelCase]

"Camel Case (upper camel case)", December 2014,
<http://wiki.c2.com/?CamelCase>.

[KebabCase]

"Kebab Case", August 2014,
<http://wiki.c2.com/?KebabCase>.

[RFC3444]

A. Pras, and J. Schoenwaelder, "On the Difference between Information Models and Data Models", RFC 3444, DOI 10.17487/RFC3444, January 2003,
<https://www.rfc-editor.org/info/rfc3444>.

[RFC4122]

P. Leach, M. Mealling, and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, DOI 10.17487/RFC4122, July 2005,
<https://www.rfc-editor.org/info/rfc4122>.

[RFC7595]

D. Thaler, T. Hansen, and T. Hardie, "Guidelines and Registration Procedures for URI Schemes", BCP 35, RFC 7595, DOI 10.17487/RFC7595, June 2015,
<https://www.rfc-editor.org/info/rfc7595>.

[RFC8322]

J. Field, S. Banghart, and D. Waltermire, "Resource-Oriented Lightweight Information Exchange (ROLIE)", RFC 8322, DOI 10.17487/RFC8322, February 2018,
<https://www.rfc-editor.org/info/rfc8322>.

[RFC8520]

E. Lear, R. Droms, and D. Romascanu, "Manufacturer Usage Description Specification", RFC 8520, DOI 10.17487/RFC8520, March 2019,
<https://www.rfc-editor.org/info/rfc8520>.

[RFC9334]

H. Birkholz, D. Thaler, M. Richardson, N. Smith, and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, DOI 10.17487/RFC9334, January 2023,
<https://www.rfc-editor.org/info/rfc9334>.

[SEMVER]

T. Preston-Werner, "Semantic Versioning 2.0.0",
<https://semver.org/spec/v2.0.0.html>.

[SWID-GUIDANCE]

G2, Inc, D. Waltermire, B. A. Cheikes, L. Feldman, and G. Witte, "Guidelines for the Creation of Interoperable Software Identification (SWID) Tags", April 2016,
<https://doi.org/10.6028/NIST.IR.8060>.

[X.1520]

ITU-T, "Common vulnerabilities and exposures", January 2014,
<https://www.itu.int/rec/T-REC-X.1520>.

Carsten Bormann

Henk Birkholz

Jessica Fitzgerald-McKay

Charles Schmidt

David Waltermire