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

Re: Zero Click Bitcoin Micropayments using HTTP 402

From: Kingsley Idehen <kidehen@openlinksw.com>
Date: Wed, 31 Dec 2014 14:15:12 -0500
Message-ID: <54A44B40.3050409@openlinksw.com>
To: public-webpayments@w3.org
On 12/31/14 1:10 PM, Anders Rundgren wrote:
> 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.

He meant: 402 is an error code for payment oriented communications over 
HTTP. That's it.

-- 
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
Twitter Profile: https://twitter.com/kidehen
Google+ Profile: https://plus.google.com/+KingsleyIdehen/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen
Personal WebID: http://kingsley.idehen.net/dataspace/person/kidehen#this


Received on Wednesday, 31 December 2014 19:15:35 UTC

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