bitcoin-bips/bip-invoicerequest-extension.mediawiki

<pre>
  BIP:     XXX
  Title:   Out of Band Address Exchange using Encrypted PaymentRequests
  Authors: Justin Newton <justin@netki.com>
           Matt David <mgd@mgddev.com>
           Aaron Voisine <voisine@gmail.com>
           James MacWhyte <macwhyte@gmail.com>
  Status:  Draft
  Type:    Informational
  Created: 2015-11-20
</pre>

==Abstract==

This BIP is an extension to BIP 70 that provides two enhancements to the existing Payment Protocol.

# It allows the requestor (Sender) of a Payment Request to voluntarily sign the original request and provide a certificate to allow the payee to know the identity of who they are transacting with. 

# It encrypts the Payment Request that is returned, before handing it off to the SSL/TLS layer to prevent man in the middle viewing of the Payment Request details.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 
"OPTIONAL" in this document are to be interpreted as described in RFC 2119.

==Definitions==
{| class="wikitable"
| Sender    || Entity wishing to transfer value that they control
|-
| Receiver  || Entity receiving a value transfer
|}

==Motivation==

The motivation for defining this extension to the BIP70 Payment Protocol is to allow 2 parties to exchange payment information in a permissioned and encrypted way such that wallet address communication can become a more automated process. Additionally, this extension allows for the requestor of a PaymentRequest to supply a certificate and signature in order to facilitate identification for address release. This also allows for automated creation of off blockchain transaction logs that are human readable, containing who you transacted with, in addition to the information that it contains today.

The motivation for this extension to BIP70 is threefold:

# Ensure that the payment details can only be seen by the participants in the transaction, and not by any third party.  

# Enhance the Payment Protocol to allow for store and forward servers in order to allow, for example, mobile wallets to sign and serve Payment Requests.

# Allow a sender of funds the option of sharing their identity with the receiver.  This information could then be used to:

#* Make bitcoin logs more human readable 
#* Give the user the ability to decide who to release payment details to 
#* Allow an entity such as a political campaign to ensure donors match regulatory and legal requirements 
#* Allow for an open standards based way to meet regulatory requirements
#* Automate the active exchange of payment addresses, so static addresses and BIP32 X-Pubs can be avoided to maintain privacy and convenience

In short we wanted to make bitcoin more human, while at the same time improving transaction privacy.

==Example Use Cases==

1. Address Book

A Bitcoin wallet developer would like to offer the ability to store an "address book" of payees, so users could 
send multiple payments to known entities without having to request an address every time. Static addresses compromise 
privacy, and address reuse is considered a security risk. BIP32 X-Pubs allow the generation of unique addresses, but 
watching an X-Pub chain for each person you wish to receive funds from is too resource-intensive for mobile applications, 
and there is always a risk of unknowingly sending funds to an X-Pub address after the owner has lost access to the 
corresponding private key.

With this BIP, Bitcoin wallets could maintain an "address book" that only needs to store each payee's public key. Adding 
an entry to one's address book could be done by using a Wallet Name, scanning a QR code, sending a URI through a text message or e-mail, or 
searching a public repository. When the user wishes to make a payment, their wallet would do all the work in the background 
to communicate with the payee's wallet to receive a unique payment address. If the payee's wallet has been lost, replaced, 
or destroyed, no communication will be possible, and the sending of funds to a "dead" address is prevented.

2. Individual Permissioned Address Release

A Bitcoin wallet developer would like to allow users to view a potential sending party's identifying information before deciding whether or not to share payment information with them. Currently, BIP70 specifies that the Merchant Server respond to a "pay now" style request with a PaymentRequest, releasing address and X.509 certificate identity information of the potential receiving party.

With this BIP, Bitcoin wallets could prompt a wallet user to release payment information while displaying identity 
information about the potential sending party via an included certificate. This gives the receiving party more control over who receives their payment and identity information, and could be helpful for businesses that need to follow KYC policies or wallets that want to focus on privacy.

3. Using Store & Forward Servers

A Bitcoin wallet developer would like to use a public Store & Forward service for an asynchronous address 
exchange. This is a common case for mobile and offline wallets.

With this BIP, returned payment information is encrypted with an ECDH-computed shared key before sending to a Store & Forward 
service. In this case, a successful attack against a Store & Forward service would not be able to read or modify wallet address 
or payment information, only delete encrypted messages.

==New Messages==
Updated [/bip-ir/paymentrequest.proto paymentrequest.proto] contains the existing PaymentRequest Protocol Buffer messages as well as
the messages newly defined in this BIP. Note: Public keys from both parties must be known to each other in order to facilitate encrypted communication. We assume Store & Forward servers will provide their own method for communicating one or both parties' public keys, so that exchange is outside the scope of this BIP. The protocol does, however, include the option of including the public keys during communication if they are not already known.

===InvoiceRequest===
The InvoiceRequest message allows a Sender to send information to the Receiver such that they can create and return a PaymentRequest.

<pre>
message InvoiceRequest {
        required bytes  sender_public_key = 1;
        required uint64 nonce = 2;
        optional uint64 amount = 3 [default = 0];
        optional string pki_type = 4 [default = "none"];
        optional bytes  pki_data = 5;
        optional string memo = 6;
        optional string notification_url = 7;
        optional bytes  signature = 8;
}
</pre>

{| class="wikitable"
! Field Name !! Description
|-
| sender_public_key     || Sender's EC public key
|-
| nonce                 || Microseconds since epoch
|-
| amount                || amount is integer-number-of-satoshis (default: 0)
|-
| pki_type              || none / x509+sha256 (default: "none")
|-
| pki_data              || Depends on pki_type
|-
| memo                  || Human-readable description of invoice request for the receiver
|-
| notification_url      || Secure (usually HTTPS) location where an EncryptedPaymentRequest (see below) SHOULD be sent when ready
|-
| signature             || PKI-dependent signature
|}


===EncryptedInvoiceRequest===
The EncryptedInvoiceRequest message allows a Sender to send an encrypted InvoiceRequest to the Receiver such that the details of the InvoiceRequest are kept secret.
<pre>
message EncryptedInvoiceRequest {
    required bytes  encrypted_invoice_request = 1;
    required bytes  invoice_request_hash = 2;
    required bytes  sender_public_key = 3;
    optional bytes  receiver_public_key = 4;
    required uint64 nonce = 5;
    optional bytes  identifier = 6;
    
}
</pre>

{| class="wikitable"
! Field Name</b> !! Description
|-
| encrypted_invoice_request || AES-256-CBC encrypted, serialized InvoiceRequest
|-
| invoice_request_hash      || SHA256 Hash of non-encrypted, serialized InvoiceRequest.  MUST be used for verification to prevent oracle attacks.
|-
| sender_public_key         || Sender's EC public key
|-
| receiver_public_key       || Receiver's EC public key, can be omitted if this message is sent directly to the recipient, or is sent to a Store & Forward server that already understands who the recipient should be (if specified by URI endpoint, for example)
|-
| nonce                     || The nonce in use for the CBC encryption
|-
| identifier                || A unique key to identify this entire exchange on the server. By default, invoice_request_hash SHOULD be used.
|}

===EncryptedPaymentRequest===

The EncryptedPaymentRequest message is an encapsulating message that allows the transmission of an encrypted, serialized PaymentRequest.

<pre>
message EncryptedPaymentRequest {
        required bytes  encrypted_payment_request = 1;
        required bytes  payment_request_hash = 2;
        optional bytes  receiver_public_key = 3;
        optional bytes  sender_public_key = 4;
        optional uint64 nonce = 5;
        optional bool   requires_payment_message = 6;
        optional bytes  signature = 7;
        optional bytes  identifier = 6;
}
</pre>
{| class="wikitable"
! Field Name</b> !! Description
|-
| encrypted_payment_request || AES-256-CBC encrypted, serialized BIP70 PaymentRequest
|-
| payment_request_hash      || SHA256 Hash of non-encrypted, serialized PaymentRequest.  MUST be used for verification to prevent oracle attacks.
|-
| receiver_public_key       || Receiver's EC public key, only necessary if not already shared or known (for example, if this message is not in response to an InvoiceRequest)
|-
| sender_public_key         || Sender's EC public key, can be omitted if this message is sent directly to the recipient, or is sent to a Store & Forward server that already understands who the recipient should be (if specified by URI endpoint, for example)
|-
| nonce                     || The nonce in use for the CBC encryption, only necessary if not already shared (for example, if this message is not in response to an InvoiceRequest)
|-
| requires_payment_message  || Internal PaymentRequest requires follow-up Payment message
|-
| signature                 || A signature of this message using Receiver's EC key, serialized with a value of "" for signature. Only necessary if required by the server to authenticate a reply to an InvoiceRequest.
|-
| identifier                || If the PaymentRequest is in response to an InvoiceRequest, use the identifier specified with the InvoiceRequest, if any. Otherwise, use payment_request_hash or other unique value.
|}

===EncryptedPayment===

The EncryptedPayment message allows a BIP70 Payment message to be transmitted through a third party without revealing the details of the transaction. This message allows Store & Forward servers or other third parties to match and authenticate PaymentRequest and Payment messages without revealing the details of the transaction, thereby protecting privacy.

<pre>
message EncryptedPayment {
        required bytes encrypted_payment = 1;
        required bytes payment_hash = 2;
        required bytes signature = 3;
        optional bytes identifier = 4;
}
</pre>
{| class="wikitable"
! Field Name</b> !! Description
|-
| encrypted_payment         || AES-256-CBC encrypted, serialized BIP70 Payment message
|-
| payment_hash              || SHA256 Hash of original non-encrypted, serialized Payment message. MUST be used for verification to prevent oracle attacks.
|-
| signature                 || A signature of this message using Sender's EC key, serialized with a value of "" for signature.
|-
| identifier                || Use the identifier specified with the EncryptedPaymentRequest, if any.
|}

===EncryptedPaymentACK===

An encrypted version of the BIP70 PaymentAck.

<pre>
message EncryptedPaymentACK {
        required bytes encrypted_payment_ack = 1;
        required bytes payment_ack_hash = 2;
        required bytes signature = 3;
        optional bytes identifier = 4;
}
</pre>
{| class="wikitable"
! Field Name</b> !! Description
|-
| encrypted_payment_ack         || AES-256-CBC encrypted, serialized BIP70 PaymentACK message
|-
| payment_ack_hash              || SHA256 Hash of original non-encrypted, serialized Payment message. MUST be used for verification to prevent oracle attacks.
|-
| signature                     || A signature of this message using Receiver's EC key, serialized with a value of "" for signature.
|-
| identifier                    || Use the identifier specified with the EncryptedPayment, if any.
|}

==InvoiceRequest / PaymentRequest Process==
The process overview for using InvoiceRequests and receiving encrypted PaymentRequests is defined below in two sections. 
Optionally, the Sender MAY choose to encrypt the InvoiceRequest message and therefore MUST follow the <b>Encrypted InvoiceRequest Overview</b> process.

===Non-Encrypted InvoiceRequest Overview===
# Sender creates InvoiceRequest
# Sender transmits InvoiceRequest to Receiver
# Receiver validates InvoiceRequest
# Receiver creates PaymentRequest
# Receiver encrypts the PaymentRequest
# Receiver creates EncryptedPaymentRequest (containing an encrypted PaymentRequest)
# Receiver transmits EncryptedPaymentRequest to Sender
# Sender validates EncryptedPaymentRequest
# Sender decrypts and validates encrypted PaymentRequest
# The PaymentRequest is processed according to BIP70, including optional Payment and PaymentACK messages


<img src="bip-ir/invoice-request-process.png"></img>

===Encrypted InvoiceRequest Overview===
# Sender retrieves Receiver InvoiceRequest Public Key
# Sender creates InvoiceRequest
# Sender encrypts the InvoiceRequest
# Sender creates EncryptedInvoiceRequest (containing an encrypted InvoiceRequest)
# Sender transmits EncryptedInvoiceRequest to Receiver
# Receiver decrypts and validates EncryptedInvoiceRequest
# Receiver validates InvoiceRequest
# Receiver creates PaymentRequest
# Receiver encrypts the PaymentRequest
# Receiver creates EncryptedPaymentRequest (containing an encrypted PaymentRequest)
# Receiver transmits EncryptedPaymentRequest to Sender
# Sender validates EncryptedPaymentRequest
# Sender decrypts and validates encrypted PaymentRequest
# The PaymentRequest is processed according to BIP70, including optional EncryptedPayment and EncryptedPaymentACK messages

<b>NOTE:</b> See section <b>Initial Public Key Retrieval for InvoiceRequest Encryption</b> below for possible options to retrieve Receiver InvoiceRequest public keys.

<img src="bip-ir/encrypted-invoice-request-process.png"></img>

==Message Interaction Details==

===New Message Content Types===
Messages MUST be transmitted via TLS-protected HTTP using the appropriate Content-Type header as defined per message type here:
{| class="wikitable"
! Message Type !! Content Type
|-
| InvoiceRequest                    || application/bitcoin-invoicerequest
|-
| EncryptedInvoiceRequest           || application/bitcoin-encrypted-invoicerequest
|-
| EncryptedPaymentRequest           || application/bitcoin-encrypted-paymentrequest
|-
| EncryptedPayment                  || application/bitcoin-encrypted-payment
|-
| EncryptedPaymentACK               || application/bitcoin-encrypted-paymentack
|}

===Message or Communication Errors===
An invalid or unparsable message or communications error MUST be communicated to the party that initiated the communication. This
SHOULD be done through standard HTTP Status Code messaging ([https://tools.ietf.org/html/rfc7231 RFC 7231 Section 6]). If the provided hash of each message does not match the contents of the message once decrypted, a general error should be returned to prevent oracle attacks.

==Process Step Details==

For the following we assume the Sender already knows the Receiver's public key, and the exchange starts with an EncryptedInvoiceRequest.

===InvoiceRequest Message Creation===
* Create an InvoiceRequest message
* sender_public_key MUST be set to the public key of an EC keypair
* nonce MUST be set to a non-repeating number. The current epoch time in microseconds SHOULD be used, unless the creating device doesn't have access to a RTC (in the case of a smart card, for example)
* Amount is optional. If the amount is not specified by the InvoiceRequest, the Receiver MAY specify the amount in the returned PaymentRequest. If an amount is specified by the InvoiceRequest and a PaymentRequest cannot be generated for that amount, the InvoiceRequest SHOULD be rejected with HTTP status code 406.
* Memo is optional. This MAY be set to a human readable description of the InvoiceRequest
* Set notification_url to URL that the Receiver will submit completed EncryptedPaymentRequest to
* If NOT including certificate, set pki_type to "none"
* If including certificate:
** Set pki_type to "x509+sha256"
** Set pki_data as it would be set in BIP-0070 (see [https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki#Certificates Certificates]) section)
** Sign InvoiceRequest with signature = "" using the X509 Certificate's private key
** Set signature value to the computed signature

===EncryptedInvoiceRequest Message Creation===
* Create an EncryptedInvoiceRequest
* Retrieve endpoint public key to use in <b>ECDH Point Generation</b> as specified in <b>Initial Public Key Retrieval for InvoiceRequest Encryption</b> (see below)
* sender_public_key MUST be set to the public key of an EC keypair
* invoice_request_hash MUST be set to the SHA256 hash of the serialized InvoiceRequest (without encryption)
* Encrypt the serialized InvoiceRequest using AES-256-CBC setup as described in <b>ECDH Point Generation and AES-256 (CBC Mode) Setup (see below)</b>
* encrypted_invoice_Request MUST be set to the encrypted values of the InvoiceRequest
* Set identifier to invoice_request_hash

===InvoiceRequest Validation===
* Validate sender_public_key is a valid EC public key
* The nonce MUST not be repeated. The service receiving the InvoiceRequest MAY use whatever method to make sure that the nonce is never repeated. 
* Validate notification_url if set, contains characters deemed valid for a URL (avoiding XSS related characters, etc).
* If pki_type is None, InvoiceRequest is VALID
* If pki_type is x509+sha256 and signature is valid for the serialized InvoiceRequest where signature is set to "", InvoiceRequest is VALID

===EncryptedPaymentRequest Message Creation and PaymentRequest Encryption===
* Encrypt the serialized PaymentRequest using AES-256-CBC setup as described in <b>ECDH Point Generation and AES-256 (CBC Mode) Setup (see below)</b>
* Create EncryptedPaymentRequest message
* Set encrypted_payment_request to be the encrypted value of the PaymentRequest
* Set payment_request_hash to generated SHA256 hash of the serialized PaymentRequest (without encryption)
* Set identifier to the value received in EncryptedInvoiceRequest
* Set signature to ""
* Sign the serialized EncryptedPayment message with the Receiver's EC public key

===EncryptedPaymentRequest Validation and Decryption===
* Decrypt the serialized PaymentRequest using AES-256-CBC setup as described in <b>ECDH Point Generation and AES-256 (CBC Mode) Setup (see below)</b>
* Validate payment_request_hash matches SHA256 of the decrypted, serialized PaymentRequest
* Deserialize the serialized PaymentRequest

===ECDH Point Generation and AES-256 (CBC Mode) Setup===
* Generate the '''secret point''' using [https://en.wikipedia.org/wiki/Elliptic_curve_Diffie–Hellman ECDH] using the local entity's private key and the remote entity's public key as inputs.
* Initialize [http://csrc.nist.gov/publications/nistpubs/800-90A/SP800-90A.pdf HMAC_DRBG] 
** Use '''secret point's''' X value for Entropy
** Use the given InvoiceRequest's nonce field for Nonce
* Initialize AES-256 in CBC Mode
** Use HMAC_DRBG.GENERATE(32) as the Encryption Key (256 bits)
** Use HMAC_DRBG.GENERATE(16) as the Initialization Vector (IV) (128 bits)

===Initial Public Key Retrieval for InvoiceRequest Encryption===
Initial public key retrieval for InvoiceRequest encryption can be done in a number of ways including, but not limited to, the following:
* Wallet Name public key asset type resolution - DNSSEC-validated name resolution returns Base64 encoded DER-formatted EC public key via TXT Record [https://www.ietf.org/rfc/rfc5480.txt RFC 5480]
* Key Server lookup - Key Server lookup (similar to PGP's pgp.mit.edu) based on key server identifier (i.e., e-mail address) returns Base64 encoded DER-formatted EC public key [https://www.ietf.org/rfc/rfc5480.txt RFC 5480]
* QR Code - Use of QR-code to encode DER-formatted EC public key [https://www.ietf.org/rfc/rfc5480.txt RFC 5480]

==EncryptedPayment and EncryptedPaymentACK Details==

===EncryptedPayment Message Creation===
* Encrypt the serialized Payment using AES-256-CBC using secret key calculated in the <b>EncryptedPaymentRequest Message Creation and PaymentRequest Encryption</b> step (see above)
* Create EncryptedPayment message
* Set encrypted_payment to be the encrypted value of the Payment
* Set identifier to the value received in EncryptedPaymentRequest
* Set payment_hash to generated SHA256 hash of the serialized Payment (without encryption)
* Set signature to ""
* Sign the serialized EncryptedPayment message with the Sender's EC public key
* Set signature to the result of the signature operation above

===EncryptedPaymentACK Message Creation===
* Encrypt the serialized PaymentACK using AES-256-CBC using secret key calculated in the <b>EncryptedPaymentRequest Message Creation and PaymentRequest Encryption</b> step (see above)
* Create EncryptedPaymentACK message
* Set encrypted_payment_ack to be the encrypted value of the PaymentACK
* Set payment_ack_hash to generated SHA256 hash of the serialized PaymentACK (without encryption)
* Set signature to ""
* Sign the serialized EncryptedPaymentACK message with the Receiver's EC public key
* Set signature to the result of the signature operation above


**SIGNATURE NOTE:** EncryptedPaymentRequest, EncryptedPayment, and EncryptedPaymentACK messages are signed with the public keys of the party transmitting the message. This allows a Store & Forward server or other transmission system to prevent spam or other abuses. For those who are privacy concious and don't want the server to track the interactions between two public keys, the Sender can generate a new public key for each interaction to keep their identity anonymous.

==Payment / PaymentACK Messages with a Store & Foward Server==
When a Store & Forward server is in use during the Payment Protocol exchange, an EncryptedPayment message generated as the result of a EncryptedPaymentRequest with the requires_payment_message flag set to true MUST be accepted by a Store & Forward server. The accepted Payment message is NOT validated as the Store & Forward server does not have access to encrypted data.

Store & Forward servers MAY accept and/or overwrite EncryptedPayment messages until an EncryptedPaymentACK message with matching identifier and valid Receiver signature is received, after which the server MAY reject all further EncryptedPayment messages matching that identifier. This feature SHOULD be used for updating Payment metadata or replacing invalid transactions with valid ones. Clients SHOULD keep in mind Receivers can broadcast a transaction without returning an ACK. If a payment message needs to be updated, it SHOULD include at least one input referenced in the original transaction to prevent the Receiver from broadcasting both transactions and getting paid twice.

==Implementation==
A reference implementation for a Store & Forward server supporting this proposal can be found here: 

[https://github.com/netkicorp/addressimo Addressimo]

A reference client implementation can be found in the InvoiceRequest functional testing for Addressimo here: 

[https://github.com/netkicorp/addressimo/blob/master/functest/functest_ir.py InvoiceRequest Client Reference Implementation]

==BIP70 Extension==
The following flowchart is borrowed from BIP70 and expanded upon in order to visually describe how this BIP is an extension to BIP70.

<img src="bip-ir/bip70-extension.png"></img>

==Mobile to Mobile Examples==

===EncryptedPayment Required===
The following diagram shows a sample flow in which one mobile client is sending value to a second mobile client with the use
of an InvoiceRequest, a Store & Forward server, an EncryptedPaymentRequest (with require_payment_message = true), an 
EncryptedPayment and an EncryptedPaymentACK. In this case, the Receiver submits the transaction to the bitcoin network.

<img src="bip-ir/mobile-sf-ir-with-payment.png"></img>

===EncryptedPayment NOT Required===
The following diagram shows a sample flow in which one mobile client is sending value to a second mobile client with the use
of an InvoiceRequest, a Store & Forward server, and an EncryptedPaymentRequest (with require_payment_message = false). 
In this case, the Sender submits the transaction to the bitcoin network.

<img src="bip-ir/mobile-sf-ir-without-payment.png"></img>

===Using EncryptedInvoiceRequest Message===
The following diagram shows a sample flow in which one mobile client is sending value to a second mobile client with the use
of an EncryptedInvoiceRequest, a Store & Forward server, and an EncryptedPaymentRequest (with require_payment_message = false). 
In this case, the Sender submits the transaction to the bitcoin network.

<img src="bip-ir/mobile-sf-encrypted-ir-without-payment.png"></img>

==References==

* [[bip-0070.mediawiki|BIP70 - Payment Protocol]]
* [https://en.wikipedia.org/wiki/Elliptic_curve_Diffie–Hellman ECDH]
* [http://csrc.nist.gov/publications/nistpubs/800-90A/SP800-90A.pdf HMAC_DRBG]
* [https://tools.ietf.org/html/rfc6979 RFC6979]
* [https://en.bitcoin.it/wiki/Address_reuse Address Reuse]