Re: Zero Click Bitcoin Micropayments using HTTP 402

Dear List,

Just for my understanding:

You (all?) believe that saving one or two lines of JS is enough to push HTTP 402
as a foundation for a new W3C payment standard?  HTTP 402 is not a payment standard,
it is just an [to date unused] HTTP code defined some 20 years ago.

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 :-)

Note that *real* standardization is anything but a rose garden:
http://lists.w3.org/Archives/Public/public-webcrypto/2014Dec/0070.html
Getting the security folks agreeing on solutions is always an uphill battle.

Anders


On 2014-12-31 16:36, UniDyne wrote:
> On Wed, Dec 31, 2014 at 9:39 AM, Anders Rundgren <anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>> wrote:
>
>
>     Since HTTP 402 directed to the *browser window* doesn't apply, we are rather talking
>     about a proxy that in the background does the communication.  In your case through XHR.
>
>     If I were to design such a scheme I would let the proxy call return two responses
>     both having the response code 200.  One message would be like "OK"  which I understand
>     should trigger the proxy to perform a URL access to the requested resource.  The
>     other response would be "Payment Required + associated information on what kind of
>     payments that are accepted and how much money that is requested.
>
>
> I think a 402 would allow better handling. A 200 response would have the requested content where 402 would indicate payment were necessary. If both types of response were 200, you are saying that neither response contains the requested media - or it is somehow embedded in the response. I would advocate handling it at protocol level (402 / 200) so you don't have to mess with the response when it contains media.
>
>     So even if one could do the same thing with HTTP 402 the question remains: Why would
>     this be better unless 402 got a built-in payment hook[*] in the browser?  I would be
>     interested hearing Manu's opinion on this since he and Digital Bazaar really are
>     the only parties who have provided CG specifications.
>
>
> A 402 response could always include headers with the necessary information. Non-compliant browsers / applications would simply read this as any other 400 "access denied" message.
>
>

Received on Wednesday, 31 December 2014 17:04:39 UTC