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

==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 any third party.  

# Enhance the Paument 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==

# Address Book

Let's say 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 the 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.

# Individual Permissioned Address Release

Let's say a Bitcoin wallet developer would like to offer the ability for a user to individually release address information 
to a new potential sending party only if they can confirm the identity of the potential sending party. 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 allows the potential receiving party to 
make a more informed decision regarding to whom they are releasing payment and identity information.

# Using Store & Forward Servers

Let's say 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.
[MATT PLEASE INCLUDE TEXT HERE REGARDING OTHER STORE AND FORWARD MODIFICATIONS]

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

==New Messages==

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

<pre>
message InvoiceRequest {
        required bytes  sender_public_key = 1;              // Sender's EC Public Key
        required uint64 nonce = 2;                          // Microseconds since epoch
        optional uint64 amount = 3 [default = 0];           // amount is integer-number-of-satoshis
        optional string pki_type = 4 [default = "none"];    // none / x509+sha256
        optional bytes  pki_data = 5;                       // Depends on pki_type
        optional string notification_url = 6;               // URL to notify on ReturnPaymentRequest ready
        optional bytes  signature = 7;                      // PKI-dependent signature
}
</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
|-
| notification_url      || Secure (usually HTTPS) location where a ReturnPaymentRequest (see below) SHOULD be sent when ready
|-
| signature             || PKI-dependent signature
|}

===ReturnPaymentRequest===

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

<pre>
message ReturnPaymentRequest {
        required bytes encrypted_payment_request = 1;      // Encrypted, Serialized PaymentRequest
        required bytes receiver_public_key = 2;            // Receiver's EC Public Key
        required bytes payment_request_hash = 3;           // SHA256 of Serialized PaymentRequest
}
</pre>
{| class="wikitable"
! Field Name</b> !! Description
|-
| encrypted_payment_request || AES-256-CBC Encrypted Serialized PaymentRequest
|-
| receiver_public_key       || Receiver's EC Public Key
|-
| payment_request_hash      || SHA256 Hash of Non-Encrypted, Serialized PaymentRequest
|}

==InvoiceRequest / ReturnPaymentRequest Process==

===Overview===

# Sender creates InvoiceRequest
# Sender transmits InvoiceRequest to Receiver
# Receiver validates InvoiceRequest
# Receiver creates PaymentRequest
# Receiver encrypts the PaymentRequest
# Receiver creates ReturnPaymentRequest (containing an encrypted PaymentRequest)
# Receiver transmits ReturnPaymentRequest to Sender
# Sender validates ReturnPaymentRequest
# Sender decrypts and validates encrypted PaymentRequest

This overview flow is illustrated below:

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

===Message Interaction Details===

====InvoiceRequest====
Sender MUST transmit InvoiceRequest to Receiver (or Receiver's agent) via TLS-protected HTTP. Sender transmitting InvoiceRequest 
messages MUST set appropriate Content-Type headers as specified here:
<pre>Content-Type: application/bitcoin-invoicerequest</pre>

====ReturnPaymentRequest====
Receiver MUST transmit ReturnPaymentRequest to Sender (or Sender's agent) via TLS-protected HTTP. Receiver transmitting
ReturnPaymentRequest messages MUST set appropriate Content-Type headers as specified here:
<pre>Content-Type: application/bitcoin-returnpaymentrequest</pre>

====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]).

===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.
* Set notification_url to URL that the Receiver will submit completed ReturnPaymentRequest 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

===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

===ReturnPaymentRequest 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 ReturnPaymentRequest message
* Set encrypted_payment_request to be the encrypted value of the PaymentRequest
* Set receiver_public_key to the Receiver's EC public key (of which the private key was previously used in ECDH secret point calculation)
* Set payment_request_hash to generated SHA256 hash of the serialized PaymentRequest (without encryption)

===ReturnPaymentRequest 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)

==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 Example==
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 a ReturnPaymentRequest.

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

==Reference==

* [[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]