On Apr 5, 2015, at 10:02 PM, Ryan Kelly <[email protected]> wrote:
> 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?
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.
>
>> 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
_______________________________________________
Dev-fxacct mailing list
[email protected]
https://mail.mozilla.org/listinfo/dev-fxacct
