BIP 0073: Difference between revisions

From Bitcoin Wiki
Jump to navigation Jump to search
Steve (talk | contribs)
Created page with "{{bip}} <pre> BIP: 73 Title: Use "Accept" header for response type negotiation with Payment Request URLs Author: Stephen Pair <stephen@bitpay.com> Status: Draft Ty..."
 
Steve (talk | contribs)
Line 12: Line 12:
==Abstract==
==Abstract==


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


==Motivation==
==Motivation==

Revision as of 13:09, 28 August 2013

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.

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

Compatibility

QR scanning wallets that do not support this BIP will not be able to process QR codes containing non bitcoin URIs. There are two possible workarounds: 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.

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.