There’s been a chat going on about login to the Payments flow in a manner that 
means users don’t have to login twice, but can just login in once to a site. 
The UX for that flow is here:

http://payments.readthedocs.org/en/latest/design/ux.html#purchase-flow 
<http://payments.readthedocs.org/en/latest/design/ux.html#purchase-flow>

We were having a chat in a thread and realized it should move to the public 
list. So apologies for that. Here’s basically what Ryan proposed in those 
emails…

   * User goes to Mozilla Concrete
   * User clicks Buy
   * User has to login on Mozilla Concrete, so:
       * Concrete uses the iframe lib to start the oauth dance
       * It requests scopes "profile+payments"
       * The user logs in as normal
       * The oauth dance completes and Concrete gets an oauth token
   * Concrete verifies the oauth token, extracts profile data, whatever
   * Mozilla Concrete then needs to send them onto buy
       * Concrete uses the payments iframe you provide
       * It passes in the oauth token as part of the call
       * Payments verifies the token to extract user and relier info
       * User is verified and lands in payment UI
       * Payment magic happens, notifications fire, whatever
   * (Actual) Profit!

I then drew a diagram, which is probably hideous and wrong:

http://payments.readthedocs.org/en/latest/design/design.html#purchase-flow-fxa 
<http://payments.readthedocs.org/en/latest/design/design.html#purchase-flow-fxa>

There were some security concerns that came up from that and Ryan also said:

"So the one comment I want to add here, is that we generally discourage
reliers from sharing their oauth tokens directly with others, since it
gives all the power and authority in that token to whoever happens to
possess it.

We'll probably want to provide some sort of "token narrowing" API to
enable this in a more secure fashion.

If for example, Mozilla Concrete has a token with scope
"profile+payments+SuperSecretOtherThing", then it doesn't want to pass
that token directly to other services.  Instead, it could call some API
on the oauth server to generate a fresh subsidiary token with only
"payments" scope, and pass that token to the payments service.”

Any comments?
_______________________________________________
Dev-fxacct mailing list
[email protected]
https://mail.mozilla.org/listinfo/dev-fxacct

Reply via email to