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

Re: Zero Click Bitcoin Micropayments using HTTP 402

From: Melvin Carvalho <melvincarvalho@gmail.com>
Date: Wed, 31 Dec 2014 16:51:00 +0100
Message-ID: <CAKaEYhK+40k9zkypdEx3dzpDXagW2nOio5HdM=AVnDEhcXzTXw@mail.gmail.com>
To: Anders Rundgren <anders.rundgren.net@gmail.com>
Cc: Kingsley Idehen <kidehen@openlinksw.com>, Web Payments <public-webpayments@w3.org>
On 31 December 2014 at 15:39, Anders Rundgren <anders.rundgren.net@gmail.com
> wrote:

> On 2014-12-31 12:11, Melvin Carvalho wrote:
>
>>
>>  <snip>
>
>>
>>     Since it doesn't do anything that you can't equally well do with 200
>> + suitable message
>>
>>
>> How can 200 + message = 402?
>>
>> 4xx in HTTP indicates an error
>>
>> 200 in HTTP indicates success
>>
>> What message do you envisage here?
>>
>
> 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.
>

xhr.status will be set to 402 and the js can switch on that


>
> 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 didnt think of using a proxy but that's another nice technique

http codes were designed to be used, sure you can issue a 200 for a page
not found and write some text, but 404 is the standards way


>
> 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.
>

I think there's some confusion.  There's some elements of payments that can
be done with *existing* standards and some that can require new standards.

If reusing standards already to solve a use case, then you are doing what
they were designed for.  Web standards are more like building blocks (think
html, css, http) than a one size fits all solution (think apple pay, google
wallet).

Payments have so many use cases that small modular pieces can end up doing
amazing things.  HTTP 402 is just one of those small pieces.

>
>
> Anders
>
> *] I guess this is what the demo thing did by "hijacking" the browser
> communication.
>
>>
>>     I didn't see the point with building on 402.
>>
>>
>>         I think this is off topic.
>>
>>
>>     Ok, I thought that HTTP 402 was the actual topic.
>>
>>
>> 402 is the topic, but it is already standardized. HTTP is one of the most
>> widely deployed protocols on the planet.  It means payment required.  So
>> the idea is that a page which is something like a paywall could return a
>> 402 as part of the request / response process.
>>
>> But this more related to HTTP / AWWW than to the 402 demo above.
>>
>> Not understanding how the extension works or what it's doing, thats ok,
>> youve said so already.
>>
>> I think your servlet demo is of topic because I dont know what you are
>> trying to show other than how HTTP works.
>>
>>
>>     IMO, you still owe us a description on entities and flows in your
>> scheme.
>>     It is completely unclear to me at least.
>>
>>     Example:
>>     http://webpki.org/papers/PKI/__EMV-Tokenization-SET-
>> 3DSecure-__WebCryptoPlusPlus-combo.pdf#__page=4 <
>> http://webpki.org/papers/PKI/EMV-Tokenization-SET-3DSecure-
>> WebCryptoPlusPlus-combo.pdf#page=4>
>>
>>
>>
>>
>>
>>                  I remain quite confused about your understanding of Web
>> Architecture.
>>
>>
>>              I'm talking about the browser-based scheme Melvin is
>> advocating which still
>>              is completely undocumented.
>>
>>
>>                  A browser is one kind of HTTP User Agent. That's it!
>>
>>
>>              Indeed, and I guess that is the one Melvin talked about.  If
>> it was not
>>              he should tell us.
>>
>>              Regards,
>>              Anders
>>
>>
>>
>>                  --
>>                  Regards,
>>
>>                  Kingsley Idehen
>>                  Founder & CEO
>>                  OpenLink Software
>>                  Company Web:http://www.openlinksw.com
>>                  Personal Weblog 1:http://kidehen.blogspot.com
>>                  Personal Weblog 2:http://www.openlinksw.com/__
>> __blog/~kidehen <http://www.openlinksw.com/__blog/~kidehen> <
>> http://www.openlinksw.com/__blog/~kidehen <http://www.openlinksw.com/
>> blog/~kidehen>>
>>                  Twitter Profile:https://twitter.com/____kidehen <
>> https://twitter.com/__kidehen> <https://twitter.com/kidehen>
>>                  Google+ Profile:https://plus.google.____com/+KingsleyIdehen/about
>> <https://plus.google.com/+__KingsleyIdehen/about <
>> https://plus.google.com/+KingsleyIdehen/about>>
>>                  LinkedIn Profile:http://www.linkedin.____com/in/kidehen
>> <http://www.linkedin.com/in/__kidehen <http://www.linkedin.com/in/kidehen
>> >>
>>                  Personal WebID:http://kingsley.idehen._
>> ___net/dataspace/person/kidehen#____this <http://kingsley.idehen.net/__
>> dataspace/person/kidehen#this <http://kingsley.idehen.net/
>> dataspace/person/kidehen#this>>
>>
>>
>>
>>
>>
>>
>>
>
Received on Wednesday, 31 December 2014 15:51:29 UTC

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