「BIP 0073」の版間の差分
細 (1 revision imported) |
|||
| 1行目: | 1行目: | ||
| − | + | ||
| − | + | ==BIP 0073== | |
| − | + | BIP: 73 | |
| − | + | Title: Use "Accept" header for response type negotiation with Payment Request URLs | |
| − | + | Author: Stephen Pair <stephen@bitpay.com> | |
| − | + | Status: Draft | |
| − | + | Type: Standards Track | |
| − | + | Created: 27-08-2013 | |
==Abstract== | ==Abstract== | ||
| − | This BIP describes an enhancement to the payment protocol ( | + | This BIP describes an enhancement to the payment protocol (BIP 73) that addresses the need for short URLs when scanning from QR codes. It generalizes the specification for the behavior of a payment request URL in a way that allows the client and server to negotiate the content of the response using the HTTP Accept: header field. Specifically, the client can indicate to the server whether it prefers to receive a bitcoin URI or a payment request. |
| − | that addresses the need for short URLs when scanning from QR codes. | ||
| − | generalizes the specification for the behavior of a payment request URL in a | ||
| − | way that allows the client and server to negotiate the content of the | ||
| − | response using the HTTP Accept: header field. | ||
| − | can indicate to the server whether it prefers to receive a bitcoin URI or | ||
| − | a payment request. | ||
| − | Implementation of this BIP does not require full payment request ( | + | Implementation of this BIP does not require full payment request (BIP 73) support. |
==Motivation== | ==Motivation== | ||
| − | The payment protocol augments the bitcoin: uri scheme with an additional | + | The payment protocol augments the bitcoin: uri scheme with an additional "payment" parameter that specifies a URL where a payment request can be downloaded. This creates long URIs that, when rendered as a QR code, have a high information density. Dense QR codes can be difficult to scan resulting in a more frustrating user experience. The goal is to create a standard that would allow QR scanning wallets to use less dense QR codes. It also makes general purpose QR code scanners more usable with bitcoin accepting websites. |
| − | "payment" parameter that specifies a URL where a payment request can be | ||
| − | downloaded. | ||
| − | a high information density. | ||
| − | in a more frustrating user experience. | ||
| − | would allow QR scanning wallets to use less dense QR codes. | ||
| − | general purpose QR code scanners more usable with bitcoin accepting | ||
| − | websites. | ||
==Specification== | ==Specification== | ||
| − | QR scanning wallets will consider a non bitcoin URI scanned from a QR code to | + | QR scanning wallets will consider a non bitcoin URI scanned from a QR code to be an end point where either a bitcoin URI or a payment request can be obtained. |
| − | be an end point where either a bitcoin URI or a payment request can be obtained. | ||
| − | A wallet client uses the Accept: HTTP header to specify whether it can accept | + | A wallet client uses the Accept: HTTP header to specify whether it can accept a payment request, a URI, or both. A media type of text/uri-list specifies that the client accepts a [[bitcoin]] URI. A media type of application/bitcoin-paymentrequest specifies that the client can process a payment request. In the absence of an Accept: header, the server is expected to respond with text/html suitable for rendering in a browser. An HTML response will ensure that QR codes scanned by non [[Bitcoin wallet]] QR scanners are useful (they could render an HTML page with a payment link that when clicked would open a wallet on the device). |
| − | a payment request, a URI, or both. | ||
| − | the client accepts a bitcoin URI. A media type of application/bitcoin-paymentrequest | ||
| − | specifies that the client can process a payment request. | ||
| − | Accept: header, the server is expected to respond with text/html suitable for | ||
| − | rendering in a browser. | ||
| − | by non Bitcoin wallet QR scanners are useful (they could render an HTML page | ||
| − | with a payment link that when clicked would open a wallet on the device). | ||
| − | It is not required that the client and server support the full semantics of an | + | It is not required that the client and server support the full semantics of an HTTP Accept header. If application/bitcoin-paymentrequest is specified in the header, the server should send a payment request regardless of anything else specified in the Accept header. If text/uri-list is specified (but not application/bitcoin-paymentrequest), a valid Bitcoin URI should be returned. If neither is specified, the server can return an HTML page. When a uri-list is returned only the first item in the list is used (and expected to be a bitcoin URI), any additional URIs should be ignored. |
| − | HTTP Accept header. | ||
| − | header, the server should send a payment request regardless of anything else | ||
| − | specified in the Accept header. | ||
| − | application/bitcoin-paymentrequest), a valid Bitcoin URI should be returned. | ||
| − | neither is specified, the server can return an HTML page. | ||
| − | only the first item in the list is used (and expected to be a bitcoin URI), any additional | ||
| − | URIs should be ignored. | ||
==Compatibility== | ==Compatibility== | ||
| − | Only QR scanning wallets that implement this BIP will be able to process QR | + | Only QR scanning wallets that implement this BIP will be able to process QR codes containing payment request URLs. There are two possible workarounds for QR scanning wallets that do not implement this BIP:<br> |
| − | codes containing payment request URLs. | + | 1) the server gives the user an option to change the QR code to a bitcoin: URI or <br> |
| − | scanning wallets that do not implement this BIP: 1) the server gives the user an | + | 2) the user scans the code with a generic QR code scanner.<br> |
| − | option to change the QR code to a bitcoin: URI or 2) the user scans the code with | + | |
| − | a generic QR code scanner. | + | In the second scenario, if the server responds with a webpage containing a link to a bitcoin URI, the user can complete the payment by clicking that link provided the user has a wallet installed on their device and it supports bitcoin URIs. If the wallet/device does not have support for bitcoin URIs, the user can fall back on address copy/paste.<br> |
| + | |||
| + | This BIP should be fully compatible with BIP 70 assuming it is required that wallets implementing BIP 70 make use of the Accept: HTTP header when retrieving a payment request.<br> | ||
| + | |||
| + | ==Examples== | ||
| + | |||
| + | The first image below is of a bitcoin URI with an amount and payment request specified (note, this is a fairly minimal URI as it does not contain a label and the request URL is of moderate size). The second image is a QR code with only the payment request url specified.[https://github.com/] | ||
| + | [[File:b.png|centre|500px|BIP 0073]] | ||
| + | |||
| + | ==BitPay and BIP 73 == | ||
| + | BitPay also supports BIP 73, which considerably improves the usability of QR codes for Bitcoin payments. BIP 73 reduces the information required to be embedded in a payment request QR code, reducing their density. Less dense QR codes are easier to use in low light situations or from longer distances. These lower density QR codes are also normal HTTP URLs, offering an opportunity to provide additional information and instructions to users of devices that don’t already have a wallet installed. Read more about BIP 73 and BitPay [https://bitpay.com/downloads/bitpayApi.pdf here]. | ||
| + | |||
| + | ==See also== | ||
| + | [[BIP 0001]] | ||
| − | + | [[Bitcoin Improvement Proposals]] | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | + | ==Source== | |
| − | + | [https://bitpay.com/downloads/bitpayApi.pdf https://bitpay.com/downloads/bitpayApi.pdf] | |
| − | |||
| − | [ | + | [https://github.com/ https://github.com/] |
| − | |||
| − | |||
2018年3月2日 (金) 20:38時点における版
目次
BIP 0073
BIP: 73 Title: Use "Accept" header for response type negotiation with Payment Request URLs Author: Stephen Pair <stephen@bitpay.com> Status: Draft Type: Standards Track Created: 27-08-2013
Abstract
This BIP describes an enhancement to the payment protocol (BIP 73) that addresses the need for short URLs when scanning from QR codes. It generalizes the specification for the behavior of a payment request URL in a way that allows the client and server to negotiate the content of the response using the HTTP Accept: header field. Specifically, the client can indicate to the server whether it prefers to receive a bitcoin URI or a payment request.
Implementation of this BIP does not require full payment request (BIP 73) support.
Motivation
The payment protocol augments the bitcoin: uri scheme with an additional "payment" parameter that specifies a URL where a payment request can be downloaded. This creates long URIs that, when rendered as a QR code, have a high information density. Dense QR codes can be difficult to scan resulting in a more frustrating user experience. The goal is to create a standard that would allow QR scanning wallets to use less dense QR codes. It also makes general purpose QR code scanners more usable with bitcoin accepting websites.
Specification
QR scanning wallets will consider a non bitcoin URI scanned from a QR code to be an end point where either a bitcoin URI or a payment request can be obtained.
A wallet client uses the Accept: HTTP header to specify whether it can accept a payment request, a URI, or both. A media type of text/uri-list specifies that the client accepts a bitcoin URI. A media type of application/bitcoin-paymentrequest specifies that the client can process a payment request. In the absence of an Accept: header, the server is expected to respond with text/html suitable for rendering in a browser. An HTML response will ensure that QR codes scanned by non Bitcoin wallet QR scanners are useful (they could render an HTML page with a payment link that when clicked would open a wallet on the device).
It is not required that the client and server support the full semantics of an HTTP Accept header. If application/bitcoin-paymentrequest is specified in the header, the server should send a payment request regardless of anything else specified in the Accept header. If text/uri-list is specified (but not application/bitcoin-paymentrequest), a valid Bitcoin URI should be returned. If neither is specified, the server can return an HTML page. When a uri-list is returned only the first item in the list is used (and expected to be a bitcoin URI), any additional URIs should be ignored.
Compatibility
Only QR scanning wallets that implement this BIP will be able to process QR codes containing payment request URLs. There are two possible workarounds for QR scanning wallets that do not implement this BIP:
1) the server gives the user an option to change the QR code to a bitcoin: URI or
2) the user scans the code with a generic QR code scanner.
In the second scenario, if the server responds with a webpage containing a link to a bitcoin URI, the user can complete the payment by clicking that link provided the user has a wallet installed on their device and it supports bitcoin URIs. If the wallet/device does not have support for bitcoin URIs, the user can fall back on address copy/paste.
This BIP should be fully compatible with BIP 70 assuming it is required that wallets implementing BIP 70 make use of the Accept: HTTP header when retrieving a payment request.
Examples
The first image below is of a bitcoin URI with an amount and payment request specified (note, this is a fairly minimal URI as it does not contain a label and the request URL is of moderate size). The second image is a QR code with only the payment request url specified.[1]
BitPay and BIP 73
BitPay also supports BIP 73, which considerably improves the usability of QR codes for Bitcoin payments. BIP 73 reduces the information required to be embedded in a payment request QR code, reducing their density. Less dense QR codes are easier to use in low light situations or from longer distances. These lower density QR codes are also normal HTTP URLs, offering an opportunity to provide additional information and instructions to users of devices that don’t already have a wallet installed. Read more about BIP 73 and BitPay here.
