Hi Fernando. On Feb 27, 2013, at 5:01 AM, Fernando Jiménez <[email protected]> wrote:
>> First, this proposal would not require any changes to the underlying >> navigator.mozPay() API or the current JWT spec. No B2G client changes would >> be needed. It would be built on top of these existing APIs. > > Is there any reason why you are not considering these changes an option for > the navigator.mozPay() API? I had a couple reasons in mind. First is that not changing the API means we could ship a server-less solution e.g. tomorrow or whenever it's ready. Another is that this feels to me more like a "helper library" solution rather than an API enhancement. Lastly, it might make sense to apply it to real solutions and let it evolve before we bake it into the API. That would prove out its usefulness and reveal warts. If there is a clear way to fit it into the API then I'd be all for it. >> > > I like your proposal, but I have a few concerns about it: > > 1. This seems to be very tied and dependent of the Mozilla Marketplace. It > would be great if we could allow developers to build and use its own JWT > signing service, while we still give them the chance to use the one exposed > by the Mozilla Marketplace or any other market (in the end, we are trying to > build the most open API as possible). You may say devs already have that > chance with the current API, and I agree on that, but I think that we still > can make the process easier (see my proposal below, please) and somehow > provide an "standard" way of signing payment requests. How is it tied specifically to Mozilla's Marketplace? Do you mean that for whatever server it's hosted on, the implementation is tied to *that* server? Then, yes. That's the only way I could see it working from a security perspective. The key point is that the client has to fetch a signed payment request (JWT) in a way that does not compromise the integrity of the payment request. If the developer wants to lock down the product price, she has to refer to the product by some identifier. The server has to know what the price is and keep it secure. But, yes, of course, if we implement this for Firefox Marketplace then we could easily do it as a standalone, easy-to-install service. Anyone could run their own service on AWS/Heroku and pay their own server bills. > > 2. IMHO a wrapper around the current API adds unnecessary complexity. We > should (and probably can) build what you are proposing extending the current > navigator.mozPay API. I am not sure if you are proposing the wrapper as a > long term solution though. Maybe you also have in mind modifying the API with > these additions in the future. It is not clear to me how the current API could be modified to securely allow server-less payments. I'm open to ideas. I think we would need some kind of drastic API change, perhaps one that managed *public* keys per merchant so that a decentralized chain of trust can be established. Even in such a case, I think servers need to be involved in that for security. At that point, we may just want to throw the whole navigator.mozPay() API out and join the Pay Swarm API :) See http://payswarm.com/ and http://www.w3.org/community/webpayments/ That could be a whole other thread. I have a few issues with their approach too. > > 3. How would you manage refunds? I can't see how would you tell the web > service that your intention is to get a JWT for a refund request and not for > a payment one. That's a good question! However, refunds are so hard for in-app payments that we've pretty much already ignored them. The current API also has no reliable way to do refunds. Take the example of ad-hoc JWTs (in the current API). Let's say a customer paid to "unlock level 10" then she beat level 10 and decided to be sneaky and ask for a refund. How do we grant a refund? The current navigator.mozPay() has no memory of "the product." It cannot take away "Unlock level 10" after a refund because it doesn't know how. In this case, it would be impossible to take away Unlock level 10. For now we are not supporting refunds for in-app payments. In the future, maybe developers could opt-in to refunds and then our app reviewers would have to be sure that they *can* grant refunds before we allow them to. For Marketplace app purchases, it's easier to implement refunds because we know what the app logic is inside the Firefox Marketplace. We know how to take away apps. > > > So my proposal, based on yours, would be extending the API this way: > > "DOMDOMRequest mozPay(DOMString signingService, jsval dataToBeSigned)" > > where: > - "signingService" would be the URL of the Mozilla web service or any other > JWT signing web service. > - "dataToBeSigned" would be a JSON object containing whatever is expected by > the signing service. It could be the identifier of the product being sold or > refunded and a flag for setting a payment or a refund, for example. ok, let's say an app does this: nav.mozPay('https://mkt/payments/signing-service', { request: { name: 'Rainbow Unicorn', pricePoint: 4 // USD $3.99 } }) What would that do? POST the raw JSON blob to the signing service and get backed a signed JWT? That would defeat the purpose of the signature because then anyone can sign anything. An attacker could just patch the app and change the JS to do this (note the price change): nav.mozPay('https://mkt/payments/signing-service', { request: { name: 'Rainbow Unicorn', pricePoint: 1 // USD $0.99 } }) and they would get the product for whatever price they wanted. Am I missing something? -Kumar _______________________________________________ dev-webapps mailing list [email protected] https://lists.mozilla.org/listinfo/dev-webapps
