diff --git a/bip-invoicerequest-extension.mediawiki b/bip-invoicerequest-extension.mediawiki index ff033d84..60e2d856 100644 --- a/bip-invoicerequest-extension.mediawiki +++ b/bip-invoicerequest-extension.mediawiki @@ -39,6 +39,13 @@ The motivation for this extension to BIP70 is twofold: In short we wanted to make bitcoin more human, while at the same time improving transaction privacy. +==Definitions== +{| class="wikitable" +| Sender || Entity wishing to transfer value that they control +|- +| Receiver || Entity receiving a value transfer +|} + ==Example Use Cases== 1. Address Book @@ -76,13 +83,6 @@ With this BIP, returned payment information is encrypted with an ECDH-computed s 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. -==Definitions== -{| class="wikitable" -| Sender || Entity wishing to transfer value that they control -|- -| Receiver || Entity receiving a value transfer -|} - ==New Messages== ===EncryptedInvoiceRequest=== @@ -159,15 +159,13 @@ message EncryptedPaymentRequest { | payment_request_hash || SHA256 Hash of Non-Encrypted, Serialized PaymentRequest |} -==Encrypted InvoiceRequest / PaymentRequest Process== - -===Overview=== +==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 Encrypted InvoiceRequest Overview process. +===Non-Encrypted InvoiceRequest Overview=== # Sender creates InvoiceRequest -# Sender encrypts the InvoiceRequest -# Sender creates EncryptedInvoiceRequest (containing an encrypted InvoiceRequest) -# Sender transmits EncryptedInvoiceRequest to Receiver -# Receiver decrypts and validates EncryptedPaymentRequest +# Sender transmits InvoiceRequest to Receiver # Receiver validates InvoiceRequest # Receiver creates PaymentRequest # Receiver encrypts the PaymentRequest @@ -176,26 +174,50 @@ message EncryptedPaymentRequest { # Sender validates EncryptedPaymentRequest # Sender decrypts and validates encrypted PaymentRequest -This overview flow is illustrated below: + - +===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 -===Message Interaction Details=== +NOTE: See section Initial Public Key Retrieval for InvoiceRequest Encryption below for possible options to retrieve Receiver InvoiceRequet public keys. + + + +==Message Interaction Details== ===EncryptedInvoiceRequest=== -Sender MUST transmit EncryptedInvoiceRequest to Receiver (or Receiver's agent) via TLS-protected HTTP, Sender transmitting +Sender MUST transmit EncryptedInvoiceRequest to Receiver (or Receiver's agent) via TLS-protected HTTP. Sender transmitting EncryptedInvoiceRequest message MUST set appropriate Content-Type headers as specified here:
Content-Type: application/bitcoin-encrypted-invoicerequest
-====EncryptedPaymentRequest==== +===InvoiceRequest=== +Sender MUST transmit InvoiceRequest to Receiver (or Receiver's agent) via TLS-protected HTTP. Sender transmitting +InvoiceRequest message MUST set appropriate Content-Type headers as specified here: +
Content-Type: application/bitcoin-invoicerequest
+ +===EncryptedPaymentRequest=== Receiver MUST transmit EncryptedPaymentRequest to Sender (or Sender's agent) via TLS-protected HTTP. Receiver transmitting EncryptedPaymentRequest messages MUST set appropriate Content-Type headers as specified here:
Content-Type: application/bitcoin-encrypted-paymentrequest
-====Message or Communication Errors==== +===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]). +==Process Step Details== + ===InvoiceRequest Message Creation=== * Create an InvoiceRequest message * sender_public_key MUST be set to the public key of an EC keypair diff --git a/bip-ir/encrypted-invoice-request-process.png b/bip-ir/encrypted-invoice-request-process.png new file mode 100644 index 00000000..beb5df1f Binary files /dev/null and b/bip-ir/encrypted-invoice-request-process.png differ diff --git a/bip-ir/invoice-request-process.png b/bip-ir/invoice-request-process.png new file mode 100644 index 00000000..47a4fac5 Binary files /dev/null and b/bip-ir/invoice-request-process.png differ