Examples of object identifiers and tag allocation schemes

A.1 Object identifiers

For ISO standards, the first byte is ’28′, i.e., 40 in decimal (see ISO/IEC 8825-1). One or more series of bytes follow; bit 8 is set to 0 in the last byte of a series and to 1 in the previous bytes, if there is more than one byte. The concatenation of bits 7 to 1 of the bytes of a series encodes a number. Each number shall be encoded on the fewest possible bytes, that is, the value ’80′ is invalid for the first byte of a series. The first number is the number of the standard; the second number, if present, is the part in a multi-part standard.

As a first example, {iso(1) standard(0) ic-cards(7816)} references ISO/IEC 7816. ⎯ 7816 is equal to ’1E88′, i.e., 0001 1110 1000 1000, i.e., two blocks of seven bits: 0111101 0001000. ⎯ After insertion of the appropriate value of bit 8 in each byte, the encoding of the first series is therefore

1011 1101 0000 1000, equal to ‘BD08′.

The data element ’28 BD08′ may be used in AIDs of standard category. AID = ‘E8 28 BD08 0B XX … XX’ (ISO/IEC 7816-11 specifies the application identifier extension ‘XX … XX’). AID = ‘E8 28 BD08 0F XX … XX’ (ISO/IEC 7816-15 specifies the application identifier extension ‘XX … XX’).

As a second example, {iso(1) standard(0) e-auth(9798) part(5)} references ISO 9798-5[8]. The first series is obtained as follows. ⎯ 9798 is equal to ’2646′, i.e., 0010 0110 0100 0110, i.e., two blocks of seven bits: 1001100 1000110. ⎯ After insertion of the appropriate value of bit 8 in each byte, the encoding of the first series is therefore 11001100 01000110, equal to ‘CC46′.

The data element ’28 CC46 05 02′ references the second mechanism in ISO/IEC 9798-5[8], i.e., GQ2. Such an identifier may be conveyed in a data object (tag ’06′, universal class, see ISO/IEC 8825-1). DO = {’06 05 28 CC 46 05 02′}

As a third example, {iso(1) standard(0) mess(9992) part(2)} references ISO 9992-2[10]. The first series is obtained as follows. ⎯ 9992 is equal to ’2708′, i.e., 0010 0111 0000 1000, i.e., two blocks of seven bits: 1001110 0001000. ⎯ After insertion of the appropriate value of bit 8 in each byte, the encoding of the first series is therefore 1100 1110 0000 1000, equal to ‘CE08′.

The data element is ’28 CE08 02′ (the second series is ’02′). It may be conveyed in a data object. DO = {’06 04 28 CE 08 02′}

A.2 Tag allocation schemes

Example of default tag allocation scheme

DO1 = {’59 02 95 02′}

DO2 = {’5F 24 03 97 03 31′}

DO1 (tag ’59′, card expiration date) encodes February 1995 as card expiration date (see ISO/IEC 7816-6).

DO2 (tag ’5F24′, application expiration date) encodes March 31st 1997 as application expiration date.

 

Example of compatible tag allocation scheme

DO1 = {’78 06′ {’06 04 28 CE 08 02′}}

DO2 = {’5F 24 03 97 03 31′}

DO3 = {’70 04′ {’80 02 XX XX’}}

DO4 = {’67 0A’ {’5F 29 03 XX XX XX’} {’81 02 XX XX’}}

DO1 (tag ’78′, compatible tag allocation authority) indicates a compatible tag allocation scheme defined in ISO 9992-2[10] referenced by its object identifier. If DO1 appears either in the initial data string, or in EF.ATR, then the tag allocation authority is valid for the entire card. If DO1 appears in the management data of a DF , then the tag allocation authority is valid within that DF.

DO2 (tag ’5F24′, application expiration date) encodes March 31st 1997 as application expiration date.

DO3 (tag ’70′, interindustry template according to the included tag allocation authority) contains a data object, tag ’80′, defined in ISO 9992-2[10]; the meaning of tag ’70′ is also defined in ISO 9992-2[10].

DO4 (tag ’67′, authentication data template) contains the interchange profile data object, tag ’5F29′, and a data object, tag ’81′, defined in ISO 9992-2[10]; the meaning of tag ’67′ is defined in ISO/IEC 7816-6[4].

Another example of compatible tag allocation scheme

DO2 = {’5F 24 03 97 03 31′}

DO3 = {’70 0C’ {’06 04 28 CE 08 02′} {’80 04 XX XX XX XX’}}

DO4 = {’67 06′ {’5F 29 03 XX XX XX’}}

DO2 (tag ’5F24′, application expiration date) encodes March 31st 1997 as application expiration date.

DO3 (tag ’70′, interindustry template defined according to the included object identifier) contains a data object, tag ’06′, which specifies that the subsequent data object, tag ’80′, is defined in ISO 9992-2[10]. The meaning of tag ’70′ is also defined in ISO 9992-2[10].

DO4 (tag ’67′, interindustry authentication data template) contains the interchange profile data object, tag ’5F29′. Note that it cannot contain data objects defined in ISO 9992-2[10], because of the choice not to transmit the interindustry data object with tag ’78′.

Example of coexistent tag allocation scheme

DO1 = {’79 05′ {’06 03 28 XX XX’}}

DO2 = {’7E 06′ {’5F 24 03 97 03 31′}}

DO3 = {’70 06′ {‘XX XX XX XX XX XX’}}

DO1 (tag ’79′, coexistent tag allocation authority) indicates a coexistent tag allocation scheme defined in a standard referenced by an object identifier starting with ’28′, therefore an ISO standard. Mandatory in such a scheme, DO1 shall appear either

 in the initial data stringor in EF.ATR if the tag allocation authority is valid for the entire card, or

 in the management data of a DF if the tag allocation authority is valid within that DF.

DO2 (tag ’7E’) is an interindustry template for nesting interindustry data objects. Note that the interindustry data object “application expiration date”, tag ’5F24′, is present, encoding March 31st 1997 as application expiration date.

DO3 (tag ’70′, interindustry template to be interpreted according to the tag allocation authority indicated in template ’79′) can only be interpreted according to the standard indicated in the object identifier