Difference between revisions of "BIP 0073"

From Bitcoin Wiki
Jump to: navigation, search
(Specification)
(Update BIP text with latest version from https://github.com/bitcoin/bips/blob/b5723035e23896d0/bip-0073.mediawiki)
 
(4 intermediate revisions by 3 users not shown)
Line 1: Line 1:
 
{{bip}}
 
{{bip}}
 +
{{BipMoved|bip-0073.mediawiki}}
  
 
<pre>
 
<pre>
 
   BIP: 73
 
   BIP: 73
   Title: Use "Accept" header for response type negotiation with Payment Request URLs  
+
  Layer: Applications
 +
   Title: Use "Accept" header for response type negotiation with Payment Request URLs
 
   Author: Stephen Pair <stephen@bitpay.com>
 
   Author: Stephen Pair <stephen@bitpay.com>
   Status: Draft
+
  Comments-Summary: No comments yet.
 +
  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0073
 +
   Status: Final
 
   Type: Standards Track
 
   Type: Standards Track
   Created: 27-08-2013
+
   Created: 2013-08-27
 
</pre>
 
</pre>
  
 
==Abstract==
 
==Abstract==
  
This BIP describes an enhancement to the payment protocol ([[BIP 0070|BIP 70]])
+
This BIP describes an enhancement to the payment protocol ([[bip-0070.mediawiki|BIP 70]])
 
that addresses the need for short URLs when scanning from QR codes.  It
 
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  
+
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  
+
way that allows the client and server to negotiate the content of the
 
response using the HTTP Accept: header field.  Specifically, the client
 
response using the HTTP Accept: header field.  Specifically, the client
 
can indicate to the server whether it prefers to receive a bitcoin URI or
 
can indicate to the server whether it prefers to receive a bitcoin URI or
 
a payment request.
 
a payment request.
  
Implementation of this BIP does not require full payment request ([[BIP 0070|BIP 70]]) support.
+
Implementation of this BIP does not require full payment request ([[bip-0070.mediawiki|BIP 70]]) support.
  
 
==Motivation==
 
==Motivation==
Line 30: Line 34:
 
in a more frustrating user experience.  The goal is to create a standard that
 
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
 
would allow QR scanning wallets to use less dense QR codes.  It also makes
general purpose QR code scanners more usable with bitcoin accepting  
+
general purpose QR code scanners more usable with bitcoin accepting
 
websites.
 
websites.
  
Line 38: Line 42:
 
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
 
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
 
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  
+
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  
+
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
 
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
 
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).
 
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
 
HTTP Accept header.  If application/bitcoin-paymentrequest is specified in the
 
header, the server should send a payment request regardless of anything else
 
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  
+
specified in the Accept header.  If text/uri-list is specified (but not
application/bitcoin-paymentrequest), a valid Bitcoin URI should be returned.  If  
+
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
 
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
 
only the first item in the list is used (and expected to be a bitcoin URI), any additional
Line 58: Line 62:
 
==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 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  
+
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  
+
option to change the QR code to a bitcoin: URI or 2) the user scans the code with
 
a generic QR code scanner.
 
a generic QR code scanner.
  
In the second scenario, if the server responds with a webpage containing a link  
+
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
 
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  
+
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
 
wallet/device does not have support for bitcoin URIs, the user can fall back on
 
address copy/paste.
 
address copy/paste.
Line 75: Line 79:
  
 
==Examples==
 
==Examples==
The first image below is of a bitcoin URI with an amount and payment request  
+
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  
+
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
 
label and the request URL is of moderate size).  The second image is a QR
 
code with only the payment request url specified.
 
code with only the payment request url specified.
  
[[File:BIP_0073a.png]]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[[File:BIP_0073b.png]]
+
<img src=bip-0073/a.png></img><img src=bip-0073/b.png></img>
[[Category:BIP]]
 

Latest revision as of 17:59, 24 September 2019

This page describes a BIP (Bitcoin Improvement Proposal).
Please see BIP 2 for more information about BIPs and creating them. Please do not just create a wiki page.

Please do not modify this page. This is a mirror of the BIP from the source Git repository here.

  BIP: 73
  Layer: Applications
  Title: Use "Accept" header for response type negotiation with Payment Request URLs
  Author: Stephen Pair <stephen@bitpay.com>
  Comments-Summary: No comments yet.
  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0073
  Status: Final
  Type: Standards Track
  Created: 2013-08-27

Abstract

This BIP describes an enhancement to the payment protocol (BIP 70) 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 70) 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.

<img src=bip-0073/a.png></img><img src=bip-0073/b.png></img>