AFSCM NFC Mobile Handset High Level Requirements v2.0 p1/23
NFC Mobile Handset High Level Requirements
V2
Release 2.0
Date : 28/09/2011Reference: 110928 - AFSCM TECH - LIVBL - NFC Mobile Handset High Level Requirements - v2.0.doc
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
0.1 28/03/2008 Document Creation
0.2 2/10/2008 all First release
1.0 24/12/2008 First version sent to handset manufacturers 1.1 (ex 2.0) 20/07/2009 3.4 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 2
TABLE OF CONTENTS
1 Introduction ... 4 1.1 Context ... 4 1.2 Copyright license ... 5 1.3 Acronyms ... 6 1.4 References ... 6 1.4.1 3GPP specifications ... 6 1.4.2 SCP specifications ... 6 1.4.3 JSR Specifications... 7 1.4.4 NFC Forum Specifications ... 7 1.4.5 Android specifications ... 71.5 Operating system environments ... 7
2 Mobile NFC Handset Technical requirements ... 8
2.1 Mobile NFC Handset Architecture Overview... 8
2.1.1 Android-specific requirements ... 9
2.1.2 Java / MIDP-specific requirements ... 10
2.1.3 Java / RIM-specific requirements ... 10
2.2 NFC Services User Primary Interface (UPI) – MNO Wallet ... 10
2.2.1 Global architecture ... 11
2.2.2 UPI Overview ... 12
2.2.3 Handset registry ... 12
2.2.4 UPI requirements ... 12
2.2.5 Java / MIDP-specific UPI requirements ... 13
2.3 NFC API requirements ... 13
2.3.1 NFC events requirements ... 13
2.3.2 Security requirements ... 14
2.3.3 Java / MIDP-specific security requirements ... 15
2.3.4 Android-specific security requirements ... 15
2.4 Required NFC Features ... 15
2.4.1 CLF Required Features ... 15
2.4.2 Secure Element UICC Required Features ... 16
2.4.3 Remote management of NFC services (Access to UICC in connected mode) ... 17
2.5 NFC tag reading/writing ... 18
2.5.1 Architecture overview ... 18
2.5.2 Tag reading/writing requirements ... 18
2.5.3 Tag data format ... 19
3 Requirements summary ... 21
1 I
NTRODUCTION
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.
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:
« Copyright © AFSCM 2008-2011 (Association Française du Sans Contact Mobile ;
http://www.afscm.org/ ). All rights reserved. Terms and conditions to copy, display and communicate these Specifications are available at http://www.afscm.org/conditions.html »
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-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: Near Field Communication
AFSCM: Association Française du Sans Contact Mobile API: Application Programming Interface
BB: Base Band
BIP: Bearer Independent Protocol CLF: ContactLess Frontend
CLT: ContactLess Tunnelling JCP: Java Community Process HCI: Host Controller Interface JSR: Java Specification Request LLCP: Logical Link Control Protocol
ME: Mobile Equipment
MIDP: Mobile Information Device Profile: MNO: Mobile Network Operator
NFC: Near Field Communication
RF: Radio Frequency
SCWS: Smart Card Web Server
SE: Secure Element
SIM: Subscriber Identity Module SWP: Single Wire Protocol UPI: User Primary Interface
UICC: Universal Integrated Circuit Card (aka SIM)
1.4 References
All standard reference(s) can be found in the following list: 1.4.1 3GPP specifications
[1] 3GPP TS 23.040 (v6.7.0, Rel-6): Technical realization of the Short Message Service (SMS) [2] 3GPP TS 23.048 (v5.9.0, Rel-5): Security Mechanisms for the (U)SIM application toolkit; Stage 2 [3] 3GPP TS 31.111 (v6.9.0, Rel-6): USIM Application Toolkit (USAT)
1.4.2 SCP specifications
[4] ETSI TS 102 223 (Rel-9): Card Application Toolkit
[5] ETSI TS 102 225 (Rel-9): Secured packet structure for UICC applications [6] ETSI TS 102 226 (Rel-9): Remote APDU Structure for UICC based Applications [7] ETSI TS 102 240 (Rel-9): UICC Java Card™ API - Stage 1
[8] ETSI TS 102 241 (Rel-9): UICC Java Card™ API - Stage 2
[9] ETSI TS 102 613 (Rel-9): Smart Cards: UICC - Contactless Front-end (CLF) Interface; Part 1: Physical and data link layer characteristics
[10] ETSI TS 102 622 (Rel-9): Smart Cards: UICC - Contactless Front-end (CLF) interface; Host Controller Interface (HCI)
[11] ETSI TS 102 705 (Rel-9): Smart Cards; UICC Application Programming Interface for Java Card™ for Contactless Applications
1.4.3 JSR Specifications
[12] JCP – JSR-000118: Mobile Information device Profile -Trusted MIDlet suites using X509 PKI [13] JCP – JSR-000177: Security and Trust Services API for J2ME
[14] JCP – JSR-000211: Content Handler API
[15] JCP – JSR-000257: Contactless Communication API
[16] Services Framework API, based on the JCP – JSR-000320 draft document, and finalized by Orange. This API is free for implementation and use and is included in this document in
Appendix A. 1.4.4 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_1.00 1.4.5 Android specifications
[29] SIMalliance Open Mobile API, Release v.1.01
[30] http://developer.android.com/guide/topics/nfc/index.html
[31] UICC secure access API:
GP_DC_secure_element_access_control_gemalto_technical_solution_v1.2.1
1.5 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
2 M
OBILE
NFC
H
ANDSET
T
ECHNICAL 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.
CLF
Peer to peer
interface (LLCP) R/W interface
Card emulation interface
NFC device NFC tag Merchant POS
UICC ISD SSD 1 NFC application App 1 App 2 App n SSD 2 App SSD n App UICC NFC API
CAT – proactive commands
Mobile handset (Application processor = baseband)
Browser Network access
Mobile UICC API
Mobile app
Mobile NFC API MNO Trusted third
party
Figure 1: General Architecture of the NFC Device
Element Description
Browser The browser inside the Handset displays internet pages (HTML), WAP (WML, XML) pages
Mobile app The mobile application is a program loaded inside the handset which acts as a graphical interface to a specific mobile NFC service
Network access Unit of the mobile phone used to communicate through the telecom network via GSM, GPRS, EDGE, UMTS, HSDPA,… Telecom bearers
Mobile UICC API The UICC API of the handset allows any mobile application installed on the handset to communicate with the UICC card using APDU commands Mobile NFC API 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).
CAT 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
UICC NFC API Specific Java card API which allows to the UICC card (Specially Java card applications embedded inside) to communicate with the NFC controller NFC application Java card application which allows managing all NFC applications
App 1 to App n Applications loaded into UICC
CLF 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
ISD The Issuer Security Domain is the primary, mandatory on-card representative of the Card Administrator, typically the Card Issuer
SSD A Supplementary Security Domain is an additional, optional on-card representative of an Application Provider or the Card Issuer
2.1.1 Android-specific requirements
This section is dedicated to handsets in an Android mobile environment.
Requirement # Requirement description 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
the uicc.secure.access.api API, described in [31], to secure the access to the UICC
API_ANDROID_REQ_02 The Mobile NFC API used in the Android architecture is the android.nfc API, described in [30].
2.1.2 Java / MIDP-specific requirements
This section is dedicated to handsets in a Java / MIDP mobile environment.
Requirement # Requirement description
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 257
2.1.3 Java / RIM-specific requirements
This section is dedicated to handsets in a Java / MIDP mobile environment.
Requirement # Requirement description
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.
2.2.1 Global architecture
This figure describes the global architecture:
UICC
Mobile environment
MNO UPINFC Services
Service 1
Service 2
Service 3
Exit
Menu
Application 1
Application 2
Application 3
MNO UPI
Service providers’ applications
Umbrella application Mobile handset registry Figure 2: UPI Architecture Overview
Element Description
UPI User’s Primary Interface for accessing NFC Services Service Provider’s
applications or MMI
Mobile application serving as a graphical interface to the mobile NFC service of a Service Provider
Handset registry A database used to link UPI and SP MMI
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 2.2.3 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.
2.2.4 UPI requirements
Requirement # Requirement description UPI_REQ_01 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 7816-4 APDU
For Java / MIDP: JSR 177 (APDU Exchange)
For Android: the org.simalliance.openmobileapi API, described in [29]
UPI_REQ_02 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
UPI_REQ_03 Application auto-updating
The handset shall include an API enabling the UPI Application to update itself.
For Java / MIDP: JSR 320 (as described in [16]) For Android: included in the Android framework
2.2.5 Java / MIDP-specific UPI requirements
This section is dedicated to handsets in a Java / MIDP mobile environment.
Requirement # Requirement description UPI_MIDP_REQ_01 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.
UPI_MIDP_REQ_02 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 : 1.0.12 shall be
written 010012) 2 Label (service name to
display in the UPI main screen)
ASCII
3 Logo (service logo to display in the UPI main screen)
Binary
4 Logo 2 (alternative service logo to display in the UPI main screen)
Binary
5 Long AID of Cardlet application
Binary
6 Service Type 1 Byte
7 RecordStore Version ASCII (ex : 1.0 shall be written 0100)
2.3 NFC API requirements
2.3.1 NFC events requirementsRequirement # Requirement description
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
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.
2.3.2 Security requirements
Requirement # Requirement description
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 the mobile NFC Handset shall implement a Protection
Domain as a set of permissions defined to limit access to some APIs
o 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 Mandatory: Certificates which give some access to the
Protection Domain are loaded into the mobile (i.e. JSR118) (also applicable to the RIM environment)
o Optional: Certificates which give some access to the Protection Domain can be loaded into the SIM card (PKCS#15 files)
uicc.secure.access.api API, described in [31] API and Android permissions
2.3.3 Java / MIDP-specific security requirements
This section is dedicated to handsets in a Java / MIDP mobile environment.
Requirement # Requirement description 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 JSR177.
2.3.4 Android-specific security requirements
This section is dedicated to handsets in an Android mobile environment.
Requirement # Requirement description
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
2.4.1 CLF Required FeaturesThe CLF enables contactless communication and shall support the following requirements:
Requirement # Requirement description NFC_REQ_01 RF compliance
The handset’s NFC chipset & antenna are compliant with contactless reader infrastructure (ISO 14443 A & B)
NFC_REQ_02 The CLF shall support the card emulation mode: Using ISO 14443 A & B
Mifare support is optional Felica support not required
NFC_REQ_03 The CLF shall support the tag reader mode: Using ISO 14443 A & B
NFC Tag reading capability enabled
Supports reading at least NFC Forum Type 1-2-4 tags NFC Forum Type 3 tags not required
NFC_REQ_04 The CLF shall support the tag writer mode: Using ISO 14443 A & B
NFC Tag writing capability enabled
Supports writing at least NFC Forum Type 1-2-4 tags NFC Forum Type 3 tags not required
NFC_REQ_05 The CLF shall support the peer-to-peer (LLCP) mode with a transfer rate of at least 206Kbps
NFC_REQ_06 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.
NFC_REQ_07 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
NFC_REQ_08 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_REQ_09 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 14 443 specifications. NFC mobile phones shall comply with upcoming test methods on the RF interface which will be considered in ISO 10373-6
NFC_REQ_10 SWP support
The CLF shall support the SWP standard as defined in [9] NFC_REQ_11 HCI support
The CLF shall support the HCI standard as defined in [10]
2.4.2 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 3.0.1
Requirement # Requirement description UIC_REQ_01 NFC SIM cards compliance
The NFC handset shall be compliant with the NFC SIM cards that are compliant with SWP ([9]) & HCI ([10]).
UIC_REQ_02 NFC Transaction duration
The UICC and Mobile Environment shall allow the shortest delay possible between the 14443 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 230-250 ms
UIC_REQ_03 CLT mode support
The handset supports the CLT mode (Mifare), as defined in [9]
2.4.3 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…)
Requirement # Requirement description OTA_REQ_01 BIP support
The handset shall support the BIP protocol in client mode (UDP) OTA_REQ_02 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 OPEN CHANNEL o CLOSE CHANNEL o SEND DATA o RECEIVE DATA
o GET CHANNEL STATUS Events
o DATA AVAILABLE o CHANNEL STATUS OTA_REQ_03 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]
2.5 NFC tag reading/writing
2.5.1 Architecture overviewUICC
Mobile handset
Application 1 Application 2 Application 3 Umbrella applicationNFC tag
Certificate control NFC controller Tag reading / writingnative application
Mobile NFC API
Figure 3: Tag reading / writing architecture overview
2.5.2 Tag reading/writing requirements
The tag reading user interface shall comply with the following requirements:
Requirement # Requirement description TAG_REQ_01 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 TAG_REQ_02 Optional tag reading/writing features
The handset may support the following NFC tag reading/writing features: Launch mobile native function
o Note o Contact o Calendar o Multimedia Pairing Tag Writing
TAG_REQ_03 Tag reading application launch
The triggering of the tag application shall be transparent for the user while reading a tag
TAG_REQ_04 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_REQ_05 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
TAG_REQ_06 NFC Forum Smart Poster support
The user shall be able to read/write the NFC Forum Smart Poster Tag. TAG_REQ_07 NFC Forum Generic Control Tag support
The mobile shall be able to read the NFC Forum Generic Control Tag. TAG_REQ_08 Tag signature verification
The mobile shall be able to verify NFC tags’ signatures. The tags’ signature follows the NFC Forum RTD signature specification.
TAG_REQ_09 Tag reading distance
NFC tags shall be read from 4 cm to 0 cm TAG_REQ_10 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
TAG_REQ_11 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.
2.5.3 Tag data format
Requirement # Requirement description
TAG_REQ_12 Tag writing format
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 http://site.com?param=value (see RFC2616)
GC JAVA VM See Generic Control Specification URI USSD Session ussd: (see RFC3966)
URI00 MMS mms:recipient?subject=subj&body=message (cf draft-wugofski-mms-uri-scheme-00)
URI eMail 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.
3 R
EQUIREMENTS SUMMARY
Requirement # Requirement title
API_ANDROID_REQ_01 The Mobile UICC API used in the Android architecture API_ANDROID_REQ_02 The Mobile UICC API used in the Android architecture API_MIDP_REQ_01 The Mobile UICC API used in the Java / MIDP architecture API_MIDP_REQ_02 The Mobile NFC API used in the Java / MIDP architecture API_RIM_REQ_01 The Mobile UICC API used in the Java / MIDP architecture API_RIM_REQ_02 The Mobile NFC API used in the Java / MIDP architecture UPI_REQ_01 UICC secure application management (APDU Exchange) UPI_REQ_02 Third party application launching
UPI_REQ_03 Application auto-updating
UPI_MIDP_REQ_01 Third party application installing/uninstalling UPI_MIDP_REQ_02 RecordStore entries storage
API_REQ_01 The CLF shall be able to trigger a mobile application API_REQ_02 Multi-SE environment requirements
SEC_REQ_01 Only authorized mobile applications shall be able to access the UICC applications
SEC_REQ_02 Certificates and permissions management
SEC_MIDP_REQ_01 Access to UICC applications is forbidden using JSR257 SEC_ANDROID_REQ_01 Eavesdropping protection in Android
NFC_REQ_01 RF compliance
NFC_REQ_02 The CLF shall support the card emulation mode NFC_REQ_03 The CLF shall support the tag reader mode NFC_REQ_04 The CLF shall support the tag writer mode
NFC_REQ_05 The CLF shall support the peer-to-peer (LLCP) mode NFC_REQ_06 NFC function toll on autonomy
NFC_REQ_07 Minimum battery requirements in battery low mode NFC_REQ_08 Transactions in battery low mode
NFC_REQ_09 NFC mobile phone test methods
NFC_REQ_10 SWP support
NFC_REQ_11 HCI support
UIC_REQ_01 NFC SIM cards compliance UIC_REQ_02 NFC Transaction duration
UIC_REQ_03 CLT mode support
OTA_REQ_01 BIP support
OTA_REQ_02 BIP proactive commands and CAT events OTA_REQ_03 UICC standards compliance
TAG_REQ_01 Mandatory tag reading/writing features TAG_REQ_02 Optional tag reading/writing features TAG_REQ_03 Tag reading application launch
TAG_REQ_04 Tag reading/NFC activation/de-activation TAG_REQ_05 Tag reading performance
TAG_REQ_06 NFC Forum Smart Poster support TAG_REQ_07 NFC Forum Generic Control Tag support TAG_REQ_08 Tag signature verification
TAG_REQ_09 Tag reading distance
TAG_REQ_10 User prompt following tag reading TAG_REQ_11 Reading un-trusted tags
TAG_REQ_12 Tag writing format
4 A
PPENDIX
A
The following file contains the javadoc documentation of the API described in [16].