PCI Watch

Tracking changes across the Payment Card Industry

SB nº 166: Clarifications and Specification Changes to Application Activation User Interface (Spec Change)

v2.0 Specification Bulletins
Mobile NFC Consumer Device

Specification Bulletin No. 166 Second Edition March 2016 Clarifications and Specification Changes to Application Activation User Interface This Specification Bulletin: 1. Corrects Lc and Le coding for GET TEMPLATE and SET MODE commands 2. Clarifies that the PPSE application is not selectable over multiple channels simultaneously 3. Addresses priority change and Application Discretionary Data change notifications in Internal Mode 4. Requires immediate FCI initialisation when PPSE is set for Internal Mode 5. Clarifies that the PPSE may reference non-payment applications 6. Recognizes the option for the PPSE to wake up the AAUI 7. Adapts the SET STATUS command to GlobalPlatform capabilities 8. Indicates how the PPSE application shall truncate its FCI when too many applications are active 9. Clarifies that the support of GET TEMPLATE command is mandatory when PPSE is configured for Internal Mode. Note: The Second Edition of this Bulletin:

  • Clarifies the expected behaviour for the PPSE configured in Internal Mode when Volatile Priority is set and reset. In particular, it differentiates the behaviour for Payment and Non-Payment applications (see Section 3)
  • Addresses Application Discretionary Data change notifications in Internal Mode (see Section 3)
  • Defines a minimum number of supported Directory Entries for the PPSE configured in Internal Mode (see Section 8)

Applicability

This Specification Bulletin applies to:

  • EMVCo Contactless Mobile Payment – Application Activation User Interface – Version 1.0 – December 2010

Related Documents

  • ISO/IEC 7816-4: Identification Cards - Integrated Circuit Cards - Part 4: Organization, security and commands for interchange
  • GlobalPlatform Card Specification v2.2 Amendment C v1.1.1 - July 2014 - Contactless Services

Effective Date

  • November 1st, 2016 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.

1. Corrections to Lc and Le coding for GET TEMPLATE and SET MODE Commands According to ISO/IEC 7816-4, the presence of the Lc byte in a C-APDU is conditioned by the presence of a Command data field. Likewise, the presence of the Le byte in a command APDU is conditioned by the expected presence of a Response data field in the R-APDU. This Specification Change affects the following in the AAUI document:

  • Table B.18 (GET TEMPLATE Command Message), the value for the Lc byte changes from '00' to Absent
  • Table B.21 (SET MODE Command Message), the value for the Lc byte changes from '00' to Absent
  • Table B.21 (SET MODE Command Message), the value for the Le byte changes from '00' to Absent countries. 2. Selection of the PPSE application To prevent that the PPSE returns inaccurate information to a contactless payment terminal while the User Interface is in the process of updating its template, the PPSE application shall not support multiple selections simultaneously. User interface applications in the Mobile Device are expected to release the connection with the PPSE application once they have completed their processing with the PPSE, so as to enable subsequent selection of the PPSE by a contactless payment terminal. This Specification Change affects the following in the AAUI document:
  • , section B.3.1, the following paragraph is added after the section title and before the description of Command Data: "The PPSE hosted in a Secure Element can be selected over the Device Interface as well as over the Antenna Interface. However, the PPSE shall not support multiple selections simultaneously to guaranty an atomic session processing to the User interface application and to the contactless payment reader. User interface applications in the Mobile Device are thus requested to close the connection with the PPSE application as soon as they have completed their processing with PPSE even if the User interface application is still processing other functions, so as to release the PPSE for subsequent selection by a contactless reader or another User interface application."
  • , requirement B.3.1.1 shall be replaced with the following: "If a SELECT command is received over the device interface, then if the PPSE is not currently selected on another channel over the device or antenna interface then the PPSE response, constructed as specified in Table B.10 on , SHALL be returned else the SELECT command SHALL be rejected with an error Status Word1."
  • , the following is appended after requirement B3.1.3 "

Requirement

B.3.1.4 applies to the Select command when received over the antenna interface only and applies to both Internal and External Modes. Requirements – SELECT Command – Antenna Interface B.3.1.4 If a SELECT command is received over the antenna interface, and the PPSE is currently selected on another channel over the device interface then the SELECT command SHALL be rejected with an error Status Word2." 1 The actual Status Word value may be platform-dependent but it shall correspond to an error Status Word, i.e. SW12 different from '9000', '61XX', '62XX' or '63XX' 2 The actual Status Word value may be platform-dependent but it shall correspond to an error Status Word, i.e. SW12 different from '9000', '61XX', '62XX' or '63XX'

countries.

3. Notification of Priority Changes and Application Discretionary Data Changes in Internal Mode On a chip platform supporting version 1.1 of GlobalPlatform Card Specification v2.2 Amendment C or higher, a CREL application is notified of partial selection order changes and volatile priority changes events on applications that have declared it as a CREL. When it supports Internal Mode, the PPSE application is a CREL and receives such notifications. The PPSE operating in Internal Mode and receiving these notifications shall rebuild its FCI to take into account the new priority change. Note that when the PPSE is notified that an application is being given the volatile priority, the FCI of the PPSE features exclusively the Directory Entry (or entries) for this application, until the volatile priority is reset or allocated to another application. Besides, there may be situations where the Application Discretionary Data of a contactless application is updated - by the application itself or by its associated Security Domain. In such a situation, the PPSE application must refresh its FCI. This Specification Change affects the following in the AAUI document:

, section A.1.3, the following 5 bullets are appended to the last bullet:

  • "On receipt of a notification that an activated application has been assigned the highest or lowest selection priority, the PPSE must rebuild the FCI with the INFO_DISCRETIONARY_DATA of all its active contactless application(s). See first bullet above for details about how to build the FCI. This notification would be the notifyCLEvent() with a parameter of EVENT_SELECTION_PRIORITY_HIGHEST, or EVENT_SELECTION_PRIORITY_LOWEST. This notification is available on Secure Elements supporting [GPCARD] from version 1.1.
  • On receipt of a notification that an application in state ACTIVATED or DEACTIVATED has been assigned the Volatile Priority, the PPSE must build the FCI based on: 1. Volatile Part: The INFO_DISCRETIONARY_DATA of this application (Part 1). Note that the INFO_DISCRETIONARY_DATA of the application receiving the Volatile Priority may contain several Directory Entries if this application is a Group Head. 2. Persistent Part: The INFO_DISCRETIONARY DATA of the other active contactless applications (Part 2). See first bullet above for details about how to build the FCI using INFO_DISCRETIONARY_DATA while respecting the platform priority and removing AID redundancies with the Length of Base AID. The Persistent Part is appended to the Volatile Part. When the application being granted the Volatile Priority is a Payment Application, then Payment Applications must be excluded from Persistent Part. Contactless applications having an Application Family Identifier (INFO_FAMILY_IDENTIFIER) with value '20' or without Application Family Identifier are considered as Payment Applications; applications with an Application Family Identifier available with value different from ‘20’ are considered as Non-Payment Applications. This notification would be the notifyCLEvent() with a parameter of EVENT_VOLATILE_SELECTION_PRIORITY_SET. This notification is available on Secure Elements supporting [GPCARD] from version 1.1.
  • On receipt of a notification that the Volatile Priority has been reset for an application, the PPSE must populate the FCI with the INFO_DISCRETIONARY_DATA of all its active contactless application(s). See first bullet above for details about how to build the FCI. countries. This notification would be the notifyCLEvent() with a parameter of EVENT_VOLATILE_SELECTION_PRIORITY_RESET. This notification is available on Secure Elements supporting [GPCARD] from version 1.1."
  • [GPCARD] specifies that the Volatile Priority is discarded when the Secure Element is reset or powered on. Upon detection that the card has been reset or powered on while an application previously had the Volatile Priority, the PPSE must populate the FCI with the INFO_DISCRETIONARY_DATA of all its active contactless application(s) (see first bullet above). If the PPSE is capable of determining that the Mobile Device is not switched on, it must return the tailored FCI corresponding to the case when the Mobile Device is not Switched On (see second bullet above).
  • On receipt of a notification that the Application Discretionary Data of an active application has changed, the PPSE must refresh the FCI as per the current situation: Mobile Device switched on or off, Volatile Priority set or not (see bullets above). This notification would be the notifyCLEvent() with a parameter of EVENT_DISCRETIONARY_DATA. countries. 4. FCI initialisation after setting PPSE for Internal Mode The AAUI document specifies that the PPSE application shall reset all its current FCI templates following the execution of a SET MODE command that sets the Internal or External Mode. This behaviour is appropriate when setting PPSE for External Mode, as it is expected that a user interface application will further use the SET TEMPLATE command to set the FCI templates of the PPSE. However, when setting PPSE for Internal Mode, a reset of the FCI templates hides all CMP applications - even when activated by the consumer - from the contactless payment terminal, until the consumer eventually changes his/her CMP activation or priority parameters. To avoid a mismatch between the consumer's choice and the PPSE FCI, the PPSE must rebuild the FCI with the Directory Entry information of all its active contactless application(s) when being set for Internal Mode. This Specification Change affects the following in the AAUI document:
  • , replace: B.3.1.37 with: Following the setting of the mode, any current FCI Templates SHALL be reset. B.3.1.37 B.3.1.38 If P1 contains a value of '01' [EXTERNAL] then any current FCI Templates SHALL be reset. If P1 contains a value of '02 [INTERNAL] then the PPSE SHALL rebuild the FCI with the Directory Entry information of all its active contactless application(s). See the Functional Behaviour description, first and second bullets in Section A.1.3 for further details about how to build the FCI. countries. 5. Extension of usage of the PPSE for Non-Payment applications The PPSE is primarily aimed at referencing the contactless applications available to the contactless terminal for payment transactions. Nevertheless, contactless payment terminals and mobile devices may also embed side applications on top of the payment functionality, such as loyalty applications. Referencing non-payment co-applications in the PPSE FCI can enable payment terminals to discover them more rapidly and efficiently, in particular without any additional SELECT command that would jeopardize the compatibility with the generic EMV Application Selection Process and impact the transaction performance. The presence of non-payment applications in the PPSE FCI is thus allowed. This Clarification affects the following in the AAUI document:
  • , append the following paragraphs after the Behaviour description: "The PPSE configured in Internal Mode SHOULD consider any contactless application for which it is a CREL as a payment application, regardless of the presence or value of the Application Family Identifier in the CRS parameters of this application. Note that the Application Family Identifier is an optional parameter for contactless applications, including for payment applications (see Table A.3). If, for proprietary reasons, the PPSE working in Internal Mode adopts a different behaviour from the above recommendation, the following rules apply:
  • Contactless applications without Application Family Identifier, or having an Application Family Identifier with value '20', SHALL be considered as payment applications;
  • The processing of contactless applications with an Application Family Identifier different from value '20' is outside of the scope of this specification. It MAY follow a different behaviour than with payment applications. The processing expected from the PPSE for payment applications includes, but is not limited to:
  • For FCI building, the behaviour described in this section
  • For SELECT command processing, the behaviour described at paragraph B.3.1.3"
  • , insert the following paragraph before the paragraph beginning with "Internal Mode is intended primarily for use in single Secure Element environments… " "The PPSE FCI contains the list of contactless payment applications available for the contactless reader. Non-payment contactless applications may also be referenced in the PPSE FCI, provided that these applications are intended to be selected by terminals supporting contactless payments and that these terminals use the PPSE for the application selection process. Typically loyalty or transport applications may be referenced in the PPSE FCI."
  • , change the text in the requirements as follows: B.3.3.10 B.3.3.11 If no contactless mobile payment application has indicated to the PPSE that it is in the active state then a response of '6A82' [Application not found] SHALL be returned. If one or more contactless payment applications have indicated to the PPSE that they are in the active state, then the PPSE response shall contain the directory entries of the active applications countries. 6. AAUI launching by PPSE The PPSE application may wake up the AAUI application with a notification when it is selected over the antenna interface, typically to prompt the user to choose a CMP application before tapping the device again. This functionality is allowed on an implementation proprietary basis. It may be standardized in the future. This Clarification affects the following in the AAUI document:
  • , add the following section:

7.5 Contactless Event AAUI Launch As an alternative to manual launch of the AAUI by the consumer, an AAUI may also be launched as a result of an interaction with a contactless reader. An AAUI may be configured to launch when the PPSE is selected on the antenna interface, so as to present messages to the consumer in a number of scenarios. The following are two examples as to when such messages may be useful:

  • The PPSE has not been populated with a payment product. In this scenario the AAUI could inform the consumer to choose a payment product to be used to conduct the transaction and to then re-attempt the transaction.
  • The PPSE has been populated with at least one payment product but the AAUI is aware that a payment did not actually occur. In this scenario the AAUI could inform the consumer that the merchant may not support the currently chosen payment product and ask him to choose an alternate payment product to be used to re-attempt the transaction. This AAUI configuration requires that the platform supports notifications, and that the PPSE invokes the platform notification mechanism when it is selected on the antenna interface. The PPSE may also transmit parameters associated with the notification, such as the complete antenna interface PPSE response - including Status Words, to enable the AAUI to interpret the situation. Notifications triggered by the PPSE application are allowed, but outside of scope of these specifications for now. countries. 7. Corrections to the SET STATUS Command [GPCARD] does not enable to support the full functionality of the SET STATUS command described in Annex C:
  • A CMP application requesting its activation cannot have access to the list of conflicting applications, therefore it cannot return this information to the User interface application.
  • A CMP application cannot request for itself to be assigned the highest or lowest priority. The SET STATUS command is adapted to these restrictions. The Command data is also made optional, so as to better fit existing implementations that do not use any authentication data. This Specification Change affects the following in the AAUI document:
  • , replace the paragraph with the following: "This annex details an interoperable alternative command for managing application activation. This command is intended for single Secure Element environments where the SECM does not provide an interface that interface is not available to the AAUI can use and it is therefore necessary to manage the state of contactless applications through the applications themselves. The ability of an application to support this command depends on the platform on which the application is being hosted, any necessary privileges, and the SECM employed by the platform. Note that [GPCARD] does not currently support the full functionality of this command." Note that this annex assumes that the platform complies with [GPCARD].
  • , Table C.24 (SET STATUS Command Message): add a footnote after the value of Lc, Data, and Le: "Presence and actual value for Lc, Command Data and Le is at the discretion of each payment system specification for their CMP application."
  • , Table C.26 (SET STATUS Command P2 if P1 is '02'), remove the two first lines of the table corresponding to "Assign Highest Priority" and "Assign Lowest Priority"
  • , update the last paragraph about Command Data as follows: "If present, theThe command data contains a Template that is either empty or contains application specific TLV-coded data objects. For example, an authentication TLV coded data object."
  • (Response Data), insert the following sentence after title Response Data: "The presence of Response Data is at the discretion of each payment system specification for their CMP application. If present, the response data is formatted as described below:"
  • :
  • Change the title from "Anticipated Behaviour" to: "Behaviour"
  • Remove the Bullet Point starting with "If P2 contains a value of '01' [Assign Highest Priority]
  • Remove the Bullet Point starting with "If P2 contains a value of '81' [Assign Lowest Priority]
  • , Table C.28 (SET STATUS Command Responses), for SW= '6984', change the Type from "Warning" to "Error": countries. 8. PPSE answer truncation for Internal Mode With the cardholder being given the possibility to activate several CMP applications simultaneously, there may be a situation where too many applications are activated and the resulting PPSE FCI is too long to fit into a single R-APDU. In such a case, the PPSE operating in Internal Mode is required to ignore the entries with a lesser priority, until the FCI can fit into a single R-APDU. This Specification Change affects the following in the AAUI document:
  • , "Behaviour" requirement, append the following sentences at the end of the first bullet point: "The PPSE must be able to present a minimum of 8 Directory Entries to the contactless reader. If the concatenated Directory Entries result in more than 229 bytes and thus cannot fit into a single R-APDU, the PPSE shall remove from the list of entries those that cause the overflow, starting from those with the least priority indicator." countries. 9. Clarification on the support of GET TEMPLATE command with Internal Mode The support of the GET TEMPLATE command by the PPSE application is mandatory, whatever the mode (internal or external) currently used by the PPSE. The GET TEMPLATE is useful to AAUI applications in Internal Mode:
  • For Mobile Device implementations where the response to the SELECT command is not provided back to the AAUI selecting the application, it can be used to retrieve the Device FCI (P1 = '04'), This enables to get information such as the Version Number and the Current Mode.
  • It can be used by the AAUI to determine which payment applications are currently activated, or if an override payment application is currently set. This Clarification affects the following in the AAUI document:
  • , add a second paragraph after the introductory paragraph: "The support of the GET TEMPLATE command is mandatory, regardless of the PPSE configuration (Internal or External Mode). countries.