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 12:11:37 +0100
Message-ID: <CAKaEYhKGa15GL73PJp7biJibxqzCfn_N0-=5F70JFzUmS95WmQ@mail.gmail.com>
To: Anders Rundgren <anders.rundgren.net@gmail.com>
Cc: Kingsley Idehen <kidehen@openlinksw.com>, Web Payments <public-webpayments@w3.org>
On 30 December 2014 at 00:38, Anders Rundgren <anders.rundgren.net@gmail.com
> wrote:

> On 2014-12-30 00:19, Melvin Carvalho wrote:
>
>>
>>
>> On 29 December 2014 at 19:47, Anders Rundgren <
>> anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>>
>> wrote:
>>
>>     On 2014-12-29 18:54, Kingsley Idehen wrote:
>>
>>         On 12/28/14 2:05 AM, Anders Rundgren wrote:
>>
>>             In addition, I don't even think the idea using HTTP 402
>> actually buys you anything since it
>>             has no meaning in a browser (and thus for the user) which
>> means that there must always be
>>             a *proxy* involved which does the actual work.
>>
>>
>>         If 402 has no meaning in the browser, how does 200 magically have
>> meaning to said browser?
>>
>>
>>     Just to verify my claim I wrote a small Servlet that returned 402.
>>     Using sendError (402) IE, Chrome and Firefox returned an error page
>> saying that "payments are needed".
>>     Using setStatus (402) the same browsers did the same thing as for 200
>> showed the HTML page.
>>
>>     None of these responses has any use for payments as far as I can tell.
>>
>>
>> Are you expecting 4xx to do something special?  Does 404?  Or 401 or 403?
>>
>
> 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?


> 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
>
>
>
>>
>>
>>         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>
>>         Twitter Profile:https://twitter.com/__kidehen <
>> https://twitter.com/kidehen>
>>         Google+ Profile: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>
>>         Personal WebID:http://kingsley.idehen._
>> _net/dataspace/person/kidehen#__this <http://kingsley.idehen.net/
>> dataspace/person/kidehen#this>
>>
>>
>>
>>
>>
>
Received on Wednesday, 31 December 2014 11:12:06 UTC

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