NFC Mobile Handset High Level Requirements V2

Transcription

1 NFC Mobile Handset High Level Requirements V2 Release 2.0 Date : 28/09/2011 Reference: AFSCM TECH - LIVBL - NFC Mobile Handset High Level Requirements - v2.0.doc AFSCM NFC Mobile Handset High Level Requirements v2.0 p1/23

2 Name Company Authors Pierre Le Pallec Bouygues Telecom Ahmad Saif Orange Thierry Simon SFR Sébastien Gauthier AFSCM Document Manager Sébastien Gauthier AFSCM Approval Laurence Becq AFSCM Document management Version Date Chapters Modifications /03/2008 Document Creation 0.2 2/10/2008 all First release /12/2008 First version sent to handset manufacturers 1.1 (ex 2.0) 20/07/ Tag read specifications added 1.2 (ex 3.1) 30/07/2009 all Copyright licence added in introduction, table of contents modified 1.3 (ex 3.2) 24/08/2009 all Document template updated, table of contents modified 2.0 DRAFT 27/07/2011 all Draft release of version /08/ UICC secure access API reference added AFSCM NFC Mobile Handset High Level Requirements v2.0 p2/23

3 TABLE OF CONTENTS 1 Introduction Context Copyright license Acronyms References GPP specifications SCP specifications JSR Specifications NFC Forum Specifications Android specifications Operating system environments Mobile NFC Handset Technical requirements Mobile NFC Handset Architecture Overview Android-specific requirements Java / MIDP-specific requirements Java / RIM-specific requirements NFC Services User Primary Interface (UPI) MNO Wallet Global architecture UPI Overview Handset registry UPI requirements Java / MIDP-specific UPI requirements NFC API requirements NFC events requirements Security requirements Java / MIDP-specific security requirements Android-specific security requirements Required NFC Features CLF Required Features Secure Element UICC Required Features Remote management of NFC services (Access to UICC in connected mode) NFC tag reading/writing Architecture overview Tag reading/writing requirements Tag data format Requirements summary Appendix A AFSCM NFC Mobile Handset High Level Requirements v2.0 p3/23

4 1 INTRODUCTION 1.1 Context AFSCM was established in April 2008 by Bouygues Telecom, Orange and SFR as a non-profit organization to foster the development of mobile contactless services. AFSCM objective is to support the inception of new contactless services for mobile phone users. In particular, AFSCM endeavors: To support service providers such as banks or transit authorities in the definition and deployment of contactless solutions suited for mobile subscribers to any available mobile network; To specify technical guidelines for the development of mobile contactless services to ensure seamless installation and consistent user experience ; To promote the benefits of the mobile phone platform for contactless service providers, for technology providers and for end users. To define a mutually beneficial mobile contactless eco-system, AFSCM will propose a shared mobile contactless target mark and a shared brand that will distinguish those contactless services that are available to mobile phone users. AFSCM constituency will include all companies involved in the development of a sustainable market for mobile contactless services such as service providers, handset makers, Smart Card Manufacturers, mobile network operators, MVNOs. Together, AFSCM members will contribute to the definition of innovative industry standards and best practices. The stated objective of the AFSCM is to facilitate the development of mobile contactless services. To this end, the founding members recognize the significance of the following success factors: virtuous eco-system in which all parties involved can develop a sustainable market position efficient customer support smooth customer experience state-of-the art application life cycle management service portability in the event of a ME swap service portability in the event of a MNO swap The purpose of this document is to provide handset manufacturers with a set of common NFC handset high level specifications consistent with this objective. The AFSCM cannot be held liable to anyone for: the use and/or publication of all or part of this document, the accuracy of this document and/or its suitability for any specific needs, any development that arises from it. AFSCM NFC Mobile Handset High Level Requirements v2.0 p4/23

5 This document remains the exclusive property of the AFSCM. This document may not be copied, translated or divulged to third parties in their present or modified form except with the prior written consent of the AFSCM. This document is supplied "AS-IS" and the AFSCM does not claim and cannot accept any liability for any errors or omissions in this document. The AFSCM makes no guarantees and refuses all liability with regard to the content of this document, and in particular any breaches of intellectual property rights such as patents, trademarks, copyright or other intellectual property rights belonging to third parties in relation to all or part of this document. On this basis, no claims and/or legal proceedings relating to the use of this document can be brought against the AFSCM or any of its members. In no case can any members of the AFSCM be held liable for any losses caused to the User or anyone else by the direct and/or indirect use of this document, such as, but not limited to, losses of income, financial losses (including cases of breach of intellectual property rights) and losses of information. 1.2 Copyright license The following document is a personal, non-exclusive copyright license between you - the Licensee - and the AFSCM founding members (*), regarding the AFSCM specifications, that must be included in any copy of said specifications. The licensee is authorized to copy, present or communicate the AFSCM specifications on any media without having to pay any license fee under the condition that the following copyright notice be included in any copy or any excerpt of the specifications: «(Association Française du Sans Contact Mobile ; ). All rights reserved. Terms and conditions to copy, display and communicate these Specifications are available at The licensee is NOT authorized to create or disclose modifications or abstracts of the specifications or work derived from the specifications. The specifications include detailed functional specifications, technical specifications, NFC handset and NFC UICC implementation guidelines, application development guidelines (midlet and cardlet) and SP-MNO interconnection guidelines. Separate patent licenses and additional materials will be proposed to those wanting to implement solutions compliant with the AFSCM specifications, under licensing conditions to be defined in separate agreements. Information for procuring such patent licenses and additional materials documents is contained in Annex 1. THE SPECIFICATIONS ARE SUPPLIED "AS IS" AND NEITHER THE AFSCM NOR ITS MEMBERS ARE COMMITTED TO ANY WARRANTY, EXPLICIT OR IMPLICIT, REGARDING THE SPECIFICATIONS, IN PARTICULAR NO WARRANTY IS GIVEN OF QUALITY, SUITABILITY TO ANY USE WHATSOEVER, ABSENCE OF TITLE OR RIGHTS TO THE CONTENT OF THE SPECIFICATIONS, INSURANCE THAT THE USE OF THE SPECIFICATIONS WILL NOT INFRINGE INTELLECTUAL PROPRETY RIGHTS OF A THIRD PARTY SUCH AS PATENTS, TRADE MARKS, COPYRIGHTS. NEITHER THE AFSCM NOR ITS MEMBERS SHALL BE HELD LIABLE FOR ANY DAMAGE INCURRED IN CONNECTION TO THE USE, REPRESENTATION OR COMMUNICATION OF THE SPECIFICATIONS. Neither the AFSCM name nor its trade marks shall be used under any circumstances, such as to communicate or advertise the specifications without the prior written agreement of the AFSCM. No rights other than the rights described above are granted under this license and the rights granted under this license cannot be construed as conferring, implicitly or explicitly, any rights (through a licensing agreement or any other means) concerning AFSCM or AFSCM members inventions, know- AFSCM NFC Mobile Handset High Level Requirements v2.0 p5/23

6 how or intellectual property, or any of their assets resulting from, based on or required in the specifications. This copyright license is subject to French law and shall be governed by and interpreted according to French laws. The exclusive place of jurisdiction shall be the Paris Court of Appeal, regardless of the number of claims or defendants. By downloading the AFSCM specifications, you indicate your acceptance of these terms and conditions. (*) : AFSCM founding members are : Bouygues Telecom, Orange France / France Telecom, SFR 1.3 Acronyms NFC: AFSCM: API: BB: BIP: CLF: CLT: JCP: HCI: JSR: LLCP: ME: MIDP: MNO: NFC: RF: SCWS: SE: SIM: SWP: UPI: UICC: Near Field Communication Association Française du Sans Contact Mobile Application Programming Interface Base Band Bearer Independent Protocol ContactLess Frontend ContactLess Tunnelling Java Community Process Host Controller Interface Java Specification Request Logical Link Control Protocol Mobile Equipment Mobile Information Device Profile: Mobile Network Operator Near Field Communication Radio Frequency Smart Card Web Server Secure Element Subscriber Identity Module Single Wire Protocol User Primary Interface Universal Integrated Circuit Card (aka SIM) 1.4 References All standard reference(s) can be found in the following list: GPP specifications [1] 3GPP TS (v6.7.0, Rel-6): Technical realization of the Short Message Service (SMS) [2] 3GPP TS (v5.9.0, Rel-5): Security Mechanisms for the (U)SIM application toolkit; Stage 2 [3] 3GPP TS (v6.9.0, Rel-6): USIM Application Toolkit (USAT) SCP specifications [4] ETSI TS (Rel-9): Card Application Toolkit [5] ETSI TS (Rel-9): Secured packet structure for UICC applications [6] ETSI TS (Rel-9): Remote APDU Structure for UICC based Applications [7] ETSI TS (Rel-9): UICC Java Card API - Stage 1 [8] ETSI TS (Rel-9): UICC Java Card API - Stage 2 [9] ETSI TS (Rel-9): Smart Cards: UICC - Contactless Front-end (CLF) Interface; Part 1: Physical and data link layer characteristics AFSCM NFC Mobile Handset High Level Requirements v2.0 p6/23

7 [10] ETSI TS (Rel-9): Smart Cards: UICC - Contactless Front-end (CLF) interface; Host Controller Interface (HCI) [11] ETSI TS (Rel-9): Smart Cards; UICC Application Programming Interface for Java Card for Contactless Applications JSR Specifications [12] JCP JSR : Mobile Information device Profile -Trusted MIDlet suites using X509 PKI [13] JCP JSR : Security and Trust Services API for J2ME [14] JCP JSR : Content Handler API [15] JCP JSR : Contactless Communication API [16] Services Framework API, based on the JCP JSR draft document, and finalized by Orange. This API is free for implementation and use and is included in this document in Appendix A NFC Forum Specifications [17] NFCForum-TS-Type-1-Tag_1.0 [18] NFCForum-TS-Type-2-Tag_1.0 [19] NFCForum-TS-Type-3-Tag_1.0 [20] NFCForum-TS-Type-4-Tag_2.0 [21] NFCForum-TS-GenericControlRTD_1.0 [22] NFCForum-SmartPoster_RTD_1.0 [23] NFCForum-TS-NDEF_1.0 [24] NFCForum-TS-RTD_1.0 [25] NFCForum-TS-RTD_Text_1.0 [26] NFCForum-TS-RTD_URI_1.0 [27] NFCForum-TS-Signature-1.0 [28] NFCForum-TS-LLCP_ Android specifications [29] SIMalliance Open Mobile API, Release v.1.01 [30] [31] UICC secure access API: GP_DC_secure_element_access_control_gemalto_technical_solution_v Operating system environments This document addresses both global requirements and environment specific requirements. When necessary, the document will indicate when a section deals with the: Java / MIDP environment Java / RIM environment Android environment AFSCM NFC Mobile Handset High Level Requirements v2.0 p7/23

8 2 MOBILE NFC HANDSET TECHNICAL REQUIREMENTS 2.1 Mobile NFC Handset Architecture Overview The NFC mobile device is divided in three main components: The NFC controller and connected antenna The secure element The application processor (called also Base Band) The Mobile NFC Handset (as shown below) offers three different interfaces: the contactless one, the OTA one, and the MMI (Man Machine Interface). The Secure element to store and execute NFC secure applications is the UICC. The UICC will be designed to comply with NFC service requirements and to interface with the other components of the ecosystem. MNO Trusted third party Mobile handset (Application processor = baseband) Browser Mobile UICC API Mobile app Network access Mobile NFC API UICC CAT proactive commands ISD SSD 1 NFC application App 1 App 2 App n SSD 2 App SSD n App UICC NFC API CLF Peer to peer interface (LLCP) R/W interface Card emulation interface NFC device NFC tag Merchant POS Figure 1: General Architecture of the NFC Device AFSCM NFC Mobile Handset High Level Requirements v2.0 p8/23

9 Element Browser Mobile app Network access Mobile UICC API Mobile NFC API CAT UICC NFC API NFC application App 1 to App n CLF ISD SSD Description The browser inside the Handset displays internet pages (HTML), WAP (WML, XML) pages The mobile application is a program loaded inside the handset which acts as a graphical interface to a specific mobile NFC service Unit of the mobile phone used to communicate through the telecom network via GSM, GPRS, EDGE, UMTS, HSDPA, Telecom bearers The UICC API of the handset allows any mobile application installed on the handset to communicate with the UICC card using APDU commands The NFC API of the handset allows any mobile application installed on the handset to communicate with the CLF. It also allows the cardlet to communicate with the mobile application (when invoked by a POS for instance). The Card Application Toolkit provides mechanisms which allow applications, existing in the SIM, to interact and operate with any Mobile equipment which supports the specific mechanism(s) required by the application Specific Java card API which allows to the UICC card (Specially Java card applications embedded inside) to communicate with the NFC controller Java card application which allows managing all NFC applications Applications loaded into UICC The Contactless Frontend (or NFC controller) is a NFC chip which allows the handset to communicate through the NFC bearer using three different modes: card emulation, card reader, peer to peer The Issuer Security Domain is the primary, mandatory on-card representative of the Card Administrator, typically the Card Issuer A Supplementary Security Domain is an additional, optional on-card representative of an Application Provider or the Card Issuer Android-specific requirements This section is dedicated to handsets in an Android mobile environment. API_ANDROID_REQ_01 The Mobile UICC API used in the Android architecture is: the org.simalliance.openmobileapi API, described in [29], to gain access to the UICC API_ANDROID_REQ_02 the uicc.secure.access.api API, described in [31], to secure the access to the UICC The Mobile NFC API used in the Android architecture is the android.nfc API, described in [30]. AFSCM NFC Mobile Handset High Level Requirements v2.0 p9/23

10 2.1.2 Java / MIDP-specific requirements This section is dedicated to handsets in a Java / MIDP mobile environment. API_MIDP_REQ_01 The Mobile UICC API used in the Java / MIDP architecture is the JSR 177 API_MIDP_REQ_02 The Mobile NFC API used in the Java / MIDP architecture is the JSR Java / RIM-specific requirements This section is dedicated to handsets in a Java / MIDP mobile environment. API_RIM_REQ_01 The Mobile UICC API used in the Java / RIM architecture is the JSR 177 API_RIM_REQ_02 The Mobile NFC API used in the Java / RIM architecture is the net.rim.device.api.io.nfc package and its sub-packages 2.2 NFC Services User Primary Interface (UPI) MNO Wallet The UPI is intended to facilitate the User experience while accessing the NFC Services portfolio. The UPI lists all Service Provider mobile NFC services loaded into the Mobile Equipment/UICC and displays their current status. Furthermore this list allows the user to launch the MMI associated with the services. Moreover, this interface may allow the end user to manage the NFC settings of his handset. This section describes the APIs required by the implementation of the NFC UPI. AFSCM NFC Mobile Handset High Level Requirements v2.0 p10/23

11 2.2.1 Global architecture This figure describes the global architecture: MNO UPI Service providers applications NFC Services Mobile environment Application 1 Service 1 Service 2 Application 2 Application 3 Service 3 MNO UPI Exit Menu Mobile handset registry UICC Umbrella application Figure 2: UPI Architecture Overview UPI Element Service Provider s applications or MMI Handset registry Umbrella Application Description User s Primary Interface for accessing NFC Services Mobile application serving as a graphical interface to the mobile NFC service of a Service Provider A database used to link UPI and SP MMI UICC Application listing NFC JavaCard applications in the UICC AFSCM NFC Mobile Handset High Level Requirements v2.0 p11/23

12 2.2.2 UPI Overview Both MNO UPI and SP MMI are mobile applications loaded into the ME. The AFSCM architecture defines two kinds of mobile applications: UPI application under the responsibility of MNO. SP MMI under the responsibility of the SP. Each SP MMI is represented by one entry in the UPI with at least the following information: Service name Service logo Service Provider Name Life cycle status Handset registry In order to list the NFC Services installed on the handset, the UPI shall access a specific shareable NFC database (Handset registry) which references the SP MMI that are installed and their related data (service name, logo, etc ). This NFC database is shared between the SP MMI and the MNO UPI. Each record of the handset registry corresponds to one Service Provider Application, with its associated data. Each SP MMI shall only access its own information in the ME Registry. It is recommended that the Operating System of the handset guarantees the confidential access to the handset registry UPI requirements UPI_REQ_01 UPI_REQ_02 UPI_REQ_03 UICC secure application management (APDU Exchange) The handset shall include an API enabling communication of the mobile applications with applications loaded into the UICC by exchanging ISO APDU For Java / MIDP: JSR 177 (APDU Exchange) For Android: the org.simalliance.openmobileapi API, described in [29] Third party application launching The handset shall include an API enabling the MNO UPI to launch third party applications. If the system allow multiple concurrent applications, both applications are staying alive; else only the third party application goes on; In this case this application shall hand over back to the MNO MMI when closing. For Java / MIDP: JSR 320 (as described in [16]) or JSR 211 For Android: Intent mechanism Application auto-updating The handset shall include an API enabling the UPI Application to update itself. AFSCM NFC Mobile Handset High Level Requirements v2.0 p12/23

13 For Java / MIDP: JSR 320 (as described in [16]) For Android: included in the Android framework Java / MIDP-specific UPI requirements This section is dedicated to handsets in a Java / MIDP mobile environment. UPI_MIDP_REQ_01 UPI_MIDP_REQ_02 Third party application installing/uninstalling The handset shall implement the JSR 320 (as described in [16]), enabling an application (such as the MNO wallet) to load, install and uninstall third party applications. RecordStore entries storage Service Providers mobile applications shall be able to create at least 100 RecordStore entries in the following format: Record Id Description Format 1 Version ASCII (ex : shall be written ) 2 Label (service name to display in the UPI main screen) 3 Logo (service logo to display in the UPI main screen) 4 Logo 2 (alternative service logo to display in the UPI main screen) 5 Long AID of Cardlet application ASCII Binary Binary Binary 6 Service Type 1 Byte 7 RecordStore Version ASCII (ex : 1.0 shall be written 0100) 2.3 NFC API requirements NFC events requirements API_REQ_01 The CLF shall be able to trigger a mobile application (as defined in [10]) A NFC event (on POS transaction, on tag reading ) must be able to trigger a mobile application: On tag reading, a NDEF is pushed from the CLF to the system On a POS reader transaction, a secure element push shall be AFSCM NFC Mobile Handset High Level Requirements v2.0 p13/23

14 understood as a UICC push through a HCI event (a.k.a. EVT_TRANSACTION) and will be able to provide the cardlet s AID with private data support as described in [10] The handset shall implement: For Java / MIDP: JSR 257 with appendix B implemented For Android: Card Events through HCI shall be implemented, and applications shall be able to register for the events using intent filters For Java / RIM: the net.rim.device.api.io.nfc package and its sub-packages API_REQ_02 Multi-SE environment requirements Whether or not the handset hosts an NFC capable embedded secure element, there should be an API that allows the following Identify which secure element is responding in card emulation Define which secure element is responding in card emulation At any given point in time, only one secure element should be active in card emulation mode Security requirements SEC_REQ_01 Only authorized mobile applications shall be able to access the UICC applications For Java / MIDP (also applicable in the Java / RIM environment): o o the mobile NFC Handset shall implement a Protection Domain as a set of permissions defined to limit access to some APIs only signed midlets shall be able to access the UICC using the JSR177 ([13]) For Android: only signed mobile applications, with a valid ACF corresponding to this signature, shall be able to access to the corresponding applications in the UICC, using the uicc.secure.access.api API, described in [31]. SEC_REQ_02 Certificates and permissions management For Java / MIDP: the handset shall implement JSR 118 ([12]) o o Mandatory: Certificates which give some access to the Protection Domain are loaded into the mobile (i.e. JSR118) (also applicable to the RIM environment) Optional: Certificates which give some access to the Protection Domain can be loaded into the SIM card (PKCS#15 files) For Android: the handset shall implement the AFSCM NFC Mobile Handset High Level Requirements v2.0 p14/23

15 uicc.secure.access.api API, described in [31] API and Android permissions Java / MIDP-specific security requirements This section is dedicated to handsets in a Java / MIDP mobile environment. SEC_MIDP_REQ_01 Access to UICC applications is forbidden using JSR257. For security reasons, the implementation of JSR257 SHALL NOT implement access to the UICC. The mobile applications shall access NFC applications on the UICC using the JSR Android-specific security requirements This section is dedicated to handsets in an Android mobile environment. SEC_ANDROID_REQ_01 Eavesdropping protection in Android The card emulation transaction event should also be protected from eavesdropping by checking whether the target application has access to the source AID in the UICC through the UICC access API (the same security policy shall apply). 2.4 Required NFC Features CLF Required Features The CLF enables contactless communication and shall support the following requirements: NFC_REQ_01 NFC_REQ_02 NFC_REQ_03 RF compliance The handset s NFC chipset & antenna are compliant with contactless reader infrastructure (ISO A & B) The CLF shall support the card emulation mode: Using ISO A & B Mifare support is optional Felica support not required The CLF shall support the tag reader mode: Using ISO A & B AFSCM NFC Mobile Handset High Level Requirements v2.0 p15/23

16 NFC Tag reading capability enabled Supports reading at least NFC Forum Type tags NFC Forum Type 3 tags not required NFC_REQ_04 NFC_REQ_05 NFC_REQ_06 NFC_REQ_07 NFC_REQ_08 NFC_REQ_09 NFC_REQ_10 NFC_REQ_11 The CLF shall support the tag writer mode: Using ISO A & B NFC Tag writing capability enabled Supports writing at least NFC Forum Type tags NFC Forum Type 3 tags not required The CLF shall support the peer-to-peer (LLCP) mode with a transfer rate of at least 206Kbps NFC function toll on autonomy Automatic and continuous switch between card emulation and reader mode. If this switch is permanent, the decrease of the autonomy of the phone in standby mode shall be less than 10%.compared to the standby time when the NFC is totally off. If this 10% threshold can t be reached, the automatic switch shall be applied only when the keyboard is activated or the screen back lighted. Minimum battery requirements in battery low mode When the battery is low and the phone is automatically switched off (no more screen display possible, no more phone calls, no more mobile data exchange), the phone shall have the capability to supply a source of power to perform a few transactions (50 transactions) in card emulation mode for at least 24 hours Transactions in battery low mode NFC transactions shall be possible in battery low mode for public transportation application but shall not be possible for payment application. NFC mobile phone test methods To address mobile phones, a new class of devices is under study within ISO/SC17 committee in charge of ISO specifications. NFC mobile phones shall comply with upcoming test methods on the RF interface which will be considered in ISO SWP support The CLF shall support the SWP standard as defined in [9] HCI support The CLF shall support the HCI standard as defined in [10] Secure Element UICC Required Features The Secure element to store and execute NFC secure applications is the UICC. [Note] For information purpose, the Mobile NFC UICC shall be compliant with the Java Card technology and UICC Config AFSCM NFC Mobile Handset High Level Requirements v2.0 p16/23

17 UIC_REQ_01 UIC_REQ_02 NFC SIM cards compliance The NFC handset shall be compliant with the NFC SIM cards that are compliant with SWP ([9]) & HCI ([10]). NFC Transaction duration The UICC and Mobile Environment shall allow the shortest delay possible between the REQ command and the response to a ISO 7816 Select command in order to ensure an acceptable user experience. For information, the targeted duration of a mobile NFC transit transaction is ms UIC_REQ_03 CLT mode support The handset supports the CLT mode (Mifare), as defined in [9] Remote management of NFC services (Access to UICC in connected mode) In order for the MNO or the SP to perform the remote management of NFC services, and access the UICC in connected mode, the mobile NFC handset shall implement standards SIM OTA protocol (SMS, Security, Proof Of Receipt ) OTA_REQ_01 OTA_REQ_02 OTA_REQ_03 BIP support The handset shall support the BIP protocol in client mode (UDP) BIP proactive commands and CAT events The handset must be "class e" compliant and BIP (Client) in Transparent mode (Alpha-ID = NULL) shall be supported. The handset must support the following proactive commands and CAT (Card application Tool KIT) events issued by the UICC, described in [3] and [4]: Proactive commands o o o o o Events o o OPEN CHANNEL CLOSE CHANNEL SEND DATA RECEIVE DATA GET CHANNEL STATUS DATA AVAILABLE CHANNEL STATUS UICC standards compliance The handset must be compliant with the UICC standards, and in particular does not limit or prevent UICC OTA functionalities described in [5], [6] and [1] AFSCM NFC Mobile Handset High Level Requirements v2.0 p17/23

18 2.5 NFC tag reading/writing Architecture overview UICC Umbrella application Application 1 Application 2 Application 3 Mobile handset Certificate control Tag reading / writing native application Mobile NFC API NFC controller NFC tag Figure 3: Tag reading / writing architecture overview Tag reading/writing requirements The tag reading user interface shall comply with the following requirements: TAG_REQ_01 TAG_REQ_02 Mandatory tag reading/writing features The handset shall support the following NFC tag reading/writing features: Launch phone call Send SMS and MMS Launch Browser Launch Service Provider application Optional tag reading/writing features The handset may support the following NFC tag reading/writing features: Launch mobile native function Store different content in mobile: AFSCM NFC Mobile Handset High Level Requirements v2.0 p18/23

19 o Note o Contact o Calendar o Multimedia Pairing Tag Writing TAG_REQ_03 TAG_REQ_04 TAG_REQ_05 TAG_REQ_06 TAG_REQ_07 TAG_REQ_08 TAG_REQ_09 TAG_REQ_10 TAG_REQ_11 Tag reading application launch The triggering of the tag application shall be transparent for the user while reading a tag Tag reading/nfc activation/de-activation The tag reading application cannot be specifically activated / deactivated by the user. However, when the NFC feature is being globally activated / deactivated by the user on his handset, all NFC features must be activated / deactivated (including the emulation card mode and the tag reader mode). Tag reading performance The user shall be informed in less than 500 ms that a tag is being read, which ensures an acceptable user experience NFC Forum Smart Poster support The user shall be able to read/write the NFC Forum Smart Poster Tag. NFC Forum Generic Control Tag support The mobile shall be able to read the NFC Forum Generic Control Tag. Tag signature verification The mobile shall be able to verify NFC tags signatures. The tags signature follows the NFC Forum RTD signature specification. Tag reading distance NFC tags shall be read from 4 cm to 0 cm User prompt following tag reading Following a tag read, once the tag reading application is launched, the user shall be prompted before an action is performed Reading un-trusted tags When reading a tag that cannot be authenticated by the tag reading application, the user shall be explicitly prompted that the tag is untrusted. However, reading the tag shall remain possible. It shall be possible to enable/disable this prompt in factory settings Tag data format TAG_REQ_12 Tag writing format Tag data must be written in NDEF following the NFC Forum SmartPoster RTD AFSCM NFC Mobile Handset High Level Requirements v2.0 p19/23

20 specification For all the undefined cases, the URI 0x00 Identifier code is used TAG_REQ_13 Tag writing format complement For all undefined cases using the 0x00 URI identifier code, data written on tags should be formatted as: Type Format Text V-Card VCARD (Seer RFC2426) Text Calendar VEVENT (See RFC2445) Text Notes VTODO (See RFC2445) URI05 Phone Number Phone number (See RFC3966) URI00 SMS sms:recipient?body=message (cf draft-wilde-sms-uri-09) URI Web Browser (see RFC2616) GC JAVA VM See Generic Control Specification URI USSD Session ussd: (see RFC3966) URI00 MMS mms:recipient?subject=subj&body=message (cf draftwugofski-mms-uri-scheme-00) URI mailto: (see RFC3966) URI video-phone functionality video: (See RFC3966) [Note] V-Card, Calendar, and Notes are directly read on the tag. Data format complies with the RFC2426 format for Vcard, and the RFC2445 format for calendar and notes. [Note] For SMS and MMS, the phone number is directly read from the tag AFSCM NFC Mobile Handset High Level Requirements v2.0 p20/23

21 3 REQUIREMENTS SUMMARY API_ANDROID_REQ_01 API_ANDROID_REQ_02 API_MIDP_REQ_01 API_MIDP_REQ_02 API_RIM_REQ_01 API_RIM_REQ_02 UPI_REQ_01 UPI_REQ_02 UPI_REQ_03 UPI_MIDP_REQ_01 UPI_MIDP_REQ_02 API_REQ_01 API_REQ_02 SEC_REQ_01 SEC_REQ_02 SEC_MIDP_REQ_01 SEC_ANDROID_REQ_01 NFC_REQ_01 NFC_REQ_02 NFC_REQ_03 NFC_REQ_04 NFC_REQ_05 NFC_REQ_06 NFC_REQ_07 NFC_REQ_08 NFC_REQ_09 NFC_REQ_10 NFC_REQ_11 UIC_REQ_01 UIC_REQ_02 Requirement title The Mobile UICC API used in the Android architecture The Mobile UICC API used in the Android architecture The Mobile UICC API used in the Java / MIDP architecture The Mobile NFC API used in the Java / MIDP architecture The Mobile UICC API used in the Java / MIDP architecture The Mobile NFC API used in the Java / MIDP architecture UICC secure application management (APDU Exchange) Third party application launching Application auto-updating Third party application installing/uninstalling RecordStore entries storage The CLF shall be able to trigger a mobile application Multi-SE environment requirements Only authorized mobile applications shall be able to access the UICC applications Certificates and permissions management Access to UICC applications is forbidden using JSR257 Eavesdropping protection in Android RF compliance The CLF shall support the card emulation mode The CLF shall support the tag reader mode The CLF shall support the tag writer mode The CLF shall support the peer-to-peer (LLCP) mode NFC function toll on autonomy Minimum battery requirements in battery low mode Transactions in battery low mode NFC mobile phone test methods SWP support HCI support NFC SIM cards compliance NFC Transaction duration AFSCM NFC Mobile Handset High Level Requirements v2.0 p21/23

22 UIC_REQ_03 OTA_REQ_01 OTA_REQ_02 OTA_REQ_03 TAG_REQ_01 TAG_REQ_02 TAG_REQ_03 TAG_REQ_04 TAG_REQ_05 TAG_REQ_06 TAG_REQ_07 TAG_REQ_08 TAG_REQ_09 TAG_REQ_10 TAG_REQ_11 TAG_REQ_12 TAG_REQ_13 CLT mode support BIP support BIP proactive commands and CAT events UICC standards compliance Mandatory tag reading/writing features Optional tag reading/writing features Tag reading application launch Tag reading/nfc activation/de-activation Tag reading performance NFC Forum Smart Poster support NFC Forum Generic Control Tag support Tag signature verification Tag reading distance User prompt following tag reading Reading un-trusted tags Tag writing format Tag writing format complement AFSCM NFC Mobile Handset High Level Requirements v2.0 p22/23

23 4 APPENDIX A The following file contains the javadoc documentation of the API described in [16]. End of document AFSCM NFC Mobile Handset High Level Requirements v2.0 p23/23