Closed Bug 894691 Opened 11 years ago Closed 10 years ago

[B2G][NFC][User Story]: NFC APIs for payments / Secure SIM / Wallet

Categories

(Firefox OS Graveyard :: NFC, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(tracking-b2g:backlog)

RESOLVED INVALID
tracking-b2g backlog

People

(Reporter: skamat, Assigned: kchang)

References

Details

(Keywords: feature, Whiteboard: [ucid:NFC9, ft:RIL])

Attachments

(3 obsolete files)

NFC Payment APIs
1)     Web APIs to access and manage credentials in secure SIM.
2)     Web APIs for secure payment
3)     Enablers to create a Wallet application.
Summary: [B2G] [NFC User Story]: NFC APIs for payments / Secure SIM / Wallet → [B2G][NFC][User Story]: NFC APIs for payments / Secure SIM / Wallet
Blocks: b2g-nfc
Flags: in-moztrap?
QA Contact: wachen
Flags: in-moztrap? → in-moztrap?(wachen)
Whiteboard: [ucid:NFC9]
Whiteboard: [ucid:NFC9] → [ucid:NFC9], [FT:RIL]
Whiteboard: [ucid:NFC9], [FT:RIL] → [FT:RIL, v1.4, ucid:NFC9]
Based on the discussion with DT during NFC work week: 

1. We need more detailed information about payment from DT. (What kinds of payments flow?)
*And, maybe we can separate this user stories to more user stories since it's strange to have only one user story for Payment / secure SIM / Wallet. Even payment should be split
Depends on: webnfc
Depends on: 860907
Depends on: 879861
Depends on: 884594
Depends on: 897312
Depends on: 902051
(In reply to Sandip Kamat from comment #0)
> 2)     Web APIs for secure payment

Isn't the WebPayment API [1] enough for this?

[1] https://wiki.mozilla.org/WebAPI/WebPayment
Whiteboard: [FT:RIL, v1.4, ucid:NFC9] → [FT:RIL, NFCv1.4, ucid:NFC9]
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
Whiteboard: [FT:RIL, NFCv1.4, ucid:NFC9] → [FT:RIL, 1.4:p1, ucid:NFC9]
Blocks: b2g-nfc-ux
No longer blocks: b2g-nfc
Payment is in v1.4.
blocking-b2g: --- → 1.4+
Remove blocking-b2g flag from User Story bugs. Use whiteboard to indicate what FxOS version we target.
blocking-b2g: 1.4+ → ---
Keywords: feature
Update whiteboard tag to follow format [ucid:{id}, {release}:p{1,2}, ft:{team-id}]
Whiteboard: [FT:RIL, 1.4:p1, ucid:NFC9] → [ucid:NFC9, 1.4:p1, ft:RIL]
Assignee: nobody → kchang
Blocks: b2g-NFC-2.0
Whiteboard: [ucid:NFC9, 1.4:p1, ft:RIL] → [ucid:NFC9, 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:NFC9, 1.4:p2, ft:RIL] → [ucid:NFC9, 1.4, ft:RIL]
Target Milestone: --- → 1.4 S3 (14mar)
It isn't a 1.4 feature.
No longer blocks: b2g-NFC-2.0
Whiteboard: [ucid:NFC9, 1.4, ft:RIL] → [ucid:NFC9, ft:RIL]
Target Milestone: 1.4 S3 (14mar) → ---
Attached file MozSecureElementManager.webidl (obsolete) —
Attached file MozSecureElementObjects.webidl (obsolete) —
Attached image FxOS_SecureElement_Architecture_v1.png (obsolete) —
- Updated the bug with the initial draft of SecureElement DOM APIs (webidl).
- Updated the SecureElement / Payment Architecture based on the consensus arrived during Poland workweek. 

Requesting for feedback.

Thanks, Sid
This is a user story bug, please move your code to the Gecko bug, Bug 879861.
Ok. Updated the Bug 879861. Not sure how I can remove attachments from this bug. Should I obsolete them? Please suggest.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → INVALID
since it resolved invalid, I will remove in-moztrap? mark
Flags: in-moztrap?(wachen)
blocking-b2g: backlog → ---
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: