PCI Watch

Tracking changes across the Payment Card Industry

PPSE and Application Management for Secure Elements

v1.0 Specifications
ContactlessMobile Chip & PlatformNFC Consumer Device

EMV<sup>®</sup> Contactless Mobile Payment PPSE and Application Management for Secure Element Specification Version 1.0 May 2017

Payment

/ 67 PPSE and Application Management for Secure Element v1.0

Legal Notice

The EMV<sup>®</sup> 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 NONINFRINGEMENT, 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.

Payment PPSE and Application Management for Secure Element v1.0

1. 1. 1. 1. 1.4. 1.4. 1. 1. 1.6.1 1.6.2 1.6. 1. 2. 2. 2.2. 2. 2. 2. 3. 3. 3.2.1 3.2.2 3.2.3 3.2.4 3.2. 3. 3.3.1 3.3.2 3.3. 3.

Payment

/ 67 PPSE and Application Management for Secure Element v1.0 3.4.1 3.4.2 3.4. 3. 3.5.1 3.5.2 3.5. 3. 3.6.1 3.6.2 3.6.3 3.6. 4. 4. 4. 4. A. A. B. B. B.

Payment PPSE and Application Management for Secure Element v1.0

/ 67 Figures Figure 2.

Payment

/ 67 PPSE and Application Management for Secure Element v1.0 Requirements R3. R3. R3. R3. R3. R3. R3. R3. R3. R3. R3. R3. R4. R4. R4.

Payment PPSE and Application Management for Secure Element v1.0

/ 67 1 Introduction 1.1

Background

EMVCo published the Application Activation User Interface ([AAUI]) document in December 2010. Since the publication of the original [AAUI] document, the mobile device and mobile payment landscape has changed considerably, and some of the concepts and predictions in the original document have not materialized or have followed a different path. The original [AAUI] document was agnostic of the Secure Element Contactless Management (SECM) used for managing contactless applications on a Secure Element, and GlobalPlatform Card Contactless Services [GPCARD C] was only considered to be one option for a SECM. Today, [GPCARD C] has become the de facto market standard for SECM, and no alternative has emerged. As such, the relevant content specific to [GPCARD C] has been extracted from the original [AAUI] document and combined with an overview of managing applications on Secure Elements to form this document. Additionally, over the intervening years, in order to enhance the quality of approved contactless products, EMVCo has refined the test cases applying to Secure Element hosted PPSE applications, and the requirements matching these test cases are reflected herein. 1.2

Scope

Requirements detailed herein correspond to those tested by EMVCo for the functional (Level 2) type approval of Secure Elements and PPSE applications for [GPCARD C] compliant platforms. They are equivalent to the requirements originally presented in [AAUI], integrate the modifications of the latest applicable Specification Update Bulletins, and are presented slightly differently. This document should be read in conjunction with the white paper document [PCM].

1.3 Audience This document is primarily intended for use by entities designing, developing, implementing, and testing a PPSE application residing in a Secure Element of the Mobile Device. It will also be useful to entities developing Payment Applications and Payment Card Manager applications, entities responsible for the provisioning of those applications, and entities responsible for the presence of the PPSE functionality on the Secure Element, e.g. handset manufacturers, operating system providers, mobile network operators, mobile application developers, smart card application developers, etc.

Payment

/ 67 PPSE and Application Management for Secure Element v1.0 1.4

References

The following documents contain provisions that are referenced in this specification. The latest version shall apply unless a publication date is explicitly stated.

1.4.1 EMV Documents EMV documents are available on the EMVCo website: http://www.emvco.com/specifications.aspx Reference [AAUI] [Book D] [ENTRY] [PCM] Table 1-1: EMV Documents Publication Name Application Activation User Interface – Overview, Usage Guidelines, and PPSE Requirements Contactless Specifications for Payment Systems: Book D – EMV Contactless Communication Protocol Specification Contactless Specifications for Payment Systems: Book B – Entry Point Specification Payment Card Management White paper 1.4.2 External References Table 1-2: External References Reference [GPCARD] Publication Name GlobalPlatform Card Specification [GPCARD C] Contactless Services – GlobalPlatform Card Specification – Amendment C: Contactless Services [ISO/IEC 14443] Identification cards – Contactless integrated circuit(s) cards – Proximity cards

Payment PPSE and Application Management for Secure Element v1.0

/ 67 1.5

Definitions

The following terms are used in this specification: Table 1-3: Definitions Term AAUI Definition Application Activation User Interface, the former terminology used in [AAUI], referring to a Payment Card Manager. Application Group A set of contactless applications consisting of a group head application and one or more member applications. From a consumer point of view, a group is synonymous with a single Payment Card on their Mobile Device that gives them access to multiple contactless services. For example, a group could comprise multiple Payment Applications, one of which is designated by the product owner as the group head and the others as members of the group. With regards to application activation and priority changes, only the group head is consumer facing, and actions that affect the group head also affect all the group members. See [GPCARD C] for further details about Application Groups. CMP Application Contactless Mobile Payment Application, the former terminology used in [AAUI], referring to a Payment Application. Payment Application A contactless application that performs information exchange and processing needed to perform a contactless payment transaction. It may be hosted in the same Secure Element as the PPSE, or in a different Secure Element, or in the HCE environment. Payment Card A consumer–facing payment service presented to the Consumer as a single product – generally represented by a card visual in a Payment Card Manager. A Payment Card may comprise a unique Payment Application, or an Application Group of contactless applications – including at least one Payment Application. Payment Card Manager A consumer visible application resident within the Mobile Device’s application environment and used by the consumer to manage which – of the possible multiple – Payment Card(s) will be used for conducting contactless payments. More than one Payment Card Manager may be present on a Mobile Device.

Payment

/ 67 PPSE and Application Management for Secure Element v1.0 Term PPSE Switched On Definition The Proximity Payment Service Environment is the first contactless application selected by a Merchant Terminal presenting the contactless applications available for conducting a transaction. A state where the Mobile Device is powered up and the user interface (screen, keyboard, etc.) is available for use. For the purposes of this document, there is only one other applicable Mobile Device power state; that is, where the user interface is not available because the device is not Switched On. For example, power is below the threshold at which the user interface becomes active, the Mobile Device is switched off, or the battery is depleted or removed.

1.6 Notational Conventions 1.6.1 Abbreviations The abbreviations listed in Table 1-4 are used in this specification. Table 1-4: Abbreviations Abbreviation AAUI

Description

Application Activation User Interface ADF Application Definition File AID Application Identifier API Application Programming Interface CREL Contactless Registry Event Listener CRS Contactless Registry Services FCI File Control Information HCE Host Card Emulation NFC Near Field Communication PPSE Proximity Payment System Environment

Payment PPSE and Application Management for Secure Element v1.0 Abbreviation SECM Description Secure Element Contactless Management TLV Tag, Length, Value UICC Universal Integrated Circuit Card

/ 67 1.6.2 Requirements Terminology The following (words are used often in this specification and have specific meanings: SHALL Defines a product or system capability which is mandatory. MAY Defines a product or system capability which is optional or a statement which is informative only and is out of scope for this specification. SHOULD Defines a product or system capability which is recommended.

1.6.3 Conventions The following conventions apply:

Requirement

Numbering Requirements in this specification are uniquely numbered with the number appearing next to each requirement: For example: R3.8.2 If the GET TEMPLATE command is received over the antenna interface, then a response of '6985' SHALL be returned. A requirement may have different numbers in different versions of the specifications. Hence, all references to a requirement should include the version of the specification as well as the requirement’s number. Requirements may include informative statements. In this case, the statement is written in the italic font and the verb ‘MAY’ instead of ‘SHALL’ is used.

Payment

/ 67 PPSE and Application Management for Secure Element v1.0 1.7 Organisation of Document This document contains the following information:

  • Chapter 1 contains general information that helps the reader understand and use this specification
  • Chapter 2 introduces the architecture of the Secure Element that will host the PPSE Application (applet) and, optionally, Payment Applications (applets)
  • Chapter 3 specifies the Secure Element hosted PPSE application, for the three modes (External Mode, Internal Mode and Internal Mode with Mutual Exclusivity Rule)
  • Chapter 4 defines the required behaviour of Secure Elements intended to host Payment Applications or the PPSE application
  • Annex A details the contactless parameters that must be set for Payment Applications during installation or personalisation
  • Annex B proposes an alternative for managing contactless application activation. This alternative can be used when the Payment Card Manager cannot interact with the Secure Element’s CRS application. In this case, the Payment Card Manager interacts with each Payment Application to manage the Payment Application’s activation state
  • Annex C establishes a correspondence between the numbering of requirements in this document and the requirements/sections in the original [AAUI] and the associated Specification Update Bulletins Payment PPSE and Application Management for Secure Element v1.0 / 67 2 Secure Element As per the [PCM], the architecture of a device capable of Contactless Mobile Payment is, at minimum, an NFC-capable Mobile Device with an NFC Controller, an antenna, and an application environment hosting one or more Payment Card Managers. In addition, the device requires an Execution Environment capable of hosting a contactless Payment Application. This environment could be the device’s own application environment (i.e. for HCE) or a Secure Element (the focus of this document). A Secure Element in the Mobile Device, such as an embedded Secure Element or a UICC, complies with the GlobalPlatform Card Specifications [GPCARD] and, specifically to manage contactless applications, the GlobalPlatform Contactless Services [GPCARD C]. In general, [GPCARD] enables the loading, installation and management of applications (applets) within the application environment of the Secure Element. Amendment C [GPCARD C] enables the management of an application’s contactless aspects if these applications are intended for use over the antenna interface of the Secure Element. The PPSE application developed in accordance with this specification is installed in this Secure Element. Likewise, Payment Applications and other applications may also be installed in this Secure Element. Payment / 67 PPSE and Application Management for Secure Element v1.0 Figure 2.1: Secure Element Environment and Architecture Application Execution Environment Payment Card 1 Payment Card 2 Payment Card Manager A Payment Card 3 Payment Card 4 Payment Card Manager B Payment Application 4 (HCE) Payment Application 1 Payment Application 2a (Head) Payment Application 2b (Member) Application Group CRS Application (optional) PPSE Application (opt: CREL) Payment Application 3 Other CREL Application (optional) GlobalPlatform CRS API - Requests GlobalPlatform CRS API - Notifications Glo balPlat form Environment Glo balPlat form Contactless Registry PPSE Application: ACTIVATED,... CMP Application 1: DEACTIVATED,... CMP AppliCation 2a: ACTIVATED,... CMP Application 2b: ACTIVATED,... CMP Application 3: DEACTIVATED,... Other CREL: DEACTIVATED,... Secure Element Mobile Device LEGEND C-APDU (Device Interface) used for activation/prioritization C-APDU (Device Interface) used for other purposes 2.1 The GlobalPlatform Environment (OPEN) This document targets Secure Elements complying with [GPCARD] (v2.2 or higher) and [GPCARD C] (v1.0 or higher). The latter provides numerous and highly valuable tools for the management of contactless applications in the Secure Element, such as:
  • A Contactless Registry within the GlobalPlatform environment that stores the contactless-related parameters of each contactless application (contactless activation state, selection priority, volatile priority, Application Group parameters, proprietary information, RF parameters, etc.) Note that GlobalPlatform is deprecating support for volatile priority and as such, while still described herein, its usage is not recommended and it is also being deprecated for the PPSE. Payment PPSE and Application Management for Secure Element v1.0 / 67
  • A Contactless Registry Service (CRS) API enabling applications to read from or write to the Contactless Registry – within the limit of the rights and privileges allocated to such applications
  • The possibility for contactless applications – within the limit of their allocated rights and privileges – to receive notifications when the contactless-related parameters for themselves or for other contactless applications change
  • The possibility to create Application Groups allowing a single customer-facing contactless service – comprising multiple underlying contactless applications – to be activated and deactivated simultaneously
  • The notion of a selectable CRS application allowing a device resident application to manage the activation state and priority of contactless applications in the Secure Element (see section 2.4)
  • The notion of Contactless Registry Event Listener (CREL) application(s), enabling privileged applications (CRELs) to be notified when the contactless parameters of related contactless applications change 2.2 The PPSE Application The main purpose of any PPSE is to return File Control Information (FCI) as a response to the selection of the PPSE application over an antenna interface. The content of the FCI contains a single directory entry or a list of directory entries. Note that, in addition to the Payment Application directory entries, other contactless application directory entries may be present in the FCI. Each Payment Application Directory Entry identifies the following information applicable to the entity selecting the PPSE (typically a Merchant Terminal):
  • The Payment Application available for selection (by AID) and use by the Merchant Terminal
  • The usage priority of each Payment Application; that is, the lower the value, the higher the priority1
  • The specific Merchant Terminal application underpinning the product; that is, the kernel to be used to interact with this Payment Application
  • Other application-specific data 1 Except that priority '0' means no priority assigned. Payment / 67 PPSE and Application Management for Secure Element v1.0 All EMVCo contactless payments are required to support the use of the PPSE. The PPSE in a card form factor has traditionally contained a static list of supported Payment Applications, accessible over the antenna interface, personalised with an Issuer-defined prioritisation of each Payment Application, and accessible over the antenna interface in the SELECT command response. The mapping of the PPSE FCI can be found in [ENTRY] as well as in section 3.2.5 of this document. For further information regarding the processing of the PPSE FCI by a contactless reader, please refer to [ENTRY].

2.2.1 PPSE on Mobile Devices For Mobile Devices, the PPSE typically contains additional functionality that allows the Payment Application(s) reflected in the PPSE to be dynamically managed by the consumer through a Payment Card Manager. This mobile-specific functionality allows a Payment Card Manager to control the PPSE’s SELECT command response depending on the Payment Card choices of the consumer. Additionally, Payment Applications may be configured to be available (or not) when the Device is not Switched On. Therefore, the SELECT command response could depend on the PPSE’s assumption related to whether or not the Mobile Device is Switched On at the time it is presented to a Merchant Terminal. The PPSE FCI contains the list of Payment Applications available for the Merchant Terminal. Non-payment contactless applications may also be present in the PPSE FCI, provided that these applications are intended to be selected by Merchant Terminals supporting contactless payments, and that these terminals make use of the PPSE for the application selection process. Typically, loyalty or transport applications may be referenced in the PPSE FCI. This specification focuses on the mechanisms used to populate/configure the PPSE with Directory Entries and how to indicate which Directory Entries are, at a given point in time, returned to the Merchant Terminal. Three mechanisms are defined for achieving this: External Mode, Internal Mode and Internal Mode with Mutual Exclusivity Rule. These modes relate to the manner in which the PPSE application in the Secure Element receives, acts on, and builds the information that will be provided to a Merchant Terminal.

  • External Mode – When this mode is being used, the Payment Card Manager provides – directly to the PPSE – the Directory Entry of each Payment Application that will be returned to a Merchant Terminal. External Mode is suitable for a single Secure Element environment as well as when multiple Execution Environments (Secure Element(s) and/or HCE) are active simultaneously. The Payment Card Manager provides the PPSE with the SELECT command responses to be returned to the Merchant Terminal. In Figure 2.1, Payment Card Manager B interacts with the PPSE application in External Mode, as seen from the black arrow linking these two entities. Payment PPSE and Application Management for Secure Element v1.0 / 67
  • Internal Mode – When this mode is being used, the PPSE will itself, internally to the Secure Element, collect the details of the active applications from the GlobalPlatform CRS and build the data to be returned to the Merchant Terminal. Internal Mode implies that the Secure Element platform provides a means for the PPSE to determine which contactless applications are active. The PPSE uses information provided by the GlobalPlatform environment related to these active applications to build the SELECT command response to be returned to the Merchant Terminal. The PPSE also needs to be able to receive notifications of changes to contactless parameters for these applications. To enable this behaviour in the frame of [GPCARD C], the PPSE must be declared as a Contactless Registry Event Listener (CREL) for all Payment Applications. Internal Mode can only be used when a single Secure Element is active. There is no interaction between Execution Environments (Secure Elements and/or HCE) that will allow a PPSE in this mode to be notified of a state change of an application on another Execution Environment or that will allow a PPSE to determine the state of applications on other Execution Environments. Therefore, when multiple Execution Environments are to be simultaneously active, External Mode is the only mode possible. In Figure 2.1, Payment Card Manager A uses the PPSE application in Internal Mode, as there is no direct arrow linking these two entities.
  • Internal Mode with Mutual Exclusivity Rule – This mode is a variant of Internal Mode and is intended to ensure that no more than one Payment Card can be active at any time. When configured for this mode, the PPSE application behaves as if configured for Internal Mode, but over and above regular Internal Mode, it will deactivate any currently active Payment Application (or Application Group) when it is notified that a new Payment Application (or Application Group) has been activated. An implementation of the PPSE may support one, two, or three modes and it is the Payment Card Manager that will configure the PPSE to behave in an expected manner.

2.3 Payment Applications Besides the PPSE, the Secure Element may also host contactless Payment Applications. For these Payment Applications, the Payment Card Manager may be able to retrieve contactless specific information, must be able to set the Payment Application’s activation state, and (if applicable) must be able to set the Payment Application’s selection priority. A Payment Application corresponds to the technical implementation of a Payment Card service (or part of it, if the Payment Card represents multiple Payment Applications) offered in a Payment Card Manager. During a contactless transaction, it processes the commands received over the antenna interface from the Merchant Terminal. The Payment Application may also receive and process commands over the device interface from a Payment Card Manager.

Payment

/ 67 PPSE and Application Management for Secure Element v1.0 When the PPSE is configured in either of the internal modes, the Secure Element hosting the PPSE application also hosts all the Payment Applications that are intended to be included in the FCI of the PPSE. Each of these Payment Applications must declare the PPSE application as a CREL. When the PPSE is configured in External Mode, Payment Applications may be installed in any Secure Element of the mobile device (in the same Secure Element as the PPSE or in a different one), or even in the HCE environment. Each Payment System defines their own requirements for their Payment Applications. Payment Applications may offer the following contactless management services to Payment Card Managers:

  • Activation/deactivation of the Payment Application on the antenna interface (see Annex B)
  • Setting or resetting of volatile priority (see Annex B)2 When a single Payment Card represents multiple Payment Applications, these Payment Applications should be hosted inside the same Secure Element and should constitute an Application Group, as defined by [GPCARD C].

2.4 CRS Application Depending on deployment choices, the Secure Element will also host a CRS application and may provide an APDU interface to a Payment Card Manager, providing direct access to the CRS. Alternatively, if this APDU interface is not present, the CRS may receive Payment Card Manager requests indirectly through the Payment Applications. 2 The use of volatile priority is deprecated by EMVCo.

Payment PPSE and Application Management for Secure Element v1.0

/ 67 If providing a direct APDU interface, this will be a single interface to all Payment Card Managers to manage all underlying Payment Applications installed in the same Secure Element to facilitate the following:

  • Global activation/deactivation of the antenna interface for the Secure Element
  • Activation/deactivation of each contactless application individually (or as an Application Group) on the antenna interface
  • Changing the selection priority for contactless applications
  • Setting or resetting of volatile priority for contactless applications3
  • Retrieval of contactless parameters from the CRS GlobalPlatform [GPCARD C] proposes a standard implementation of the CRS application. The services listed above are offered by the GlobalPlatform CRS application with the command APDUs GET STATUS and SET STATUS. See [GPCARD C] section 3.11 for further details. As per the GlobalPlatform specifications, there is at most one CRS application in the Secure Element, and the APDU interface to the CRS application in the Secure Element is optional. If the CRS application is not available for use through the APDU interface, Payment Card Managers should use the contactless management functionality offered by each Payment Application – a standardized APDU interface is described in Annex B. However, in the absence of an APDU interface to the CRS application, some management functions like changing the selection priority of Payment Applications will definitely be unavailable to Payment Card Managers. When this is the case, the Secure Element configuration should ensure that no more than one Payment Card is active at a given time. This can be achieved by a dedicated Contactless Registry Event Listener (CREL) application, or by the PPSE application itself (see the description for Internal Mode with Mutual Exclusivity Rule).

2.5 Other Contactless Applications Besides Payment Applications, the PPSE and the CRS application, other applications may be present in the Secure Element at the discretion of the Secure Element issuer/manager. These would typically include third-party service provider applications e.g. loyalty, transport, communication, authentication, gaming etc. and are largely out of scope of this document. Contactless payment may be associated with the processing of loyalty information by the Merchant Terminal. Depending on implementation choices, loyalty applications may or may not be visible to Merchant Terminals in the PPSE FCI. 3 The use of volatile priority is deprecated by GlobalPlatform.

Payment

/ 67 PPSE and Application Management for Secure Element v1.0 Some Secure Element configurations may include additional, non-consumer-facing applications serving payment purposes. For example, as opposed to using the Internal Mode with Mutual Exclusivity Rule, the Secure Element may host a dedicated CREL application that deactivates the currently active Payment Application when a new Payment Application is activated.

Payment PPSE and Application Management for Secure Element v1.0 3 PPSE Requirements

/ 67 3.1 General Requirements Table 3-1 summarizes the instructions that are supported by a PPSE application in a Secure Element, based on the currently active mode and depending on the interface on which the instruction is received. Table 3-1: PPSE supported instructions Instruction SELECT Internal Mode Yes Device Interface Internal Mode with Mutual Exclusivity Rule External Mode Yes Yes Internal Mode Antenna Interface Internal Mode External with Mutual Mode Exclusivity Rule Yes Yes Yes PUT No No Yes No No No TEMPLATE GET Yes Yes Yes No No No TEMPLATE SET MODE If more than 1 mode is supported No No No The following are general functional requirements. Command-specific functional requirements are listed in the following sections. R3.1: General Requirements R3.1.1 The PPSE application SHALL be installed with the Contactless Protocol Parameters specified in Table A-1. R3.1.2 The SELECT command SHALL be accessible over the device interface and over the antenna interface.

Payment

/ 67 PPSE and Application Management for Secure Element v1.0 R3.1: General Requirements R3.1.3 If a SELECT command is received and the PPSE application is already selected on another logical channel over the device or antenna interface then the SELECT command SHALL be rejected with an error Status Word 4. R3.1.4 The GET TEMPLATE command SHALL be supported. It SHALL be accessible over the device interface and SHALL NOT be accessible over the antenna interface. R3.1.5 The SET MODE command SHALL be supported if the PPSE supports two or three modes. If the SET MODE command is supported, then it SHALL be accessible over the device interface and SHALL NOT be accessible over the antenna interface. R3.1.6 If the PPSE supports External Mode, then the PUT TEMPLATE command SHALL be accessible over the device interface and SHALL NOT be accessible over the antenna interface. 4 The actual Status Word value may be platform-dependent but it shall correspond to an error Status Word, i.e. SW different from '9000', '61XX', '62XX' or '63XX'

Payment PPSE and Application Management for Secure Element v1.0

/ 67 3.2 SELECT Command The PPSE hosted in a Secure Element can be selected over the device interface as well as over the antenna interface. However, in order to guarantee an atomic session, the PPSE does not support multiple selections simultaneously over the device interface and over the antenna interface (see R3.1.3). Payment Card Managers using the device interface are thus requested to close the connection with the PPSE application as soon as they have completed their processing with PPSE, even if the Payment Card Manager is still processing other functions, so as to release the PPSE for subsequent selection by a Merchant Terminal or another Payment Card Manager.

3.2.1 Command Data Code CLA INS P1 P2 Lc Data Le Table 3-2: SELECT Command Message '00' – '03', ‘40’ – ‘4F’ Value 'A4' '04' '00' Length of the command data field ‘2PAY.SYS.DDF01’ '00' 3.2.2 Functional Requirements - Device Interface Requirements R3.2 apply to the SELECT command when received over the device interface only. They apply to all three modes. R3.2: SELECT Command – Device Interface R3.2.1 If a SELECT command is received over the device interface, and the PPSE application is not active over the antenna interface, then the PPSE application SHALL become active over the antenna interface. R3.2.2 If a SELECT command is received over the device interface, then the PPSE response, constructed as specified in Table 3-3 SHALL be returned.

Payment

/ 67 PPSE and Application Management for Secure Element v1.0 R3.2: SELECT Command – Device Interface R3.2.3 If any of the following is true:

  • the PPSE only supports [External Mode], or
  • the PPSE was originally configured to support [External Mode] and has never received a SET MODE command, or
  • the most recently received SET MODE command configured the PPSE to operate in [External Mode], then the value for tag '89' in the PPSE response to the SELECT command SHALL be '01' [External Mode]. R3.2.4 If any of the following is true:
  • the PPSE only supports [Internal Mode], or
  • the PPSE was originally configured to support [Internal Mode] and has never received a SET MODE command, or
  • the most recently received SET MODE command configured the PPSE to operate in [Internal Mode], then the value for tag '89' in the PPSE response to the SELECT command SHALL be '02' [Internal Mode]. R3.2.5 If any of the following is true:
  • the PPSE only supports [Internal Mode with Mutual Exclusivity Rule], or
  • the PPSE was originally configured to support [Internal Mode with Mutual Exclusivity Rule] and has never received a SET MODE command, or
  • the most recently received SET MODE command configured the PPSE to operate in [Internal Mode with Mutual Exclusivity Rule], then the value for tag '89' in the PPSE response to the SELECT command SHALL be '03' [Internal Mode with Mutual Exclusivity Rule]. Payment PPSE and Application Management for Secure Element v1.0 / 67 3.2.3 Functional Requirements – Antenna Interface, External Mode Requirements in this section apply when the PPSE is configured to operate in [External Mode], when the SELECT command is received over the antenna interface
  • Requirements R3.3 (in the order listed) apply when the Mobile Device is Switched On or when the PPSE is incapable of determining (or does not implement functionality to determine) whether the Mobile Device is Switched On.
  • Requirements R3.4 (in the order listed) may apply when the PPSE is capable of determining whether the Mobile Device is Switched On and it is not. R3.3: SELECT Command – Antenna Interface, External Mode / Mobile Device Switched On R3.3.1 If the most recent PUT TEMPLATE command received had a usage parameter of '05' [Mandatory data only], then the PPSE response to the SELECT command, constructed as specified in Table 3-4, SHALL be returned. R3.3.2 If any of the following is true:
  • the PPSE has not received a PUT TEMPLATE command since being configured to operate in [External Mode], or
  • the most recent PUT TEMPLATE command received had a usage parameter of '06' [Hide], or
  • the most recent PUT TEMPLATE command received had a usage parameter of '04' [Cancel override] and no [Device Switched On no override] FCI is currently configured, then a response of '6A82' [Application not found] SHALL be returned. R3.3.3 If no override is currently set, then the FCI built on receipt of the most recent PUT TEMPLATE command with a usage parameter of '01' [Device Switched On no override] SHALL be returned. Payment / 67 PPSE and Application Management for Secure Element v1.0 R3.3: SELECT Command – Antenna Interface, External Mode / Mobile Device Switched On R3.3.4 If all of the following are true:
  • An FCI was built on receipt of the most recent PUT TEMPLATE command with a usage parameter of '03' [Override until cancelled], and
  • No subsequent PUT TEMPLATE command with a usage parameter of '04' [Cancel override] or '05' [Mandatory data only] or '06' [Hide] has been received, and
  • The override has not been cancelled due to the Mobile Device being switched off (see R3.4.2). then the FCI built on receipt of the most recent PUT TEMPLATE command with a usage parameter of '03' [Override until cancelled] SHALL be returned. R3.4: SELECT Command – Antenna Interface, External Mode / Mobile Device Not Switched On R3.4.1 If the most recent PUT TEMPLATE command received had a usage parameter of '05' [Mandatory data only], then the PPSE response to the SELECT command, constructed as specified in Table 3-4, MAY be returned, else,
  • If no [Device not Switched On] FCI is currently configured, then a response of '6A82' [Application not found] MAY be returned, else, the FCI built on receipt of the most recent PUT TEMPLATE command with a usage parameter of '02' [Device not Switched On] MAY be returned. R3.4.2 If the most recent PUT TEMPLATE command had a usage parameter of '03' [Override until cancelled] (and even though no subsequent PUT TEMPLATE command with a usage parameter of '04' [Cancel override] has been received), then the [Override until cancelled] FCI MAY be cancelled. Payment PPSE and Application Management for Secure Element v1.0 / 67 3.2.4 Functional Requirements – Antenna Interface, Internal modes Similar to [External Mode] (see section 3.3 for details of how these FCI values are set), a PPSE supporting [Internal Mode] or [Internal Mode with Mutual Exclusivity Rule] may support up to three FCI values:
  • The PPSE always supports functionality to build the FCI value [Device Switched On no override].
  • The PPSE may support functionality to build the FCI value [Device not Switched On] if the platform allows applications to determine whether the device is switched on or off.
  • The PPSE may support functionality to build the FCI value [Override until cancelled] if the platform is able to transmit to CREL applications the events notifying a volatile priority change5. Such events are only transmitted on Secure Elements supporting [GPCARD C] version 1.1 and 1.2. Requirements in this section apply when the PPSE is configured to operate in [Internal Mode] or in [Internal Mode with Mutual Exclusivity Rule], when the SELECT command is received over the antenna interface
  • Requirements R3.5 apply when the Mobile Device is Switched On, or when the PPSE is incapable of determining (or does not implement functionality to determine) whether or not the Mobile Device is Switched On.
  • Requirements R3.6 may apply when the PPSE is capable of determining whether the Mobile Device is Switched On and it is not. R3.5: SELECT Command – Antenna Interface, Internal modes / Mobile Device Switched On R3.5.1 If no contactless application has indicated to the PPSE that it is in the active state (that is, FCIs [Device Switched On no override] and [Override until cancelled] are currently empty), then a response of '6A82' [Application not found] SHALL be returned. 5 The use of volatile priority is deprecated by GlobalPlatform. Payment / 67 PPSE and Application Management for Secure Element v1.0 R3.5: SELECT Command – Antenna Interface, Internal modes / Mobile Device Switched On R3.5.2 If no contactless application is assigned the volatile priority (that is, FCI [Override until cancelled] is currently empty), and one or more contactless applications have indicated to the PPSE that they are in the active state (that is, FCI [Device Switched On no override] is currently NOT empty), then the PPSE response SHALL contain the FCI [Device Switched On no override]. R3.5.3 If a contactless application is assigned the volatile priority (that is, FCI [Override until cancelled] is currently NOT empty), then the PPSE response SHALL contain the FCI [Override until cancelled]. R3.6: SELECT Command – Antenna Interface, Internal modes / Mobile Device Not Switched On R3.6.1 If either of the following is true:
  • no contactless payment application is in the active state, or
  • there are contactless payment applications in the active state, but none of these is configured for operation when the Mobile Device is not Switched On (that is, FCI [Device not Switched On] is currently empty), then a response of '6A82' [application not found] MAY be returned. R3.6.2 If one or more contactless payment applications that are configured for use when the Mobile Device is not Switched On are in the active state (that is, FCI [Device not Switched On] is currently NOT empty), then the PPSE response returned MAY contain the FCI [Device not Switched On]. Payment PPSE and Application Management for Secure Element v1.0 / 67 3.2.5 Response Data The PPSE response depends on whether the PPSE is being selected over the device interface (by the Payment Card Manager) or over the antenna interface (by the Merchant Terminal). The response to a SELECT command received from the Payment Card Manager over the device interface is coded as per Table 3-3. Table 3-3: PPSE Response over the Device Interface Tag '6F' FCI Template Value '84' ‘2PAY.SYS.DDF01’ 'A5' FCI Proprietary Template '9F08' Version Number:
  • '3130': as per [AAUI]
  • '3131': as per this document '89' Current Mode:
  • '01' – External Mode
  • '02' – Internal Mode
  • '03' – Internal Mode with Mutual Exclusivity Rule Presence M M M M M The response to a SELECT command received over the antenna interface is coded as per:
  • Table 3-4 to indicate that the Mobile Device is an EMV-enabled device but no EMV-based contactless applications are to be accessible over the antenna interface, or
  • Table 3-5 if at least one EMV-based contactless application is to be accessible over the antenna interface. Tag '6F' Table 3-4: PPSE Response without an FCI Proprietary Template FCI Template Value '84' ‘2PAY.SYS.DDF01’ Presence M M Payment / 67 PPSE and Application Management for Secure Element v1.0 Tag '6F' Table 3-5: PPSE Response with an FCI Proprietary Template FCI Template Value '84' ‘2PAY.SYS.DDF01’ 'A5' FCI Proprietary Template 'BF0C' FCI Issuer Discretionary Data '61' Directory Entry '4F' DF Name (AID) '50' Application label '87' Priority indicator '9F2A' Kernel Identifier '9F0A' Application Selection Registered Proprietary Data '61' Directory Entry '4F' DF Name (AID) '50' Application label '87' Priority indicator '9F2A' Kernel Identifier '9F0A' Application Selection Registered Proprietary Data... Presence M M M M M M O C C O O O O O O O O O The response Status Word may contain one of the values shown in Table 3-6. Payment PPSE and Application Management for Secure Element v1.0 Field SW Table 3-6: SELECT Command Responses Length 2 Status Word Value Type '6A86' Error '6A82' Error '9000' Normal Value Meaning Incorrect P1/P2 Application not found Successful processing / 67 Payment / 67 PPSE and Application Management for Secure Element v1.0 3.3 PUT TEMPLATE Command The PUT TEMPLATE command enables the Payment Card Manager to define one of the FCI Proprietary Templates to be returned in response to a subsequent SELECT command over the antenna interface.

3.3.1 Command Data Code CLA INS P1 P2 Lc Data Le Table 3-7: PUT TEMPLATE Command Message '80' – '83', 'C0' – 'CF' Value 'D2' Usage – see Table 3-8 '00' Length of the command data field FCI Proprietary Template Not present Usage (P1) This parameter indicates when this FCI Proprietary Template is to be used. Code '01' '02' '03' '04' '05' '06' Table 3-8: PUT TEMPLATE Command P1 Usage Meaning Device Switched On no override Device not Switched On (optional) Override until cancelled Cancel override Mandatory data only (Delete all) Hide Length If P1 is '04', '05', or '06', then length (Lc) is one ('01'). Otherwise, length (Lc) contains the length of the FCI Proprietary Template.

Payment PPSE and Application Management for Secure Element v1.0

/ 67 Data If P1 is '04', '05', or '06', then the command data is a single byte of '00'. Otherwise, the data is formatted as per Table 3-9. Table 3-9: PUT TEMPLATE Command Data Value 'A5' FCI Proprietary Template Presence M 'BF0C' FCI Issuer Discretionary Data M '61' Directory Entry M '4F' DF Name (AID) M '50' Application label O '87' Priority indicator C '9F2A' Kernel Identifier C '9F0A' Application Selection Registered O Proprietary Data... O... O '61' Directory Entry O '4F' DF Name (AID) M6 '50' Application label O '87' Priority indicator C '9F2A' Kernel Identifier C '9F0A' Application Selection Registered O Proprietary Data... O 6 Only relevant if the Directory Entry is present.

Payment

/ 67 PPSE and Application Management for Secure Element v1.0 3.3.2 Functional Requirements R3.7: PUT TEMPLATE Command R3.7.1 If P1 contains a value other than '01', '02', '03', '04', '05', or '06', or P2 contains a value other than '00', then a response of '6A86' SHALL be returned. If the PPSE does not support handling for when the device is not Switched On, and P1 of the GET TEMPLATE command contains a value of '02', then a response of '6A86' SHOULD be returned. R3.7.2 If a PUT TEMPLATE command is received over the antenna interface, then a response of '6985' SHALL be returned. R3.7.3 If the PPSE is not currently configured to operate in [External Mode], then a response of '6985' SHALL be returned. R3.7.4 If the template received in the command data is not formatted as per Table 3-9, then a response of '6984' SHALL be returned. R3.7.5 If P1 contains a value of '01' [Device Switched On no override], then the received command data SHALL become the FCI Proprietary Template for the FCI that would be returned (as a response to the SELECT command over the antenna interface) when no override is currently set. Note, that in the case that the PPSE supports handling for when the device is not Switched On, the FCI that would be returned (as a response to the SELECT command over the antenna interface) may contain a different value (see R3.7.7). R3.7.6 If P1 contains a value of '02' [Device not Switched On], and the PPSE is not capable of determining (or does not implement functionality to determine) whether the device is Switched On or not, then a response of '6985' SHOULD be returned.

Payment PPSE and Application Management for Secure Element v1.0

/ 67 R3.7: PUT TEMPLATE Command R3.7.7 If P1 contains a value of '02' [Device not Switched On] and the PPSE is capable of determining whether the device is Switched On or not, then the received command data MAY become the FCI Proprietary Template for the FCI that would be returned (as a response to the SELECT command over the antenna interface) when the device is not Switched On. R3.7.8 If P1 contains a value of '03' [Override until cancelled], then the received command data SHALL become the FCI Proprietary Template for the FCI that would be returned (as a response to the SELECT command over the antenna interface). This FCI is returned over the antenna interface until the override is cancelled. Note, that in the case that the PPSE supports handling for when the device is not Switched On, the FCI that would be returned (as a response to the SELECT command over the antenna interface) may contain a different value (see R3.7.7). R3.7.9 If P1 contains a value of '04' [Cancel override], then the current override, if any, SHALL be disabled. R3.7.10 If P1 contains a value of '05' [Mandatory data only], then only the DF Name within the FCI Template (see Table 3-4) SHALL be returned (as a response to the SELECT command over the antenna interface). R3.7.11 If P1 contains a value of '06' [Hide], then the PPSE SHALL behave as if it were not present. R3.7.12 If command data contains an FCI Proprietary Template, then the length field of the newly constructed FCI Template (tag '6F') SHALL reflect the length of the data received in the command message in addition to the length of the PPSE’s DF Name data object.

Payment

/ 67 PPSE and Application Management for Secure Element v1.0 3.3.3 Response Data The response Status Word may contain one of the values shown in Table 3-10. Field SW Table 3-10: PUT TEMPLATE Command Responses Length 2 Status Word Value Type '6984' Error '6985' Error Value Data invalid Meaning Conditions of use not satisfied '6A86' Error Incorrect P1/P2 '9000' Normal Successful processing

Payment PPSE and Application Management for Secure Element v1.0

/ 67 3.4 GET TEMPLATE Command The GET TEMPLATE command enables the Payment Card Manager to retrieve the current FCI settings within the PPSE; that is, the same response data that would be returned in response to a SELECT command over the antenna interface. The support of the GET TEMPLATE command is mandatory, regardless of the PPSE configuration mode.

3.4.1 Command Data Code CLA INS P1 P2 Lc Le Table 3-11: GET TEMPLATE Command Message '80' – '83', 'C0' – 'CF' 'D4' Usage; see Table 3-12 '00' '00' Absent Value Usage (P1) This parameter indicates which of the possible FCI records present in the PPSE is to be returned. Code '01' '02' '03' '04' Table 3-12: GET TEMPLATE Command P1 Usage Meaning Device Switched On no override Device not Switched On (optional) Override until cancelled Device The response to the GET TEMPLATE command is dependent on the parameter set in P1, as defined in the following requirements.

Payment

/ 67 PPSE and Application Management for Secure Element v1.0 3.4.2 Functional Requirements R3.8: GET TEMPLATE Command R3.8.1 If P1 contains a value other than '01', '02', '03', or '04', or P2 contains a value other than '00', then a response of '6A86' SHALL be returned. If the PPSE does not support handling for when the device is not Switched On, and P1 of the GET TEMPLATE command contains a value of '02', then a response of '6A86' SHOULD be returned. R3.8.2 If the GET TEMPLATE command is received over the antenna interface, then a response of '6985' SHALL be returned. R3.8.3 If P1 contains a value of '01' [Device Switched On and no override], then the response command data SHALL contain the FCI that would be returned (as a response to the SELECT command over the antenna interface) when the device is Switched On, whether or not there is a current override FCI. R3.8.4 If P1 contains a value of '02' [Device not Switched On], then the response command data SHOULD contain the FCI that would be returned (as a response to the SELECT command over the antenna interface) when the device is not Switched On. R3.8.5 If P1 contains a value of '03' [Override until cancelled], but no current override response is available, then the response command data SHALL contain an FCI without an FCI Proprietary Template (see Table 3-4). R3.8.6 If P1 contains a value of '03' [Override until cancelled], and a current override response is available, then the response command data SHALL contain the same FCI that would be returned (as a response to the SELECT command over the antenna interface) when the device is Switched On.

Payment PPSE and Application Management for Secure Element v1.0

/ 67 R3.8: GET TEMPLATE Command R3.8.7 If P1 contains a value of '04' [Device], then the response command data SHALL contain the FCI that would be returned as a response to the SELECT command over the device interface.7 3.4.3 Response Data Depending on the value of P1 the response command data is formatted as defined in Table 3-4 or Table 3-5. The response Status Word may contain one of the values shown in Table 3-13. Field SW Table 3-13: GET TEMPLATE Command Responses Length 2 Status Word Value Type '6A86' Error '6985' Error '9000' Normal Value Meaning Incorrect P1/P2 Conditions of use not satisfied Successful processing 7 This functionality is provided specifically for Mobile Device implementations where the response to the SELECT command is not provided back to the entity selecting the application. © 2017 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant

Shown in part. Read the original for the full text.