Closed Bug 979158 Opened 6 years ago Closed 2 years ago

[B2G][NFC][User Story]: Enable management of NFC services with the Mobile Wallet UI app

Categories

(Firefox OS Graveyard :: NFC, defect)

ARM
Gonk (Firefox OS)
defect
Not set

Tracking

(feature-b2g:3.0?, tracking-b2g:backlog)

RESOLVED WONTFIX
2.2 S6 (20feb)
feature-b2g 3.0?
tracking-b2g backlog

People

(Reporter: skamat, Assigned: vchang)

References

Details

(Keywords: feature, Whiteboard: [ucid:NFC15, 2.2, FT:RIL])

User Story

As a user, I would like to manage my NFC services with the Mobile Wallet UI app. The wallet management functions include set default payment service, add new NFC services via MNO’s over-the-air provision channel, show the service profile data, etc.

Acceptance Criteria:

AC1: If the settings has NFC turned on with appropriate secure elements, the user accesses the list of subscribed services via the app/UI.
AC2: The user can browse the services and make changes as necessary. 
AC3: There will be a visual confirmation (saved) to the user that the transaction succeeded or failed.

Phase2: The user can also add new services.(to create a new bug for tracking)
As a user, I would like to manage my NFC services with the Mobile Wallet UI app. The wallet management functions include set default payment service, add new NFC services via MNO’s over-the-air provision channel, show the service profile data, etc.

Acceptance Criteria:

AC1: If the settings has NFC turned on with appropriate secure elements, the user accesses the list of subscribed services via the app/UI.
AC2: The user can browse the services and make changes as necessary. The user can also add new services.
AC3: There will be a visual confirmation (saved) to the user that the transaction succeeded or failed.
Add two high-level OS/NFC features that are closely related to supporting this user story.

1. The mobile device SHALL support UICC access from web application layer via logical channel;
2. The mobile device SHALL support BIP in UICC client mode for UDP/TCP.
Whiteboard: [ucid:NFC15, FT:RIL]
User Story: (updated)
Blocks: 879861
Blocks: 884594
No longer blocks: 879861
Depends on: 879861
No longer blocks: 884594
Depends on: 884594
Duplicate of this bug: 894322
Wesley and Sandip, this bug should be put into Gaia teams' backlog.
Flags: needinfo?(whuang)
Flags: needinfo?(sandip.kamat)
Flags: needinfo?(sandip.kamat) → needinfo?(skamat)
Flags: needinfo?(skamat)
This user story mostly is from GAIA, but I'm not sure which function team could take it.
Very likely this will be contributed from partner.
Flags: needinfo?(whuang)
(In reply to Wesley Huang [:wesley_huang] from comment #4)
> This user story mostly is from GAIA, but I'm not sure which function team
> could take it.
> Very likely this will be contributed from partner.
Sandip, Are you sure that partner will contribute this?
Some explanations about the raised question from Wesley and Ken. 

To my understanding, whether Mozilla/Gaia needs to be involved in the mobile wallet development depends on the way how this wallet will be developed. There could one of the following cases.

Case-1: the mobile wallet application is solely developed by carrier partner, running on top of Firefox OS Web APIs, such as WebNFC, WebSecureElement, etc. In this case, the UI/UX issue is decided by partner.

Case-2: Mozilla develops a reference mobile wallet application based on NFC and Secure Element APIs. 
In this case, mozilla owns this  wallet app and decides how the UI/UX of this app should look like. 

Case-3: The wallet will be co-developed by Mozilla and the partner.

I think, before the decision(which case for the mentioned m-wallet) is made, it is for me still early to talk about whehter GAIA should jump in.
Depends on: 987043
blocking-b2g: --- → backlog
Depends on: 1016003
(In reply to Ming Yin from comment #6)
> Some explanations about the raised question from Wesley and Ken. 
> 
> To my understanding, whether Mozilla/Gaia needs to be involved in the mobile
> wallet development depends on the way how this wallet will be developed.
> There could one of the following cases.
> 
> Case-1: the mobile wallet application is solely developed by carrier
> partner, running on top of Firefox OS Web APIs, such as WebNFC,
> WebSecureElement, etc. In this case, the UI/UX issue is decided by partner.
> 
> Case-2: Mozilla develops a reference mobile wallet application based on NFC
> and Secure Element APIs. 
> In this case, mozilla owns this  wallet app and decides how the UI/UX of
> this app should look like. 
> 
> Case-3: The wallet will be co-developed by Mozilla and the partner.
> 
> I think, before the decision(which case for the mentioned m-wallet) is made,
> it is for me still early to talk about whehter GAIA should jump in.

Current assumption is case 1, where Partner contributions or a third party downloadable (or preloadble app) is provided. It makes the most sense as having generic Mozilla provided app has little value given deep customizations needed there anyways.
User Story: (updated)
Assignee: nobody → vchang
nom'ing for 2.2
feature-b2g: --- → 2.2?
feature-b2g: 2.2? → 2.2+
QA Whiteboard: [COM=NFC]
Whiteboard: [ucid:NFC15, FT:RIL] → [ucid:NFC15, 2.2, FT:RIL]
QA Whiteboard: [COM=NFC] → [COM=NFC][2.2-feature-qa+]
Status: NEW → ASSIGNED
Flags: in-moztrap?(ashiue)
Vincent, 
I suppose we can expect the dependent bugs to be landed before sprint6.
So I'm setting this meta to sprint6.
Target Milestone: --- → 2.2 S6 (20feb)
We have landed the Bug 879861 for security element Web APIs. The APIs work fine with 2.1 branch + QC RIL in partner's build. The partner has done some excellent demo based on these APIs and is going to showcases in 2015 MWC.

However, these are still a lot of works need to be done before we can use these API in privileged app.
Let's keep finishing the works on master/central.
feature-b2g: 2.2+ → 3.0?
blocking-b2g: backlog → ---
Firefox OS is not being worked on
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.