Thanks Kumar!
I really love the idea of allowing in-app payments without forcing developers
to maintain a server side for their apps. IIRC there were already some
discussions about a possible web service for signing JWTs on the Marketplace
side during the Barcelona work week. I'm glad that this is still an option.
A few comments inline.
On 26/02/2013, at 23:42, Kumar McMillan 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 think we can introduce server-less in-app payments by hosting a Mozilla web
> service on behalf of developers -- that is, a service that any developer can
> use.
\o/ That'd be awesome!
>
> Instead of this on the app server:
>
> signedJWT = jwt.encode({
> request: {
> name: 'Rainbow Unicorn',
> description: 'A virtual unicorn for Adventure Game',
> pricePoint: 1 // EUR 0.89
> }
> }, '<secret-key>')
>
> and this on the client:
>
> navigator.mozPay([signedJWT])
>
> the developer could do something like this on the client only:
>
> var unicornId = 1234;
> payment.start(unicornId, function(jwt, transaction) {
>
> var request = navigator.mozPay([jwt]);
> request.onsuccess = function() {
> transaction.whenDone(function(error) {
> if (!error) {
> alert('You bought a Rainbow Unicorn!');
> }
> });
> };
>
> });
>
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.
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.
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.
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.
The process of getting the signed JWT and sending the payment request would be
completely handled by the native implementation.
We could also still keep the current navigator.mozPay([JWT]) along with this
addition.
Let me know if this makes sense, please.
Cheers!
/ Fernando
_______________________________________________
dev-webapps mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-webapps
