- Update BIP75 Motivation and use cases to provide more color around reasoning and use of BIP75
NOTE: The BIP75 language no longer contains a description of the KYC compliance use case, as it is a single, very specific use-case that does not have any bearing on the technical specifications herein. BIP75 extends the original BIP70 Payment Protocol to become a two-way, encrypted messaging process, which can be used for a variety of reasons one of which is regulatory compliance.
# Please enter a commit message to explain why this merge is necessary,
# especially if it merges an updated upstream into a topic branch.
#
# Lines starting with '#' will be ignored, and an empty message aborts
# the commit.
# Please enter a commit message to explain why this merge is necessary,
# especially if it merges an updated upstream into a topic branch.
#
# Lines starting with '#' will be ignored, and an empty message aborts
# the commit.
- Remove status_code and status_message from individual Payment Protocol messages
- Remove EncryptedInvoiceRequest, EncryptedPaymentRequest, EncryptedPayment and EncryptedPaymentACK messages from protobuf definition file
- Add ProtocolMessageType enum and ProtocolMessageType and EncryptedProtocolMesssage messages to bip-0075/paymentrequest.proto definition file
- Update BIP75 text to remove old individual message encryption paths and include new encapsulating messages for self-contained PaymentProtocol communication (including errors) over various transport layers
- Add initial list of status codes
- Update BIP75 to use AES-256-GCM and remove message hash as GCM mode provides authenticated encryption
- Update ECDH calculation to use SHA256 hash of ECDH's X point instead of the raw X point itself
- Add Updated Messages section to describe the status_code and status_message
- Separated Message and Communication Errors into Payment Protocol Errors and Communication Errors
- Add first draft Payment Protocol error codes
- Update InvoiceRequest Message Creation description amount example to return Payment Protocol error in the case of an issue with the amount.
- Add nonce to EncryptedPaymentRequest, EncryptedPayment and EncryptedPaymentACK
- Update ECDH instruction to allow for the current message instead of an InvoiceRequest to contain the nonce
- Updated paymentrequest.proto with BIP definition changes
- Add ephemeral_public_key and requires_payment_message fields to EncryptedPaymentRequest + updated descriptions
- Update EncryptedPayment and EncryptedPaymentACK message descriptions to use ECDH-derived key for signature instead of each side's public key
- Slim down message content-types
- Add EncryptedPayment and EncryptedPaymentACK creation detail steps
- Add updated paymentrequest.proto to bip-ir/ directory
- Add additional flow diagrams for various mobile-to-mobile / Store & Forward scenarios
- Update InvoiceRequest notification_url definition to use SHOULD instead of MAY
- Capitalize MUST, SHOULD, etc.
- Update InvoiceRequest Message Creation steps to specifically define behavior for empty amount or amount out of bounds
- Add implementation section with references to Addressimo reference Store & Forward server and a client implementation in functest_ir.py
- Add flow diagrams for BIP70 extension and moble-to-mobile example with store and forward service
- Update InvoiceRequest to include nonce
- Remove ephemeral_public_key from ReturnPaymentRequest
- Update message validation and nonce usage in processes
- Make Abstract more readable
- Update Sender definition and acronym descriptions
- Added comments to ReturnPaymentRequest definition
- Bold ECDH and AES Setup notes and added "(see below)" for reference
- Removed Requestor/Responder definitions
- Seperated ECDH secret point generation and AES-256 (CBC Mode) setup from individual steps (listed twice) and created it's own section
- Added InvoiceRequest Validation section
Matt David