highperfocused/bips
1
0
Fork 0
mirror of https://github.com/bitcoin/bips.git synced 2025-03-26 01:31:51 +01:00
Code Issues Packages Projects Releases Wiki Activity

- Fixed typos and added a bit more explanation for the Wallet Name public key retrieval example

Browse Source
This commit is contained in:
Matt David 2016-02-15 17:35:23 -08:00
parent db2bf02180
commit e0bd3b599a
1 changed files with 6 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
bip-invoicerequest-extension.mediawiki
View File

@ -133,7 +133,7 @@ message InvoiceRequest {
|-
| pki_data || Depends on pki_type
|-
| notification_url || Secure (usually HTTPS) location where a EncryptedPaymentRequest (see below) SHOULD be sent when ready
| notification_url || Secure (usually HTTPS) location where an EncryptedPaymentRequest (see below) SHOULD be sent when ready
|-
| signature || PKI-dependent signature
|}
@ -183,7 +183,7 @@ This overview flow is illustrated below:
===Message Interaction Details===
===EncryptedInvoiceRequest===
Sender MUST transmit EncryptedInvoiceRequest to Receiver (or Receiver's agent) via TLS-protected HTTP, Sending 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:
<pre>Content-Type: application/bitcoin-encrypted-invoicerequest</pre>
@ -214,7 +214,7 @@ SHOULD be done through standard HTTP Status Code messaging ([https://tools.ietf.
* 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 blow)</b>
* 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
===InvoiceRequest Validation===
@ -247,8 +247,8 @@ SHOULD be done through standard HTTP Status Code messaging ([https://tools.ietf.
===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 [https://www.ietf.org/rfc/rfc5480.txt RFC 5480]
* Key Server lookup - Key Server looked based on keyserver identifier (i.e., e-mail address) returns Base64 encoded DER-formatted EC public key [https://www.ietf.org/rfc/rfc5480.txt RFC 5480]
* 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]
==Payment Messages with a Store & Foward Server==
@ -258,7 +258,7 @@ with the following exception:
When a Store & Forward server is in use during the Payment Protocol exchange, a Payment message generated as the result of a
received EncryptedPaymentRequest MUST be accepted by a Store & Forward server if the Payment message is appropriately correlated
to an InvoiceRequest/PaymentRequest exchange. This correlation SHOULD BE done in order to decrease spam requests. The accepted
Payment message IS NOT validated as the Store & Forward server does not have access to the original Payment Request.
Payment message IS NOT validated as the Store & Forward server does not have access to the original PaymentRequest.
==Implementation==
A reference implementation for a Store & Forward server supporting this proposal can be found here: