- If a more trusted cert is an EV end cert, and a less trusted is a DV end cert (not chained off the EV) then it's easy for the wallet to distinguish between the two, and they are both valid certs. EV signs pubKey offline, DV used hot on the web server.

 - If the more trusted cert is an EV or DV end cert, and the less trusted cert is chained off that end cert, it's technically 'invalid' so again its obvious which one is more/less trusted, but it's easier for an attacker to get their own DV end cert for your domain.

 - The third way is getting the pubKey into the cert attributes, such as encoding the pubKey, or a fingerprint of the pubKey, as a Subject Alternate Name, so the attacker would need to get their own cert to change the address, meaning it's not as critical if your cert key is stolen.

On the wallet side, it comes down to additional validation code paths which get triggered by some detection logic. For example, if you pass PubKey and InvoiceID in the Payment Request, the wallet needs to know if it should check for a Subject Alternate Name in the cert for a fingerprint of the PubKey, how the fingerprint is calculated, and then verify the Address is indeed PubKey * InvoiceID.  I think falsely rejecting a legacy Payment Request would get the extra validation code path commented out pretty quickly.

I really like Mike Hearn's idea of 'You have paid this recipient 4 times' but also agree completely on the crying wolf due to expiration or revocation. At least such a message could be based on the domain name only, to try to prevent phishing with similar domain names, then there's no expiration issue. Slightly more restrictive would be domain + CA, again not considering expiration, but pinning the pay count to the CA seems to have little downside and makes it harder for an attacker to get their own cert for your domain if you choose your CA 'wisely'.

I assume the ship has sailed on v1, but if we can get consensus on how we want this to work in the near-term, we can start prototyping it and maybe get this available sooner than later. In any case we should be confirm v1 doesn't do anything to prevent this from working in a clean, extensible manor, which I think means prototyping it and seeing the new Payment Request is handled transparently by v1 code.

Right now I'm leaning towards writing a prototype using a single cert with a fingerprint of PubKey in the Subject Alternate Name, and getting PubKey and InvoiceID in the Payment Request.  Gavin, would the best way to work on this be to just fork your code on Github?

Thanks,

--Jeremy