Previous section.

Systems Management: Software License Use Management (XSLM)
Copyright © 1999 The Open Group

License Certificate Format

The primary purpose of a license certificate is to encode the terms and conditions contained within a license agreement in a machine-readable representation. In addition, a license certificate may also contain certain management-related information that is not directly included within the license agreement, such as designations of specific users that may use a product; whether exceeding the available number of concurrent uses should result in rejection of further license requests; and so on.

The license certificate format is such that an external license certificate can be created in an environment different from that where the license certificate will be installed, and different from the environment where the licensed application will be running. There is not even any requirement that the tools used to create a license certificate and to install it into a license server are provided by the same publisher. The only requirement is that the tools used by publishers and customers both can create and accept the same external representation.

A license certificate issuer may deliver a license certificate to a customer in many different ways, for example as a binary file on a diskette; as a binary-file attachment via electronic mail; or as a textual representation (for example, by displaying each binary byte of data as two hexadecimal characters) via fax. Some publishers may choose to include a limited-function license certificate on the shipping media for a product; others may require the customer to contact the publisher to receive a license certificate. Any such delivery mechanism is acceptable. However, all compliant license servers must be able to process a license certificate as a pure binary file, as described in this chapter.

A license certificate may contain security and integrity data (such as a digital signature) to ensure that any tampering is detectable by the licensing system, or directly by the application when it requests a license.

This chapter specifies the format of a license certificate and defines how application and licensing system publishers can define their own, private, data elements. Data Elements contains a list of all predefined data elements, both required and optional ones.

Overall Certificate Structure

In its simplest form, a license certificate consists of a compound data element (as described in Data Elements) containing one or more sections, each in turn made up of one or more simple and/or compound data elements. Some of these predefined data elements are required, while others are optional. In addition, both application publishers and licensing system publishers can define their own custom data elements within special sections. However, it's also possible to combine several independent certificates in one certificate group, for example when licensing several products together in a bundle or suite. License Certificate Structure shows the overall structure of a certificate (the detailed definition is given in Data Elements).

GROUP_CERTIFICATE GROUP_TYPE CERTIFICATE_LIST CERTIFICATE BASE_SECTION PUBLISHER_SECTION LICENSING_SYSTEM_SECTION_LIST LICENSING_SYSTEM_SECTION AUTHENTICATION_SECTION GROUP_AUTHENTICATION_SECTION A certificate group consists of one or more related certificates (if there's only one certificate, the group element may be omitted). Each certificate contains a required base section, may have an application-publisher-defined section and/or one or more licensing system-dependent sections, and/or an authentication section. Finally, the certificate group (if present) must have its own authentication section.
BASE_SECTION FUNCTIONAL_LEVEL CERTIFICATE_CREATED CERTIFICATE_ID CERTIFICATE_DESCRIPTION PUBLISHER_USE REPLACE_CERTIFICATE LIFE DURATION LICENSED_UNITS PUBLISHER_CAPACITY_LIMITS_LIST PUBLISHER_ASSIGNMENTS_LIST CERTIFICATE_TARGET_NODES CUSTOMER_ASSIGNABLE_LIMITS COUNTERS_CONSUMPTIVE COUNTERS_CUMULATIVE CONFIRM_INTERVAL NON_MASKABLE_EVENTS RESETTING_FREQUENCY LOCALLY_AVAILABLE DEFAULT_UNITS_TO_GRANT FORCE_RELEASE_OK ADVANCE_EXPIRATION_NOTIFICATION DISASTER_RECOVERY MULTI_USE_ALLOWED The base section contains all the data elements normally used for granting license requests. Of particular importance are CERTYIFICATE_ID whose components uniquely identify a particular certificate; REPLACE_CERTIFICATE which allows an already installed certificate to be replaced with an updated one; LIFE and DURATION which define the date/time interval during which the certificate is valid; and UNITS which specifies the number of license units (for example, number of concurrent users of an application, or how many times an application may be executed).

The remaining components further qualify and quantify how license request can be granted from this certificate, and also define such items as the counters used for application-initiated metering; control of which events must be logged; and some management-related elements such as whether the customer may make use of this certificate in a disaster recovery situation.

Table: License Certificate Structure

Required and Optional License Certificate Sections

The base section contains all data elements that are required within a certificate, as well as the data elements that are optional but for which the certificate issuer wants to specify values. This section is required.

The publisher section contains data elements that the certificate issuer has defined for use directly by the application. These data elements are not understood by the licensing system; the only processing it will perform on this section is to store it and make it available to an application upon request. This section is optional.

The licensing system sections contain settings for data elements defined by a particular licensing system publisher. These data elements are only understood by the licensing system that defines them. A certificate that contains licensing system sections may only be installed on a licensing system that understands one of the licensing system sections. This section is optional, and there may be more than one such section (but at most one for each unique licensing system).

One possible use of a licensing system section is to encapsulate the complete license password and data pertaining to a license managed by a technical license manager, thus providing a way to provide some management capabilities also for such licenses without requiring major changes to their format.

Finally, an authentication section may optionally be part of each certificate as well as of the group of certificates, to ensure that the data created by the certificate issuer is unaltered when it reaches the licensing system and, eventually, the licensed application.

License Certificate State Data

In addition to the data contained within a license certificate, each licensing system must maintain some license certificate-related data that, while not physically part of a license certificate, logically can be seen as belonging to it. This includes the following types of data:

These types of data can be considered collected into a state section. The status section is not part of the certificate as created by a certificate issuer - it exists only within the data maintained by a licensing system and its contents is made available externally via the management API.

Base and Optional Data Element Sets

The certificate data elements defined in this specification are arranged in sets. The basic set contains all data elements that must be supported by all compliant licensing systems. Other sets contain data elements that need not be supported by all licensing systems. However, any licensing system that supports one data element within a particular set must also support all other data elements within that set. (The current specification defines the basic set and one optional set.)

A certificate that contains data elements defined in one or more optional sets can only be installed in a licensing system that supports all those sets.


Why not acquire a nicely bound hard copy?
Click here to return to the publication details or order a copy of this publication.

Contents Next section Index