Bitcoin and HTTP 402

[Matt Corallo]

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?

[1714822945]

1714822945

[1714822945]

1714822945

[Matt Corallo]

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?

[garyrowe]

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.

[garyrowe]

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.

[Andreas Schildbach]

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

[paraipan]

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

[garyrowe]

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 

[Andreas Schildbach]

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.

[garyrowe]

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.

[gweedo]

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

[garyrowe]

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.

[gweedo]

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.

[garyrowe]

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