Hey Some comments inline.
On 21/03/2013 22:54, Kumar McMillan wrote: Hi Fernando. I am a bit uneasy of adding this feature to the mozPay API because it feels like a hack :) but it totally makes sense to do so in our case. Some responses inline: On Mar 19, 2013, at 11:30 AM, Fernando Jiménez <[email protected]<mailto:[email protected]>> wrote: Hi folks, I'd like to expose a few ideas about the possible inclusion of a "silent SMS" flow within the current payment flow triggered by the navigator.mozPay API [1]. *** Why an SMS? *** In order to charge a user for a purchased digital good via carrier billing, the payment provider needs to identify the user as an authenticated carrier user. The way the user is identified depends on the capabilities of the carrier's network and on the device connection status. Some carriers provide a network based authentication mechanism where the users can be identified and authenticated by IP. This mechanism requires the user's device to have an active data connection (i.e. 3G) and it obviously won't work if the user's device is connected via WiFi. The network based authentication mechanism provides a seamless UX where the user can be "silently" authenticated. However, the requirements for this authentication mechanism are unfortunately not always met, so we also need to provide fallback mechanisms as an alternative to the network based one. One of this fallbacks is the SMS MT flow, where the user is asked to enter her phone number, so the payment provider can send an SMS with a challenge that the user needs to retrieve and send back to the payment provider. *** Why silent? *** The above described SMS flow provides a bad UX, where the user might even need to leave the actual payment flow to check her SMS inbox looking for the challenge to be sent back to the payment provider. This flow is the one that it is currently implemented for Firefox OS payments in v1 and the one that we might be able to change with the introduction of the silent SMS flow. With the current implementation, the first time a user wants to buy an app via the Firefox Marketplace, she needs to go through the following steps: 1) Click on purchase the app 2) Enter her email and submit it to login with Firefox Accounts 3) Enter her password twice to create the Firefox Account 4) Enter a new PIN for the marketplace 5) Type the PIN again to confirm its right 6) Enter her phone number and mobile operator 7) Receive an SMS with a PIN 8) Enter the SMS with the PIN 9) Authorise the payment 10) Confirm the installation As you can see, the flow is pretty painful. The idea of the silent SMS proposal is to get rid of steps 6 to 8. *** How? *** There have already been a few discussions about how to implement a silent SMS flow [2]. The comment at [3] mentions the possibility of having an SMS flow only with SMS MO [4], which would be absolutely great, but I can't see how this flow can work in a secure way since it is possible to replace the sender of an SMS [5]. So I will explain my proposal based on the need of having an SMS MO <-> SMS MT flow. However, I am including David Lozano (author of that comment) in CC so he can explain that flow in more detail. Hopefully we might only need to send an SMS and the flow would be significantly simpler :). At a high level overview, the silent SMS flow would consist in the following steps: a. The payment provider requests the send of an SMS to a short number defined by the carrier. The short number could be stored as a preference in the device and might be tied to the payment provider's origin. b. An SMS containing a randomly generated ID is sent to that short number. The ID would be used later to identify the corresponding reply. c. Once the carrier receives the SMS, it generates a token an replies back to the origin number with a new SMS containing the ID and the generated token. d. The device receives the SMS and gets back to the payment provider flow (via DOMRequest callback) with the generated token. e. The payment provider can use the received token to check with the carrier the user's identity to continue with the payment process. I don't see why we would need to have both MO (mobile originated) and MT (mobile terminated). If mozPay() generates a random ID on the device, sends it to the short code (the MO flow) then why not just follow up with a web request like this: GET https://payment-provider/did-you-receive-my-sms/randomID If the answer from the server is yes, then the payment can continue because the operator got the MSISDN from the first silent SMS and can link them by randomID. Do we have access to a good enough /dev/urandom on the phone? If so, then we can probably generate an ID that cannot be guessed. Thus I wouldn't see any reason for the device to *receive* a confirmation SMS. It seems redundant. The problem here is that what we want is to get automatically the MSISDN of the user. The SMS MO includes that data, but on a general case it cannot be trusted (it's "trustiness" depends on the SMS-C used by the user, which for short numbers should be his operator SMS-C and thus *should* not have any problem). The SMS-MT is thus used to confirm that the number we received on the SMS-MO is, indeed, owned by the user making the payment. Adding a random ID from the device will not help here, since the risk the MT mitigates is the user making the payment cheating. And he would have access to that random ID also. Sending an SMS to a short code, as I understand incurs no charge to the user. However, *receiving* an SMS back from the mobile operator will incur a charge. Hmm... it's usually the reverse around here :). Sending costs money but receiving usually doesn't (since you don't have control over what you receive but you have control over what you send). The first challenge here is how to achieve step (a) so we let the payment provider request the send of an SMS knowing that the payment provider flow is web content that has not the possibility of requesting WebSMS API permissions. As some of you already know, the navigator.mozPay API triggers the creation of a trusted UI that embeds the content of the payment provider flow. The API implementation injects [6] two functions in the corresponding payment flow to allow the payment provider to complete or cancel the payment process and to return the control to the caller application. Basically, the idea for the silent SMS flow is to inject an additional function in the payment flow to allow the payment provider to request a silent SMS flow to get the user's authentication. So the payment provider facing API would have a new function like: DOMRequest doSilentSMS(); This sounds like the best solution. I also like putting the short code on the phone as a pref. We don't want to give web content any way to send arbitrary SMS's. This function might probably need a new explicit permission, so we let the user choose if she wants to allow or not the payment provider to send SMSs on her behalf. Jonas, any thought about this? You already expressed some concerns about privacy regarding navigator.mozPay before [7].
From a UX perspective I think we need to be careful about adding yet another prompt. As you saw from the first-time flow up above, it is already complicated. Also, if the device only sends a silent SMS after the user clicks "charge my phone bill" then the user would be implicitly granting the mobile operator permission to know about her MSISDN :)
I still think receiving an SMS that the user may be charged for could be problematic. Again, if anything *sending* SMS could be problematic. Anywhere where just by *receiving* and SMS there's a costs on the user, the user has a problem (since there's nothing that prevents me from using my worst enemy phone number on each and every form that asks for a phone number). Best regards, Antonio In order to get the "silence" for this flow we will need to modify the current SMS implementation to allow sending (step b) and receiving (step d) SMSs without storing them in the mobile messages database. Note that depending on the flow required by the carrier (only an SMS MT as suggested in [3]) we might only need to modify the sending methods. Vicamo, any thoughts about this? Sorry for the long email. Any feedback would be highly appreciated. Cheers! / Fernando [1] https://wiki.mozilla.org/WebAPI/WebPayment [2] https://bugzilla.mozilla.org/show_bug.cgi?id=816564 [3] https://bugzilla.mozilla.org/show_bug.cgi?id=816564#c4 [4] http://en.wikipedia.org/wiki/Short_Message_Service#Early_development [5] http://en.wikipedia.org/wiki/SMS_spoofing [6] https://wiki.mozilla.org/WebAPI/WebPaymentProvider#Completion [7] https://groups.google.com/forum/#!searchin/mozilla.dev.b2g/pay/mozilla.dev.b2g/YGITHnnjh0M/ciQO9Y_AdGoJ<https://groups.google.com/forum/#%21searchin/mozilla.dev.b2g/pay/mozilla.dev.b2g/YGITHnnjh0M/ciQO9Y_AdGoJ> -- Antonio Manuel Amaya Calvo_/ / _ /Security&Trust on N&S email: [email protected]<mailto:[email protected]> / _ _/ ( / Telefonica I+D Tlf.: +34-91.312.98.95 _/ _/ \__/ D. Ramón de la Cruz 82 Fax : 28006 Madrid, SPAIN ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
