public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
* [Bitcoin-development] "On behalf of" BIP 70 extension proposal
@ 2014-07-27  6:55 Mark van Cuijk
  2014-07-27 19:31 ` Mike Hearn
  0 siblings, 1 reply; 8+ messages in thread
From: Mark van Cuijk @ 2014-07-27  6:55 UTC (permalink / raw)
  To: bitcoin-development

When I asked a non-tech friend to do a BIP 70 payment using our wallet as a first round of user experience testing, he made the remark the he wanted to do a payment to a merchant, but instead our software shows a payment to “BitPay, Inc.”

This can be problematic for a couple of reasons:
- As a user you don’t need to know and trust individual payment processors. As long as you can identify and authenticate the merchant, you should be able to rely on the merchant’s choice for a payment processor.
- An attacker can become a client of a payment processor, use it to create a PaymentRequest message and send this message to a victim as part of a MITM attack; the victim now thinks he is paying a merchant through the payment processor, but is actually paying the attacker through the payment processor.

I have a proposal that can be transformed into a BIP or into an extension of BIP 70 and adds a way to include merchant identity in the PaymentRequest message and I’d like to see a discussion on this topic.

At this moment, the PaymentRequest message contains a pki_data field with a certificate chain to authenticate the entity that generates the message, which in the above case is the payment processor.

I’m proposing to extends the PaymentRequest message with three more fields:
- payee_pki_type
- payee_pki_data
- payee_mandate

The payee_pki_type and payee_pki_data fields can be of the same format as the pki_type and pki_data fields, except that they authenticate the identity of the merchant, instead of the identity of the payment processor. The payee_mandate fields contains a claim by the merchant, signed using his own private key, that he grants the payment processor the right to collect the payment on his behalf.

The solution is backwards compatible, since existing wallets can ignore these fields. They will not show the identity of the merchant, but keep showing the identity of the payment processor, they are still able to verify the signature in the PaymentRequest message and therefore can complete the payment process.

A wallet that understands this extension, needs to check the validity of both certificate chains when present and also the validity of the mandate. If all is fine, it can now show the identity information from the merchant certificate instead of (or besides) the identity of the payment processor and allow an end user to correctly identify the merchant.

A payment processor supporting this extension may offer it as an optional service to clients. A client that wishes to use this extension needs to obtain his own certificate from a CA and use it to sign a mandate. One potential obstacle is that this process probably needs to be repeated both when the certificate of the merchant or the certificate of the payment processor expires, but we may be able to address that when defining the format of the mandate.

/Mark


^ permalink raw reply	[flat|nested] 8+ messages in thread
end of thread, other threads:[~2014-07-30 11:35 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-07-27  6:55 [Bitcoin-development] "On behalf of" BIP 70 extension proposal Mark van Cuijk
2014-07-27 19:31 ` Mike Hearn
2014-07-28  9:01   ` Mark van Cuijk
2014-07-28 12:46     ` Mike Hearn
2014-07-28 13:06       ` Mark van Cuijk
2014-07-28 13:32         ` Mike Hearn
2014-07-30  7:54           ` Mark van Cuijk
2014-07-30 11:34             ` Mike Hearn

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox