<p dir="ltr">That makes total sense and look a lot like what we set up for the reading list where users can store some urls attached to their fxa profile *besides* permissions.</p>
<p dir="ltr">Permissions are in our roadmap so we'd love a real use case.</p>
<p dir="ltr">For the RL we have /v1/articles and we can add a purchases collection in the same spirit. Our JSON api is very similar to your proposal.</p>
<p dir="ltr">In fact if you want to toy with a storage server we can start one dev instance on aws today and we could iterate on the permission model to see how it could look like.</p>
<p dir="ltr">In the long run if you need to have this endpoint under the profile server endpoint we can probably set up a routing on the server side and make sure our tokens can be used in both servuces (profile and storage)</p>
<p dir="ltr">Cheers <br>
Tarek<br></p>
<div class="gmail_quote">Le 3 avr. 2015 15:06, "Andy McKay" <<a href="mailto:amckay@mozilla.com">amckay@mozilla.com</a>> a écrit :<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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<br>
<br>
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>
<br>
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>
<br>
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>
<br>
Does that idea make sense?<br>
<br>
[1] <a href="https://twitter.com/andymckay/status/583619994396725248" target="_blank">https://twitter.com/andymckay/status/583619994396725248</a><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" target="_blank">https://mail.mozilla.org/listinfo/dev-fxacct</a><br>
</blockquote></div>