<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Apr 5, 2015, at 10:02 PM, Ryan Kelly <<a href="mailto:rfkelly@mozilla.com">rfkelly@mozilla.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">On 4/04/2015 00:05, Andy McKay wrote:<br><blockquote type="cite">tl;dr we need somewhere people can query to see if a purchase has been completed.<br><br>So as an example, Mozilla Concrete [1] is selling a pro subscription where you can get a virtual concrete block each month. A users goes to Mozilla Concrete and logs in with Firefox Accounts, she then clicks the buy button, we process the payment etc... and then know that she has purchased a shiny virtual red brick.<br><br>Behind the scenes we'll send a server to server notification, hopefully through FxA notification queue (more on that in later emails).<br><br>Mozilla Concrete will now need to query and find out if she has purchased a product. There are a few different ways of doing this:<br><br>1) payments stands up an API that can receive the appropriate bearer token for that user or<span class="Apple-converted-space"> </span><br></blockquote><br>I suspect it's not the solution you intend to advocate, but at first<br>glance, this feels like the right shape for the public-facing API of<br>this thing.<br><br>Internally we may implement it atop a more generic fxa-attached<br>cloud-storage thing based on Tarek's team's ongoing work. But I like<br>the idea of it appearing to the rest of the world as a separate<br>"payments info" service with a purpose-specific API.<br><br>What downsides do you see to implementing this as a special-purpose API?<br></div></blockquote><div><br></div><div>The downside I see is that the app selling products needs to talk to two parties: 1) FxA for authentication and 2) the payments service for receipt validation. Why not just talk to FxA? It seems simpler. Everything about a user owning a product points to FxA as a logical authority on product ownership in my mind.</div><br><blockquote type="cite"><div style="font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br><blockquote type="cite">2) we write into an storage space, like the profile server.<br><br>In the latter, Mozilla Concrete then will then have to query the profile server to find out if she has purchased the product. It makes it easier for Mozilla Concrete because they only have to query one service. A service they would already have to query anyway to get profile information.<br></blockquote><br>This seems like a conflation of concerns to me.<br><br>For example, I don't think having any old token with "profile" scope<br>should grant access to a user's subscription data. Keeping it as a<br>separate service with separate rules seems like it would avoid a lot of<br>auth-related complexity.<br><br><blockquote type="cite">GET /v1/purchases<br><br>{<br> "purchases": [<br> {<br> "mozilla-concrete": {<br> "products": ["product-a", "product-b"...],<br> "end-date": ...<br> ...<br> }<br> }<br> ]<br>}<br><br>Of course, there needs to be appropriate access on such information and this are features I don't think FxA has. For example: users and services (like Mozilla Concrete) would be able to read from /v1/purchases. But the user wouldn’t have access beyond GET, so they couldn’t alter their purchases.<br><br>Payments would have a service token that would allow us to alter the profile when the status of a purchase changes.<br></blockquote><br>Aside: we've started sketching out an idea for how backend<br>service-to-service authentication might work in the FxA ecosystem, any<br>feedback welcome:<br><br> <a href="https://github.com/mozilla/fxa-auth-server/pull/901">https://github.com/mozilla/fxa-auth-server/pull/901</a><br><br><blockquote type="cite">The goal is not to do to much specific around payments in Firefox Accounts, but in the end there's nothing special about an end-point like purchases. Its just an end point in the profile server with particular ACLs around it.<br></blockquote><br>Are all of the users purchases represented on a single endpoint? Does<br>this mean that Mozilla Concrete is able to see what I've purchased on<br>other unrelated services?<br><br><blockquote type="cite">Does that idea make sense?<br></blockquote><br>Broadly yes, but I think it makes *more* sense as a separate<br>micro-service than as an extra endpoint on any existing service.<br><br><br> Cheers,<br><br> Ryan<br>_______________________________________________<br>Dev-fxacct mailing list<br><a href="mailto:Dev-fxacct@mozilla.org">Dev-fxacct@mozilla.org</a><br><a href="https://mail.mozilla.org/listinfo/dev-fxacct">https://mail.mozilla.org/listinfo/dev-fxacct</a></div></blockquote></div><br></body></html>