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. 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
