The user should be able to make payments by using their NFC enabled mobile device.

Hi Ken, this (or something close) is currently supported in one of our branches against a demo wallet payment app (not public yet). Including NFC, there is a Secure Element API associated with the feature that's also required.

Change the description, "The user should be able to make secure payments by using their NFC enabled mobile device, by using a <carrier/OEM partner specified> payment app."

This user story is really vague. I'm trying to piece together how this stuff works and it's a bit confusing the say the least. It seems like there are two parts to this: 1) Wallet application where your payment methods are stored (credit cards, debit, etc): Google wallet, Samsung Wallet, ISIS. 2) Contactless payment technology: Paypass (MC), Paywave (Visa) Then there is the proprietary NFC systems out there for transit services like MiFare (Poland), Oyster (London), Octopus (Hong Kong). I guess the question is: What parts of NFC payments are we working on and want to be compatible with? Additional information on how this all works would also be really useful.

Is this feature going to use navigator.mozPay() in any way?

<Acceptance Criteria> (Proposal) 1. User can pay by a payment app 2. User can charge by a payment app (small amount payment app for example)

Moving NI to Sandip

In order to support payments (visa/mastercard) or transit card (ie. mifare), the NFC shall support the Card Emulation capability and the possibility to interact with third party applet (like VMPA https://developer.visa.com/paywavemobile) installed an a SE.

(In reply to Fernando Jiménez Moreno [:ferjm] (needinfo, please) from comment #5) > Is this feature going to use navigator.mozPay() in any way? I think the easiest way to drive this feature is to ask 'what is missing from the platform in order to fulfill the user story?' I'm not sure mozPay is needed. It sounds like we need an API access to the Secure Element for starters, maybe other things.

Moving to target v1.4

please refer to the following document from GSMA, which defines exactly the concrete NFC handset requirements for NFC payment from global carrier's standpoint. http://www.gsma.com/mobilenfc/wp-content/uploads/2012/10/GSMA-NFC-Handset-APIs-Requirements-V3.01.pdf The authors of this specification are Telefónica, Orange, Telecom Italia, Vodafone and Deutsche Telekom.

Assume that the NFC payment/ticketing applications(MasterCard/VISA) have already been installed on SIM card, here is the proposal for the prio 1 features that FFOS should support for such applications. 1. Support NFC Card Emulation Mode 1) The mobile device SHALL support Card-emulation as per ISO/IEC 14443 Type A and Type B PICC. 2) Card Emulation mode SHALL be enabled as soon as the NFC hardware is turned on. 3) Card Emulation Mode should work in flight-mode. 4) Even the device is "locked" (display on but not logged in) the device SHALL allow transaction via card emulation mode. 2. Support UICC Access from Web App 1) The modem/baseband SHALL enable access to logical channels from the application layer. 2) Accessing the UICC SHALL still be possible during the device is switched to flight mode. 3) Firefox OS SHALL provide Open Mobile SIM similiar API (per SIM Alliance spec; Transport Layer) for developers to use. A complete description of the different functions is available in the SIM Alliance specification available here: http://www.simalliance.org/en?t=/documentManager/sfdoc.file.supply&e=UTF-8&i=1185787014303&l=0&fileID=1300467720550 Note: Reference implementations for Open Mobile APIs and access control exist for Android. 4) The API SHALL prevent access to basic channel (channel 0). Note: For implementation purposes this can be done by raising an exception." 5) Access to the UICC SHALL be protected by the Access Control component or the Global Platform Access Control as described in "Global Platform-Secure Element Access Control v1.0" 3. Support web application triggering 1) The mobile NFC Handset SHALL support HCI event EVT_TRANSACTION as per ETSI TS 102.622 2) The AID parameter SHALL be used during the process of tiggering the UI application. REPHRASE: The format of the EVT_TRANSACTION must be compliant to the "NFC Handset APIs & Requirements v3.0, section 4.5.1"" 3) For handling the EVT_TRANSCTION the handset SHALL support the mechanism described in "NFC Handset APIs & Requirements v3.0, section 4.5.3" and provide the related API

This is planned to be in v1.4.

Remove blocking-b2g flag from User Story bugs. Use whiteboard to indicate what FxOS version we target.

Update whiteboard tag to follow format [ucid:{id}, {release}:p{1,2}, ft:{team-id}]

1.4 user story supposedly needs to be complete before Sprint3. Will communicate with team to reconfirm target milestone.

It isn't a 1.4 feature.

remove in-moztrap? for its resolved duplicate