If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

[B2G][NFC][User Story]: Support NFC Payment App / Enablers

RESOLVED DUPLICATE of bug 979158

Status

Firefox OS
NFC
RESOLVED DUPLICATE of bug 979158
4 years ago
3 years ago

People

(Reporter: kenkai, Assigned: kenkai)

Tracking

({feature})

unspecified
ARM
Gonk (Firefox OS)
feature
Bug Flags:
in-moztrap -

Firefox Tracking Flags

(tracking-b2g:backlog)

Details

(Whiteboard: [ucid:NFC6, ft:RIL])

(Assignee)

Description

4 years ago
The user should be able to make payments by using their NFC enabled mobile device.
(Assignee)

Updated

4 years ago
Component: General → NFC
(Assignee)

Updated

4 years ago
Blocks: 860906

Comment 1

4 years ago
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.
(Assignee)

Comment 2

4 years ago
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."
Summary: [User story][NFC]Payments. → [B2G] [NFC User Story]: Support NFC Payment App / Enablers
(Assignee)

Updated

4 years ago
Duplicate of this bug: 894681

Updated

4 years ago
Summary: [B2G] [NFC User Story]: Support NFC Payment App / Enablers → [B2G][NFC][User Story]: Support NFC Payment App / Enablers

Updated

4 years ago
Flags: in-moztrap?
QA Contact: wachen

Updated

4 years ago
Flags: in-moztrap? → in-moztrap?(wachen)

Updated

4 years ago
Whiteboard: [ucid:NFC6]

Comment 4

4 years ago
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.
Flags: needinfo?(ffos-product)

Comment 5

4 years ago
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)

Updated

4 years ago
Whiteboard: [ucid:NFC6] → [ucid:NFC6], [FT:RIL]
Moving NI to Sandip
Flags: needinfo?(ffos-product) → needinfo?(skamat)

Comment 8

4 years ago
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.

Updated

4 years ago
Whiteboard: [ucid:NFC6], [FT:RIL] → [FT:RIL, ucid:NFC6]

Updated

4 years ago
Whiteboard: [FT:RIL, ucid:NFC6] → [FT:RIL, v1.4, ucid:NFC6]
(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.

Updated

4 years ago
Whiteboard: [FT:RIL, v1.4, ucid:NFC6] → [FT:RIL, NFCv1.4, ucid:NFC6]

Comment 10

4 years ago
Moving to target v1.4

Updated

4 years ago
Flags: needinfo?(skamat)

Comment 11

4 years ago
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.

Comment 12

4 years ago
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

Updated

4 years ago
Whiteboard: [FT:RIL, NFCv1.4, ucid:NFC6] → [FT:RIL, 1.4:p1, ucid:NFC6]
(Assignee)

Updated

4 years ago
Blocks: 933150
(Assignee)

Updated

4 years ago
No longer blocks: 860906

Comment 13

4 years ago
This is planned to be in v1.4.
blocking-b2g: --- → 1.4+

Comment 14

4 years ago
Remove blocking-b2g flag from User Story bugs. Use whiteboard to indicate what FxOS version we target.
blocking-b2g: 1.4+ → ---

Updated

4 years ago
Keywords: feature

Comment 15

4 years ago
Update whiteboard tag to follow format [ucid:{id}, {release}:p{1,2}, ft:{team-id}]
Whiteboard: [FT:RIL, 1.4:p1, ucid:NFC6] → [ucid:NFC6, 1.4:p1, ft:RIL]
Depends on: 948280

Updated

4 years ago
Assignee: nobody → kchang
Blocks: 949293
Whiteboard: [ucid:NFC6, 1.4:p1, ft:RIL] → [ucid:NFC6, 1.4:p2, ft:RIL]
1.4 user story supposedly needs to be complete before Sprint3.
Will communicate with team to reconfirm target milestone.
blocking-b2g: --- → backlog
Whiteboard: [ucid:NFC6, 1.4:p2, ft:RIL] → [ucid:NFC6, 1.4, ft:RIL]
Target Milestone: --- → 1.4 S3 (14mar)
(Assignee)

Comment 17

4 years ago
It isn't a 1.4 feature.
Whiteboard: [ucid:NFC6, 1.4, ft:RIL] → [ucid:NFC6, ft:RIL]
Target Milestone: 1.4 S3 (14mar) → ---
No longer blocks: 949293
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 979158
No longer blocks: 933150
remove in-moztrap? for its resolved duplicate
Flags: in-moztrap?(wachen) → in-moztrap-
blocking-b2g: backlog → ---
tracking-b2g: --- → backlog
You need to log in before you can comment on or make changes to this bug.