On 4/04/2015 00:05, Andy McKay wrote:
> tl;dr we need somewhere people can query to see if a purchase has been
> completed.
>
> 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.
>
> Behind the scenes we'll send a server to server notification, hopefully
> through FxA notification queue (more on that in later emails).
>
> 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:
>
> 1) payments stands up an API that can receive the appropriate bearer token
> for that user or
I suspect it's not the solution you intend to advocate, but at first
glance, this feels like the right shape for the public-facing API of
this thing.
Internally we may implement it atop a more generic fxa-attached
cloud-storage thing based on Tarek's team's ongoing work. But I like
the idea of it appearing to the rest of the world as a separate
"payments info" service with a purpose-specific API.
What downsides do you see to implementing this as a special-purpose API?
> 2) we write into an storage space, like the profile server.
>
> 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.
This seems like a conflation of concerns to me.
For example, I don't think having any old token with "profile" scope
should grant access to a user's subscription data. Keeping it as a
separate service with separate rules seems like it would avoid a lot of
auth-related complexity.
> GET /v1/purchases
>
> {
> "purchases": [
> {
> "mozilla-concrete": {
> "products": ["product-a", "product-b"...],
> "end-date": ...
> ...
> }
> }
> ]
> }
>
> 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.
>
> Payments would have a service token that would allow us to alter the profile
> when the status of a purchase changes.
Aside: we've started sketching out an idea for how backend
service-to-service authentication might work in the FxA ecosystem, any
feedback welcome:
https://github.com/mozilla/fxa-auth-server/pull/901
> 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.
Are all of the users purchases represented on a single endpoint? Does
this mean that Mozilla Concrete is able to see what I've purchased on
other unrelated services?
> Does that idea make sense?
Broadly yes, but I think it makes *more* sense as a separate
micro-service than as an extra endpoint on any existing service.
Cheers,
Ryan
_______________________________________________
Dev-fxacct mailing list
[email protected]
https://mail.mozilla.org/listinfo/dev-fxacct
