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