PCI Watch

Tracking changes across the Payment Card Industry

SB nº 175: Application Selection Registered Proprietary Data (Spec Change)

v1.0 Specification Bulletins
ContactContactless

EMV® Specification Bulletin No. 175 First Edition February 2016 Application Selection Registered Proprietary Data This Specification Bulletin introduces a new EMV data object for contact and contactless.

Applicability

This Specification Bulletin applies to:  EMV Integrated Circuit Card Specifications for Payment Systems Version 4.3 Book 1  EMV Integrated Circuit Card Specifications for Payment Systems Version 4.3 Book 3  EMV Contactless Book A: Architecture and General Requirements  EMV Contactless Book B: Entry Point Specification

Related Documents

  • None

Effective Date

  • February 2016

Description

In certain circumstances, markets require proprietary terminal functionality based on card proprietary data. For instance, a terminal in a specific market may be required by a local regulatory authority to offer specific services based on this information. This proprietary functionality is beyond the scope of EMVCo. Possibilities exist to use Payment System specific or Issuer specific data objects on the card but these solutions have limitations and, if not carefully implemented, may present risks of interoperability issues. This Specification Update Bulletin introduces a new data object with a tag in the EMVCo reserved range. The definition is therefore governed by EMVCo. However, the intention is to allow for proprietary use of the data object. This Specification Update Bulletin defines the rules that shall be respected if this new data object is to be used. Following these rules is essential to ensure that independent solutions use the same data object without clashes.

countries.

Specification Change Notice Application Selection Registered Proprietary Data The Application Selection Registered Proprietary Data is a variable length data object with binary format and tag ‘9F0A’. It is governed by EMVCo (EMVCo reserves the right to assign new IDs) and its source is the ICC. The value field of the Application Selection Registered Proprietary Data object follows the following format: ID1, L1, V1, ID2, L2, V2,… Where

  • ID is a two byte Proprietary Data Identifier. Proprietary Data Identifiers are registered by EMVCo, and the ID registration process will be defined by EMVCo in a subsequent bulletin.
  • L is the length of the value field coded in 1 byte (0 to 255)
  • V is the value field. Its content is proprietary and format is out of scope of EMVCo The Application Selection Registered Proprietary Data is a primitive data object and its value field is not BER-TLV coded. In particular:
  • IDs have no structure (they are not tags according to BER-TLV coding)
  • The lengths L are always 1 byte IDs can appear in the Application Selection Registered Proprietary Data only if:
  • they have been registered by EMVCo
  • their usage by the Terminal/Kernel is according to their intended usage, as agreed by EMVCo during registration Following these rules ensures that a single ID would not be used for different purposes, preventing potential interoperability issues. Ideally, the value field corresponding to a Proprietary Data Identifier should be short, so that several different Proprietary Data Identifiers may appear in the Application Selection Registered Proprietary Data data object. However, no maximum length is defined other than that imposed by the 1 byte length. Location The Application Selection Registered Proprietary Data is an optional primitive data object that may be returned by the ICC during Application Selection. For contact, it may be present:
  • In the Directory Discretionary data (tag ‘73’) within any ADF Directory Entry,
  • AND/OR in the FCI Issuer Directory Discretionary data (tag ‘BF0C’) within the FCI of any ADF For contactless, it may be present:
  • In any Directory Entry (tag ‘61’) within the FCI of the PPSE,
  • AND/OR in the FCI Issuer Directory Discretionary data (tag ‘BF0C’) within the FCI of any ADF countries. Terminal behaviour Usage of the Application Selection Registered Proprietary Data received from the ICC is optional and proprietary. Terminal/Kernel not supporting the Application Selection Registered Proprietary Data When parsing a BER-TLV encoded response from the ICC, Terminal/Kernel may encounter the Application Selection Registered Proprietary Data.
  • Terminal/Kernel SHALL ignore the Application Selection Registered Proprietary Data and continue processing as if the data was not present.
  • Terminal/Kernel SHALL NOT check for any consistency between the various instances of the Application Selection Registered Proprietary Data that may be encountered during application selection processes. Note that this is the expected behaviour of Terminal/Kernel for unrecognized data objects and it is anticipated that this Specification Update Bulletin introduces no change to Terminal/Kernel if they are not supporting the Application Selection Registered Proprietary Data. Terminal/Kernel supporting the Application Selection Registered Proprietary Data When parsing a BER-TLV encoded response from the ICC, Terminal/Kernel may encounter the Application Selection Registered Proprietary Data. If the Application Selection Registered Proprietary Data is present in a field identified in the Location section above, the Terminal/Kernel interprets the value field to recover all the Proprietary Data Identifiers:
  • If the value field of the Application Selection Registered Proprietary Data is not correctly formatted (ID L V, ID L V, … as defined in the Application Selection Registered Proprietary Data section above), then the Terminal/Kernel SHALL ignore this instance of the Application Selection Registered Proprietary Data and continue processing as if the data was not present. Note that no assumption can be made on the IDs already registered by EMVCo nor on the format of the value fields of the Proprietary Data Identifiers and as a consequence the value field of the Application Selection Registered Proprietary Data is considered to be incorrectly formatted only if a length problem is detected.
  • If the value field is correctly formatted, proprietary functionality may be activated for the recognized Proprietary Data Identifiers.
  • Terminal/Kernel are not required to keep track of the Proprietary Data Identifiers defined by EMVCo, therefore unrecognized Proprietary Data Identifiers are ignored Different values may be used for the different instances. In particular, different values for the same Proprietary Data Identifier may be present in the different instances of the Application Selection Registered Proprietary Data recovered by the Terminal/Kernel, even if these instances are linked to the same ADF (e.g. an instance in the Directory Discretionary Data within an ADF Directory Entry and another instance in the FCI Issuer Directory Discretionary Data within the FCI of the same ADF). countries.

Legal Notice

The EMV® Specifications are provided “AS IS” without warranties of any kind, and EMVCo neither assumes nor accepts any liability for any errors or omissions contained in these Specifications. EMVCO DISCLAIMS ALL REPRESENTATIONS AND WARRANTIES, EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT, AS TO THESE SPECIFICATIONS. EMVCo makes no representations or warranties with respect to intellectual property rights of any third parties in or in relation to the Specifications. EMVCo undertakes no responsibility to determine whether any implementation of the EMV® Specifications may violate, infringe, or otherwise exercise the patent, copyright, trademark, trade secret, know-how, or other intellectual property rights of third parties, and thus any person who implements any part of the EMV® Specifications should consult an intellectual property attorney before any such implementation. Without limiting the foregoing, the Specifications may provide for the use of public key encryption and other technology, which may be the subject matter of patents in several countries. Any party seeking to implement these Specifications is solely responsible for determining whether its activities require a license to any such technology, including for patents on public key encryption technology. EMVCo shall not be liable under any theory for any party’s infringement of any intellectual property rights in connection with the EMV® Specifications

countries.