Closed
Bug 894322
Opened 11 years ago
Closed 11 years ago
[B2G][NFC][User Story]: Support NFC Payment App / Enablers
Categories
(Firefox OS Graveyard :: NFC, defect)
Tracking
(tracking-b2g:backlog)
RESOLVED
DUPLICATE
of bug 979158
tracking-b2g | backlog |
People
(Reporter: kchang, Assigned: kchang)
References
Details
(Keywords: feature, Whiteboard: [ucid:NFC6, ft:RIL])
The user should be able to make payments by using their NFC enabled mobile device.
Assignee | ||
Updated•11 years ago
|
Component: General → NFC
Comment 1•11 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•11 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
Updated•11 years ago
|
Summary: [B2G] [NFC User Story]: Support NFC Payment App / Enablers → [B2G][NFC][User Story]: Support NFC Payment App / Enablers
Updated•11 years ago
|
Flags: in-moztrap?
QA Contact: wachen
Updated•11 years ago
|
Flags: in-moztrap? → in-moztrap?(wachen)
Updated•11 years ago
|
Whiteboard: [ucid:NFC6]
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•11 years ago
|
||
Is this feature going to use navigator.mozPay() in any way?
Comment 6•11 years ago
|
||
<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•11 years ago
|
Whiteboard: [ucid:NFC6] → [ucid:NFC6], [FT:RIL]
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•11 years ago
|
Whiteboard: [ucid:NFC6], [FT:RIL] → [FT:RIL, ucid:NFC6]
Updated•11 years ago
|
Whiteboard: [FT:RIL, ucid:NFC6] → [FT:RIL, v1.4, ucid:NFC6]
Comment 9•11 years ago
|
||
(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•11 years ago
|
Whiteboard: [FT:RIL, v1.4, ucid:NFC6] → [FT:RIL, NFCv1.4, ucid:NFC6]
Comment 10•11 years ago
|
||
Moving to target v1.4
Updated•11 years ago
|
Flags: needinfo?(skamat)
Comment 11•11 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•11 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•11 years ago
|
Whiteboard: [FT:RIL, NFCv1.4, ucid:NFC6] → [FT:RIL, 1.4:p1, ucid:NFC6]
Assignee | ||
Updated•11 years ago
|
Blocks: b2g-nfc-ux
Comment 14•11 years ago
|
||
Remove blocking-b2g flag from User Story bugs. Use whiteboard to indicate what FxOS version we target.
blocking-b2g: 1.4+ → ---
Comment 15•11 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]
Updated•11 years ago
|
Assignee: nobody → kchang
Blocks: b2g-NFC-2.0
Whiteboard: [ucid:NFC6, 1.4:p1, ft:RIL] → [ucid:NFC6, 1.4:p2, ft:RIL]
Comment 16•11 years ago
|
||
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•11 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) → ---
Updated•11 years ago
|
Updated•11 years ago
|
No longer blocks: b2g-nfc-ux
Comment 19•11 years ago
|
||
remove in-moztrap? for its resolved duplicate
Flags: in-moztrap?(wachen) → in-moztrap-
Updated•10 years ago
|
blocking-b2g: backlog → ---
tracking-b2g:
--- → backlog
You need to log in
before you can comment on or make changes to this bug.
Description
•