Secretariat: CANADA (SCC) - ISO/IEC JTC1/SC7 …jtc1-sc7.logti.etsmtl.ca/N3951-N4000/07N3972 ISO-IEC 19770-2 Public...ISO/IEC JTC1/SC7 Software and Systems Engineering Secretariat:

ISO/IEC JTC1/SC7 Software and Systems Engineering Secretariat: CANADA (SCC)

Address reply to: ISO/IEC JTC1/SC7 Secretariat École de technologie supérieure – Department of Software and IT Engineering

1100 Notre Dame Ouest, Montréal, Québec Canada H3C 1K3 [email protected]

www.jtc1-sc7.org

ISO/IEC JTC1/SC7 /N3972

2008-04-21

Document Type WD

Title WD3 19770-2 - Information technology - Software asset management - Part 2: Tagging

Source WG21

Project

Status Final

Reference Replace N3866 and N3935

Action ID FYI or ACT

Distribution AG

No. of Pages 77

Note Commenting template must be downloaded from http://www.agnitioadvisors.com/19770-2-WD3/19770-2-WD3.zip. Please sent comments to [email protected]

© ISO/IEC 2007, 2008 – All rights reserved

Document type: Working Draft Version 3 Document subtype: Document stage: (2) Preparatory Document language: E Filename: ISO-IEC 19770-2 Public Review Working Draft 3.doc

ISO/IEC JTC 1/SC 7 N 2 1

Date: 2008-03-14 2

ISO/IEC WD3 19770-2 3

ISO/IEC JTC 1/SC 7/WG 21 4

Secretariat: BSI 5

Information technology — Software asset management — Part 2: 6 Software Tag 7

Élément introductif — Élément central — Partie 2: Titre de la partie 8

9

Warning 10

This document is not an ISO International Standard. It is distributed for review and comment. It is subject to 11 change without notice and may not be referred to as an International Standard. 12

Recipients of this draft are invited to submit, with their comments, notification of any relevant patent rights of 13 which they are aware and to provide supporting documentation. 14

15

WORKING DRAFT 3 ISO/IEC WD3 19770-2

© ISO/IEC 2007, 2008 – All rights reserved 1

Copyright notice 1

This ISO document is a working draft or committee draft and is copyright-protected by ISO. While the 2 reproduction of working drafts or committee drafts in any form for use by participants in the ISO 3 standards development process is permitted without prior permission from ISO, neither this document 4 nor any extract from it may be reproduced, stored or transmitted in any form for any other purpose 5 without prior written permission from ISO. 6

Requests for permission to reproduce this document for the purpose of selling it should be addressed 7 as shown below or to ISO's member body in the country of the requester: 8

[Indicate the full address, telephone number, fax number, telex number and electronic mail address, 9 as appropriate, of the Copyright Manager of the ISO member body responsible for the secretariat of 10 the TC or SC within the framework of which the working document has been prepared.] 11

Reproduction for sales purposes may be subject to royalty payments or a licensing agreement. 12

Violators will be prosecuted 13

2 © ISO/IEC 2007, 2008 – All rights reserved

Contents Page 1

Foreword ......................................................................................................................................................... 5 2

Introduction ..................................................................................................................................................... 6 3

1 Scope .................................................................................................................................................. 8 4 1.1 Purpose ............................................................................................................................................... 8 5 1.2 Field of application ............................................................................................................................ 8 6 1.3 Limitations .......................................................................................................................................... 8 7

2 Conformance ...................................................................................................................................... 9 8 2.1 Product conformance ........................................................................................................................ 9 9 2.1.1 Product scope .................................................................................................................................... 9 10 2.1.2 Software product conformance ........................................................................................................ 9 11 2.1.3 Software installer product conformance .........................................................................................10 12 2.1.4 Tag tool conformance .......................................................................................................................11 13 2.1.5 Platform conformance ......................................................................................................................12 14 2.2 Organizational conformance ............................................................................................................12 15 2.2.1 Organizational scope ........................................................................................................................12 16 2.2.2 Software provider conformance ......................................................................................................12 17 2.2.3 Tag tool provider conformance........................................................................................................12 18 2.2.4 Software consumer conformance ....................................................................................................12 19 2.3 Agreement compliance .....................................................................................................................13 20

3 Terms and definitions .......................................................................................................................14 21

4 Alignment and rationalization with prior standards .......................................................................16 22 4.1 Statement of alignment for this part of ISO/IEC 19770 ...................................................................16 23 4.2 Alignment with ISO/IEC 19770-1:2006 specification .......................................................................16 24 4.3 Alignment with ISO/IEC 20000-1:2005 specifications .....................................................................16 25 4.4 Alignment with ISO/IEC 20000-2:2005 specifications .....................................................................17 26

5 Implementation of software tagging processes .............................................................................19 27 5.1 General guidelines ............................................................................................................................19 28 5.1.1 Consistency among data values ......................................................................................................19 29 5.1.2 Pre-manufactured media ..................................................................................................................19 30 5.1.3 Languages .........................................................................................................................................19 31 5.1.4 Software tag installation and location .............................................................................................20 32 5.1.5 Unique identifiers ..............................................................................................................................20 33 5.1.6 Unique software tag file name .........................................................................................................21 34 5.1.7 Authenticity of software tags ...........................................................................................................21 35 5.1.8 Standardized types for XSD definition ............................................................................................21 36 5.2 Software tagging life cycle: operational breakdown ......................................................................22 37 5.2.1 Software tag creators .......................................................................................................................22 38 5.2.2 Software tag modifiers include: .......................................................................................................23 39 5.2.3 Software tag end users .....................................................................................................................23 40 5.2.4 Software tag correction ....................................................................................................................23 41

6 Platform recommendations ..............................................................................................................25 42 6.1 Types of platforms ............................................................................................................................25 43 6.2 Basic platform services ....................................................................................................................25 44 6.3 Virtual environments ........................................................................................................................26 45 6.4 Virtual machines ...............................................................................................................................26 46 6.5 Support for software installed on removable media ......................................................................26 47

7 Identity elements ...............................................................................................................................27 48 7.1 General...............................................................................................................................................27 49 7.2 Identity element names.....................................................................................................................27 50 7.2.1 Mandatory elements .........................................................................................................................27 51


7.2.2 Optional elements ............................................................................................................................. 27 1 7.2.3 Extended identity elements .............................................................................................................. 28 2 7.3 Mandatory identity elements ............................................................................................................ 28 3 7.3.1 Entitlement required indicator ......................................................................................................... 28 4 7.3.2 Product title ....................................................................................................................................... 29 5 7.3.3 Product version ................................................................................................................................. 29 6 7.3.4 Software manufacturer identity ....................................................................................................... 30 7 7.3.5 Software unique identifier ................................................................................................................ 31 8 7.4 Optional identity elements ............................................................................................................... 31 9 7.4.1 Abstract ............................................................................................................................................. 31 10 7.4.2 Component association.................................................................................................................... 32 11 7.4.3 Components list ................................................................................................................................ 33 12 7.4.4 Data source ....................................................................................................................................... 34 13 7.4.5 Dependency ....................................................................................................................................... 34 14 7.4.6 License and channel information .................................................................................................... 35 15 7.4.7 Package footprint .............................................................................................................................. 37 16 7.4.8 Packager ............................................................................................................................................ 38 17 7.4.9 Product category ............................................................................................................................... 39 18 7.4.10 Product identifier .............................................................................................................................. 40 19 7.4.11 Release date ...................................................................................................................................... 41 20 7.4.12 Release id .......................................................................................................................................... 41 21 7.4.13 Release package ............................................................................................................................... 41 22 7.4.14 Release rollout .................................................................................................................................. 42 23 7.4.15 Release verification .......................................................................................................................... 43 24 7.4.16 Serial number .................................................................................................................................... 43 25 7.4.17 SKU .................................................................................................................................................... 44 26 7.4.18 Software manufacturer alias ............................................................................................................ 44 27 7.4.19 Supported languages ....................................................................................................................... 45 28 7.4.20 Upgrade for ........................................................................................................................................ 45 29 7.4.21 Usage ................................................................................................................................................. 46 30 7.4.22 Validation ........................................................................................................................................... 46 31 7.5 Extended identity elements .............................................................................................................. 47 32 7.5.1 Extended information ....................................................................................................................... 48 33 7.6 Data type definitions ......................................................................................................................... 48 34 7.6.1 GUIDtype ............................................................................................................................................ 48 35 7.6.2 Numeric version ................................................................................................................................ 48 36 7.6.3 FootprintModuleComplex type ........................................................................................................ 49 37

Annex A (informative) Software producer use cases and guidance .......................................................... 50 38 A.1 Software manufacturers and providers ........................................................................................... 50 39 A.1.1 Roles Involved in the software tag creation/management ............................................................. 50 40 A.1.2 Product manager role ....................................................................................................................... 51 41 A.1.3 Development manager/engineer ...................................................................................................... 53 42

Annex B (informative) Tool provider use cases ........................................................................................... 56 43 B.1 Discovery tool vendors .................................................................................................................... 56 44 B.1.1 Primary use cases ............................................................................................................................. 56 45 B.1.2 Secondary use cases ........................................................................................................................ 56 46 B.1.3 Distribution tool vendors .................................................................................................................. 57 47 B.1.4 Appending software tags for distribution: primary use cases ...................................................... 57 48 B.1.5 Appending software tags for distribution: secondary use cases ................................................. 57 49 B.1.6 Consuming software tag data for distribution: primary use cases ............................................... 57 50 B.1.7 Consuming software tag data for distribution: secondary use cases .......................................... 58 51

Annex C (Informative) Distributors, re-packagers and re-sellers use cases and guidance ..................... 59 52 C.1 Distribution, re-packaging and re-selling use cases ...................................................................... 59 53 C.2 Distributor software tag data creation and modification ............................................................... 59 54

Annex D (informative) Software tag data end users use cases and guidance .......................................... 60 55 D.1 Overview ............................................................................................................................................ 60 56 D.2 Software tag ...................................................................................................................................... 60 57 D.3 Definition of roles .............................................................................................................................. 61 58


D.4 Scenario: baseline inventory ..........................................................................................................61 1 D.4.1 Objectives ..........................................................................................................................................61 2 D.4.2 Functional roles involved .................................................................................................................62 3 D.4.3 Requirements ....................................................................................................................................62 4 D.4.4 Challenges .........................................................................................................................................63 5 D.5 Scenario: electronic software distribution .....................................................................................63 6 D.5.1 Objectives ..........................................................................................................................................63 7 D.5.2 Functional roles involved .................................................................................................................64 8 D.5.3 Requirements ...................................................................................................................................64 9 D.5.4 Challenges .........................................................................................................................................64 10 D.6 Scenario: migration planning ..........................................................................................................64 11 D.6.1 Objectives ..........................................................................................................................................64 12 D.6.2 Functional roles involved .................................................................................................................65 13 D.6.3 Requirements ....................................................................................................................................65 14 D.6.4 Challenges .........................................................................................................................................65 15 D.7 Scenario: patch management .........................................................................................................65 16 D.7.1 Objectives ..........................................................................................................................................65 17 D.7.2 Functional roles involved .................................................................................................................65 18 D.7.3 Requirements ....................................................................................................................................66 19 D.7.4 Challenges .........................................................................................................................................66 20 D.8 Scenario: creating a unique software tag ......................................................................................66 21 D.8.1 Objectives ..........................................................................................................................................66 22 D.8.2 Functional roles involved .................................................................................................................66 23 D.8.3 Requirements ....................................................................................................................................66 24 D.8.4 Challenges .........................................................................................................................................67 25

Annex E (normative) XML schema definition (XSD) ....................................................................................68 26

Annex F (informative) Extended examples ...................................................................................................73 27

Bibliography ...................................................................................................................................................75 28 29


Foreword 1

ISO (the International Organization for Standardization) and IEC (the International Electrotechnical 2 Commission) form the specialized system for worldwide standardization. National bodies that are members of 3 ISO or IEC participate in the development of International Standards through technical committees 4 established by the respective organization to deal with particular fields of technical activity. ISO and IEC 5 technical committees collaborate in fields of mutual interest. Other international organizations, governmental 6 and non-governmental, in liaison with ISO and IEC, also take part in the work. In the field of information 7 technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1. 8

International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2. 9

The main task of the joint technical committee is to prepare International Standards. Draft International 10 Standards adopted by the joint technical committee are circulated to national bodies for voting. Publication as 11 an International Standard requires approval by at least 75% of the national bodies casting a vote. 12

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent 13 rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights. 14

ISO/IEC 19770-2 was prepared by Joint Technical Committee ISO/IEC JTC 1, ISO/IEC JTC, Subcommittee 15 SC 7, Software and system engrneering. 16

ISO/IEC 19770 consists of the following parts, under the general title Information technology — Software 17 asset management: 18

⎯ Part 1: Processes 19

⎯ Part 2: Software Tag 20

21


Introduction 1

This part of ISO/IEC 19770 provides a software asset management (SAM) data standard for software tags. 2 Software tags provide authoritative identifying information for software configuration items (3.2). This 3 document is intended to be sufficiently supported and implemented by software manufacturers, modifiers and 4 owners alike to ensure the viability of conformance. 5

Standardization in software tag content makes SAM practice more efficient, consistent and straightforward. 6 Standardization will benefit all parties involved in the software tag life cycle (5.2): 7

a) Software tag creators. These include software manufacturers, publishers and line of business 8 application developers. Benefits of standardization in software tagging practices for software tag 9 creators include, but are not limited to, the following: 10

a. Improved product resulting from advanced identification, installation and usage capabilities. 11

b. Immediate end-installation recognition of details pertaining to software manufacture. 12

c. Ability to specify to software tag modifiers what can and cannot be changed in a software tag, 13 ensuring consistency in identification. 14

d. Increased awareness of software license compliance issues on the part of software tag end-15 users. 16

e. Enhanced focus on required tools and technology during software development. 17

b) Software tag modifiers. These include SAM tool providers, deployment tool providers, re-sellers, 18 value-added re-sellers, re-publishers, packagers and release managers. Benefits of standardization in 19 software tagging practices for software tag modifiers include, but are not limited to, the following: 20

a. Receipt of consistent and uniform data from software tag creators. 21

b. Enhanced power to ensure that software has been properly tagged and to determine need for 22 modification. 23

c. Improved tool discovery capabilities resulting from standardization in location and format of 24 software tag data. 25

d. Improved tool reconciliation capabilities resulting from standardization in location and format 26 of software tag data. 27

e. Improved tool capabilities to differentiate licensed from unlicensed software. 28

f. Improved tool capabilities to differentiate authorized corporate software installations from non-29 authorized installations. 30

g. The ability to include ITIL release information directly into deployment packages. 31

c) Software tag end users. These include SAM owners, SAM practitioners, IT support professionals and 32 end users of a given software configuration item. Benefits from standardization in software tagging 33 practices for software tag end users include, but are not limited to, the following: 34

a. Receipt of consistent and uniform data from software tag creators and modifiers. 35


b. Enhanced power to ensure that software has been properly tagged and to determine need for 1 modification. 2

c. Improved capabilities for identifying software origination, modification and dependencies with 3 other software packages. 4

d. Improved SAM and Software license compliance capabilities stemming from standardized, 5 manufacturer-supplied, easily reconcilable software tags and software entitlements. 6

e. Standardized software tag usage across multiple platforms, rendering heterogeneous 7 computing environments more consistent and manageable. 8

f. Improved reporting from additional categorization made possible by the use of software tags 9

g. Improved analysis of purchasing process through use of standardized categorization tags. 10

h. Improved and more efficient communications between desktop management, purchasing and 11 asset management roles through standardization of fields and data. 12

Relationship of Software Tags to Software Entitlements 13

This standard – ISO/IEC 19770-2 is focused on Software Tags – specifically the standard is providing 14 consistent and reliable information that conveys exactly which products are installed on computing device. 15 This standard will significantly help organizations that have Software Asset Management processes in place, 16 or that want to put SAM processes in place. However, this standard must also consider the issues involved 17 with a future standard that needs to be created to define how software entitlements are specified in a 18 standardized electronic form. Should a software entitlement standard be created, the goal is to ensure that 19 the software tag provides enough information for a SAM tool to automatically reconcile discovered software 20 tags against stored software entitlement information. 21

There are some components of the tag that have been designed expressly for the purpose of allowing a more 22 direct link between the Software Tag and an Electronic Software Entitlement. These components include: 23

• Entitlement required indicator (entitlement_required element) 24

• License and channel information (license_linkage element) 25

• Data source (data_source element) 26

• Product unique identifier (product_id element) 27

This information will be directly useful to a SAM practitioner prior to electronic software entitlements being 28 available; however the information will be invaluable to a SAM tool once an electronic software entitlements 29 standard is completed. The goal in the development of the Software Tag standard was to provide enough 30 identification information that down-stream processes that occur during Software Asset Management software 31 license reconciliation and compliance validation can be effectively implemented in as automated fashion as 32 possible. 33


Information technology — Software asset management — 1

Part 2: Software Tag 2

1 Scope 3

1.1 Purpose 4

This part of ISO/IEC 19770 establishes specifications for how software should be tagged to optimize5 identification and management. 6

1.2 Field of application 7

The applicability of this part of ISO/IEC 19770 is to: 8

• Platform provider: These are the organizations which provide tag management capabilities at the level 9 of the platform or operating system. 10

• Software providers: These are organizations which provide software for distribution or installation. These 11 include software manufacturers and all re-packagers of previously manufactured software. They may 12 also be in-house developers of software. 13

• Tag tool provider: These are organizations that may provide any number of tools that create, modify or 14 use software tags. These tools include development environments that provide automatically generated 15 software tags, installation tools that may create and/or modify tags on behalf of the installation process 16 as well as desktop management tools that may create tags for software that does not have a tag and/or 17 modify tags with release details throughout the software lifecycle. 18

• Software consumers: These are the organizations which install or consume software, and who are 19 intended as the ultimate beneficiaries of the improved information provided by the SAM tag as specified 20 in this part of ISO/IEC 19770. 21

1.3 Limitations 22

This part of ISO/IEC 19770 does not detail SAM processes required for reconciliation of software entitlements 23 with software tags. 24

This part of ISO/IEC 19770 does not consider identifying mechanisms for product activation or launch controls. 25

This part of ISO/IEC 19770 is not intended to conflict neither with any organization’s policies, procedures and 26 standards nor with any national laws and regulations. 27


2 Conformance 1

Conformance may apply to a product or an organization. For organizational conformance, the scope defined 2 must cover both the organizational scope as well as the products that are included in scope. 3

If a claim of conformance is made for a product or organization, the claim must include the scope for which 4 conformance was tested. 5

2.1 Product conformance 6

There are reasons for a company to seek individual product conformance against this part of ISO/IEC 19770. 7 This may be done in the case where a specific product is being provided for a market that requires 8 conformance (for example, if government organizations require products to conform to this part of ISO/IEC 9 19770 in order to be included on a project). It may also be desired by platform owners that want to provide a 10 more secure and auditable tag storage that can be used to definitively identify which software packages were 11 installed and by which user. 12

2.1.1 Product scope 13

There shall be a clear statement for product scope describing, in unambiguous terms, the software products to 14 which it applies, and where appropriate, clarifying the products to which it does not apply. The product 15 conformance scope may be defined in any way considered appropriate, such as for a specific software 16 product, for all software products, for all software products on specific platforms, for the software products of 17 specified manufacturers, and/or for all software products created after a specified date, as long as it is 18 unambiguous. In the case of a software tag-creating or modifying product, the scope shall be the product 19 itself and all software produced by the product when tag-conformity functionality is enabled. 20

2.1.2 Software product conformance 21

Full conformance for a software product is achieved in one of two ways: 22

For a product which is installable, full conformance is achieved by demonstrating that all software tags created 23 and/or installed by it at installation comply with all mandatory requirements of this standard, as specified in 24 clause 7.3. If optional or extended tag elements are used these must also comply with requirements as 25 specified in clauses 7.4 and 7.5. 26

NOTE1: Testing must be done against results after an installation of a product is completed. This ensures 27 that the tag that is found during a discovery process is the same tag that is generated by the installation 28 process. Testing may be done by using comparative snapshots of a computer system that allow all files and 29 configuration data that changes before and after an installation to be identified. Tags discovered in the "after" 30 snapshot are then verified for conformance to this specification. 31

NOTE2: This may be demonstrated on a 100% testing basis; or alternatively on the basis of procedures and 32 technology in established use, which are independently verified as able to ensure and sustain continued full 33 conformance, together with random sample testing of at least 5% of all software tags produced, with no 34 exceptions identified. As discussed within ISO/IEC 25051, documented test plans, results and procedures can 35 be shown to be effective for testing conformance. 36

NOTE3: If the software product consists of a package of other software products, then the software product 37 must retain any component tags and reference any child tag elements which under any circumstances still 38 need to be identified separately (for the purpose of licensing, security or other). 39

NOTE4: Existing tag values that are provided with distributable software must not be modified in any way, with 40 some specific exceptions. If a distributed software tag is found to be corrupted and that software tag does not 41 provide a "validation" routine to fix the tag, a software product may provide options for handling this type of 42 exception that a Software Asset Manager can authorize. Based on actions specified by the Software Asset 43 Manager, the handling of such exceptions may include actions such as fixing the software tag if it is corrupt, 44 deleting the software tag if it no longer belongs on the device, or modifying the software tag to specify that the 45


software is no longer installed on the device. Should any modifications of the tag be specified by the user, 1 these actions must be logged and retained by the software product. 2

For a product which is distributable, but not yet installed, full conformance is achieved by demonstrating that 3 all distributable builds are issued with a unique tag which complies with all mandatory requirements of this 4 standard, as specified in clause 7.3. If optional or extended tag elements are used these must also comply 5 with requirements as specified in clauses 7.4 and 7.5. 6

NOTE1: This may be demonstrated on a 100% testing basis; or alternatively on the basis of procedures and 7 technology in established use, which are independently verified as able to ensure and sustain continued full 8 conformance, together with random sample testing of at least 5% of all software tags produced, with no 9 exceptions identified. As discussed within ISO/IEC 25051, documented test plans, results and procedures can 10 be shown to be effective for testing conformance. 11

NOTE2: If the software product consists of a package of other software products, then the software product 12 must retain any component tags and reference any child tag elements which under any circumstances still 13 need to be identified separately (for the purpose of licensing, security or other). 14

NOTE3: Existing tag values that are provided with distributable software must not be modified in any way, with 15 some specific exceptions. If a distributed software tag is found to be corrupted and that software tag does not 16 provide a "validation" routine to fix the tag, a software product may provide options for handling this type of 17 exception that a Software Asset Manager can authorize. Based on actions specified by the Software Asset 18 Manager, the handling of such exceptions may include actions such as fixing the software tag if it is corrupt, 19 deleting the software tag if it no longer belongs on the device, or modifying the software tag to specify that the 20 software is no longer installed on the device. Should any modifications of the tag be specified by the user, 21 these actions must be logged and retained by the software product. 22

2.1.3 Software installer product conformance 23

Full conformance for a software installer product is achieved by demonstrating (a) software product 24 conformance for the product; and (b) that all software tags created and/or installed by it at installation comply 25 with all mandatory requirements of this standard, as specified in clause 7.3. If optional or extended tag 26 elements are used these must also comply with requirements as specified in clauses 7.4 and 7.5. 27

NOTE1: This may be demonstrated on the basis of procedures and technology in established use, which are 28 independently verified as able to ensure and sustain continued full conformance, together with comprehensive 29 testing against a test bed of distributable software representing all reasonable combinations of valid and 30 invalid conditions for the purposes of this part of ISO/IEC 19770, and random sample testing of installations of 31 distributable software from at least 100 different software providers, with no exceptions identified. As 32 discussed within ISO/IEC 25051, documented test plans, results and procedures can be shown to be effective 33 for testing conformance. 34

NOTE2: If the software being installed consists of a package of other software products, then the software 35 product must retain any component tags and reference any child tag elements which under any circumstances 36 still need to be identified separately (for the purpose of licensing, security or other). 37


NOTE4: It is expected that such products may have the capability to turn this functionality on or off. A 46 statement of product conformance shall apply only to the product with this functionality turned on. 47


2.1.4 Tag tool conformance 1

Full conformance for a tag tool is achieved in one of two ways: 2

Full conformance for a product which produces or modifies software tags independent of software installation 3 is achieved by demonstrating (a) software product conformance for the product; and (b) that all software tags 4 produced by the product comply with all mandatory requirements of this standard, as specified in clause 7.3. If 5 optional or extended tag elements are used these must also comply with requirements as specified in clauses 6 7.4 and 7.5. Any new data that is added must conform to the same standards as those required for installable 7 software conformance. 8





For tools that discover, collect, report on and and use tags (such as discovery tools, desktop management 29 tools or SAM reconciliation tools), full conformance is achieved by demonstrating the following: 30

• that all tags available on a computing device are collected. This includes tags that are stored in the 31 system location as well as tags that are located in the top level directories of software installations. 32

• that all tags collected on computing devices can be shown to contain exactly the same information as 33 the contents of the tag located on the computing device from which it was collected. 34

• If a tag is digitally signed and the corresponding public key is available, that the tool validates the 35 signature and the information that has been signed. 36






2.1.5 Platform conformance 11

Full conformance for a platform's tag functionality is achieved by demonstrating that it can store tag data 12 centrally, and provide the following services with integrity as specified in clause (6.2): 13

• Basic functionality: Add, modify, read, and delete tag data 14

• Audit functionality: Identify who installed and who modified a given software configuration items and 15 when modification occurred 16

• Security: Determine who can read, create, delete and modify software tags. 17

2.2 Organizational conformance 18

Organizations may want to conform to this standard for multiple reasons. First, software providers want to 19 promote their software products as being easier to manage. Second, software consumers want to show that 20 they are actively managing their software assets and desire to provide accurate information to any 21 reconciliation or audit request. 22

2.2.1 Organizational scope 23

There shall be a clear statement for the organizational scope describing, in unambiguous terms, the 24 organizational structure to which it applies, and where appropriate, clarifying the areas to which it does not apply. 25 A statement of organizational scope must be accompanied by a statement of software product scope. 26

2.2.2 Software provider conformance 27

Full conformance for a software provider is achieved by the organization demonstrating that all software in 28 scope meets the relevant product conformance requirements. 29

2.2.3 Tag tool provider conformance 30

Full conformance for a tag tool provider is achieved by an organization demonstrating that all software in 31 scope meets the relevant product conformance requirements. 32

NOTE1: In order to claim tag tool provider conformance, all tag tools produced by the organization must be 33 included in the product scope. 34

2.2.4 Software consumer conformance 35

Full conformance for an organization which installs software is achieved by demonstrating that there are 36 software tags in place for all software in the consumer organization's product scope, and that the software 37 tags comply with all mandatory requirements of this standard, as specified in clause 7.3. If optional or 38 extended tag elements are used, these must also comply with requirements in clauses 7.4 and 7.5. 39


2.3 Agreement compliance 1

This part of ISO/IEC 19770 may be used to help develop an agreement between a software manufacturer and 2 a customer, in which case clauses of this part of ISO/IEC 19770 can be selected for incorporation into the 3 agreement, with or without modification. In such an instance, it is necessary for both parties to comply with 4 their agreement rather than conform to this part of ISO/IEC 19770. 5

NOTE: ISO/IEC's copyright and patent policy extends to all of this part of ISO/IEC 19770 and contents thereof. 6 However, for the specific use of agreement compliance, there is no need to obtain copyright permission. 7


3 Terms and definitions 1

For the purposes of this document, the following terms and definitions apply. 2

3.1 3 configuration management database (CMDB) 4 database containing all the relevant details of each configuration item and details of the important 5 relationships between them 6

3.2 7 configuration item (CI) 8 item or aggregation of hardware or software or both that is designed to be managed as a single entity 9 10 NOTE 1: Configuration items may vary widely in complexity, size and type, ranging from an entire system including all 11 hardware, software and documentation, to a single module or a minor hardware component. 12 13 NOTE 2: This document refers primarily to software configuration items. 14 15 3.3 16 extensible markup language (XML) 17 license-free and platform independent markup language that carried rules for generating text formats that 18 contain structured data 19

3.4 20 globally unique identifier (GUID) 21 pseudo-random, 16-byte string of characters that is generated in a manner that gives a very high probability 22 that the string is unique in any context. Other globally unique identifier algorithms may be used in some 23 situations. In general, alternative algorithms use URI based structures, so the id owner's domain is included in 24 the identifier. 25

NOTE 1: in this document, GUID as an all capitalized term refers specifically to the 16 byte. If the term is in 26 lowercase (guid), it refers to a general algorithm that could use a URI, or 16 byte based identifier. 27

3.5 28 identity element 29 component of a software tag describing a common attribute of most or all software configuration items 30

3.6 31 line of business application developer 32 person or company specializing in developing applications providing specific functions that are important to 33 the success of a particular business function 34

3.7 35 platform 36 computer or hardware device and/or associated operating system 37

3.8 38 release 39 collection of new and/or changed configuration items which are tested and introduced into a production 40 environment together 41

3.9 42 release manager 43 individual responsible for implementing release management processes, primarily those relating to software 44 development, packaging and distribution 45

3.10 46 software asset management (SAM) 47 effective use, control and protection of software assets within an organization 48


3.11 1 SAM owner 2 individual at a senior organization-wide level who is identified as being responsible for SAM 3

3.12 4 SAM practitioner 5 Individual involved in the practice or role of working with software assets. Typically, a SAM practitioner is 6 involved in the collection or reconciliation of software inventory and/or software entitlements 7

3.13 8 software entitlement 9 The legal ownership of software license use rights as defined. 10

Note 1: Effective use rights take into account any contracts and all applicable licenses, including full licenses, 11 upgrade licenses and maintenance agreements. 12 13 3.14 14 software license 15 terms and conditions for using a software product. 16 17 Note 1: "using a software product" may include: accessing, copying, distributing, installing and executing the 18 software product. 19 20 3.15 21 software manufacturer 22 person, group or company that develops software 23

3.16 24 software provider 25 any organization or person that is creating software for use on computing devices. This may include software 26 manufacturers or line of business application developers 27

3.17 28 software publisher 29 person, group or company that packages and distributes software. The publisher may or may not be a 30 software manufacturer as well 31

3.18 32 software tag 33 file comprised of identity elements containing authoritative identification information about a software 34 configuration item 35

3.19 36 Uniform Resource Identifier (URI) 37 a compact sequence of characters that identifies an abstract or physical resource. The syntax used for URI's 38 is defined in the IETF RFC 3986 39

3.20 40 value-added re-seller (VAR) 41 company licensed to re-package and support existing products as combined software packages 42

3.21 43 version 44 a unique string of number and letter values indicating a unique revision of an item. Versions are often referred 45 to in software to identify revsions of software that unique functionality or fixes. A Version typically has multiple 46 parts with at least a major version indicating large changes in functionality or user interface changes and a 47 minor version indicating smaller changes in functionality or user interface changes. 48


4 Alignment and rationalization with prior standards 1

4.1 Statement of alignment for this part of ISO/IEC 19770 2

The contents of this part of ISO/IEC 19770 are intended to complement and align with prior ISO/IEC standard 3 publications. 4

4.2 Alignment with ISO/IEC 19770-1:2006 specification 5

The following areas of ISO/IEC 19770-1:2006 are supported by this standard. 6

a) ISO/IEC 19770-1:2006, clause 3 stipulates terms and definitions relevant to that document. 7 8 This part of ISO/IEC 19770 aligns with ISO/IEC 19770-1:2006, clause 3 and terms and definitions 9 relevant to both parts have been reproduced here. 10

b) ISO/IEC 19770-1:2006, clause 4.4.2.2 stipulates: "Implementation of the software asset 11 identification process will enable the organization to demonstrate that a) types of assets to be 12 controlled and the information associated with them are formally defined... b) a register of stores 13 and inventories exists, clarifying which stores and types of information are held, with duplication 14 allowed only if duplicate information can be traced back to the definitive source record." 15 16 This part of ISO/IEC 19770 affirms the necessity of formal definitions, stores and inventories for software 17 configuration items. According to ISO/IEC 19770-1:2006, clause 4.4.2.2.a.2.i, software configuration 18 items include "all platforms on which software can be installed or run." To align with this inclusion of 19 platforms in the definition of software configuration item, this part of ISO/IEC 19770 proposes that an 20 optional identity element "Platforms" may be defined in software tag creation (7.4.9). 21

c) ISO/IEC 19770-1:2006, clause 4.4.2.2 stipulates: "Basic information required for all assets is i) Unique 22 identifier ii) Name/description iii) Location iv) Custodianship (owner) v) Status (e.g., test/production 23 status; development or build status) vi) Type (e.g., software, hardware, facility), vii) Version (where 24 applicable)." 25 26 This part of ISO/IEC 19770 affirms these requirements for basic information. The location and 27 custodianship of a software configuration item, however, are not included as values specified in 28 this document as these are associated with the asset on which the software configuration item is 29 discovered and not with the item itself. 30 31 The status of a software configuration item is defined by the Release values in the software tag. 32 These values are optional and it is recommended that they are furnished alongside information 33 pertaining to the signoff date and the operator who performed the process (7.4.10-14). 34

d) ISO/IEC 19770-1:2006, clause 4.4.3.2.f stipulates: "Each inventory report produced has a clear 35 description including its identity, purpose and details of the data source." 36 37 This part of ISO/IEC 19770 upholds the need for clear description in the reporting process and 38 acknowledges that an identity element is required to identify the software data source for a 39 software configuration item. This document specifies the "Software data source" identity element to 40 allow for a free-form text-value for the purposes of reporting and grouping (7.4.17). 41

4.3 Alignment with ISO/IEC 20000-1:2005 specifications 42

a) ISO/IEC 20000-1:2005, clause 9.1 stipulates: "Changes to configuration items shall be 43 traceable and auditable where appropriate, e.g. for changes and movements of software and 44 hardware."This part of ISO/IEC 19770 affirms the usage of software tags for disclosure and 45 definition of traceable and auditable information for software configuration items. 46

b) ISO/IEC 20000-1:2005, clause 9.1 stipulates: "Configuration control procedures shall ensure that 47 the integrity of systems, services and service components are maintained." 48 49


This part of ISO/IEC 19770 upholds the necessity of configuration control procedures for integrity 1 assurance purposes and therefore proposes the identity element "Signatures" to provide software 2 manufacturers the option to include a digital fingerprint (7.4.16). The digital fingerprint can be 3 used to validate that specified mandatory identity element values have not been modified, this 4 validation in turn allowing software manufacturers to authoritatively identify software tampering, or lack 5 thereof. 6 7

c) ISO/IEC 20000-1:2005, clause 9.1 stipulates: "Master copies of digital configuration items shall be 8 controlled in secure physical or electronic libraries and references to the configuration records, e.g. 9 software, testing products, support documents." 10 11 This part of ISO/IEC 19770 that recommends software tags be included with respective software 12 configuration items in the definitive software library. 13

d) ISO/IEC 20000-1:2005, clause 9.1 stipulates: "All configuration items shall be uniquely identifiable 14 and recorded in a CMDB to which update access shall be strictly controlled." 15 16 This part of ISO/IEC 19770 aligns with the specification that all software configuration items be 17 uniquely identifiable. A software configuration item is uniquely identifiable by stock keeping unit or 18 manufacturer part number, either of which can be related back to proof of license, purchase order 19 and software configuration items stored in the CMDB (7.3.3). 20 21 The method by which a software tag is stored in the CMDB and referenced uniquely therein is not 22 within the scope of this part of ISO/IEC 19770 (1.2). 23

e) ISO/IEC 20000-1:2005, clause 10.1 stipulates: "Release and distribution shall be designed and 24 implemented so that the integrity of hardware and software is maintained during installation, 25 handling, packaging and delivery." 26 27 This part of ISO/IEC 19770 affirms the necessity of integrity within the release process and 28 therefore specifies that software tags fully conform to release processes detailed in ISO/IEC 29 20000-1:2005. This part of ISO/IEC 19770 recommends that optional identity elements pertaining 30 to release details be included with software tags (7.4.10-14). 31

4.4 Alignment with ISO/IEC 20000-2:2005 specifications 32

a) ISO/IEC 20000-2:2005, clause 10.1.5 stipulates: "Release and distribution should be designed and 33 implemented to: a) conform with the service provider's systems architecture, service management 34 and infrastructure standards; b) ensure the integrity is maintained during build, installation, handling, 35 packaging and delivery..." 36 37 This part of ISO/IEC 19770 affirms the importance of release and distribution conformance through 38 the creation of the optional identity element "Release package" (7.4.12). 39

b) ISO/IEC 20000-2:2005, clause 10.1.6 stipulates: "The verification and acceptance processes 40 should: a) verify that the controlled acceptance test environment matches the requirements of the 41 target production environment; b) ensure that the release is created from versions under 42 configuration management and installed in the acceptance test environment using the planned 43 production process..." 44 45 This part of ISO/IEC 19770 affirms the importance of matching the controlled acceptance test 46 environment to the requirements of the target production environment through the creation of the 47 optional identity element "Release verification" (7.4.14). 48

c) ISO/IEC 20000-2:2005, clause 10.1.7 stipulates: "It is important that the release is delivered 49 safely to its destination in its expected state." 50

This part of ISO/IEC 19770 upholds the need for efficient and secure release delivery by proposing 51 the creation of the optional identity element "Release rollout" that allows an organization to validate 52


who signed-off on a software package as ready for production use and when said sign-off occurred 1 (7.4.13). 2


5 Implementation of software tagging processes 1

5.1 General guidelines 2

5.1.1 Consistency among data values 3

One large issue with software asset management is the fact that details provided by software manufacturers 4 are constantly changing. Since the software tag will not typically be seen by the end-user, this tag can provide 5 a consistent and reliable source of information to enable effective inventory and software entitlement 6 reconciliation. Keeping values consistent from one version to another, or across product lines is a large part 7 of the value software tags provide the end-user. 8

Numerous elements in the software tag must remain consistent from tag to tag to optimize the overall 9 Software Asset Management process. It is recommended, for example, that software manufacturers maintain 10 consistency in the following identity element: 11

• Software manufacturer Identity (7.3.4) – this element must remain consistent across all 12 software packages created by the manufacturer. 13

• License and channel information (7.4.6) - information in this optional element structure 14 should be kept consistent across various product lines and it is recommended that the 15 values are consistent across all software created by a specific manufacturer. Note that data 16 in the License and channel information elements of a software tag do not specify software 17 license or software entitlement information – instead, data in these elements provides 18 guidance to a SAM practitioner that will help them determine and perhaps automate software 19 license reconciliation procedures. 20

• Product category (7.4.9) – this optional element should remain consistent for a particular 21 product unless the product adds or removes functionality to make it obvious that it belongs in 22 a different category. 23

• Product identifier (7.4.10) – this optional element should remain consistent especially for 24 products that have maintenance agreements that provide for upgrade rights over a period of 25 time. This element is used to identify a specific product from release to release – it does not 26 have a product name, simply an identifier so the relationship for upgrade purposes can be 27 done automatically. 28 29

5.1.2 Pre-manufactured media 30

Software is generally created as a gold master copy by software publishers, then copied and distributed 31 through multiple different channels. Depending on the software publisher's requirements, the software tag 32 may be incorporated directly into the gold master, or it may be created by the installer, or even the software 33 package itself. The primary requirement is that the software tag for the package can be discovered on the 34 machine the package was installed on. For more details, refer to the annex detailing guidance for software 35 publishers (Annex A.). 36

5.1.3 Languages 37

Acknowledging that many software manufacturers produce software with specific builds that are dependent on 38 language while many others produce software with one build that implements add-on "language packs," this 39 document does not require software tags to recognize different language versions of the same product. 40 Consistent categorization of the type of language solution employed is, however, strongly encouraged (7.4.19). 41


5.1.4 Software tag installation and location 1

The functionality to embed software tags should be built into software installers to allow software tag 2 installation concurrent with associated software configuration items. 3

Operating system vendors may specify where software tags are located (6.2). 4

In the absence of Operating System vendor guidance, software manufacturers should install the software tags 5 in commonly known shared folders that are used for collecting commonly used system information. The 6 following examples provide information on where shared folders may be found on various platforms. 7

8

Apple Macintosh OS:X root/Library/Application Data/ISOIEC-19770/<company>

Unix and Linux usr/share/ISOIEC-19770/<company>

Windows “%AllUserProfile%\Application Data\ISOIEC-19770\<company>”

9

In addition a copy of the software tag should also be installed in the top level directory of the application itself. 10 This allows the software tag to be discovered even if a removable storage device (such as a USB hard disk) is 11 moved from one system to another (6.5). Should the same application be installed in two different locations 12 for the same set of users, the expectation is that there would still be a single instance of the software tag in 13 the system location specified above as well as two (or more) other tags that are located in the root directories 14 of the installation directory. In this case, a software manufacturer will need to be aware of the two installation 15 at uninstall time in order to ensure that a software tag is not removed from the system directory until all 16 installations are unintstalled. 17

Note to SAM tool providers – there will be cases where a software tag can be found in the common system 18 location as well as in one or more top level directory of an application. Rules need to be included in the SAM 19 tools to identify this situation. In cases where the tag is found in the application directory, and not in the 20 system directory, additional rules are required to identify if software is located on removable storage media 21 that may have been moved to another system. Finally, if a tag is found in the system location as well as 22 multiple tags found in installation directories, rules need to be applied as appropriate for the corporate policies. 23 Appropriate reporting and action can then be taken by the SAM practitioner. 24

The goal of a SAM tool is to make it as easy as possible for a SAM practitioner to manage exceptions to 25 corporate policy, so recognizing some of these issues and reporting on them based on the policies specified 26 by the practitioner make overall SAM implementations significantly easier to manage. 27

5.1.5 Unique identifiers 28

For purposes of uniqueness, software tag creators must create a globally unique identifier for tags such as 29 software_manufacturer -> guid and software_id->unique_id. These values are created by the software 30 manufacturer and should be created in such a way that they can be considered unique in any context. 31 Typically, this means that the ID should be created as a 16 byte GUID, or as a URI based unique identifier. 32

The benefits of implementing a unique identifier during software tag creation include, but are not limited to, the 33 following: 34

a) Identification of parent-child relationships. 35

b) Explicit definition of dependencies and recognition of dependent software. 36

c) Identification of upgrade software and allowed upgrade packages. 37

d) Reference to identifying software tags from within software configuration items. 38


5.1.6 Unique software tag file name 1

The name of a software tag must be unique and align with the following structure: <product_title>- 2 <unique_id>.swtag. The components of the tag filename are identity elements required of all software tags 3 (7.3.2 and 7.3.5). The .swtag file extension will be used for all software tags. This naming scheme allows for 4 multiple software tags to be applied to the same product, thereby providing support for upgrades and audit 5 capabilities. 6

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

5.1.7 Authenticity of software tags 10

Often, there will be a desire, or need to provide an ability to prove the authenticity of a software tag. For 11 example, during an audit, a software vendor may want to validate that the software tag collected during a 12 discovery process has not had key elements of the tag altered in any fashion. This authenticity is provided by 13 supporting digital signatures within the software tag. 14

There is an existing recommendation published by the W3C that addresses the need to provide digital 15 signatures in an XML document. The recommendation is "XML-Signature Syntax and Processing" and it can 16 be found at the following location: 17

http://www.w3.org/TR/xmldsig-core/ 18

The W3C recommendation provides integrity message authentication as well as signer authentication services 19 for data of any type. 20

This standard will not define the process for applying digital signatures to a software tag since the W3C 21 recommendation already does that. The XSD provided for ISO/IEC 19770-2 does include the schema 22 references necessary to incorporate digital signatures into a software tag. 23

Signatures are not a mandatory part of the tag, and can be used as required by any tag modifier to ensure 24 that sections of a tag are not modified and/or to provide authentication of the signer. 25

5.1.8 Standardized types for XSD definition 26

There are a number of standardized types used in the software tag including specific date/time entries that 27 must follow a specified format. The standard types are defined in the W3C recommendation titled, "XML 28 Schema Part 2: Datatypes Second Edition". Details for these data types can be found at the following 29 location: 30

http://www.w3.org/TR/xmlschema-2/ 31

By using specific types as specified by the above W3C recommendation, software tags can go through an 32 automated validation step that allows a much more consistent structure to the data provided. 33


5.2 Software tagging life cycle: operational breakdown 1

The following diagram shows the software tag lifecycle as it progresses from a software producer to an end-2 user organization. 3

4

Figure 1 — Software Tag Lifecycle 5

5.2.1 Software tag creators 6

Software tag creators are usually software manufacturers. As software is built, the software manufacturer 7 creates a corresponding software tag to identify it and indicate its origin. 8

Example software tag creators include: 9

a) Software manufacturers. A software tag is frequently created when a software manufacturer develops 10 a particular software configuration item. Subsequently, the software tag and software installation 11 routine are shipped together. Software may be dispatched directly to consumers, publishers or both. 12 Arrangements have to be pre-planned as to who creates the software tag and who defines the 13 software configuration item's origins. It is possible that this process may have mixed ownership as it 14 depends on the channel used for software distribution. Software manufacturers will regularly use 15 digital signatures within software. 16

b) Software publishers. When software is developed by another organization and then shipped for 17 publication, during the packaging process the software publisher will create a software tag to include 18 as part of the product installation process. 19

c) Line of business application developers. In-house application developers will also create software tags 20 to include as part of the product installation process. 21


d) Distributors, re-packagers, value-added re-sellers and other tag modifying organizations. 1 Organizations that distribute software that does not include standardized software tags may want to 2 add them in order to accommodate the needs of their end users. (When a software package does not 3 include a software tag, software tag end users are encouraged to create and include their own 4 software tag to optimize SAM processes.). 5

5.2.2 Software tag modifiers include: 6

Individuals or companies that alter software tags and/or add supplemental information to software tags are 7 considered tag modifiers. This group may include software aggregators, VAR's and may also include groups 8 within a company that manage software release processes. 9 10 Example software tag modifiers may include: 11

a) Distributors 12

b) Re-sellers 13

c) Value-added re-sellers 14

d) Re-publishers 15

e) Packagers 16

f) Discovery tool providers 17

g) Deployment tool providers 18

h) Release managers 19

5.2.3 Software tag end users 20

Although end users are the ultimate beneficiaries of standardized software tag content, discovery tools and 21 operating systems are its primary consumers. They read software tag data to gather inventory about a given 22 system of software configuration items. When a software configuration item is deposited onto a particular 23 device, a well-formed software tag provides authoritative identification of the specific software installed, the 24 software manufacturer, all third-party providers who may have modified the software and the organization that 25 is using it. This information is invaluable to the end users of consumed software tag data. 26

Example software tag end users include: 27

a) SAM owners 28

b) IT support professionals 29

c) End users of the software configuration item 30

5.2.4 Software tag correction 31

Although software tags should be managed along with all other components associated with a specific 32 software application, there will be times when a tag may be removed, deleted or corrupted – either on purpose 33 or accidentally. 34

In the case where a product installation does not include a software tag, Desktop Administrators may choose 35 to create a software tag to provide with the software to ease the SAM reconciliation process. 36

In the case where a software tag becomes corrupt, there are optional methods available for the software 37 application to automatically self-heal the software tag and/or to validate that the software tag is up-to-date and 38 correct. These methods help to ensure a higher level of integrity of the data collected by discovery tools. 39


In all cases, there must be methods available for a discovery agent or service to cross check information in a 1 manner that provides a higher degree of accuracy of the data. For example, a discovery agent may collect 2 software tags and all executable filenames from a system. Software tags have the ability to specify all the 3 files that are associated with a particular piece of software. Using an appropriate algorithm, a reconciliation 4 service can quickly validate that a system with a specific software tag also includes the necessary files that 5 are associated with that title. The reconciliation engine can then filter out the known application filenames 6 from the collected list of executable filenames. Any filenames that remain in the list at the end of this process 7 would be considered exceptions and may require that a SAM practitioner investigate these files further. 8


6 Platform recommendations 1

6.1 Types of platforms 2

For the purposes of this document, the term platform refers to a computer or hardware device and/or its 3 associated operating system (3.9). The Linux operating system, for example, is used on a wide variety of 4 hardware, from cell phone devices to mainframe computers, and each variation can be considered a 5 separate platform for the purposes of this document. Additional example platforms include, but are not 6 limited to: 7

a) Redhat Linux Enterprise 4.0 Intel x86 8 b) Novell SuSE Linux 10.2 Intel x64 9 c) Mac OS 10.4 Intel x64 10 d) Microsoft Windows Vista x64 11 e) HP-UX 11i Itanium 12

A platform can also be exemplified by a virtual environment (i.e., such as Java or .NET) and, in such cases, 13 hardware support is generally unimportant. Versioning, however, is of great consequence in virtual 14 environments. Software written and compiled for one version of Java or .Net, for example, may not run in a 15 prior version's environment. 16

NOTE: Do not confuse the terms virtual environment and virtual machine. The latter may run within a host 17 operating system platform but still represents a complete operating system environment onto itself. The 18 virtual machine, supplied with virtual hardware, should therefore be treated as a separate hardware 19 instance comparable to that of a separate physical machine. 20

6.2 Basic platform services 21

Platforms exist independently of the software tag details of software configuration items they contain and 22 should be indifferent to them. A platform, however, should define processes to store and retrieve these 23 software tags efficiently. 24

It is recommended that platforms store and retrieve software tags in a process similar to how operating 25 systems manipulate files, the exception being that software tags should be stored in a central location for 26 efficiency in inventory processing. Software tags should be installed in a common area for each operating 27 system for ease of discovery. If a centralized store is unavailable for software tags, they will then be stored in 28 a location related to the software configuration items they define. 29

Each vendor of an operating system may specify where software tags are located. Windows installations, for 30 instance, may have a Windows Management Instrumentation value specifying location; Linux distributions 31 may use a Red Hat Package Manager value. Software tag files must include the ".swtag" file extension in their 32 names for the recognition purposes of operating systems and discovery tools (5.1.5). 33

A platform supporting this part of ISO/IEC 19770 will also provide the following services: 34

a) Basic add, modify, read and delete operations. 35

b) Audit capabilities 36

1. Identify who installed a given software configuration item and when installation occurred. 37

2. Identify who modified a given software configuration item and when modification occurred. 38

NOTE: In order to fully enable audit capabilities and related issues of software license compliance 39 and reconciliation of software entitlements with software tags, the latter should not be uninstalled even 40 when the software configuration items they define are removed from a platform. 41

c) Security 42


1. Determine who can create and modify software tags. 1

2. Determine who can read software tags. 2

6.3 Virtual environments 3

Virtual environments are typically installed on a computing device and will provide their own software tags to 4 identify themselves to discovery tools. 5

EXAMPLE: When a Java Virtual Machine (JVM) is installed on a computing device, it should be installed with 6 a software tag just as any other software package should. 7

The globally unique identifier for a virtual environment's software tag can then be utilized by other packages to 8 identify a software configuration item's compatibility with the virtual environment. 9

EXAMPLE: Once the JVM is installed, the Unique ID from that package can be referenced by Java-based 10 applications that utilize the JVM. This will be done by the Java-based application specifying that the JVM is a 11 dependency. 12

6.4 Virtual machines 13

Virtual machines provide a guest operating environment that is independent of the host operating environment. 14 As far as software is concerned, the installation, and discovery process will be exactly the same, with the 15 exception that the discovery process will occur completely within the Virtual Machine. In these environments, 16 the software tag will be provided just as it would be for any other computer. 17

It is expected that discovery tools will collect information about the system the tag is discovered on as part of 18 the discovery process. If the system is a virtual machine, the details about the virtual machine, its host 19 environment, etc should be collected as well. The SAM reconciliation process then will use the details of the 20 software tags that are collected, in addition to details about the environment the tag is installed on (virtual 21 machine type, host for the virtual machines, etc.) and use these pieces of information to aid in reconciliation. 22

It is expected that the software entitlement standard will include provisions to specify the reconciliation 23 process that should be used for tags discovered on virtual machines. 24

6.5 Support for software installed on removable media 25

Software can often be installed on removable media. In these cases, the software tag needs to identify that 26 the software was installed on a specific computing device as well as provide tag information that will follow the 27 removable media. This will be done by providing a software tag in the common operating system location 28 (either the OS defined tag store, or tags located in common directories) for the computing device. A second 29 copy of the software tag will be included in the top level directory that is used to install the software. 30

Tool providers will need to recognize that two tags may be discovered on the same computing device and be 31 able to recognize that the computing device only has one installation of a software package. In the instance 32 where the removable media is discovered on another computing device, the software entitlement rules for that 33 particular package will specify if the package should be considered a single entity (the installation on the 34 removable media), or two entities (the system the software was installed on as well as the actual software on 35 the removable media). 36

37


7 Identity elements 1

7.1 General 2

Identity elements describe common attributes of most or all software configuration items. Operating systems 3 and discovery tools can use these attributes to identify software configuration items. 4

Identity elements may be altered by an assortment of software tag modifiers and end users (5.2.2, 5.2.3). 5

Identity elements proposed in this part of ISO/IEC 19770 are not exhaustive; this document enumerates 28 6 distinct identity elements. They are predefined to ensure consistency between software tags (7.2). 7

Identity elements are described with examples in clauses 7.3 and 7.4, respectively. The examples are 8 specified in XML syntax, the format which must be used for software tag creation. The examples provide 9 insight as to what information is to be included within data fields corresponding to defined identity element. 10

This part of ISO/IEC 19770 does not require a specific process for generating field content for identity 11 elements. 12

7.2 Identity element names 13

Software tag content must be identified in accordance with the identity element names specified in clauses 7.3 14 and 7.4 below. This naming requirement ensures consistent interpretation of software tag content, regardless 15 of mandatory or optional nature. 16

If an identity element is optional, its description still must adhere to this naming requirement and to limitations 17 implied in the specified definitions of clause 7.4. 18

The following are the elements specified for the Software tag: 19

7.2.1 Mandatory elements 20

• Entitlement required indicator 21

• Product title 22

• Product version 23

• Software manufacturer identity 24

• Software unique identifier 25

7.2.2 Optional elements 26

• Abstract 27

• Component association 28

• Components list 29

• Data source 30

• Dependency 31

• License and channel information 32

• Package 33


• Packager 1

• Product category 2

• Product identifier 3

• Release id 4

• Release package 5

• Release rollout 6

• Release verification 7

• Serial number 8

• SKU 9

• Software manufacturer alias 10

• Supported languages 11

• Upgrade for 12

• Usage 13

• Validation 14

7.2.3 Extended identity elements 15

• Extended information 16

7.3 Mandatory identity elements 17

Mandatory identity elements are required for a software tag to be considered valid or complete. Incomplete 18 software tags should be flagged by discovery tools as invalid, notifying the software tag data end user that 19 these are not in use. There are five mandatory identity elements: 20

It is recommended that software manufactures maintain a central repository of all software tags created for all 21 product releases containing at least the mandatory elements. This repository can then be used to validate the 22 uniqueness of GUID’s as well as ensuring that the manufacturer name and GUID remain consistent 23 throughout the product line. This standard does not require an external registration agency for software tags, 24 so it is up to each software manufacturer to ensure each of their tags is unique. 25

7.3.1 Entitlement required indicator 26

XML Tag entitlement_required

Type Boolean

Definition This element is a Boolean tag that indicates if a software entitlement must match up against this item in order for a software reconciliation to be considered successful. Open Source software, for example, may not “require” a software entitlement in the reconciliation process to be legally installed and used. This does not mean that the software does not have a software entitlement; simply that it does not need a software entitlement specified in a SAM system for the reconciliation to be complete. This provides the ability for a practitioner to manage by exception and focus only on those items that are legally required to be in compliance. This does not mean that a company won’t manage compliance of items such as open source, or freeware products,


simply that they can make that choice.

This element must occur exactly once in the software tag.

Example <entitlement_required>true</entitlement_required>

1

7.3.2 Product title 2

XML Tag product_title

Type XML character sting

Definition Name of product, as assigned by software manufacturer. This value is primarily used in user focused reports and is not typically going to be used as part of the process of reconciliation.


Example <product_title>Viewmaster Standard</product_title>

3

7.3.3 Product version 4

XML Tag product_version

Type Complex type

Definition Version of the product defined as two elements – numeric version and version name.

This element allows software publishers to provide purely numeric version information which is used for comparison purposes against software entitlement information and for grouping purposes. Additionally, the String version is provided so software manufactures have the ability to specify any textual representation they want an end-user to see in a report.

A good example of this is Windows XP. Most users will immediately recognize a text version for this OS if it’s listed as Windows XP, Version SP2. However, many users will not recognize the numeric version of 5.1.2600.

Each element is independent, but they should be related and consistent with each other.

Numeric-based version number consists of major and minor version numbers plus build and maintenance numbers. If a vendor does not choose to use all available version numbers, the non-used values should be set to 0. The numeric version will be used for comparison purposes against software entitlement information during the reconciliation phase of the Software Asset Management process.

The string version of the product version may contain numeric and/or alphabetic characters. It is a more user friendly name of the product version than numeric-based version number. This value will typically be used in user oriented reports.


Data XML tag Type Definition


Structure name XML character string Textual name of the version

numeric Numeric version - Complex type consisting of four elements with numeric values: “major”, “minor”, “build”, “review”

Numeric version identifier

Example <product_version> <name>10.2 Fix Pack 1</name> <numeric> <major> 10 </major> <minor> 2 </minor> <build> 0 </build> <review> 0 </review> </numeric> </product_version> OR <product_version> <name>6.2.1279.00</name> <numeric> <major> 6 </major> <minor> 2 </minor> <build> 1279 </build> <review> 0 </review> </numeric> </product_version>

1

7.3.4 Software manufacturer identity 2

XML Tag software_manufacturer

Type Complex type

Definition This Element allows a discovery process to identify the specific software manufacturer that created the software package.

Software manufacturer names in different countries may have exactly the same name, but be separate companies. To ensure uniqueness, this element must contain a GUID in addition to the textual name.

A GUID for a particular software manufacture should remain constant for all software product releases made by that specific vendor.


Data Structure

XML tag Type Definition

name XML character string

The text representation of the Manufacturers name – e.g. “Acme Widget Company”

guid GUID Type Unique GUID that is linked to the software manufacturer. This value should be the same for all releases of a product and all products that the software manufacturer develops.

Example <software_manufacturer> <name>XYZ Corporation</name> <guid>3A2504E0-ABCD-11D3-9A0C-0305E82C3301</guid>


</software_manufacturer> 1

7.3.5 Software unique identifier 2

XML Tag software_id

Type Complex type

Definition The software_id provides information that can be used to reference a specific version of a specific product. This element requires the creator to ensure that the unique_id is unique for each software title and version as well as unique to other ID's that may be created by other companies.

Different upgrade levels must be distinguished by unique software identifiers.

To avoid the need for an external registration agency, each tag creator should use their own manufacture domain (specified as a URI as per IETF RFC 3986 – providing the authority preferably as the registered name of the company's domain). The domain is provided along with a globally unique ID (unique_id). Different platforms and/or development environments may have different methods of creating unique ID's.


Data Structure


unique_id XML character string Unique ID that identifies the specific version of a specific product.

software_manufacturer_domain

XML character string A URI as specified in IETF RFC 3986 and that includes the authority preferably as the registered name of the companies domain.

Example <software_id> <unique_id>fc3cc419-b5a1-9f16-ed203e537c40</unique_id> <software_manufacturer_domain>http://www.adobe.com</software_manufacturer_domain> </software_id>

OR

<software_id> <unique_id>com.adobe.Acrobat-3D-Win-Multilingual-8.00</unique_id> <software_manufacturer_domain>http://www.adobe.com</software_manufacturer_domain> </software_id>

3

4

7.4 Optional identity elements 5

Optional identity elements may or may not be provided in a software tag. The content fields that correspond to 6 optional identity elements permit software tag creators additional opportunities to improve reliability of 7 information for software users and tool providers. 8

7.4.1 Abstract 9

XML Tag abstract


Type Complex type

Definition Summary that provides information for the software package that this tag applies to, including a language component to allow for mulit-language support.

The abstract element may occur more than once in a software tag, but should only occur once for each language specified.

If language is not specified, it is assumed to be English ("en").

This element may occur 0 to unlimited times in the software tag.

Data Structure


lang XML character string. This is a tag attribute

The language the abstract is written in See IETF RFC 4646 for language specifications - http://www.ietf.org/rfc/rfc4646.txt.

abstract XML character string The description of the software package.

Example <abstract lang=en>The View Master software enables viewing of all kinds of document formats.</abstract>

1

7.4.2 Component association 2

XML Tag component_of

Type Complex type

Definition Component_of is an element that is used to show a child to parent relationship between packages (i.e. which parent does this package belong to). Typically, this element will be used when additional components are installed, but are related to an existing package on a computing device. This element is not used as part of a suite definition, rather it's used when a package is installed that adds functionality to an existing package on the computing device.

Typically either component_of or complex_of will be used to specify a product grouping, not both at the same time.

This element may occur 0 to 1 times in the software tag.

Data Structure


software_id Software identification type described in 7.3.4

One to unlimited entries

List of unique software identifiers that defines an association between this package and a parent package.

Example <component_of> <software_id> <unique_id>fc3cc419-b5a1-9f16-ed203e537c40</unique_id>


<software_manufacturer_domain>http://www.adobe.com</software_manufacturer_domain></software_id>

</component_of> Or <component_of> <software_id> <unique_id>com.adobe.Acrobat-3D-Win-Multilingual-8.00</unique_id> <software_manufacturer_domain>http://www.adobe.com</software_manufacturer_domain> </software_id> </component_of>

1

7.4.3 Components list 2

XML Tag complex_of

Type Complex type

Definition Complex_of is an element that specifies child relationships for this package (i.e. which packages belong to this one). This element is typically used to provide a list of products that are a part of a “suite”. This element is made up of a list of unique identifiers that represent the products that make up the suite. Typically either complex_of or component_of will be used to specify a product grouping, not both at the same time.


Data Structure




Unique Software identifier that defines an association between this package and its child packages. This item is generally used when defining the packages that make up a suite.

Example <complex_of> <software_id> <unique_id>fc3cc419-b5a1-9f16-ed203e537c40</unique_id> <software_manufacturer_domain>http://www.adobe.com</software_manufacturer_domain> </software_id>

</complex_of> Or <complex_of> <software_id> <unique_id>com.adobe.Acrobat-3D-Win-Multilingual-8.00</unique_id> <software_manufacturer_domain>http://www.adobe.com></software_manufacturer_domain> </software_id> </complex_of>

3


7.4.4 Data source 1

XML Tag data_source

Type XML character string

Definition Basis for the data source of the final installation.

Values include, but are not limited to, strings such as the following: CD, MSDN CD, Electronic distribution and Definitive software library – Released for distribution. By providing such values in the software tagging process, SAM owners can rapidly assess what software configuration items are installed on which platforms and how each was installed. This element does not require normalization between different companies, because exceptions are typically required.

Values used in this field should be consistent within a company and across product lines.


Example <data_source> DVD</data_source>

2

7.4.5 Dependency 3

XML Tag dependency

Type Complex type

Definition This element is provided in order to allow software to specify that it requires a different product in order to run. This is not necessarily related to software licensing or software entitlements, but simply to requirements. For example, a Java application may be dependent on a specific version of Java to run properly. An Excel template requires Excel. These dependencies are not necessarily strict dependencies that will be used by the software to validate that a specific software tag is available before the application runs, but rather guidance that's provided to the SAM database to assist with software relationships and/or potentially to provide information to a help desk environment.


Data Structure




Unique Software identifier that defines the dependency tag.

Example < dependency> <software_id> <unique_id>fc3cc419-b5a1-9f16-ed203e537c40</unique_id> <software_manufacturer_domain>http://www.adobe.com</software_manufacturer_domain> </software_id>

</dependency>


1

7.4.6 License and channel information 2

XML Tag license_linkage

Type Complex type

Definition This element provides information that can be used to help determine the proper software entitlement structure for the product installation that is related to this tag. The elements that are part of the license_linkage element provide information on how the product may have been installed and its current license state on the particular system the tag is discovered on. Note that the license state is not directly related to a software entitlement – license state is for a specific machine, entitlements are the details of what a company may have installed and in use for a number of machines.

Elements provided as part of the license_linkage element can help SAM practitioners quickly identify when un-authorized software is installed in their environment. These tags are optional, but they will help the SAM practitioner by providing more information about where software may have come from. By providing these tags, SAM practitioners can build rules that help them manage by exception rather than having to monitor each and every change that may occur in the environment they work in.



Data Structure


activation_status

XML character string

The values in this element are related to the various different licensing levels that a specific publisher tracks for an individual machine. Every publisher may have a different set of status values, but as much as possible, the values should be consistent for one publisher. A representation of these values may include:

• Trial – this indicates that the software is in a trial mode and this value may include the number of days the trial mode is valid, or that the trial has expired.

• Serialized – this indicates that the user has entered a valid serial number during the installation process, but that the product has not yet been activated.

• Fully Licensed – this indicates that the product has been activated and as far as the software publisher is concerned, this is a fully capable installation for a specific system.

• Unlicensed – this indicates that the software should no longer be able to be run on a device, or it is running in a limited mode. Software can get into this state by the following:

o A trial period has expired o A time-based license has expired o Package was serialized, but never activated

in the given timeframe. Values used in this field should be consistent within a company and across product lines.

channel_type


Zero to unlimited entries

Provides information on which channel this particular software was targeted for. The values used in this element may be unique to the software vendor, but should be consistent between products published by a particular vendor. A representation of these values may include:

• Volume • Retail • OEM • Academic

If used by a software publisher, it allows a SAM practitioner to identify software that may be installed in a corporate environment but that doesn’t follow corporate policy. For example, software that was destined for an academic channel is not generally considered appropriate for installation in a corporate setting. Values used in this field should be consistent within a company and across product lines.

customer_type


Zero to unlimited

Customer type identifies the target customer, not the channel. The values used in this element may be unique to the software vendor, but should be consistent between products published by a particular vendor. A representation


entries of these values may include:

• Government • Corporate • Educational • Retail

With current software entitlements, there is often a different cost associated with products that are targeted at different customers. However, there are also limitations placed on the installation of these products. For example, a copy of software that is created for an educational customer is typically sold at a lower cost and often not licensed for use in a corporate setting. Values used in this field should be consistent within a company and across product lines.

Example <license_linkage> <activation_status>Fully Licensed</activation_status> <channel_type>Volume</channel_type> <customer_type>Corporate</customer_type> </license_linkage>

Or

<license_linkage> <activation_status>Trial</activation_status> <channel_type>Retail</channel_type> <customer_type>Retail<customer_type> </license_linkage>

1

7.4.7 Package footprint 2

XML Tag package_footprint

Type Complex type

Definition Specifies a set of files and other entries that indicate a product is installed. Also provides for a link to a full list of files from an external URI. This element allows items that are specified to be filtered from a list of discovered elements and, more importantly, allows the software manufacture to define the footprint providing a much more reliable and consistent means of validation.


Data Structure


External_description

URI string

Zero or one entry

This element allows a software manufacture to keep the list of entities associated with a particular system available through an indirect reference to their site. By doing this, the software manufacture owns the list and can update the list as necessary without having to distribute a patch, or a new version of the product with a new set of files listed.


primary FootprintModuleComplex type


Defines files that are considered "primary" to a software application. If any of these files is found on a device, then software is considered to have a high probability of being installed and the tag should be considered to be valid.

secondary FootprintModuleComplex type


Defines files that are considered "secondary" to a software application. These files are not used to validate that a software tag is valid, but are instead used as a filter by software recognition algorithms that determine if a software package is installed based on files found. By providing a list of files that can be safely "filtered out", the software recognition engine will end up with many fewer unmatched files that require research by a human desktop administrator.

other FootprintModuleComplex type


Defines files that are "loosely coupled" to a software package, but that may also be installed with a particular software package. These file entries are aso used to filter a complete list of files that a discovery agent may collect in order to remove files that are associated with "known" applications.

An example of this is an application that installs an OEM version of a software package. The files in the OEM installation should be able to be loosely associated with the primary package (so they can be appropriately filtered by a software recognition process), but if another application claims ownership to those files, than that application claiming ownership gets precedence over any applications that have a loose association.

Example <package_footprint> <primary> <file> <name>acrobat.exe</name> </file> </primary> <secondary> <referenced>http://www.adobe.com/acrobat/(sofware_id)/filelist.xm</referenced> </secondary> </package_footprint>

Note that the filelist.xml file would be the same structure as the software tag and the "package_files" element would be used to provide the file definitions for a particular software_id.

1

7.4.8 Packager 2

XML Tag packager

Type Complex type

Definition Third party packaging product for distribution or installation. This would be used if a product is OEM’d and re-packaged by a third party, or if a company re-packages a product with a


specific configuration.


Data Structure


by XML character string

Attribute gives the information about third party packaging product company

part XML character string

Additional information about third party product

Example

1

7.4.9 Product category 2

XML Tag category

Type Complex type

Definition Means by which product titles are classified by high-level function; a standardized l ist of categories/groups is provided by the United Nations Standard Products and Serv ices Code: UNSPSC (for more informat ion see ht tp: / /www.unspsc.org/) , COMMODITY l ist ing number 43230000, which covers the major categories for software will be the most commonly used commodity definition.


Data Structure


UNSPSC_ver XML character string

Version number of the UNSPSC code set used. The version is not required to use the code, however, if a tool uses the version to provide additional functionality (such as providing various names in one of 9 other languages), the version will be needed by the tool. An example of the format of the UNSPSC versions is 10.0501.

segment_title XML character string

Name of the segment the product belongs to

family_title XML character string

Name enabling recognition of the family of the product

class_title XML character string

Name of the class

commodity_title XML character string

Name of the commodity


code Numerical value with 10 digits

UNSPSC code

Example <category>

<UNSPSC_ver>10.0501</UNSPSC_ver> <segment_title>Information Technology Broadcasting and

Telecommunications</segment_title> <family_title>software</family_title> <class_title>Finance accounting and enterprise resource planning ERP

software</class_title> <commodity_title>Enterprise resource planning ERP software</commodity_title> <code>43231602</code>

</category> 1

7.4.10 Product identifier 2

XML Tag product_id


Definition Identification of the product. It is independent from its version.

It's recommended that the Product ID not be the product name, or other marketing term as these often change from release to release. Instead the product_id should be an identifier that can follow products through their lifecycle without requiring marketing changes. product_id is used to define a lineage between products for identification of allowed upgrades. This value may or may not be used by a software entitlement. If a software entitlement specifies that a product may allow upgrades during a certain period of time, the software entitlement document cannot know which future product names, or product versions can be applied and will become available during that time. The product_id allows a software entitlement document to specify that a specific version of the product is entitled to be installed initially, and any updated products that have the same product_id are also entitled to be installed as long as the release_date falls within the range provided in the software entitlement. Note that there may be more than one entry for product_id. This may happen in the case where a manufacturer comes out with a new product and allows users from two different older products to upgrade to the new one. For example: Product A product_id = 1234XYZ Product B product_id = ABCDPDQ Product C (this product allows maintenance upgrades from Product A or Product B) product_id = 9876HJK <- this is the new product ID for Product C… product_id = 1234XYZ product_id = ABCDPDQ If later releases of Product C only wanted to allow maintenance upgrades from earlier versions of Product C, the product_id would only include the new ID for that product – 9876HJK. This element may occur 0 to unlimited times in the software tag


Example <product_id>fc3cc419-b5a1-9f16-ed203e537c40</product_id>

1

7.4.11 Release date 2

XML Tag release_date

Type XML dateTime type

Definition This tag will typically be used by an end-user organization as part of an ITIL release process.

Date software configuration item was released for installation. The software configuration item should use a single date of release in order to facilitate reconciliation.

.

This element may occur 0 to 1 time in the software tag.

Example

<release_date>2008-01-21T12:00:00</release_date>

3

7.4.12 Release id 4

XML Tag release_id



Data used in reconciliation to identify release package attributes upon installation and associated software entitlements. Entries for this identity element must be kept consistent across all software tags for any given software configuration item.


Example <release_id>COE-Base-Ver 8, 2008-01-21</release_id>

5

7.4.13 Release package 6

XML Tag release_package

Type Complex type


Validation information that a release package has been built to conform to the service provider's systems architecture, service management and infrastructure specifications.

NOTE 1: End-use software packages will almost always be customized to the needs of the service provider, with specific installation options and/or combinations of software bundling specified (release software tags are completely independent of any manufacturer or re-seller software tag).



Data Structure


signoff XML character string

This entry indicates the person who authorized that the software was packaged properly and is ready to go into a testing phase.

signoff_date XML dateTime type

This entry indicates the date the software package was signed off.

by XML character string

This entry indicates the engineer who created the package. This information may be used if questions come up during the testing phase.

Example <release_package> <signoff>Jane Doe</signoff> <signoff_date> 2008-01-10T12:00:00</signoff_date> <by>John Doe</by> </release_package>

1

7.4.14 Release rollout 2

XML Tag release _rollout

Type Complex type

Definition Validation information relevant to who signed-off a release package as ready for production use and when said signoff occurred.


Data Structure

XML tag

Type Definition

signoff XML character string This entry indicates the person who authorized that the software was properly tested in a production pilot and is ready to go into a production use.

signoff_date

XML dateTime type This entry indicates the date the software pilot was signed off.

by XML character string This entry indicates the engineer who managed the pilot testing phase. This information may be used if questions come up once the software is in production.

Example <release_rollout> <signoff>Mary Jane</signoff> <signoff_date> 2008-01-16T12:00:00</signoff_date> <by>John Smith</by> </release_rollout>

3


7.4.15 Release verification 1

XML Tag release_verification

Type Complex type

Definition Validation information that a release package has been verified against a testing environment that matches the requirements of the target production environment.


Data Structure

XML tag

Type Definition

signoff XML character string This entry indicates the person who authorized that the software was properly tested in a controlled environment and is ready to go into a pilot testing.

signoff_date

XML dateTime type This entry indicates the date the software testing was signed off.

by XML character string This entry indicates the engineer who managed the controlled testing phase. This information may be used if questions come up once the software is in the pilot testing phase.

Example <release_verification> <signoff>Jane Smith</signoff> <signoff_date> 2008-01-14T12:00:00</signoff_date> <by>Doug Johnson</by>

</release_verification> 2

7.4.16 Serial number 3

XML Tag serial_number


Definition Unique identifying number or signature; may be represented as a combination of numbers, letters or symbols. Serial Number is a commonly used unique number assigned for identification of a particular title and purchase. In the case of software tags, the unique_id becomes the primary unique key, but many organizations may still want to use the serial number where it’s available.

Note that the serial number may be put through a one way hash that obfuscates the actual serial number – this is still useful to the SAM practitioner – especially if the same reference serial number is included on the purchase order, invoice or other details provided by the distributor to the software customer.


Example <serial_number>1088-9015-2034-4567</serial_number> or <serial_number>10PQR28FTQN2008</serial_number>


1

7.4.17 SKU 2

XML Tag sku


Definition Stock Keeping Unit may be represented as a combination of numbers, letters or symbols. This identifier is used similarly to Serial Number, The manufacturer or reseller may choose which one to use.


Example <sku>1088-9015-2034-4567</sku> or <sku>10PQR28FTQN2008</sku>

3

7.4.18 Software manufacturer alias 4

XML Tag software_manufacturer_alias

Type Complex type

Definition Provides a Tag entry that a software publisher can use to enable SAM practitioners to identify previous publishers who “owned” the copyrights to a particular piece of software. Though not strictly required for software discovery purposes, this entry will ease the burden of a SAM practitioner by providing them with previous software manufacturers which can be used to more easily find an older software entitlement. This is especially important in the case where an upgrade is allowed from a previous software manufacturer’s version of a product to the current manufacturer’s version.

This element may occur 0 to unlimted times in the software tag.

Data Structure


name XML character string

The text representation of the Manufacturers name – e.g. “Acme Widget Company”

guid GUID Type

zero or one entry for guid

Unique GUID that is linked to the software manufacturer. This value should be the same for all releases of a product and all products that the software manufacturer develops.

Providing GUID’s for aliases provides a more authoritative identifier of a copyright holder. Providing the GUID is not required, but is recommended if it can be determined.

Example <software_manufacture_alias> <name>Macrovision</name> <guid>CF5737AF-8550-4546-A69B-0EA9EF5A9B55</guid> </software_manufacture_alias> Or, if the guid is unknown:


<software_manufacture_alias> <name>Macrovision</name> </software_manufacture_alias>

1

7.4.19 Supported languages 2

XML Tag supported_languages

Type Languages as specified in IETF RFC 4646 and IETF RFC 4647

Definition Languages that the program interface presents to the user: refer to IETF RFC 4646 and IETF RFC 4647 for a list of standard language codes and the process used for language matching.


Data Structure


language XML character tring

Languages supported by this software package. Language may occur multiple times. Specification of the language is defined by IETF RFC 4646 and the process used for matching language tags is specified in IETF RFC 4647.

Example <supported_languages> <language>en</language> <language>fr</language> </supported_languages>

3

7.4.20 Upgrade for 4

XML Tag upgrade_for

Type Complex type

Definition Product title that represents an upgrade for an earlier, down-level version, providing specific details about what is upgraded.


Data Structure


upgrade_id Software identification type described in 7.3.4

This refers to the software_id’s that may be upgraded to the version indicated in this tag. If the software_id’s are provided, SAM managers can then do a completely automated reconciliation to ensure that all upgrades are done appropriately.

upgrade_description


Optional description of upgrade

Example <upgrade_for> <upgrade_id> <unique_id>fc3cc419-b5a1-9f16-ed203e537c40</unique_id> <software_manufacturer_domain>http://www.adobe.com</software_manufacturer_domain> </upgrade_id> <upgrade_description>{Optional description of upgrade}</upgrade_description>

</upgrade_for>


1

7.4.21 Usage 2

XML Tag usage

Type Complex Type

Definition Provides information specifying which running process should be used to validate usage of the product. The usage element may not specify software components that load at startup, but rather those components that indicate that an end user is actually using the product.


Data Structure


filename XML character string

This defines the filename that is executed to start an application.


processname


This defines the process name as it would be found in the process table for the application.


URI XML URI type This defines a web based location that should be tracked to determine application usage. This may be used in the case of an on-line tool that an organization wants to track usage on, or it may be used in a case where an application requests information from a URI during execution.


Example <usage> < filename>winword.exe</filename> < processname>windword.exe</processname> </usage>

3

7.4.22 Validation 4

XML Tag validation

Type Complex Type

Definition Provides a callout that a discovery agent can use to validate the software tag. Due to system issues, installation and uninstallation defects or other issues, a software tag may not be fully in sync with the application installation. This element allows a software tag to include a validation callout that may be used, if required to validate that the software tag is correct.

It's expected that software manufacture will regularly validate that software tags related to their applications are validated at some interval when the applications are executed – this would be considered a self-healing process. During this self-healing, the tag sub-elements that are part of the validation element, last_validated_by and last_validated_date would be updated to show that the tag has been compared and found to be accurate.


In those cases where a software package is not run for an extended period, the last_validated_by and last_validated_date would not be updated. A discovery agent, by policy, may require that a software tag be validated within a specified period (for example, if a software tag has not been validated in 3 months, it may be considered suspect and possibly out of sync). If the last_validated_date is older than the specified period, the discovery agent can call the routine defined in validation_call to ensure the software tag is up-to-date.


Data Structure


validation_call


This is a call that a discovery agent can make to validate that the software tag is valid. It's expected that this call would be to one of the executable applications in the software application with a command line parameter that specifies that the tag should be validated.

last_validated_by


This element identifies the process that was used to validate the software tag. It's expected that the software manufacturer will create an ID for any validation routines and include that ID in this element. Depending on the publisher, this reference may be the same for all of the software publishers titles (i.e. ACME's validation routine), or it may be unique per application. It may even be possible that an installation routine may be used to do a tag validation.

last_validated_date

XML dateTime type

The last date and time that this tag was validated.

last_validated_result

Boolean This element will be True or False. It's purpose is to provide a method that can identify if the Validation_call is not able to be called for some reason, or if the Validation_call results in an error. For the SAM practitioner, if they receive software tag informaiton that includes "Validation_result=false", that will provide an exception that needs to be investigated. It does not indicate that the tag is not valid, it simply indicates that there is an issue with the validation process and let's the SAM practitioner become aware of a problem.

Example <validation> <validation_call>"ACME_validator.exe /tag-validate" <\validation_call> <last_validated_by>"ACME_validator.exe" </last_validated_by> <last_validated_date>2008-03-31T12:00:00</ last_validated_date> <last_validated_result>true</last_validated_result> </validation>

1

7.5 Extended identity elements 2

Extended information is provided in the software tag to allow the inclusion of additional values that have not 3 been predefined. Extended information must be in an XML format and should include an XSD reference that 4 can be used to validate the information in this section. 5

Unlike the Mandatory and Optional sections, there may be multiple Extended Sections in a tag. Each 6 extended section will be available for only one specific owner. For example, a software publisher may include 7


extended information that they want included for their own discovery tool. An end-user organization may want 1 to include extended information related to their overall software lifecycle policies and procedures. 2

7.5.1 Extended information 3

XML Tag extended_information

Type Sequence of elements of any type

Definition Supplemental information that may be provided by the Software Publisher, the purchaser of the software, or a 3rd party (such as a distributor, SAM tool or Desktop Management tool).

Data must be provided in an XML structure.

This element contains any extended information required. Data provided in this section must be provided in an xml compliant structure. Additionally, an XSD should be provided so this section can be properly validated. The XSD file must be referenced properly in the Software Tag XML file as per standard XML definitions.

Since this element is optional, it may not appear in the software tag. If this element is in the software tag, it may appear multiple times. The expectation is that every extended_information section included in the software tag is owned and managed by a single organization. Thus, a software manufacture may provide one extended_information element, a reseller may provide another extended_information element and a release manager may provide a 3rd extended_information element. Each of these will be independent entries and a tag modifier should generally not modify data in an extended_information section that they did not create or own.


Example <extended_information> <software_publisher_activation_ref>xyzzy</software_publisher_activation_ref>

</extended_information> 4

7.6 Data type definitions 5

7.6.1 GUIDtype 6

Data Type GUIDType

Definition This data type specifies a GUID and validates that the data value matches a GUID definition that should look something like the following:

00001101-0000-1000-8000-00805f9b34fb

Data Structure Type String

Restrictions pattern value="[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}"

7

7.6.2 Numeric version 8

Data Type Numeric


Definition This data type is created to provide a standardized 4 digit numeric version. If the version number used for the product has less than 4 levels, lower levels should be set to zero '0'

Data Structure XML Tag Type Definition

major Integer Highest level of the version number. Typically, this is called the major version.

minor integer 2nd level of the version number. Typically, this is call the minor version

build integer 3rd level of the version number. Many organizations call this the build version.

review integer 4th level of the version number. Many organizations call this the patch or review level.

1

7.6.3 FootprintModuleComplex type 2

Data Type Complex Type

Definition This type is used to define the files, registry entries and other data values associated with a specific applications installation.

Data Structure XML Tag Type Definition

referenced XML URI type

zero to one entries

This element is similar to the external_description but can be used for the specific footprint module only.

file File footprint complex type

zero to unlimited entries

This element represents description of the file with its attributes: size, md5, version, translation key, and any other needed.

registry Registry footprint complex type

zero to unlimited entries)

This element represents description of the registry entry with its attributes: path and value

other Other footprint complex type

zero to unlimited entries)

This element represent any footprint needed and not leasted above. It may contain any attributes.

3


Annex A 1 (informative) 2

3 Software producer use cases and guidance 4

A.1 Software manufacturers and providers 5

The Software Manufacture is driven to implement the ISO 19770-2 standard for three primary reasons: 6

1. Ease of identification: The easier it is, the higher the chance customers would do it. It's also true for 7 software audits (software auditors, internal or otherwise, would be more efficient in the process of 8 understanding what's installed across the organization). 9

2. Accuracy of identification: current methods typically rely on signatures based on application 10 components installed on machines. These signatures are often not at the same resolution level as 11 software entitlements. Additionally, many product titles have no obvious correlation to the application 12 components that are actually installed. These issues make identification results very hard to reconcile 13 with software entitlements. 14

3. Control over software identification: software manufacturers can specify exactly what can and 15 cannot be changed in the tag ensuring consistency in software identification. 16

Additionaly, when electronic software entitlements become standardized, the software manufacture and 17 provider that already uses tags will readily be able to implement software entitlements that provide automated, 18 or nearly automated links to existing software tags. As a software manufacture is implementing software tags 19 for their product lines, they need to consider some of the details of how software entitlements may necessarily 20 influence how much information is provided in the software tag. 21

From a software product definition and development perspective, it’s also very beneficial to define the tag as 22 early in the project as possible to ensure that the software project is focused on the right tools and technology 23 to meet the requirements specified for the target languages and platforms. 24

In general, a software manufacturer wants to make their software easy to install, easy to use and easy to 25 identify. In addition, the use of standardized tags benefits both end-customers and software manufacturers 26 alike. Customers gain increased efficiencies through a simplified discovery process, while making the overall 27 process more effective. Software vendors benefit from customers having sound asset management practices 28 that ensure that the software will be installed and used in accordance with the software license agreements.. 29

The following use cases provide different perspectives on how the tag is created and updated through the 30 lifecycle of a software product. 31

A.1.1 Roles Involved in the software tag creation/management 32

There are numerous people in different roles that will be responsible for ensuring a software tag is created 33 and maintained properly, including: 34

Product Manager – this person defines the product being developed/enhanced and must specify many 35 aspects of the product that are referenced in the software tag. By referring to the Software tag as part of the 36 product definition, a cleaner product definition document can be created. 37

Development Manager/Engineer – this person determines the technology that will be used to develop and 38 deliver the software. Having the tag specifications provided in advance allows them to have a clearer 39 understanding of the final environment the product will be used in. 40


Software licensing/product release specialist – this role has an interest in ensuring that they know exactly 1 which piece of software they are working with. If a suite is comprised of multiple different products, these folks 2 need to understand how that may impact licensing or product release activities (including catalog updates). 3 This role is responsible for making sure that a software item, its license and any associated catalog 4 information is cross referenced and correct. 5

6

A.1.2 Product manager role 7

The Product Manager will want to see lots of different examples of software tags. Basically, if the Product 8 Manager can take an existing example of a software tag and modify it for the definition of their product, the tag 9 has a much greater chance of being defined properly. Examples should include not only the Mandatory fields, 10 but should include different sections on other fields that are likely to be included in a software tag with 11 explanations of why these sections should or should not be included. 12

As the Product Manager generates the product definition, the definition template should include a section that 13 specifies the required portions of the software tag. The Product Manager will first work through the Mandatory 14 elements in the tag: 15

• Entitlement Required — This tag determines whether or not the discovered software should be 16 accounted during the reconciliation process or not. The Product Manager can clearly state when a 17 requirement is needed (such as the case of a software license sold to customers), or not (such as the 18 case of an expiring software trial). 19

20 • Product Title — This element correspond to the official marketing name of the product as defined by 21

the software manufacturer. It is recommended for Product Manager to ensure the product name is 22 consistent across geographies and languages as it simplifies the recognition of a particular software 23 title, even though the title itself may not have a direct impact in the reconciliation process. 24

25 • Product Version — This important element allows the definition of both, a text-based marketing 26

version (commonly used by software manufacturers to simplify the naming of a particular version for 27 promotional purposes), plus the formal numeric version for the licensed software.. The numeric 28 version may include up to four elements providing the complete version information: major version 29 number, minor version number, build, and review. A software vendor may license a software product 30 by its major or major.minor version only. In such cases, the Product Manager must make sure that the 31 software entitlement information (purchase order, invoice, software license certificate or equivalent) 32 reflects that so there is no confusion during the asset reconciliation process. 33 34

• Software Manufacturer Identity — The goal for this element is to provide a unique and consistent 35 identification of the vendor producing the software. Given that some software companies may have 36 slightly different regional names, it is critical to augment the name with an identifier that will remain 37 constant across all countries, regions and languages (such as a unique GUID that is linked to the 38 software manufacturer. This value should be the same for all releases of a product and all products 39 that the software manufacturer develops). 40 41

• Software Unique Identifier — The Product Manager working with the rest of the development 42 organization will define an unique identification for each product and product version. The unique 43 identifier will enable proper comparison at reconciliation time. 44 45

Once the mandatory tags are specified, the product manager will then wonder which other tags need to be 46 specified. A best practices approach to the definition of a software tag should be included to allow the 47 software manufacturer to know which Optional tags are useful to be specified as the software is shipped as 48


well as understand which software tags are likely to be modified as the software progresses through the sales 1 channel and is eventually installed on a computer. 2

Optional Elements to Consider 3

The ISO 19770-2 standard includes a rich set of optional elements that augments the content of the tag itself 4 and increases efficiencies in the identification and reconciliation processes. This section of the document 5 highlights the use of a few key optional tags defined in the standard. 6

• Component Association and Component List – These two optional elements enable Product 7 Managers to properly tag a software program as a component of an abstract licensing product entity 8 such as suite or collection. Likewise, the component list element provides the ability to list the rest of 9 the components associated with the same licensing entity (i.e., the suite). Including one or both 10 optional elements in the tag drastically improves the proper identification of seemingly independent 11 software binaries, at the same time that ensures that the reconciliation process will account for the 12 proper software license of suite versus point products and vice-versa. 13

• Languages – The languages element allows software manufacturers specify the language(s) of the 14 software program installed on a machine. This information is particularly important for software 15 vendors who sell language-specific software licenses as the software entitlement/purchase order 16 would also reflect the language-specific products sold to the customer. Software manufacturers may 17 offer the same product at different prices depending on the language and/or region where sold, hence 18 the relevance of the language element in the tag. 19

• License and Channel Information – This additional element further refines the identification of the 20 software installed on a given machine, increasing the efficiency of the SAM Practitioner and the 21 effectiveness of the overall reconciliation process. For example, knowing the source of an installation 22 would make it easy for SAM practitioners to separate software purchased directly versus titles 23 included as OEM with the purchase of new PCs. Product Managers should strongly consider the use 24 of these two optional elements. 25

• Package footprint – This element allows the software manufacture to specify the files, registry 26 enteries, and other information that can be used to identify an application. This element provides for 27 multiple entries per file so that patches and minor releases can be handled efficiently with a single 28 referenced file. The goal of this element is to allow a discovery tool to eliminate all "known" files from 29 the discovered list, so keeping all files for a particular product listed will be very helpful to discovery 30 tool providers and Software Asset Managers. 31

• Product Identifier – This element is meant to be an identifier that follows a specific product from 32 release to release. This element should not use a marketing term for the product (such as Product 33 Title), but should be a referencable identifier that can be consistent from release to release. For 34 example, if a company created and sold a product called "Acme Widgets 2007 Pro" and the next 35 release of that product came out with the name "Acme Widgets 2008 Expert", using a Product title, a 36 practitioner would not necssarily know if these two products were both part of a specified maintenance 37 agreement. However, if both products had the Product Identifier of "fc3cc419-b5a1-9f16-38 ed203e537c40", then a practitioner could readily determine that both products were part of the same 39 maintenance agreement and could then determine compliance. This element allows an organization 40 to specify which upgrades are allowed through maintenance agreements without specifying a specific 41 title. 42

• Serial Number – The value of including the serial number as part of the identification tag is directly 43 proportional to the importance of the serial number as a software entitlement element for the software 44 license purchased by end-customers. Companies that require customer- and/or purchase-specific 45 serial numbers in order to install and use the software should strongly consider including the serial 46


number element in the tag as it will directly correlate to the purchase order / software entitlement 1 during the reconciliation process. Serial numbers are commonly known at the time of installation and 2 are also included in the purchase order, making it possible to establish a direct link between the 3 installation and the licensing software entitlement. 4

o Special consideration regarding serial numbers in the tag: 5 Because serial numbers often represent the enablement of the a software entitlement, 6 Product Managers must consider whether to include the serial number in the clear as part of 7 the identification tag, or otherwise include a one-way hash form of the customer-specific serial 8 number to minimize exposure and possible leakage of valid serial number over the Internet. 9 In case a software vendor chooses to include an obfuscated/hashed version of the serial 10 number in the tag, the same obfuscated/hashed version must be included in the purchase 11 order, software entitlement or software license certificate in order to realize the benefits during 12 the reconciliation process, using either manual or automated processes. 13

• SKU – for companies that do not utilize serial numbers as part of the activation of software, the SKU 14 may be a necessary item for software entitlements to be able to identify a possible link to installed 15 software. 16

• Supported Languages – The languages element allows software manufacturers specify the specific 17 language(s) installed on a machine. This information is particularly important for software vendors who 18 sell language-specific software licenses as the software entitlement/purchase order would also include 19 language-specific products sold to the customer. 20

• Software Manufacturer Alias – While this optional element may not generally have the same level of 21 relevance others may have as it reflects the name of the product and manufacturer prior an 22 acquisition; this element is particularly important in the case where an upgrade is allowed from a 23 previous software manufacturer’s version of a product to the current manufacturer’s version. Product 24 Managers should consider including this element in the identification tag when releasing new versions 25 of software products after an acquisition. 26

• Upgrade for – This identification element is designed to simplify, and potentially help in an automated 27 reconciliation to ensure that all upgrades are done appropriately. However, the value and relevance 28 for this identification element is relative to the deployment environment, configuration practices and 29 the type of software in which it is used. The reason for this is because frequent re-imaging of desktop 30 PCs is common in certain environments (e.g., computer labs, health sector, legal offices and some 31 government agencies), so previous identification tags may be lost in the process. This is also the case 32 where personal computers are recycled every 36 months or so. There are certain categories of 33 software titles where the user of this identification element would be highly recommendable such as in 34 software with long development cycles between releases, deployed in stable environments where 35 machines are not re-imaged or recycled very often. Product Managers need to take under 36 consideration the type of software they manufacture and the environment where it is deployed when 37 making a decision to include this identification element or not. 38

The use of signatures ensures the integrity of those identification elements the Software Manufacturer wants 39 to ensure remain unchanged after the tag has been created. Product Managers need to consider the cost of 40 the extra protection versus the cost of implantation and testing in order to make a decision whether to sign 41 specific elements within the tag or not. 42

A.1.3 Development manager/engineer 43

The Development Manager will work directly with the Product Manager to ensure the product specification is 44 clear and complete. They will need to have the same level of detail as that expected by the Product Manager. 45


However, when it comes to design and implementation time, the Development Manager is going to need more 1 detail. The following list outlines some of the implementation details that need to taken under consideration 2 and decided upon prior proceeding with the implementation: 3

• Identification tag file creation: When and how will the identification tag be created? 4 There are multiple approaches to consider. The specific circumstances of each Software 5 Manufacturer, development cycles, operational and manufacturing process will determine the 6 approach that will work best. Possible options include: 7 8

o Pre-generated tag file(s): included with the installation disc, selected and copied to the target 9 machine at installation time. 10

o Generated at execution time: dynamic identification tag file that is generated upon execution 11 of the software program, using the information collected at installation time. 12

o Partially pre-generated and updated on the fly: combination of the two prior options. 13 14

• Identification tag file for multi-product licensing entities (e.g. Suites): How the tag file will be created 15 and maintained? 16 Development Managers need to consider where and how will the tag file(s) for the suite components 17 will be created. This may be accomplished either at installation or execution time. If it is done at 18 execution time, the software running needs to ensure that the tags for all the suite components will be 19 properly created and copied to the correct location(s). 20 21

• Lifecycle management of identification tag files: how does the identification tag file evolve with 22 changes to the installed software over time? 23 Developer managers need to anticipate a number of lifecycle scenarios that will impact the 24 identification tags. Some of those scenarios include: 25 26

o Patches and updates: If the patch or update changes the product version, then the tag file 27 needs to reflect the latest version. If the Product Version element was originally signed, then 28 the signature would need to be updated as well. 29

o Missing identification tag file: Tags files may be accidentally deleted by users or corrupted. In 30 such cases, the software should implement self-healing mechanisms to re-generate the tag 31 as needed. 32

o Evidence of tampering: If the file includes signed tag elements, the software should perform a 33 periodic signature check to detect for potential tampering. In case tampering is detected, the 34 software should implement self-healing mechanism similar to the case where the file is 35 missing. Development Manager should work with Product Manager to determine business 36 policies in case of tamper detection in the identification tags. 37 38

• Additional implementation considerations: 39 40

o Does a tag have to be numeric or can it contain string values? 41 o Is the length of a tag is constrained or not? 42 o Can we correctly determine all the mandatory elements of the tag? 43 o How can the tag be validated for correctness during the QA cycle? 44 o Centralized library versus product-specific implementation: Mid to large Software 45

Manufacturers should strongly consider isolating product teams from the details and 46 implementation expenses by developing and maintaining a centralized identification tagging 47 library that can be easily integrated across all product releases. 48

o Common commercial off the shelf (COTS) software may also benefit from providing a 49 software producer specified Product Footprint. This footprint can be hosted on the software 50 producers site to enable ease of management and problem resolution and will significantly aid 51


SAM Tools and SAM practitioners in being able to automatically filter out "known" files, 1 registry and WMI entries that are "known" to be part of an installed application. This allows 2 SAM Tools and SAM practitioners to focus on software installations that are exceptions to 3 corporate policy, knowing that all details of the COTS software are properly accounted for. 4

o Package_footprint, if used, will typically refer the tag to a URL location on the software 5 manufactures domain. When providing footprint information, the development manager 6 should institute a policy that keeps all file information up-to-date as patches and minor 7 releases are released to the market. The package_footprint element allows more than one 8 entry for each file, so referring to a specific URI location allows tags from multiple versions of 9 a product to be included in one single package_footprint. 10

Essentially the development team needs to ensure that no assumptions are made about the software tag and 11 that the tag can be included and tested accurately. 12


Annex B 1 (informative) 2

3 Tool provider use cases 4

B.1 Discovery tool vendors 5

Discovery tools should be able to read data from software tags when available. The roles in an end-user 6 organization that would use a discovery tool might include an audit manager tasked with reconciling software 7 entitlements to software tags or a SAM owner tasked with collecting and analyzing information (5.2, A.4). 8

Use cases for tool vendor products and their consumption can be divided into primary and secondary 9 scenarios. 10

B.1.1 Primary use cases 11

Discovery tools should be able to do the following: 12

a) Implement consistent and uniform values in software tag data. 13

NOTE: If the software manufacturer who created the software tag employs multiple "Software 14 manufacturer name" or "Manufacturer part number or stock keeping unit" identity elements, the 15 discovery tool should be able to refer to a reconciliation table (provided by each software 16 manufacturer) to facilitate the reconciliation of different values (7.3.2, 7.3.3, A.1). This task could 17 require an optional identity element to be furnished by the software manufacturer 18

EXAMPLE: If software company A were acquired by software company B, then B should provide 19 reconciliation information for software formerly released and tagged by A. Or, if A released an 20 application only later to release a newer version of the same with an altered "Software manufacturer 21 name," then A should provide in its reconciliation table a reference to these two application names as 22 applied to different versions of the same. 23

b) Reconcile data from software tags with that from corresponding software entitlements. 24

NOTE: This reconciliation could be facilitated by an agent on the platform or an administrative console 25 reconciling from multiple agents. Reconciliation processes need both software tag and software 26 entitlement data to determine software license compliance. 27

EXAMPLE The tool should recognize from identity elements the difference between installs of 28 different but related products (by dependency, complex, platform or product version), such as 29 differences between Microsoft Excel, Microsoft Excel Viewer (unaccompanied), Microsoft Office 30 Standard 2000, Microsoft Office Standard 2003 and Microsoft Office XP Professional. 31

c) Read all mandatory identity elements during a discovery along with any optional ones, if available. 32 Such capability would utilize standardization in location and format of software tag data (5.1.4, 5.1.5). 33

B.1.2 Secondary use cases 34

Discovery tools should be able to do the following: 35

a) Utilize optional identity elements to assist in usage tracking. The "Usage identifiers" identity element is 36 of particular importance in such cases (7.3.19). 37

b) Read software tag data at a high level, using an agent-less or network-based tool when possible. 38


NOTE: Readings may expose identity elements to simple network management protocol or similar 1 protocol. 2

c) Utilize optional identity elements, when available, to determine the presence of a software key for 3 authorization of product usage. 4

B.1.3 Distribution tool vendors 5

Distribution tool vendors create tools to package, test, distribute and install software. End-user roles 6 implementing software distribution tools include the release manager, the packaging engineer responsible for 7 packaging applications for deployment and the SAM owner tasked with deployment itself. 8

Use cases for software distribution tool vendor products and their consumption can be divided into primary 9 and secondary scenarios. 10

B.1.4 Appending software tags for distribution: primary use cases 11

Software distribution tools should be able to do the following: 12

a) Create a software tag from scratch in these sample scenarios: 13

i) An end-user organization develops software such as a simple script file or document containing 14 macros that needs to be qualified as an application for tracking 15

ii) An end-user organization deploys legacy applications that do not contain software tags. 16

b) Understand whether a particular identity element should or should not be open to modification or 17 deletion. 18

c) Permit software re-packaging by maintaining identity elements pertaining to the original software 19 package alongside those for the re-package. 20

NOTE: Such re-packaging might include the bundling of multiple software packages into one software 21 package for distribution and deployment. Software tags can determine the difference between a simple 22 software configuration item and a software package, uncovering critical software package and release details. 23

EXAMPLE: Creation of a software package within a software package. A software manufacturer creates a 24 software tag for a product, packaging the latter in a distribution format. Separate software tag data is then 25 created for the software package containing the original product. When consumed by a software distribution 26 tool utilized at the end-user organization, the distribution format will be encompassed by the tool's own 27 proprietary software package. This new software distribution package creates its own software tag. Once the 28 final, complex software package is installed, all three software tags should be available for consumption. 29

B.1.5 Appending software tags for distribution: secondary use cases 30

Software distribution tools should be able to utilize available mandatory and optional identity elements to track 31 and identify release management steps. These include designing, building, testing, approving, distributing and 32 installing a given software package. 33

B.1.6 Consuming software tag data for distribution: primary use cases 34


a) Implement consistent and uniform values in software tag data. 36

b) Use software tags to automate packaging processes. 37

c) Determine if an application is allowed on a particular platform or for a particular language installed on the 38 platform (6.3). 39


B.1.7 Consuming software tag data for distribution: secondary use cases 1


a) Determine from software tag data whether a particular software configuration item is an upgrade or 3 replacement for another. 4

EXAMPLE If one software manufacturer allows multiple copies of the same product to be installed 5 alongside each other, the distribution tool should be able to determine this attribute upon install. On 6 the other hand, if a software manufacturer requires the upgrade or uninstall of a prior version to 7 precede installation of the new software, the tool should be able to determine this attribute as well 8 from software tag data. 9

b) Utilize optional identity elements "Complex of and "Licensing Dependency" to determine dependency 10 software configuration items that need to be installed along with a given piece of software (7.4.3, 7.4.7). 11

c) Utilize optional identity elements "Signatures" and "Software data source" to determine if an application 12 should or should not be installed based on a set of security specifications for installation (7.4.16, 13 7.4.17). 14

NOTE: If a company requires all software configuration items to be digitally signed prior to installation, then 15 the distribution tool should be able to read and validate appropriate digital signatures from optional identity 16 elements. 17

18


Annex C 1 (Informative) 2

3 Distributors, re-packagers and re-sellers use cases and guidance 4

C.1 Distribution, re-packaging and re-selling use cases 5

If a distributor re-packages applications into a bundle to re-sell with differing properties from the original 6 applications, new identity elements, mandatory and optional, should be modified or added to the bundle. 7

EXAMPLE If a distributor re-packages three products from publishers in the United States into one software 8 package to market to three different European Union states, it is probable that at least one of the original 9 software products will need to be translated into a different spoken language. The distributor should create or 10 modify relevant identity elements; one possible implementation scenario among many could specify an 11 internal commercial team provide developers with software tag data, which would ultimately be examined by 12 Quality Assurance. 13

C.2 Distributor software tag data creation and modification 14

Software tags created or modified in the distribution, re-packaging and re-sell processes can involve all 15 mandatory and optional identity elements, with the identity element "Signatures" differentiating data furnished 16 by the software manufacturer from modified data added later in the software tagging life cycle (7.4.16, 5.2). 17

A distributor can either modify the software tag with the requisite information before re-selling to the consumer, 18 or the software manufacturer can create a software package specific to the distributor and supply the 19 necessary software tag information itself. In the latter case, the distributor has no responsibilities in the 20 software tagging process except to ensure that the software manufacturer properly tags the software. 21 Regardless of practice, the outcomes should be the same. 22


Annex D 1 (informative) 2

3 Software tag data end users use cases and guidance 4

D.1 Overview 5

While the benefits of SAM are many, the ability to accurately inventory software is a key element required to 6 facilitate the following needs within the IT environment: 7

1. Software License Management – encompassing the ability to manage software licenses to include 8 software license use compliance, financially related decisions, and lifecycle management of assets: 9

o Software license compliance activities determine if an Organization is compliant with their 10 software license agreements. In order to make these determinations, analysis and 11 reporting is required of software usage rights and entitled quantities versus installed 12 quantities and actual usage attributes. 13

o Financial related decisions activities related to software licenses can include decision 14 points around: purchasing additional or new software licenses, upgrading existing 15 software licenses, renewing maintenance and/or support, Merger/Acquisition/Divestiture 16 activities and others. 17

o Lifecycle management 18

2. Platform stability – encompassing the ability to identify compatibility issues between software 19 applications and operating systems. In order to maintain platform stability, an Organization must 20 identify and remediate incompatible technology. 21

3. IT Security – encompassing all aspects of security (virus protection, malware protection, encryption 22 requirements, etc). In order to provide good security, an Organization must be able to identify potential 23 areas of risk. 24

D.2 Software tag 25

The ability to utilize a Software Tag will enhance SAM functionality and benefit to an Organization. Even if an 26 organization is only utilizing this Software Tag to accurately identify the various software applications, this 27 would be an enormous step forward for SAM. This Software Tag will be comprised of three segments: 28 Vendor provided data, Distributor / Reseller data and, to provide even more benefit, the Software Tag includes 29 an End User defined section. This End User segment would allow for enhanced capabilities of SAM activities 30 and abilities. 31

End User defined fields may include (this is not an exhaustive list): 32

• Software Asset Tag (SAT) – a unique identifier based on the End User’s defined criteria 33 • Package Release Date 34 • Package Release ID 35

o if the user utilizes this methodology to install packages 36 o as an aid in change control 37

• Image identifier 38 • License Version 39 • Location restriction 40

o if the software is restricted to a particular location (e.g. company, country, division, etc.) 41 • Special metrics or monitoring requirements (i.e. FlexLM monitoring, etc.) 42

• User Defined fields (must be a valid XML field) 43


D.3 Definition of roles 1

Roles used in this section have definitions that may not conform to the generally accepted understanding of 2 the given term. The defintions provided below are provided as a guideline as to the general roles that may be 3 of use in the described case studies. 4

• Asset Manager - responsible for overseeing the company's software use, inventory and compliance with 5 applicable contracts, agreements and copyright laws 6

• Inventory Control Technician – supporting the Asset Manager in reporting and management of tasks and 7 issues related to software inventory 8

• System / Platform Manager – assigned to manage tasks and issues related to software on an identified platform, 9 defines standards and policies related to software within that platform for the organization 10

• Packaging / Imaging Technician – person responsible for creating software packages or images for 11 distribution 12

• Service Desk Staff – internal customer support for computing issues within the organization 13 • IMAC Technician - person responsible for making changes to the desktop environment 14 • Application / Software System Administrator – product owner / support for a particular application or set of 15

applications 16 • IT Security Staff - Responsible for the security of the company's computing environment 17

The following sections provide use cases end-users may experience when working with software tags. 18

D.4 Scenario: baseline inventory 19

Organizations of all sizes have the need to establish a baseline or original inventory of their software. It is 20 assumed that most organizations will utilize a commercially available software inventory tool to obtain this 21 baseline software inventory. However, it is expected that some organizations will desire and attempt to obtain 22 a baseline software inventory via non-commercial means, depending on documented techniques for retrieving 23 data tag values. 24

D.4.1 Objectives 25

Establish and deliver reporting of installed software in support of: 26

• Software license management 27

o Contractual reviews and negotiation 28

o Reallocation of existing base to meet needs 29

• Compliance requirements 30

o Risk management 31

o Contractual compliance with Terms and Conditions 32

o Fixed asset reconciliation 33

• Audit requirements 34

o Publisher initiated audits 35

o Financial process validation 36

o Internal Audit validation 37


D.4.2 Functional roles1 involved 1

• Software Asset Manager 2

• Inventory Control Technician 3

• System or Platform Manager 4

• Packaging / Imaging Technician 5

D.4.3 Requirements2 6

For reporting and analysis, a number of data values for each software inventory item must be present, 7 retrievable and standardized (normalized) as to consistently represent the appropriate information: 8

• Publisher name3 9

o Publisher name at time of purchase 10

o Previous publisher names (highly desirable) 11

• Product name3 12

o Product name at time of purchase and as referred to in contractual documents 13

o Previous product names (highly desirable) 14

• Product version3 15

o Current product version at time of purchase and as referred to in contractual documents 16

o Previous and upgrade product versions (highly desirable) 17

• Inventory item type3 18

o All individual software items are identifiable, able to be inventoried and accurately recognized 19

o All packaged software suites are identifiable, able to be inventoried and accurately recognized 20

o Products are separately distinguished from non-products (ex. subcomponents, drivers, etc.) 21

• Software license type (OEM, Retail, Volume, Evaluation, Freeware, etc.) 22

o Infinite variations currently exist, however key software license model attributes must be 23 codified for proper analysis and self-audit by end-user organizations 24

o 3rd party products “bundled” as part of a single product offering, including suites, must be 25 identified as such and include the full “root” product data values (ex. publisher name, product 26 name and product version) 27

• Manufacturer part number (SKU) if provided by vendor 28

o At time of sale 29

o Must be unique across all publishers and channels (resellers, distributors, etc.) 30

o Should be GS1 (UCC/ECCC) compliant 31

• Purchase vendor – (VAR or Distributor field) 32

1 Brief descriptions of these roles are provided in section D.3 of this document. These lists are not exhaustive and may not include all roles that may be involved.

2 Not all data requirements listed for the Use Case are necessarily expected to be obtained from the Data Tag

3 May be made available through a post-inventory data service or data table provided by the vendor


o At time of sale 1

o Must be unique across all publishers and channels (resellers, distributors, etc.) 2

o Should be GS1 (UCC/ECCC) compliant 3

• Installation date 4

• Installation type 5

o Unaltered publisher supplied installer routine using media 6

o Unaltered publisher supplied installer routine via download 7

o End user derived installer routine (custom packaging) 8

o Duplication and distribution via Imaging technology 9

May require correlation with additional data tag values 10

• Installation Location Details (System) 11

o Machine/Host name 12

o IP address 13

o Mac address 14

o OS name and version 15

Alternately, a single unique software inventory item identifier could be provided with all other publisher 16 provided data values made available through a post-inventory data service. 17

D.4.4 Challenges 18

• Since the Software Tag is assumed to be implemented over time4, co-existence with current inventory 19 and associated product recognition technologies / content will increase complexity 20

• Some of these fields will be mandatory while some of them may be optional – success of the 21 reconciliation will be dependent on the amount and quality of information retrieved 22

• Software license models contrived by publishers that end user organizations cannot self-audit using 23 publisher provided or “common” commercial means should now be contestable in court and precluded 24 from publisher or 3rd party (external) audits 25

D.5 Scenario: electronic software distribution 26

Larger organizations with higher levels of ITAM program maturity often exercise significant electronic software 27 distribution (ESD) functionality. This generally involves standardized processes for internal packaging of 28 software products for distribution and installation, including base or “core” imaging, and the potential for 29 software product “builds” based on Business Unit (BU) or Line of Business (LOB) and/or functional staff roles. 30

D.5.1 Objectives 31

Minimize manual delivery and installation software products to: 32

• Reduce cost to purchase and support 33

• Reduce frequency of unauthorized installations 34

• Improve / speed customer support services 35

4 Publishers will adopt ISO 19770-2 over time, and it is anticipated that adherence will be applied to new product releases and optionally, new installer builds for previously released products. Some publishers, such as niche, vertical software developers and independents (especially Freeware and Open Source developers), may never adopt ISO 19770-2.


• Increase standardization of product installation and / or configuration 1

• Reduce cost and effort to support non-standardized installations 2

D.5.2 Functional roles involved 3


• Service Desk staff 5

• IMAC Technician 6


• System / Platform Manager 8

D.5.3 Requirements 5 9

For reporting and analysis, a number of data values for each software inventory item must present, retrievable 10 and standardized (normalized) as to consistently represent the appropriate information: 11

• Installation date 12

• Installation type 13

o Unaltered publisher supplied installer routine using media 14

o Unaltered publisher supplied installer routine via download 15

o End user derived installer routine (custom packaging) 16

o Duplication and distribution via Imaging technology 17

May require correlation with additional data tag values 18

• Packaging/Imaging technology employed 19

• Packager Identification (UserID, etc.) 20

• Packaging date 21

• Installer Identification (UserID, etc.) 22

• Organizational Asset Tag data 23

• Installation restrictions (location / country for export compliance, etc.) 24

D.5.4 Challenges 25

• Inconsistencies are likely to result from widely differing processes practiced by the innumerable 26 publishers, vendors, user organizations and individuals without firm guidance as to design, structure 27 and use 28

D.6 Scenario: migration planning 29

Organizations of all sizes have the periodic need to determine the effort and cost required to implement 30 migration from one Operating System version to a newer version or from one platform to another. 31

D.6.1 Objectives 32

Leverage Software Data Tag content to: 33

• Increase accuracy, completeness and speed of reporting (identification) and analysis of gathered data 34

5 Not all data requirements listed for the Use Case are necessarily expected to be obtained from the Data Tag. Requirements listed for previous Scenarios not specifically related to this Scenario have not been reiterated.



• IT Security staff 2

• Application / Software System Administrator 3


• System / Platform Manager 5


• Software item identifier 7

o Unique to each individually installable software component 8

Includes all forms “operational” software items, regardless of file type 9 (executables, dll files, Active X controls, other browser add-ons, etc.) 10

Excludes “non-operational” software items, such as .txt files 11

o Could be a combination of multiple unique identifiers, such Publisher ID + Product Family ID + 12 Version + Component ID 13

• Software Product “Systems Requirements” 14

o Must include both minimum and recommended hardware, OS and 3rd-party dependent / 15 subordinate software products / versions 16

• Software Product support status 17

o End-of-life date, etc. 18

• Software Product Upgrade path 19

o Replacement software product / version 20

D.6.4 Challenges 21

• The nature of the software environment to continually change after a given software product is 22 installed together with the unlikelihood that organizations will update content in installed Data Tags 23 consistently and in a timely manner will require a post-inventory service to provide complete, fully 24 updated migration information. 25

D.7 Scenario: patch management 26

Organizations learning of identified critical security risks with specific software require the means to quickly, 27 accurately and completely identify all installed instances of that software. A standardized Software Tag will 28 support those efforts and facilitate effective remediation with greater confidence than can be achieved given 29 the current, unstructured software environment. 30

D.7.1 Objectives 31

Leverage Software Data Tag content to: 32

• Increase accuracy, completeness and speed of reporting (identification) and remediation efforts 33


• IT Security staff 35

• Application / Software System Administrators 36




• System / Platform Managers 2


• Software item identifier 4

o Unique to each individually installable software component 5

Includes all forms “operational” software items, regardless of file type (executables, dll 6 files, Active X controls, other browser add-ons, etc.) 7

Excludes “non-operational” software items, such as .txt files 8

o Could be a combination of multiple unique identifiers, such Publisher ID + Product Family ID + 9 Version + Component ID 10

D.7.4 Challenges 11

• The sheer volume of potential software items may create a demand for a centrally administered 12 registration source for all software asset tags to ensure uniqueness within an organization. 13

D.8 Scenario: creating a unique software tag 14

While many software manufacturers will create software tags there will be those who opt not to implement 15 them. Organizations may choose to create their own Software Tag to facilitate the identification and 16 reconciliation of their software inventory. 17

D.8.1 Objectives 18

Leverage Software Tag methodology to: 19

• Assist in internal software asset management activities through increased accuracy, completeness 20 and speed of reporting (identification) 21

• Increase the accuracy of remediation efforts 22

• Facilitate in vendor reconciliation and audit requirements 23



• IMAC Technician 26


D.8.3 Requirements 28

• End user would need the ability to create the Software Asset tag 29

o This more than likely will require a tool 30

• The end user part of the tag would need the ability to include the vendor specific data 31

• End user would need to gather some of the same information that is provided in the vendor supplied 32 tags8 33


8 In order for the non-vendor issued Software Tag to be of benefit it is critical that information created follow the same proposed guidelines as those created by vendors following ISO 19770-2 recommendations.


D.8.4 Challenges 1

• For those end users that “package” the software for installation they would need the ability to create 2 the tag during the packaging process 3

• For those end users that do not “package” the software for installation they would need the ability to 4 create the tag during installation 5

6


Annex E 1 (normative) 2

3 XML schema definition (XSD) 4

The following XSD provides the definition for the software tag. This XSD file will be located at the following 5 location: 6 7

http://standards.iso.org/iso/19770/-2/2008/schema.xsd 8 9 Note that the location of the XSD as specified above is an expected location and is not yet confirmed. 10 11 12 <?xml version="1.0" encoding="UTF‐8"?> 13 <xs:schema elementFormDefault="qualified" 14 targetNamespace="http://standards.iso.org/iso/19770/‐2/2008/schema.xsd" 15 xmlns:sat="http://standards.iso.org/iso/19770/‐2/2008/schema.xsd" 16 xmlns:xs="http://www.w3.org/2001/XMLSchema"> 17 18 <!‐‐ Root tag ‐‐> 19 <xs:element name="software_asset_tag" type="sat:SoftwareAssetTagComplexType" /> 20 21 <!‐‐ Software Asset Tag structure definition ‐‐> 22 <xs:complexType name="SoftwareAssetTagComplexType"> 23 <xs:sequence> 24 <!‐‐ Mandatory Elements ‐‐> 25 <xs:element name="entitlement_required" type="xs:boolean" /> 26 <xs:element name="product_title" type="xs:token" /> 27 <xs:element name="product_version" type="sat:ProductVersionComplexType" /> 28 <xs:element name="software_manufacturer" type="sat:SoftwareManufacturerComplexType" /> 29 <xs:element name="software_id" type="sat:SoftwareIdComplexType" /> 30 31 <!‐‐ Optional Elements ‐‐> 32 <xs:element minOccurs="0" maxOccurs="unbounded" name="abstract" type="sat:AbstractComplexType" /> 33 <xs:element minOccurs="0" name="component_of" type="sat:ListOfSoftwareIdsComplexType" /> 34 <xs:element minOccurs="0" name="complex_of" type="sat:ListOfSoftwareIdsComplexType" /> 35 <xs:element minOccurs="0" name="data_source" type="xs:string" /> 36 <xs:element minOccurs="0" name="dependency" type="sat:ListOfSoftwareIdsComplexType" /> 37 <xs:element minOccurs="0" name="license_linkage" type="sat:LicenseLinkageComplexType" /> 38 <xs:element minOccurs="0" name="package_footprint" type="sat:PackageFootprintComplexType" /> 39 <xs:element minOccurs="0" name="packager" type="sat:PackagerComplexType" /> 40 <xs:element minOccurs="0" name="category" type="sat:CategoryComplexType" /> 41 <xs:element minOccurs="0" maxOccurs="unbounded" name="product_id" type="xs:token" /> 42 <xs:element minOccurs="0" name="release_date" type="xs:dateTime" /> 43 <xs:element minOccurs="0" name="release_id" type="xs:token" /> 44 <xs:element minOccurs="0" name="release_package" type="sat:ReleaseComplexType" /> 45 <xs:element minOccurs="0" name="release_rollout" type="sat:ReleaseComplexType" /> 46 <xs:element minOccurs="0" name="release_verification" type="sat:ReleaseComplexType" /> 47 <xs:element minOccurs="0" name="serial_number" type="xs:token" /> 48 <xs:element minOccurs="0" name="sku" type="xs:token" /> 49 <xs:element minOccurs="0" maxOccurs="unbounded" name="software_manufacturer_alias" 50 type="sat:SoftwareManufacturerAliasComplexType" /> 51 <xs:element minOccurs="0" name="supported_languages" type="sat:SupportedLanguagesComplexType" /> 52 <xs:element minOccurs="0" name="upgrade_for" type="sat:UpgradeForComplexType" /> 53 <xs:element minOccurs="0" maxOccurs="unbounded" name="usage" type="sat:UsageComplexType" /> 54 <xs:element minOccurs="0" name="validation" type="sat:ValidationComplexType"/> 55 56 <!‐‐Extended Information ‐‐> 57


<xs:element minOccurs="0" maxOccurs="unbounded" name="extended_information" 1 type="sat:ExtendedInformationComplexType" /> 2 </xs:sequence> 3 </xs:complexType> 4 5 <!‐‐ Mandatory Elements complex types ‐‐> 6 <xs:complexType name="ProductVersionComplexType"> 7 <xs:sequence> 8 <xs:element name="name" type="xs:token" /> 9 <xs:element name="numeric" type="sat:NumericVersionComplexType" /> 10 </xs:sequence> 11 </xs:complexType> 12 13 <xs:complexType name="SoftwareManufacturerComplexType"> 14 <xs:sequence> 15 <xs:element name="name" type="xs:token" /> 16 <xs:element name="guid" type="sat:GUIDType" /> 17 </xs:sequence> 18 </xs:complexType> 19 20 <xs:complexType name="SoftwareIdComplexType"> 21 <xs:sequence> 22 <xs:element name="unique_id" type="xs:token" /> 23 <xs:element name="software_manufacturer_domain" type="xs:token" /> 24 </xs:sequence> 25 </xs:complexType> 26 27 <!‐‐ Optional Elements complex types ‐‐> 28 <xs:complexType name="AbstractComplexType"> 29 <xs:simpleContent> 30 <xs:extension base="xs:string"> 31 <xs:attribute use="optional" default="en" name="lang" type="xs:token" /> 32 </xs:extension> 33 </xs:simpleContent> 34 </xs:complexType> 35 36 <xs:complexType name="ListOfSoftwareIdsComplexType"> 37 <xs:sequence> 38 <xs:element maxOccurs="unbounded" name="software_id" type="sat:SoftwareIdComplexType" /> 39 </xs:sequence> 40 </xs:complexType> 41 42 <xs:complexType name="LicenseLinkageComplexType"> 43 <xs:sequence> 44 <xs:element name="activation_status" type="xs:string" /> 45 <xs:element minOccurs="0" maxOccurs="unbounded" name="channel_type" type="xs:string" /> 46 <xs:element minOccurs="0" maxOccurs="unbounded" name="customer_type" type="xs:string" /> 47 </xs:sequence> 48 </xs:complexType> 49 50 <xs:complexType name="PackageFootprintComplexType"> 51 <xs:choice> 52 <xs:element name="external_description" type="xs:anyURI" /> 53 <xs:sequence> 54 <xs:element minOccurs="0" name="primary" type="sat:PackageFootprintModuleComplexType" /> 55 <xs:element minOccurs="0" name="secondary" type="sat:PackageFootprintModuleComplexType" /> 56 <xs:element minOccurs="0" name="other" type="sat:PackageFootprintModuleComplexType" /> 57 </xs:sequence> 58 </xs:choice> 59 </xs:complexType> 60 61 <xs:complexType name="PackageFootprintModuleComplexType"> 62 <xs:choice> 63


<xs:element name="referenced" type="xs:anyURI" /> 1 <xs:sequence> 2 <xs:element minOccurs="0" maxOccurs="unbounded" name="file" type="sat:PackageFootprintFileComplexType" /> 3 <xs:element minOccurs="0" maxOccurs="unbounded" name="registry" type="sat:PackageFootprintRegistryComplexType" /> 4 <xs:element minOccurs="0" maxOccurs="unbounded" name="other" type="sat:PackageFootprintOtherComplexType" /> 5 </xs:sequence> 6 </xs:choice> 7 </xs:complexType> 8 9 <xs:complexType name="PackageFootprintFileComplexType"> 10 <xs:sequence> 11 <xs:element name="name" type="xs:token" /> 12 <xs:element minOccurs="0" maxOccurs="unbounded" name="size" type="xs:unsignedLong" /> 13 <xs:element minOccurs="0" maxOccurs="unbounded" name="md5" type="sat:MD5" /> 14 <xs:element minOccurs="0" maxOccurs="unbounded" name="version" type="xs:token" /> 15 <xs:element minOccurs="0" maxOccurs="unbounded" name="other" type="sat:PackageFootprintOtherParamComplexType" /> 16 </xs:sequence> 17 </xs:complexType> 18 19 <xs:complexType name="PackageFootprintRegistryComplexType"> 20 <xs:sequence> 21 <xs:element name="path" type="xs:token" /> 22 <xs:element minOccurs="0" name="value" type="xs:string" /> 23 </xs:sequence> 24 </xs:complexType> 25 26 <xs:complexType name="PackageFootprintOtherComplexType"> 27 <xs:sequence> 28 <xs:element maxOccurs="unbounded" name="param" type="sat:PackageFootprintOtherParamComplexType" /> 29 </xs:sequence> 30 <xs:attribute name="type" type="xs:token" use="required" /> 31 </xs:complexType> 32 33 <xs:complexType name="PackageFootprintOtherParamComplexType"> 34 <xs:simpleContent> 35 <xs:extension base="xs:string"> 36 <xs:attribute name="name" type="xs:token" use="required" /> 37 </xs:extension> 38 </xs:simpleContent> 39 </xs:complexType> 40 41 <xs:complexType name="PackagerComplexType"> 42 <xs:sequence> 43 <xs:element name="by" type="xs:string" /> 44 <xs:element name="part" type="xs:string" /> 45 </xs:sequence> 46 </xs:complexType> 47 48 <xs:complexType name="CategoryComplexType"> 49 <xs:sequence> 50 <xs:element name="UNSPSC_ver" type="xs:token" /> 51 <xs:element name="segment_title" type="xs:string" /> 52 <xs:element name="family_title" type="xs:string" /> 53 <xs:element name="class_title" type="xs:string" /> 54 <xs:element name="commodity_title" type="xs:string" /> 55 <xs:element name="code" type="sat:UnspscIdType" /> 56 </xs:sequence> 57 </xs:complexType> 58 59 <xs:complexType name="ReleaseComplexType"> 60 <xs:sequence> 61 <xs:element name="signoff" type="xs:string" /> 62 <xs:element name="signoff_date" type="xs:dateTime" /> 63


<xs:element name="by" type="xs:string" /> 1 </xs:sequence> 2 </xs:complexType> 3 4 <xs:complexType name="SoftwareManufacturerAliasComplexType"> 5 <xs:sequence> 6 <xs:element name="name" type="xs:token" /> 7 <xs:element minOccurs="0" name="guid" type="sat:GUIDType" /> 8 </xs:sequence> 9 </xs:complexType> 10 11 <xs:complexType name="UpgradeForComplexType"> 12 <xs:sequence> 13 <xs:element maxOccurs="unbounded" name="upgrade_id" type="sat:SoftwareIdComplexType" /> 14 <xs:element minOccurs="0" name="upgrade_description" type="xs:string" /> 15 </xs:sequence> 16 </xs:complexType> 17 18 <xs:complexType name="UsageComplexType"> 19 <xs:sequence> 20 <xs:element minOccurs="0" maxOccurs="unbounded" name="filename" type="xs:string" /> 21 <xs:element minOccurs="0" maxOccurs="unbounded" name="processname" type="xs:string" /> 22 <xs:element minOccurs="0" maxOccurs="unbounded" name="URI" type="xs:anyURI" /> 23 </xs:sequence> 24 </xs:complexType> 25 26 <xs:complexType name="SupportedLanguagesComplexType"> 27 <xs:sequence> 28 <xs:element maxOccurs="unbounded" name="language" type="xs:token" /> 29 </xs:sequence> 30 </xs:complexType> 31 32 <xs:complexType name="ValidationComplexType"> 33 <xs:sequence> 34 <xs:element name="validation_call" type="xs:string" /> 35 <xs:element minOccurs="0" name="last_validated_by" type="xs:string" /> 36 <xs:element minOccurs="0" name="last_validated_date" type="xs:dateTime" /> 37 <xs:element minOccurs="0" name="last_validated_result" type="xs:boolean" /> 38 </xs:sequence> 39 </xs:complexType> 40 41 <!‐‐ Extended Information type definition ‐‐> 42 <xs:complexType name="ExtendedInformationComplexType"> 43 <xs:sequence> 44 <xs:any minOccurs="0" maxOccurs="unbounded" /> 45 </xs:sequence> 46 </xs:complexType> 47 48 <!‐‐ Other complex types ‐‐> 49 <xs:complexType name="NumericVersionComplexType"> 50 <xs:sequence> 51 <xs:element name="major" type="xs:unsignedInt" /> 52 <xs:element name="minor" type="xs:unsignedInt" /> 53 <xs:element name="build" type="xs:unsignedInt" /> 54 <xs:element name="review" type="xs:unsignedInt" /> 55 </xs:sequence> 56 </xs:complexType> 57 58 <xs:simpleType name="GUIDType"> 59 <xs:restriction base="xs:string"> 60 <xs:pattern value="[0‐9a‐fA‐F]{8}‐[0‐9a‐fA‐F]{4}‐[0‐9a‐fA‐F]{4}‐[0‐9a‐fA‐F]{4}‐[0‐9a‐fA‐F]{12}" /> 61 </xs:restriction> 62 </xs:simpleType> 63


1 <xs:simpleType name="UnspscIdType"> 2 <xs:restriction base="xs:unsignedLong"> 3 <xs:pattern value="[0‐9]{10}" /> 4 </xs:restriction> 5 </xs:simpleType> 6 7 <xs:simpleType name="MD5"> 8 <xs:restriction base="xs:hexBinary"> 9 <xs:length value="16" /> 10 </xs:restriction> 11 </xs:simpleType> 12 </xs:schema> 13


Annex F 1 (informative) 2

3 Extended examples 4

The following example is provided for informational purposes only. The actual values provided in the tag 5 sample are fictitious and should not be utilized for any production purposes. 6

7 <?xml version="1.0" encoding="UTF-8"?> 8 9 <sat:software_asset_tag 10 xmlns:sat="http://standards.iso.org/iso/19770/-2/2008/schema.xsd" 11 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 12 xsi:schemaLocation="http://standards.iso.org/iso/19770/-2/2008 schema.xsd http://standards.iso.org/iso/19770/-13 2/2008/schema.xsd "> 14 15  16 <sat:entitlement_required>true</sat:entitlement_required> 17 <sat:product_title>Adobe Photoshop CS3</sat:product_title> 18 <sat:product_version> 19 <sat:name>10.2</sat:name> 20 <sat:numeric> 21 <sat:major>10</sat:major> 22 <sat:minor>2</sat:minor> 23 <sat:build>0</sat:build> 24 <sat:review>0</sat:review> 25 </sat:numeric> 26 </sat:product_version> 27 <sat:software_manufacturer> 28 <sat:name>Adobe Systems Incorporated</sat:name> 29 <sat:guid>ADBEADBE-ADBE-ADBE-ADBE-ADBEADBEADBE</sat:guid> 30 </sat:software_manufacturer> 31 <sat:software_id> 32 <sat:unique_id>Photoshop-CS3-Win-GM-en_US</sat:unique_id> 33 <sat:software_manufacturer_domain>http://www.adobe.com</sat:software_manufacturer_domain> 34 </sat:software_id> 35 36  37 <sat:license_linkage> 38 <sat:activation_status>Licensed</sat:activation_status> 39 <sat:channel_type>Retail</sat:channel_type> 40 <sat:customer_type>Retail</sat:customer_type> 41 </sat:license_linkage> 42 <sat:serial_number>970787542600909445599756</sat:serial_number> 43 <sat:supported_languages> 44 <sat:language>eng</sat:language> 45 </sat:supported_languages> 46  47 <sat:extended_information> 48 <exti:install_state xmlns:exti="http://www.adobe.com/AdobeExtendedInfo.xsd" 49 xsi:schemaLocation="http://www.adobe.com/AdobeExtendedInfo.xsd http://www.adobe.com/AdobeExtendedInfo.xsd 50 ">Installed</exti:install_state> 51 </sat:extended_information> 52 </sat:software_asset_tag> 53 54

55 Example 1.0: Adobe Photoshop CS3 56

<?xml version="1.0" encoding="UTF-8"?> 57 <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" 58


targetNamespace="http://www.adobe.com/AdobeExtendedInfo.xsd" elementFormDefault="qualified" 1 attributeFormDefault="unqualified"> 2 <xs:element name="install_state" type="xs:string"/> 3 </xs:schema> 4

5 Example 1.1: XSD defined for Adobe Photoshop CS3 extended information 6

7

<?xml version="1.0" encoding="UTF-8"?> 8 <sat:software_asset_tag xmlns:sat="http://standards.iso.org/iso/19770/-2/2008/software_asset_tag.xsd" 9 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://standards.iso.org/iso/19770/-10 2/2008/software_asset_tag.xsd http://standards.iso.org/iso/19770/-2/2008/software_asset_tag.xsd "> 11  12 <sat:entitlement_required>false</sat:entitlement_required> 13 <sat:product_title>Firefox</sat:product_title> 14 <sat:product_version> 15 <sat:name>2.0.0.10</sat:name> 16 <sat:numeric> 17 <sat:major>2</sat:major> 18 <sat:minor>0</sat:minor> 19 <sat:build>0</sat:build> 20 <sat:review>10</sat:review> 21 </sat:numeric> 22 </sat:product_version> 23 <sat:software_manufacturer> 24 <sat:name>Mozilla Corporation</sat:name> 25 <sat:guid>01234567-89ab-cdef-0123-456789abcdef</sat:guid> 26 </sat:software_manufacturer> 27 <sat:software_id> 28 <sat:unique_id>firefox.2.0.0.10</sat:unique_id> 29 <sat:software_manufacturer_domain>com.mozilla</sat:software_manufacturer_domain> 30 </sat:software_id> 31 32  33 <sat:abstract lang="en">Mozilla Corporation's flagship browser.</sat:abstract> 34 <sat:data_source>Electronic distribution</sat:data_source> 35 <sat:license_linkage> 36 <sat:activation_status>Fully licensed</sat:activation_status> 37 <sat:channel_type>Internet</sat:channel_type> 38 <sat:customer_type>End user</sat:customer_type> 39 </sat:license_linkage> 40 <sat:category> 41 <sat:UNSPSC_ver>10.0501</sat:UNSPSC_ver> 42 <sat:segment_title>Information Technology Broadcasting and Telecommunications </sat:segment_title> 43 <sat:family_title>Software </sat:family_title> 44 <sat:class_title>Network applications software </sat:class_title> 45 <sat:commodity_title>Internet browser software </sat:commodity_title> 46 <sat:code>4323270500</sat:code> 47 </sat:category> 48 49 </sat:software_asset_tag> 50 51

52 Example 2: Mozilla Firefox 53

54


Bibliography 1

[1] ISO/IEC 19770-1:2006, Information technology — Software asset management — Part 1: Processes 2

[2] ISO/IEC 20000-1:2005, Information technology service management, Part 1: Specification for 3 information technology service management 4

[3] ISI/IEC 20000-2:2005, Information technology service management, Part 2: Code of practice for 5 information technology service management 6

[4] ISO/IEC 25051:2006, Software engineering -- Software product Quality Requirements and Evaluation 7 (SQuaRE) -- Requirements for quality of Commercial Off-The-Shelf (COTS) software product and 8 instructions for testing 9

[5] IETF RFC 3986, Uniform Resource Identifier (URI): Generic Syntax 10

[6] IETF RFC 4646, Tags for Identifying Languages 11

[7] IETF RFC 4647, Matching of Language Types 12

[8] W3C Recommendation, XML-Signature Syntax and Processing 13

[9] W3C Recommedation, XML Schema Part 2: Datatypes Second Edition 14

[10] UNSPSC, The United Nationss Standard Products and Services Code 15

Documents

Secretariat: CANADA (SCC) - ISO/IEC JTC1/SC7 …jtc1-sc7.logti.etsmtl.ca/N3951-N4000/07N3972 ISO-IEC 19770-2 Public...ISO/IEC JTC1/SC7 Software and Systems Engineering Secretariat: