From: Mark van Cuijk <mark@coinqy•com>
To: Mike Hearn <mike@plan99•net>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] "On behalf of" BIP 70 extension proposal
Date: Mon, 28 Jul 2014 11:01:06 +0200 [thread overview]
Message-ID: <C9BF4A1A-5363-4725-8CFC-9EFE0C0B6B15@coinqy.com> (raw)
In-Reply-To: <CANEZrP0u-yoS4Sx2sC9uCf0xnzm-g1gYP8atUQO9-s3PW2kYKw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2423 bytes --]
Good to see that it has been discussed, but I see the idea has been postponed. I agree our proposals don’t differ substantially. Besides naming, I think the differences are the algorithms that are used for signing the extended certificate / mandate by the merchant and the way backwards compatibility is handled.
Also taking into consideration the replies on your proposal, I think the following decisions are most important to be made when we make a step back:
What party/system do we want to rely on to verify the identity of the merchant? Options I’ve seen:
- X.509 CAs
- Payment Processors (PP)
- PGP/Bitcoin-based
Which “PKI" do we want to use to identify the merchant (related to the previous question)?
- X.509 certificate
- Merchant identifier
- Twitter handle
Which “PKI” do we want to use to authenticate the PP?
- X.509 certificate
- Extended certificate
My personal opinion:
I’d prefer to stick to the X.509 system for identification of the merchant, even though the system is not perfect. In the case of a webshop transaction, a customer probably already relies on the X.509 system to authenticate the identity of the merchant during the shopping session (HTTPS) in his browser when he transmits his personal data like his address. I’d prefer not to add a competing identification system a customer also needs to rely on, unless that system brings objective improvements and can also be used in the HTTPS session.
I do like the idea coined by Mike that a PP can issue non-SSL certificates for the purpose of merchant identification, as long as a customer is free to determine whether he trusts the PP for this purpose.
Regarding the choice of how to authenticate the PP, I’m a bit undetermined. Disregarding backward compatibility, I think the extended certificate system proposed by Mike is cleaner. However, I don’t like the concept of requiring two separate signatures for old and new clients. Taking backward compatibility in mind, I tend to prefer my proposal.
/Mark
On 27 Jul 2014, at 21:31 , Mike Hearn <mike@plan99•net> wrote:
> Hi Mark,
>
> This is very similar to a proposal I made some time ago:
>
> https://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg04053.html
>
> I think the outlines of a design are clear - my proposal and yours don't I think differ substantially. Someone needs to make it happen though.
>
>
[-- Attachment #2: Type: text/html, Size: 3287 bytes --]
next prev parent reply other threads:[~2014-07-28 9:01 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-27 6:55 Mark van Cuijk
2014-07-27 19:31 ` Mike Hearn
2014-07-28 9:01 ` Mark van Cuijk [this message]
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=C9BF4A1A-5363-4725-8CFC-9EFE0C0B6B15@coinqy.com \
--to=mark@coinqy$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=mike@plan99$(echo .)net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox