> On May 13, 2015, at 5:28 PM, Nicholas Alexander <[email protected]> > wrote: > > > > On Wed, May 13, 2015 at 3:02 PM, Kumar McMillan <[email protected] > <mailto:[email protected]>> wrote: > Hi all. > > This is for Ryan Kelly (or anyone) to check what we’d like to do for payments > to see if it’s sane. We started talking about it before but this email adds a > few more details. > > The goal: provide generic payment processing via Firefox Accounts so that any > Mozilla site can sell premium services. The user should only have to log in > *once* to purchase the product. > > Abstract user flow: > > - User decides to purchase 20GB more of Mozilla Backup storage for $9.99 / > month (just an example) > - Click the purchase button > - Sign in with Firefox Account > - Enter credit card information > - Enjoy enhanced storage > > Implementation proposal: > > - On backup.firefox.com <http://mozillabackup.com/> , the click of a purchase > button begins an OAuth flow by requesting a code->token with the scope > ‘profile payments’ > - backup.firefox.com <http://mozillabackup.com/> opens an iframe (or > redirect) to payments.mozilla.com <http://payments.mozilla.com/> and passes > the OAuth token as a GET parameter > - payments.mozilla.com <http://payments.mozilla.com/> verifies the token on > the server and checks that it has the *payments* scope > - payment processing proceeds… > > I'm not an expert, but this seems odd. Suppose backup wanted to support > multiple payment providers, or payments.mozilla.com > <http://payments.mozilla.com/> were run by a third-party.
We’re assuming the Mozilla site would only use one payment processor (the Mozilla one). > It wouldn't be sensible for backup to initiate the login flow; it would be > sensible for backup to ask payments (or the appropriate payment provider) to > initiate a payment flow, which for payments.mozilla.com > <http://payments.mozilla.com/> would know about FxA. (For some other > provider, it would likely not.) We’re thinking that by nature you could already be logged into backup.firefox.com <http://backup.firefox.com/> for whatever reason; e.g. you would need to log in to access your data or just simply to use the site. If we change it so the payments site requests the login then I see many potential double login situations. We’re trying to avoid that at all costs. If we end up with a tight coupling between the Mozilla site and the payment processor then that’s ok. > > That is, it seems that the redirect flow should be split: backup and payments > communicate with one redirect type of flow; and then payments and FxA > communicate with a separate redirect flow. > > Please critique. > > Nick > > > Does that sound sane? This makes token sharing sound scary: > https://developer.mozilla.org/en-US/docs/Mozilla/Tech/Firefox_Accounts/Introduction#Security_considerations > > <https://developer.mozilla.org/en-US/docs/Mozilla/Tech/Firefox_Accounts/Introduction#Security_considerations> > > > -Kumar > > _______________________________________________ > Dev-fxacct mailing list > [email protected] <mailto:[email protected]> > https://mail.mozilla.org/listinfo/dev-fxacct > <https://mail.mozilla.org/listinfo/dev-fxacct>
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Dev-fxacct mailing list [email protected] https://mail.mozilla.org/listinfo/dev-fxacct
