|
| 1 | +<pre> |
| 2 | + BIP: 273 |
| 3 | + Title: Use "Accept" header for response type negotiation with Simplified Payment Request URLs |
| 4 | + Author: Wallet Workshop |
| 5 | + Created: 2019-02-22 |
| 6 | +</pre> |
| 7 | + |
| 8 | +==Abstract== |
| 9 | + |
| 10 | +This BIP describes an enhancement to the payment protocol ([[bip-0270.mediawiki|BIP 270]]) |
| 11 | +that addresses the need for short URLs when scanning from QR codes. It |
| 12 | +generalizes the specification for the behavior of a payment request URL in a |
| 13 | +way that allows the client and server to negotiate the content of the |
| 14 | +response using the HTTP Accept: header field. Specifically, the client |
| 15 | +can indicate to the server whether it prefers to receive a bitcoin URI or |
| 16 | +a payment request. |
| 17 | + |
| 18 | +Implementation of this BIP does not require full payment request ([[bip-0270.mediawiki|BIP 270]]) support. |
| 19 | + |
| 20 | +==Motivation== |
| 21 | + |
| 22 | +The simplified payment protocol augments the bitcoin: uri scheme with an |
| 23 | +additional "payment" parameter that specifies a URL where a payment request can |
| 24 | +be downloaded. This creates long URIs that, when rendered as a QR code, have a |
| 25 | +high information density. Dense QR codes can be difficult to scan resulting in |
| 26 | +a more frustrating user experience. The goal is to create a standard that would |
| 27 | +allow QR scanning wallets to use less dense QR codes. It also makes general |
| 28 | +purpose QR code scanners more usable with bitcoin accepting websites. |
| 29 | + |
| 30 | +==Specification== |
| 31 | + |
| 32 | +QR scanning wallets will consider a non bitcoin URI scanned from a QR code to |
| 33 | +be an end point where either a bitcoin URI or a payment request can be obtained. |
| 34 | + |
| 35 | +A wallet client uses the Accept: HTTP header to specify whether it can accept |
| 36 | +a payment request, a URI, or both. A media type of text/uri-list specifies that |
| 37 | +the client accepts a bitcoin URI. A media type of application/bitcoinsv-paymentrequest |
| 38 | +specifies that the client can process a payment request. In the absence of an |
| 39 | +Accept: header, the server is expected to respond with text/html suitable for |
| 40 | +rendering in a browser. An HTML response will ensure that QR codes scanned |
| 41 | +by non Bitcoin wallet QR scanners are useful (they could render an HTML page |
| 42 | +with a payment link that when clicked would open a wallet on the device). |
| 43 | + |
| 44 | +It is not required that the client and server support the full semantics of an |
| 45 | +HTTP Accept header. If application/bitcoinsv-paymentrequest is specified in the |
| 46 | +header, the server should send a payment request regardless of anything else |
| 47 | +specified in the Accept header. If text/uri-list is specified (but not |
| 48 | +application/bitcoinsv-paymentrequest), a valid Bitcoin URI should be returned. If |
| 49 | +neither is specified, the server can return an HTML page. When a uri-list is returned |
| 50 | +only the first item in the list is used (and expected to be a bitcoin URI), any additional |
| 51 | +URIs should be ignored. |
| 52 | + |
| 53 | +==Compatibility== |
| 54 | + |
| 55 | +Only QR scanning wallets that implement this BIP will be able to process QR |
| 56 | +codes containing payment request URLs. There are two possible workarounds for QR |
| 57 | +scanning wallets that do not implement this BIP: 1) the server gives the user an |
| 58 | +option to change the QR code to a bitcoin: URI or 2) the user scans the code with |
| 59 | +a generic QR code scanner. |
| 60 | + |
| 61 | +In the second scenario, if the server responds with a webpage containing a link |
| 62 | +to a bitcoin URI, the user can complete the payment by clicking that link provided |
| 63 | +the user has a wallet installed on their device and it supports bitcoin URIs. If the |
| 64 | +wallet/device does not have support for bitcoin URIs, the user can fall back on |
| 65 | +address copy/paste. |
| 66 | + |
| 67 | +This BIP should be fully compatible with BIP 70 assuming it is required that wallets |
| 68 | +implementing BIP 70 make use of the Accept: HTTP header when retrieving a |
| 69 | +payment request. |
| 70 | + |
| 71 | +==Examples== |
| 72 | +The first image below is of a bitcoin URI with an amount and payment request |
| 73 | +specified (note, this is a fairly minimal URI as it does not contain a |
| 74 | +label and the request URL is of moderate size). The second image is a QR |
| 75 | +code with only the payment request url specified. |
| 76 | + |
| 77 | +<img src=bip-0073/a.png></img><img src=bip-0073/b.png></img> |
0 commit comments