On Jun 14, 2013, at 4:47 AM, Fernando Jiménez Moreno <[email protected]> wrote:
> Hi folks! > > Thanks Jonas and sorry for the late reply. > > On 16/05/2013, at 06:22, Jonas Sicking wrote: > >> Hi Guys, >> >> Spent the last few days digging my way out of email and got to this one. >> >> The main problem here sounds like the fact that the user may incur >> charges for either the incoming, the outgoing or both SMSs. To make >> matters worse we have no idea how big charges. And to make matters yet >> worse, I assume that once BlueVia knows the phone number, it might >> realize that it doesn't have the appropriate business relationships in >> place to actually charge that number? >> >> So what can we do to lessen these problems? >> >> One thing we could do is to check the SIM card to see if we can get >> the phone number from that, and if we can avoid sending the MO message >> (we'd still need the MT message). This obviously won't always help, >> but seems like it often could. Though maybe not in our currently >> targeted markets? > > I wish we could do this, but I am afraid that it is not going to be possible > because: > > 1. First of all, there are privacy (and probably legal) issues with allowing > the payment provider to get the MSISDN from the device. We've been warned > about this several times on TEF side. The payment provider should never get > the plain MSISDN. Instead, it will get a hash of the MSISDN that the carrier > (BlueVia in TEF case) will provide. Take a look at the flow at [1], I am > talking about the "Device ID" value. > > 2. The SIM card usually doesn't have the MSISDN and even if it has it, we > cannot trust this value as the user can change it. Take a look at point > 4.2.27 from [2], the MSISDN field can be updatable. > >> Second issue is that we should make sure to avoid international >> charges if we can. Can the number that we are sending messages to/from >> be made local? We should be able to detect even scenarios like the >> user currently roaming to determine if international charges will >> apply or not. > > If I am not wrong, short codes are network specific, so for example an SMS > sent to an spanish short code while roaming from Germany won't work. I am not > sure what would be the story on the operator side in that case. I don't know > if the SMS will need to be sent to a regular number with the usual > international charges or if the SMS can be sent to a local short code. > Ernesto, Jorge or David in CC might know about this. > > This is quite an edge case. Note that the SMS flow should ideally only happen > during the first payment flow as a fallback for other authentication > mechanisms. I agree that we still need to solve this though. > >> Basically what I'm suggesting is to surface the following information >> to the payment provider: >> * User's current phone number (if available from SIM) > > As I previously said, I am afraid that this is not an option. > >> * User's current MCC/MNC (could be multiple for multi-sim devices) >> * User's home MCC/MNC (could be multiple for multi-sim devices) > > We can expose the SIM(s) MCC/MNC and a roaming flag. > > I can't think about any problem in exposing this information to the payment > provider. However, if I am not wrong, Antonio mentioned that there are some > privacy concerns involved and that we probably need to notify and ask > permission to the user for this. > >> * Ability for payment provider to send a MO message to an arbitrary >> number (including which sim for a multi-sim device) >> * Ability for payment provider to be notified when there's an incoming >> message from a particular number. This notification would include the >> message body. > > This can be done :)! Probably with a few changes in the SMS implementation > that we'll need to discuss though. > >> This way the payment provider can display UI which lets the user know >> how many messages will be sent, and if they will be >> international/roaming messages or not. >> >> Or is this overly complex? Should we skip the MCC/MNC stuff and let >> the payment provider simply show UI saying "you may be charged for one >> or two SMS messages which may be international. This is a one-time >> cost"? > > For me, the problem here is not the complexity, but the possible privacy > issues. If notifying the user about the exposure of the MCC/MNC (with a user > friendly message :)) solves the privacy concerns, I am totally up to expose > this info to the payment provider. The SMS authentication flow already prompts the user for a challenge and it's a pretty quick prompt. If we are talking about replacing the SMS challenge with a silent SMS that also includes a user prompt then it may not be worth our time :) We began discussing the silent SMS flow simply to optimize the first time payment experience so that it happens quicker -- that is the only reason. Kumar > > Thanks! > > / Fernando > > [1] https://wiki.mozilla.org/Apps/ID_and_Payments#Payments_Data_Flow_Diagram > [2] http://www.3gpp.org/ftp/tsg_t/tsg_t/TSGT_05/Docs/PDFs/TP-99186.pdf _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
