<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On May 13, 2015, at 11:48 PM, Ryan Kelly <<a href="mailto:rfkelly@mozilla.com" class="">rfkelly@mozilla.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">On 14/05/2015 08:02, Kumar McMillan wrote:<br class=""><blockquote type="cite" class=""><br class="">The goal: provide generic payment processing via Firefox Accounts<br class="">so that any Mozilla site can sell premium services. The user should<br class="">only have to log in *once* to purchase the product.<br class=""></blockquote><br class="">Just to be clear, are we talking about a special privileged flow<br class="">that's only available to Mozilla applications? How would the flow<br class="">differ if we were talking about payments in a third-party app that<br class="">also uses Firefox Accounts for authentication?</div></blockquote><blockquote type="cite" class=""><div class=""><br class="">A (purely hypothetical!) example might be purchasing a premium Pocket<br class="">subscription after connecting to Pocket via FxA.<br class=""></div></blockquote><div><br class=""></div><div>A third party approach w/ FxA sounds reasonable but it’s out of scope for us. So, yes, we’re only talking about Mozilla<->Mozilla payments. We do not even have distant plans to support third parties.</div><br class=""><blockquote type="cite" class=""><div class=""><br class=""><blockquote type="cite" class="">Abstract user flow:<br class=""><br class="">- User decides to purchase 20GB more of Mozilla Backup storage for<br class="">$9.99 / month (just an example) - Click the purchase button - Sign<br class="">in with Firefox Account - Enter credit card information - Enjoy<br class="">enhanced storage<br class=""></blockquote><br class="">Do you have a UX flow you could share to go along with this? I<br class="">remember seeing some go past but didn't keep any links.<br class=""></div></blockquote><div><br class=""></div><div>It’s in progress but here is the latest patch: <a href="https://raw.githubusercontent.com/mozilla/payments/brampitoyo-patch-1/docs/design/ux-pay-wireframe.png" class="">https://raw.githubusercontent.com/mozilla/payments/brampitoyo-patch-1/docs/design/ux-pay-wireframe.png</a> You’ll have to ignore the flow that begins with an email address (no FxA account) since we won’t be implementing that yet. Focus on the fork that starts with the FxA sign-in screen.</div><br class=""><blockquote type="cite" class=""><div class=""><br class=""><blockquote type="cite" class="">Implementation proposal:<br class=""></blockquote><br class="">The below proposal will work and I think it'll be OK for privileged<br class="">Mozilla<->Mozilla service coordination. But token sharing is indeed<br class="">pretty scary, so I'd like to dig into the security properties here.<br class=""><br class=""><blockquote type="cite" class="">- On <a href="http://backup.firefox.com" class="">backup.firefox.com</a> <<a href="http://MozillaBackup.com" class="">http://MozillaBackup.com</a>> , the click of<br class="">a purchase button begins an OAuth flow by requesting a code->token<br class="">with the scope ‘profile payments’<br class=""></blockquote><br class="">What's the purpose of the `profile` scope here? Is this for Backup's<br class="">own internal needs so that it can get at the user's email address etc?<br class=""></div></blockquote><div><br class=""></div><div>That was just an example. I’m not sure what each Mozilla property will actually need to request. But, yes, I assumed they would want access to the email address.</div><br class=""><blockquote type="cite" class=""><div class=""><br class=""><blockquote type="cite" class="">- <a href="http://backup.firefox.com" class="">backup.firefox.com</a> <<a href="http://MozillaBackup.com" class="">http://MozillaBackup.com</a>> opens an iframe<br class="">(or redirect) to <a href="http://payments.mozilla.com" class="">payments.mozilla.com</a> <<a href="http://payments.mozilla.com" class="">http://payments.mozilla.com</a>><br class="">and passes the OAuth token as a GET parameter<br class=""></blockquote><br class="">We don't have APIs for it yet, but in general, at this step Backup<br class="">might like to produce a narrower token having only the scopes that are<br class="">relevant to Payments. Sean's working on the API as noted in:<br class=""><br class=""> <a href="https://mail.mozilla.org/pipermail/dev-fxacct/2015-April/001422.html" class="">https://mail.mozilla.org/pipermail/dev-fxacct/2015-April/001422.html</a><br class=""><br class="">(Between trusted services we can get away without doing this, and we<br class="">might decide that the payments processor also needs "profile" scope<br class="">anyway. But it's an important step to think about in general).<br class=""></div></blockquote><div><br class=""></div><div>Cool, I think this will be helpful. Once it lands we plan to experiment with it here <a href="https://github.com/mozilla/payments-example/issues/5" class="">https://github.com/mozilla/payments-example/issues/5</a></div><br class=""><blockquote type="cite" class=""><div class=""><br class=""><blockquote type="cite" class="">- <a href="http://payments.mozilla.com" class="">payments.mozilla.com</a> <<a href="http://payments.mozilla.com" class="">http://payments.mozilla.com</a>> verifies the<br class="">token on the server and checks that it has the *payments* scope<br class=""></blockquote><br class="">The key question here is: what power does a token with "payments"<br class="">scope provide? If I were to somehow obtain a "payments" scope token<br class="">tied to "<a href="mailto:kmcmillan@mozilla.com" class="">kmcmillan@mozilla.com</a>", what would the Payments system let me<br class="">do on your behalf?</div></blockquote><blockquote type="cite" class=""><div class=""><br class="">Can I use that token to initiate new transactions using your stored<br class="">credit card details without any further authentication?<br class=""></div></blockquote><div><br class=""></div><div>Yes, they could make a purchase which includes access to saved credit cards (full numbers obviously are not obtainable). </div><div><br class=""></div><div>The acquired product would only be attributed to the FxA user of the token and funds would only be sent to the configured vendor. I suppose one threat is where a stolen token could be used to put purchases on someone else’s account but nothing is gained by the attacker in that case.</div><div><br class=""></div>We’re still discussing the details on this. Previously on Firefox OS we had required a PIN entry but we don’t think that’s crucial for desktop. Also, we may want to force re-authentication if it has been a while since the user entered their password.</div><div><br class=""><blockquote type="cite" class=""><div class=""><br class="">I suspect that it must grant this level of power, if we're to avoid a<br class="">double-login scenario at all costs. That's a lot of power to put in<br class="">the hands of the Backup app. So I feel like the security concerns<br class="">here are less around sharing the token from Backup to Payments, and<br class="">more around delegating that much authority to the Backup app in the<br class="">first place.<br class=""><br class="">It that's not acceptable (which it certainly wouldn't be for a<br class="">third-party relier) then we could try to come up with some clever<br class="">extra step on the FxA side. For example, Payments could bounce you<br class="">through a confirmation prompt on FxA, which proceeds transparently if<br class="">you've got an active FxA session in that browser but prompts you to<br class="">re-authenticate otherwise.<br class=""></div></blockquote><div><br class=""></div><div>That’s interesting. How could we bounce through with a potential prompt? This sounds like something that would improve security without adding friction because in the happy path the user would have an active session. This would address the attack I mentioned above.</div><div><br class=""></div><div>Thanks for the feedback. It sounds like it’s ok to proceed with token sharing, at least as a first pass.</div><div><br class=""></div><div><br class=""></div><div>-Kumar</div><br class=""><blockquote type="cite" class=""><div class=""><br class=""><br class=""> Cheers,<br class=""><br class=""> Ryan<br class=""><br class=""><br class=""></div></blockquote></div><br class=""></body></html>