W3C home > Mailing lists > Public > public-webpayments@w3.org > December 2014

Re: Zero Click Bitcoin Micropayments using HTTP 402

From: Anders Rundgren <anders.rundgren.net@gmail.com>
Date: Wed, 31 Dec 2014 19:10:39 +0100
Message-ID: <54A43C1F.7060503@gmail.com>
To: Randall Leeds <randall.leeds@gmail.com>, UniDyne <unidyne@gmail.com>
CC: Melvin Carvalho <melvincarvalho@gmail.com>, Kingsley Idehen <kidehen@openlinksw.com>, Web Payments <public-webpayments@w3.org>
On 2014-12-31 18:59, Randall Leeds wrote:
>
> You're taking past one another. Let me clear a few things, having read this whole back and forth.
>
> - This would be more than a couple lines of js.
>
> - The code would need to intercept navigation and present a payment screen. That could be done by a proxy or a browser extension or as built in browser behavior. For a proof of concept, any would be acceptable.
>
> - A Chrome extension is a working demonstration of something which could be built into a browser, and is more reasonable for many people to test an idea than installing a fork of a browser. It's closer to the right separation of entities than having a proxy. No one should be concerned that a proof of concept starts this way. Everyone should understand that whatever UI and interaction is written into such an extension is a stand in for a future built in feature.
>
> - 402 is the clear choice for the status code of the initial response exactly because it has largely been ignored. There are no *conflicting* semantics already defined, and that's what really matters.
>
> - 402 is only sufficient to say that payment is required, whereas accessing paid content involves also making the payment and then requesting the content with proof of payment. Melvin described this proof as given by certificates, but didn't describe the payment or the mechanism by which that payment changes the balance associated with the certificate. All that needs to be specified still, but that doesn't mean 402 is wrong.
>
> Interface guidelines are needed for the agent, as well as the protocol for making the payment and making the authenticated access thereafter.
>
> But let that come later.
>
>
>     Anyway, this idea won't go anywhere (in this context NB...) until a proper
>     specification is presented.  Based on two years experience with this forum
>     I don't think there will be such a thing but nobody would be more happy
>     than I if I was proven wrong :-)
>
>
> I would encourage people to follow through with demonstrations and implementations and worry about spec writing later.
>

Currently the specification is: "HTTP 402 was defined for payments, let's put it to work"
That's apparently enough for this forum, for me it is not.

Melvin claims that an AJAX solution + X.509 works great.  However, there is neither a description or a test-site for verifying this.

I don't intend to debate this more, ideas without descriptions lack value.

Anders

> A mailing list is a fine place for informal collaboration and design. Proposals need not come in the form of entity diagrams and specifications. If something isn't clear, work together to clarify. No need to get mired in spec writing before even trying to implement a prototype.
>
> I hope that wasn't too confrontational and that it helps move the conversation forward.
>
Received on Wednesday, 31 December 2014 18:11:13 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:07:37 UTC