Only large merchants are able to maintain such an infrastructure; (even
Coinbase recently failed at it, they forgot to update their
certificate). For end users that is completely unpractical.

Payment protocol is for when you buy stuff from purse.io, not really needed for face-to face transfers, end users, IMO.



I disagree with your statements. There are many face to face use cases where the payment protocol is essential. Pretty much anything where the payee's hardware device that the payer interacts with is automated in public and/or operated or accessible by untrusted employees. In any of those cases the software on the payee's hardware device can be modified. Providing a signed payment request gives the payer additional confidence that they are paying the correct person.

See some examples here: http://andyschroder.com/BitcoinFluidDispenser/2.3/


There was a secure bluetooth protocol that Andreas Schildbach and Eric Voskuil and I were working on, but we never pulled it all the way together. This would also need a two way exchange for a face to face payment. This could be used without using some sort of key/certificate verification service if being done between two humans who are the direct senders and receivers of the payment and are using hardware that they personally own (not necessarily the case of untrusted employees or public vulnerable machines).




 
The same benefit can be achieved without the complexity of BIP70, by
extending the Bitcoin URI scheme. The requestor is authenticated using
DNSSEC, and the payment request is signed using an EC private key. A
domain name and an EC signature are short enough to fit in a Bitcoin URI
and to be shared by QR code or SMS text.

 bitcoin:address?amount=xx&message=yyy&name=john.example.com&sig=zzz

I agree.  A TXT record at that name could contain the pubkey.  


Did you not see my previous message about the size of the bitcoin: URI getting too big for NFC and QR codes? Do you not care about giving the payer the option of using multiple destination payment addresses? This is important for many reasons.


 
That extension is sufficient to provide authenticated requests, without
requiring a https server. The signed data can be serialized from the
URI, and DNSSEC verification succeeds without requesting extra data from
the requestor. The only assumption is that the verifier is able to make
DNS requests.

The problem is that there's no way for a merchant to refuse a payment without a direct communication with the merchant's server.    Verify first / clear later is the rule.   Check stock, ensure you can deliver, and clear the payment on the way out the door.  

So, are you saying first the payer should send an unsigned transaction for review, and then once the payee has agreed it's good, they can send an ACK message back and then wait for the signed version? I don't think this is a bad option to have. Many wallets simultaneously broadcast a signed transaction to their peers and and also back to the payee via https or bluetooth. So, you'd have to add another step to do the unsigned transaction review in order to avoid a transaction being accidentally broadcast that both parties don't like.



Also, as a merchant processing monthly subscriptions, you don't want the first time you hear about a user's payment to be after it hits the blockchain.  You could add a refund address to deal with it after the fact... stuff a refund address int OP_RETURN somehow?

bitcoin:address?amount=xx&currency=ccc&message=yyy&name=john.example.com&offset=3d&interval=1m&sig=zzz

Again, my comments above about issues with using bitcoin: URI for everything. Also, why do you want to bloat the blockchain with unnecessary refund transaction data?