CHAPTER 4: INTRODUCTION TO THE SWID TAG

It is important to understand that classic tagging only indicates the raw functional model deployment in general. Therefore it may offer only part of the business rules of deployment in many cases since the overall licensing model, which may go beyond simple functionality, may not be detectable.

ISO/IEC 19770-2 software ID tag functionality

This part of ISO/IEC 19770 was developed in order to provide a software data standard for software/software component tagging. This is the process by which digital identification (SWID tag) is made to contain information about a given software configuration and the items or components it contains, so as to best facilitate deployed software identification and management.

Significant standardisation in SWID tag content makes software life cycle management practices more efficient, consistent and straightforward. Certifiable systematic software tagging practices also allow information technology professionals and others to place reliance on the adequacy of these practices and the consequences of standardised tagging benefits all parties involved in software life cycle management.

Operational breakdown

SWID tag business functions

SWID tag creation

• Create SWID tag to identify software and origin, with creators furnishing most mandatory SWID tag elements.
• Create optional SWID tag elements to facilitate identification and software life cycle management.
• Create SWID tag when none is provided by manufacturer, with modifiers or consumers furnishing SWID tag data in such an instance.

SWID tag modification

• Modify SWID tag information, particularly incomplete mandatory SWID tag elements.
• Provide additional SWID tag information, such as those identity elements pertaining to release management.
• Ensure consistent and uniform values in SWID tag data.

SWID tag consumption

• Implement SWID tag information for software life cycle management purposes.
• Rely on SWID tag information as being in compliance with ISO standards.

SWID tag business roles

SWID tag creators

The creators are software manufacturers, ISVs, software publishers and line-of-business application developers. The benefits from standardisation in software tagging practices for these parties include, but are not limited to, the following:

1. The end-installation immediately recognises who created the software being installed.
2. If the SWID tag creator resolves to allow a reseller, OEM customer or distributor to change the software identification information, the SWID tag creator can specify exactly what can and cannot be changed in the SWID tag and thus work to ensure consistency in software identification.
3. By making software easier to identify and potentially simple to correlate to software licences, the SWID tag creator benefits from SWID tag consumers’ increased awareness of licence compliance issues (consumers are more likely to purchase additional software items from software manufacturers, publishers and vendors should they find themselves out of compliance).
4. By defining SWID tags as early in the software life cycle as possible, projects for software under development become focused on the right tools and technology to meet the requirements specified for target languages and platforms.
5. Manufacturers, publishers and vendors thus make software that is easy to identify, install and use.

Example SWID tag creators include:

• Software manufacturers: a SWID tag is frequently created when the manufacturer builds software. Subsequently, the SWID tag and product are shipped together. Software may be dispatched directly to the consumer, a publisher or both. For this reason, arrangements have to be pre-planned as to who creates the SWID tag and who defines the software origins. It is possible that this process may have mixed ownership as it depends upon the channel used for software distribution.
• Independent software vendors: similar to the manufacturer in the tagging life cycle role, the independent software vendor building and publishing proprietary software must include, as part of the release process, the creation of a SWID tag to ship with media.
• Software publishers: when software is developed by another organisation and then shipped for publication, the publisher can create a SWID tag during the packing process to include in the media.
• Line-of-business application developers: in-house application developers can also create SWID tags to include in their media.
• Distributors, repackagers, value-added resellers: parties that distribute software that was received without standardised SWID tags may add them so as to accommodate the needs of their end-users.
• Release publishers: when a software package does not include a standardised SWID tag, end-users are encouraged to create and embed their own SWID tag so as to conform to ISO/IEC 19770-1 SAM processes.

Tag creation mechanisms

A SWID tag can be conceived and created at any time, and this process is not necessarily part of the engineering process for the software product to be tagged.

In their simplest form, tags may be created as a single object (a single instance of a software ID tag) per software component and the tag is then bundled with the distribution at distribution build time. The tag may then exist, unaltered, for its entire lifetime and remain forever static in content. Such practice, while useful, does not take full advantage of the abilities that the SWID tag enables by leveraging the attributes (elements) that a SWID tag contains.

Use of VTP enables a SWID tag to have some attributes injected at creation time, prior to the signing of the SWID tag that may eventually be used to track the life cycle of the deployed software that the SWID is installed with. Examples of these attributes are as follows:

• Serial_number – allows each instance of a generated SWID to be uniquely identified and thus indexed back to the transaction that created it. Such a transaction might include the generation of a licence for use of the software component being tagged. This value, in combination with the software_licensor_alias attribute might possibly be used at reconciliation time in order to help verify the exact details of the licence status of the deployment. Another kind of transaction may be the generation of an ESD distribution from an identifiable ESD delivery system that can be included in the data_source element, enabling reconciliation of a distribution with a distribution generation, and thus the publisher business transaction that enabled the distribution delivery.
• SKU – may be the stock-keeping unit (SKU) for the licence generated (either from the publisher’s ESD delivery system or perhaps the enterprise resource planning (ERP) system); again, in combination with the software_licensor_alias attribute it might possibly be used at reconciliation time in order to help verify the exact details of the licence status of the deployment.

The SWID tags are signed and certified in real time by a tool such as VTP. Appropriate integration of VTP into the software publisher/SWID tag creator’s infrastructure would be required to achieve this.

Figure 5: VeriTag Publisher application

SWID tag modifiers

Tags are modified by SAM and other software life cycle management tool providers, deployment tool providers, software resellers, value-added resellers, republishers, packagers and release publishers. The benefits from standardisation in software tagging practices for these parties include, but are not limited to, the following:

1. SWID tag modifiers are able to expect consistent and uniform values in SWID tag data.
2. Products released by SAM and other software life cycle management tool providers and deployment tool providers can more easily discover mandatory software tag information by virtue of the implementation of standardised location and formatting of SWID tag data.
3. Products released by SAM and other software life cycle management tool providers and deployment tool providers are able to utilise SWID tag data to reconcile an application from discovery information.
4. Products released by SAM and other software life cycle management tool providers and deployment tool providers are able to utilise SWID tag data to distinguish differences between licensed and unlicensed applications.
5. Products released by SAM and other software life cycle management tool providers and deployment tool providers are better able to determine from SWID tag data whether or not an application should be installed on a particular platform or computer system.
6. SAM and other software life cycle management tool providers and deployment tool providers are able to free more proprietary resources to enhance best practices and improve product lines by virtue of improvements made in software identification via tagging standardisation.
7. SWID tag information is used to assist in the automation of the packaging of an application for distribution.
8. Distributors, repackagers and resellers can more easily determine if a particular SWID tag needs modification by having quicker access to the requisite information.
9. Distributors, repackagers and resellers can ensure that SWID tag creators have properly tagged their software.

Examples of SWID tag modifiers include:

• distributors
• software resellers
• value-added resellers
• republishers
• packagers
• sam tool providers
• deployment tool providers
• release publishers.

SWID tag consumers

Tag consumers include SAM owners, IT support professionals and end-users of a given software configuration item. The benefits from standardisation in software tagging practices for these parties include, but are not limited to, the following:

1. Asset publishers, professionals and end-users are able to rely on software products as compliant with industry-standard identification mechanisms.
2. Standardised tagging can improve inventory identification, thereby enhancing the ability to provide details regarding a given software product’s origination, modification and dependencies upon other software products and operating system platforms.
3. Standardised tagging improves SAM and other software life cycle management and eases compliance auditing by shifting some of the work of reconciling software inventory to the publishers and by enhancing processes of reconciling software use entitlements and installation data.
4. Standardised tagging across multiple computing and operating system platforms brings order and consistency to identifying what is installed on a given computing device.

Figure 6: VeriTag Enterprise application