Hi, Some comments on this: - although we're still waiting for a final confirmation, we will very likely adopt Oauth 2.0 as the solution for identifying/authenticating users instead of BrowserID. This means that automatically "sending" the identity information on step 3 depends on the use of session cookies between the device and BlueVia, and we could configure this as chosen by the final user at BlueVia (remember sessions yes or no). I understand that your concern comes from the fact that this automatic sharing of information + identity would depend on a configuration at the payment processor (e.g. BV in this case), thus, not completely under Gecko control, right? Anyway, from an e2e perspective everything would be at user's control for the v1 scenario. - what worries me more is the resulting UX. Note that the user definitely needs to authorize the payment at BlueVia side, as the payment processor is the one in charge of showing the price in the correct currency, etc, and more importantly: introduce a password to protect this authorization against "stolen-device" scenarios. In summary, the user will end up giving at least two consecutive authorizations, one for Gecko and another one at BlueVia, and that looks too much (aren't we getting kind of paranoid?)
Best David El 16/08/12 16:52, "Fernando Jiménez" <ferjmor...@gmail.com> escribió: >Hi, > >On 16/08/2012, at 13:41, Jonas Sicking wrote: > >> Don't we have the freedom to impose what JWTs that we are willing to >> funnel between the website and the payment provider? I.e. can't we >> require that the JWT contains human readable descriptions? > >Yes, we do have that freedom. That's why I was also giving the solution >of imposing some mandatory JWT parameters (IMO at least product price and >description). > >> Yup. I'm aware of this. It's definitely somewhat worrying, but it >> seems to me like it should work as long as the JWT request is signed >> rather than encrypted with the developer key. >> >> It could result in the situation when the user could be shown a UI >> saying "a payment for $10 is requested for this bowl of virtual >> chicken soup", but once the user clicks "pay using BlueVia" and logs >> in, he/she is faced with a dialog saying that the payment request is >> invalid. >> >> Not ideal, but also likely not going to happen terribly often since >> there is no incentive for the website to do so. > >Indeed. The final payment provider screen would contain the "real" >information about the current digital good being sold, so the user can >compare with the information not verified but showed by Gecko in the >previous step. > >> I'm a bit confused as to what you are proposing since you are >> commenting on the user-flow in my counter proposal. Did you intend for >> this comment to be in response to step 3 in the original flow? > >Sorry, I was referring to step 6 of your proposal. As I said, IMHO where >to ask for a user login should be up to the payment provider. It >shouldn't be Gaia loading the payment provider login screen, but the >payment flow (that would contain the login screen) in general. > >> If so, yes, it's true that we could do step 3 without sending user >> identifying information to BlueVia. But that wasn't the flow that was >> described to me when I asked how the proposed API worked. If we make >> sure to not send any cookies to BlueVia in step 3 of the original flow >> then that definitely limits the privacy leak. But it would also mean >> adding platform support to loading iframes without sending cookies. >> Something we currently don't have. >> >> The other problem is that it's relatively easy to fingerprint people >> even if we don't send cookies. Especially once you open an <iframe> >> which lets scripts run. You can read about it here: >> https://panopticlick.eff.org/. Hence it's generally better to not send >> data to 3rd parties, than to rely on that they can't identify who is >> sending the data. >> >> But I definitely agree that we should keep in mind the option of >> keeping the original flow, but not sending user-identifying >> information in step 3. > >Well, we would keep the original flow with the addition of a confirmation >screen shown by Gecko. > >> If it turns out that I'm the only person worried about this privacy >> leak, then we should absolutely go with the current API. I mostly >> started this thread to get input from the security and privacy teams >> to see if this was something that worried them. If it doesn't, then we >> shouldn't let this issue block us. > >Actually, you are not the only one, as I am also concerned about this >matter, that I must confess that I didn't think about until you >mentioned. I still think that this is mostly a payment provider identity >protocol issue, but I agree that Gecko should probably ask for user's >confirmation before sending any users data ,even if he authorized the >payment provider to automatically log him in. Anyway, even if we want to >implement this, it may not a be a reason to block the basic parts of the >implementation. But that's not my decision at all :) > >I just need confirmation to start developing the fix for this, that I >repeat, should not be hard to implement. > >Thanks for your help Jonas! > >-Fernando > ________________________________ 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-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
