Bitcoin Forum
December 03, 2016, 04:44:00 AM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Bitcoin and HTTP 402  (Read 3295 times)
Matt Corallo
Hero Member
*****
expert
Offline Offline

Activity: 751


View Profile
February 26, 2011, 11:52:37 AM
 #1

When HTTP/1.1 was created, a return code (402) was created to indicate that a payment is required.  However, no protocol has ever been created to use it, hence it sits as "reserved for future use".  Almost no sites actually use it (wikipedia seems to indicate that Apple's MobileMe uses it from time to time) and I though it would be a great use for bitcoin.
Many companies (Facebook/Zyga, Google's Chrome App Store, etc) are working to make it as easy to pay for goods on Internet "apps" as it is to pay on iPhones and Androids (well mostly iPhones). 
If Bitcoin is to be a currency for online purchases (IMHO it is perfect for such things), making it easy to buy things with Bitcoin is important.  Although it needs to be easy to buy Bitcoins with USD, it is also important for it to be easy to spend Bitcoins on digital goods.
Hence, I think the HTTP 402 Status Code should be used to request payment in-browser.  This could allow one-click ordering of digital goods with Bitcoin. 
A server would respond to a request with HTTP error 402 as well as a X-Bitcoin-Address and X-Bitcoin-Price headers and a browser could ask the user if they wish to transfer the amount specified to the address specified.  When the server confirms the payment, the user would be allowed to continue.  This could be implemented in a Firefox/Chrome/Safari/etc plugin which connects to a bitcoin RPC daemon or to Mybitcoin,etc.  If a client doesn't have such a plugin, the 402 should still allow the site to send a page which requests that a Bitcoin or other transfer be made.
Does this seem like a good idea?  Would someone be willing to make a simple plugin which implements this?

Bitcoin Ubuntu PPA maintainer - donate to me personally: 1JBMattRztKDF2KRS3vhjJXA7h47NEsn2c
http://bitcoinrelaynetwork.org maintainer
PGP ID: 07DF 3E57 A548 CCFB 7530  7091 89BB B866 3E2E65CE
1480740240
Hero Member
*
Offline Offline

Posts: 1480740240

View Profile Personal Message (Offline)

Ignore
1480740240
Reply with quote  #2

1480740240
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1480740240
Hero Member
*
Offline Offline

Posts: 1480740240

View Profile Personal Message (Offline)

Ignore
1480740240
Reply with quote  #2

1480740240
Report to moderator
Matt Corallo
Hero Member
*****
expert
Offline Offline

Activity: 751


View Profile
February 26, 2011, 12:44:36 PM
 #2

TD brings up a good point on IRC.  There already is a bitcoin:... uri scheme which it would make more sense to use (why reinvent the wheel?).  In any case a protocol handler browser plugin or application would work just as well in this case.  Comments?

Bitcoin Ubuntu PPA maintainer - donate to me personally: 1JBMattRztKDF2KRS3vhjJXA7h47NEsn2c
http://bitcoinrelaynetwork.org maintainer
PGP ID: 07DF 3E57 A548 CCFB 7530  7091 89BB B866 3E2E65CE
garyrowe
Full Member
***
Offline Offline

Activity: 124



View Profile WWW
August 08, 2012, 09:06:25 AM
 #3

I don't think that the Bitcoin URI on its own is sufficient. Bitcoin provides a strong case to make the 402 PAYMENT_REQUIRED HTTP response code much more useful and I would like to solicit further comments from the community on this.

Here is a simplified version of Matt's original proposal:

Current credit card approach
The HTTP traffic surrounding a standard credit card intercept looks like this:

> GET /premium/track/10
> Accept: audio/ogg

< 302 FOUND
< Location: https://secure.example.org/cc-form.html

The above response initiates a chain of requests and responses involving the entry of a number of credentials which culminates in the server accepting that payment has been made and then delivering the content.

What should be noted is that the use of the 302 FOUND is subverting the semantics of the HTTP response code. The resource has not been temporarily moved, rather a new process has been introduced. There is a specific HTTP response code for this scenario but it has not been given sufficient detail in the current HTTP specification.

Proposed internet currency approach
There are many competing technologies in the online payment space. However, Bitcoin has the advantage of having a single URI providing all the information required to make a secure payment.

> GET /premium/track/10
> Accept: audio/ogg; payment/litecoin; q=0.2, payment/bitcoin

Bitcoin response
< 402 PAYMENT_REQUIRED
< Location: bitcoin:1KzTSfqjF2iKCduwz59nv2uqh1W2JsTxZH?amount=0.5&label=Track10

In the second approach, the client is able to specify a range of preferred payment protocols which the server can negotiate. The above request would be interpreted as "I want audio/ogg, but if payment has to be made then I prefer Bitcoin but Litecoin is acceptable".

Since an appropriate HTTP response code is being given the client knows that it has to initiate a payment. This could trigger additional security measures and warnings to the user. The Location header provides a URI which can be handled by the client, such as a HTTPS URI, or by a dedicated protocol handler such as a Bitcoin client.

I've been in discussion with Michael Leonhard who manages the http://http402.org/ site and he is of the opinion that Roy Fielding or Tim Berners-Lee might be interested in this.

Bitcoin enthusiast and Java programmer contributing to https://multibit.org and http://bitcoin.stackexchange.com
garyrowe
Full Member
***
Offline Offline

Activity: 124



View Profile WWW
August 08, 2012, 09:56:43 AM
 #4

I don't think it's a good idea. This HTTP code could be useful for micro-payments, to give instant access to a newspaper article for example. But Bitcoin is not suitable for micro-payments, and nobody wants to wait for X confirmations before being able to continue browsing the web.
 

A 402 response code will not cause the browser to freeze up while payment is made. Instead, it simply communicates the need for payment to the browser which, in the case of Bitcoin, would occur out of band through the blockchain.

To address your concerns over micro-payments - that is a policy decision to be made by the merchant running the server. If they choose to allow 0-confirm transactions for small value items then that is up to them.

For larger value items, the merchant may choose to only accept a 6-confirm transaction before shipment. However, if the product is software then a trial version can be downloaded immediately, with a note stating that the full license key will be made available under a particular URI once payment is fully confirmed (or simply emailed for those less concerned about privacy).

All of the above are policy decisions for the merchant, HTTP cares not about this. The 402 response code still provides an efficient communication of a demand for payment and a means for the browser to accomplish this.

Bitcoin enthusiast and Java programmer contributing to https://multibit.org and http://bitcoin.stackexchange.com
Andreas Schildbach
Hero Member
*****
Offline Offline

Activity: 563



View Profile WWW
August 08, 2012, 02:10:24 PM
 #5

I think there should be a way for the user to hand a signed Bitcoin transaction directly to the webserver requesting the coins. Because there is no guarantee that even a non-confirmed transaction will ever arrive. Perhaps the sender does not even have Internet access (the web page could be on a local LAN only).

Bitcoin Wallet for Android: Your own Bitcoins, in your own pocket!
https://play.google.com/store/apps/details?id=de.schildbach.wallet
paraipan
Legendary
*
Offline Offline

Activity: 924


Firstbits: 1pirata


View Profile WWW
August 08, 2012, 02:20:19 PM
 #6

Interesting, I think this could go very well with the Wifi hotspot powered by bitcoin

BTCitcoin: An Idea Worth Saving - Q&A with bitcoins on rugatu.com - Check my rep
garyrowe
Full Member
***
Offline Offline

Activity: 124



View Profile WWW
August 08, 2012, 02:33:06 PM
 #7

I think there should be a way for the user to hand a signed Bitcoin transaction directly to the webserver requesting the coins. Because there is no guarantee that even a non-confirmed transaction will ever arrive. Perhaps the sender does not even have Internet access (the web page could be on a local LAN only).

Bear in mind that this is HTTP error response code. Essentially, you have just rocked up and asked for a premium resource and been pushed back. If you know in advance that this requires payment then you perform something like the following:

> GET /premium/track/10
> Bitcoin-Transaction: <signed tx using generally defined non-HTTP standard>

I leave the implementation of the bit above as an exercise for the reader  Wink

Bitcoin enthusiast and Java programmer contributing to https://multibit.org and http://bitcoin.stackexchange.com
Andreas Schildbach
Hero Member
*****
Offline Offline

Activity: 563



View Profile WWW
August 08, 2012, 02:47:13 PM
 #8

Yes, sure, I was thinking of something like that.

After being pushed back and trying again - this time with money in your hands - you'll be granted access. Similar to HTTP authentication mechanisms.

Bitcoin Wallet for Android: Your own Bitcoins, in your own pocket!
https://play.google.com/store/apps/details?id=de.schildbach.wallet
garyrowe
Full Member
***
Offline Offline

Activity: 124



View Profile WWW
August 08, 2012, 03:00:05 PM
 #9

Yes, sure, I was thinking of something like that.

After being pushed back and trying again - this time with money in your hands - you'll be granted access. Similar to HTTP authentication mechanisms.

That's the idea.

Of course this approach is not limited to Bitcoin. PayPal could do something similar, but they would set the 402 Location header to some kind of credential entry page.

Bitcoin enthusiast and Java programmer contributing to https://multibit.org and http://bitcoin.stackexchange.com
gweedo
Legendary
*
Offline Offline

Activity: 1246


Java, PHP, HTML/CSS Programmer for Hire!


View Profile WWW
August 08, 2012, 03:24:26 PM
 #10

This is super insecure!!! Bitcoin URI is the best way to do this, there is a reason no one uses 402 response http header

Want to earn 2500 SATOSHIS per hour? Come Chat and Chill in https://goseemybits.com/lobby
garyrowe
Full Member
***
Offline Offline

Activity: 124



View Profile WWW
August 08, 2012, 03:27:00 PM
 #11

This is super insecure!!! Bitcoin URI is the best way to do this, there is a reason no one uses 402 response http header

Would you mind walking me through the security issues with this approach?

The 402 response for "payment/bitcoin" contains a Bitcoin URI, and can be served up through HTTPS to avoid MITM attacks. Short of a server compromise I'm not sure what the attack vector is.

Bitcoin enthusiast and Java programmer contributing to https://multibit.org and http://bitcoin.stackexchange.com
gweedo
Legendary
*
Offline Offline

Activity: 1246


Java, PHP, HTML/CSS Programmer for Hire!


View Profile WWW
August 08, 2012, 03:34:13 PM
 #12

This is super insecure!!! Bitcoin URI is the best way to do this, there is a reason no one uses 402 response http header

Would you mind walking me through the security issues with this approach?

The 402 response for "payment/bitcoin" contains a Bitcoin URI, and can be served up through HTTPS to avoid MITM attacks. Short of a server compromise I'm not sure what the attack vector is.

Yes I can, and if your just use the 402 http header as a way to tell programs thru an api to pay, and return a bitcoin URI is fine. BUTTTTTTTT someone was describing using 402 to start the client to start the payment process and locking down the browser, this is a security flaw. PHP can start a 402 and use javascript to control everything so the user would have no idea until funds are flowing.

Want to earn 2500 SATOSHIS per hour? Come Chat and Chill in https://goseemybits.com/lobby
garyrowe
Full Member
***
Offline Offline

Activity: 124



View Profile WWW
August 08, 2012, 04:06:35 PM
 #13

This is super insecure!!! Bitcoin URI is the best way to do this, there is a reason no one uses 402 response http header

Would you mind walking me through the security issues with this approach?

The 402 response for "payment/bitcoin" contains a Bitcoin URI, and can be served up through HTTPS to avoid MITM attacks. Short of a server compromise I'm not sure what the attack vector is.

Yes I can, and if your just use the 402 http header as a way to tell programs thru an api to pay, and return a bitcoin URI is fine. BUTTTTTTTT someone was describing using 402 to start the client to start the payment process and locking down the browser, this is a security flaw. PHP can start a 402 and use javascript to control everything so the user would have no idea until funds are flowing.

Thanks for the extra detail.

From what you describe, you're worried that the browser would handle the Bitcoin URI differently as a result of a 402 than it would as a result of, say, a user clicking on a link. That is not the case. Having the additional information from the server that a payment is about to be made, the browser can tighten its security to provide a temporary locked down sandbox while the payment process goes through. Simply clicking a link does not give the browser this information.

Of course, a compromised browser would have the option of rewriting data, but that would happen with any HTML feed and the browser manufacturers go to some lengths to detect internal compromise. That is outside the scope of this proposal.

Regarding a PHP/JavaScript attack by controlling the browser to make the payment, this is mitigated by the Bitcoin client (the protocol handler) asking the user to confirm the payment in the same way as clicking on the link does. The browser isn't in charge of the payment, an external app is.

EDIT To emphasise that JavaScript is not permitted to take over the mouse pointer and drive it around the screen
http://stackoverflow.com/a/4752512/396747

Bitcoin enthusiast and Java programmer contributing to https://multibit.org and http://bitcoin.stackexchange.com
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!