CHAPTER 5: IMPLEMENTATION OF THE ISO/IEC 19770-2 PROCESS

ISO/IEC 19770 general guidelines

Consistency among data types

Data input into tagging fields must maintain consistencies that optimise the software detection processes for discovery tools, SAM and other software life cycle management owners alike. For example, it is recommended that, if possible, software manufacturers should maintain consistency in the manufacturer name field within any given product line. Although this document does not require consistency in the manufacturer name field for operating systems, uniformity is strongly urged.

Pre-manufactured media

Acknowledging that some resellers may only ship pre-manufactured media and therefore find tag modification difficult or impossible, this document proposes three possible implementation alternatives to allow for, or preclude the necessity of, reseller tag modification:

• Download a tag separately from the media – an alternative that requires a manual step from the reseller to get the correct tag from the manufacturer and to modify it.
• Allocate modification to the software manufacturer, each individual reseller’s tags preconfigured with the relevant information specific to that reseller.
• Implement a tag from the manufacturer that is generic enough to preclude the necessity of modification.

Languages

Acknowledging that many manufacturers produce software with specific builds that are dependent on language and that many others produce software with one build that implements add-on language packs, this document does not require that tagging methods allow for the recognition of different language versions for the same product. Consistent categorisation of the type of language solution employed is, however, strongly encouraged.

Tag installation

It is recommended that SWID tags should be routinely embedded into software installers so as to distinguish unapproved versions of a product from approved versions via the presence/absence of a manufacturer’s proprietary tag elements.

Unique identification

For purposes of uniqueness, tag creators must create a globally unique identifier (GUID) to assign to each particular piece of software’s SWID tag. The value of the GUID should be exclusive to a particular release of software. The GUID can be used to reference a tag in other, related tags. TagVault.org managed tags allow the assignment of a unique GUID across the TagVault domain. The cross-referencing capabilities of a GUID include, but are not limited to:

• the creation of a supported platforms list in which software vendors can list supported platform unique identifiers in the SWID tag so as to specify operating system compatibilities;
• direct reference of parent-child relationships via the specification of the parent SWID tag for software packages;
• explicit definitions of dependencies by direct references to the GUIDs of dependent software;
• identification of upgrade software as such and specifications for allowed upgrade packages;
• reference from executable software configuration items to corresponding SWID tags via embedded identifiers within the former.

Basic process

The sequence of applying tags consists of multiple steps. For each product requiring tagging, analyse as follows:

• Understand the deployment/functional model.
• Design the tag(s) to describe the functional components of the deployment model.

For each deployment to be tagged:

• Create the tagging directories.
• Deploy tag appropriate to the deployment/functional model.

Understanding the deployment/functional model

Simple classic model

The deployment can be a simple set of binaries that provides a single set of functionality that is not configurable.

Figure 7: Classic tag

In this case, the deployment can be labelled with a single classic tag in two locations:

• root location of the application
• ISO/IEC 19770-2 proposed standard location.

Details of each are described below.

Complex classic model

In the case where there may be add-ons in the deployment model, there are tags for each component, where the build tag can describe the ‘base component’ and then component tags describe each component.

Figure 8: Classic complex tag

If the entire available functionality is installed as a single deployment, then the build tag can describe the deployment. If the additional functionality is achieved by adding new components to the base component, then each component tag can describe the additional deployment.

The presence of any tag does not imply that the software that is tagged is in use. If there are rules for measuring activity, these rules can be derived from the optional usage element, if it is included in the tag.

Attribute/element groups

In the case where attributes may need protection, the attributes are grouped by owner (either a creator or modifier) and the group is signed. In the above example, for instance, all mandatory elements plus either the ‘component list’ or ‘component of’ elements might form a group for signing. There may be other elements that do not require protection in any tag generated and these can be formed within the tag at the same time as the signed group by the tag generation mechanism.

Designing the tags to match the functional deployment model

Tag identification

The functionality of an IEC/ISO 19770-2 tag is such that each tag can be identifiable as unique (see serial_number below in the section on tag optional elements).

In order to achieve this, there is a preference for a central clearing house that assigns, at minimum, a unique identifier for each tag generated that is identified in the ISO proposed standard as serial_number.

The tag container

The tag container, or file, must also conform to specific parameters. The proposed ISO standard is as follows:

The name of a software tag must be unique and align with the following structure: <product_title>-<serial_number>.swtag. The components of the tag filename are identity elements required of all software tags. The .swtag file extension can be used for all software tags. This naming scheme allows for multiple software tags to be applied to the same product, thereby providing support for upgrades and audit capabilities.

If a software configuration item is installed for a specific user, a suffix containing user identification information (e.g. ‘userlD’) should be used to differentiate unique installations. An example name in such an instance would be <product_title>-<serial_number>-<userlD>.swtag.

An application, such as VTP, must generate digitally signed tag files as part of the process.

The digital signature can be generated uniquely based upon pre-selected criteria, e.g. by publisher or by tag attribute, or a combination of attributes. This functionality can allow verification of tags in a customised fashion.

The clearing house can provide additional services such as:

• providing tag information and contents by tag attribute
• providing other management facilities on a per tag or tag provider basis.

Indicating the presence of an application deployment

The detection of a deployment may vary depending upon the deployment measurement tool.

Create the tagging directories

ISO/IEC 19770-2 standard tagging location

Table 1: Tagging directories

The above is the ISO-defined root location.

The field ‘Company’ can use a unique corporate identifier as assigned by the clearing house, in much the same way as a DNS domain name is assigned. The ‘Company’ may be chosen by the requestor and maintained as unique by the clearing house. The identifier field may also use the 10-digit IBEI/ISO16372 standard, or the Standard and Poor’s, Dun and Bradstreet, etc. identifiers, and be assigned by the clearing house.

Root location of the application

A single classic tag should also be deployed in the top-level directory of the application directory in case it is located on removable media.

This has to be determined by research on the product. This is usually some logical location that is defined as a global environment variable in the installation machine.