Published on: 2014-07-30T11:34:59+00:00
During a conversation between Mark van Cuijk and Mike Hearn, they discussed the implementation of a new BIP for formalizing the extensions process. Mike expressed frustration with payment processors not using useful memo fields and hopes that once wallets start displaying memos in their transactions list, this will change. Mark offered to write the proposal for the new BIP but was unsure whether it should be a standalone BIP or part of BIP70. They also discussed how the extensions process should describe the proposal's process.On July 28, 2014, Mike Hearn expressed his priority with BIP70 to formalize the extensions process. He planned to write a proposal and hoped to get BitPay/Coinbase to put useful text in the memo field instead of random numbers. Although he was unsure about the process to follow, he could probably pick up writing the proposal. He questioned if the proposal should be formatted as a new BIP or part of BIP.70 and how the extensions process would describe it.In a discussion thread on the Bitcoin development mailing list, participants debated the best way for a payment processor (PP) to issue non-SSL certificates for merchant identification. One participant referred to another's idea, which suggested that a merchant should issue an extension certificate that allows the PP to act on their behalf. However, the original poster clarified that their proposal required two signatures over the payment request data, one with the X.509 certificate key for backward compatibility and one with the ECDSA public key. Another participant suggested that this was too complex and argued in favor of a simpler proposal that only required one signature using the former key. Overall, the discussion focused on balancing security concerns with backward compatibility.In an email exchange between Mark van Cuijk and Mike, they discussed the idea of a payment processor issuing non-SSL certificates for merchant identification. Mark suggests the opposite, where a merchant issues an extension cert to allow the payment processor to act on their behalf. They also discussed the choice of how to authenticate the payment processor, with Mark preferring his proposal due to backward compatibility concerns, while Mike's extended certificate system was deemed cleaner but required two separate signatures for old and new clients.In another email exchange, two individuals discuss the idea of implementing a system for verifying merchant identity in online transactions. They consider options including X.509 CAs, Payment Processors (PP), and PGP/Bitcoin-based systems for verifying the identity of the merchant. They also discuss different methods of identification and authentication, such as X.509 certificates, merchant identifiers, Twitter handles, and extended certificates. One individual suggests sticking with the X.509 system for identification of the merchant but likes the idea of a PP issuing non-SSL certificates for merchant identification. The other individual agrees that their proposals do not differ substantially and thinks that the extended certificate system is cleaner but prefers Mark's proposal because of backward compatibility concerns. They conclude by stating that someone needs to make the proposed system happen.During a user experience test, it was discovered that identifying payment processors instead of merchants could create problems. Mark proposes extending the PaymentRequest message with additional fields to authenticate the identity of the merchant, rather than the payment processor. This solution allows existing wallets to continue showing the identity of the payment processor, while wallets that understand the extension can display the identity information of the merchant. Payment processors supporting the extension may offer it as an optional service, where clients must obtain their own certificate from a CA and sign a mandate. The process may need to be repeated when either the merchant's or payment processor's certificates expire.
Updated on: 2023-08-01T10:06:41.464636+00:00