I understand the reason why chargebacks are a bad idea for online commerce.
Bitcoin makes more sense, because it is a system where consumers have to trust the reputation of established sellers, instead of asking sellers to trust random customers.

However, the current system could be improved.
When I place an order, I receive a Bitcoin address from the merchant. At that point, sending my coins to that address remains a leap of faith.

As a buyer, I would feel more comfortable if I had a public proof that I sent coins to that merchant, (not just to an anonymous address), in case of  litigation.

I propose the following:
Instead of simply displaying "Please send <xx> BTC to address <aaa>", the merchant's website should also sign that message with a private key, and give the signature to the customer.
The corresponding public key should be visible on their website. That way, a customer can prove that he actually sent money to the merchant, not just to a random address.

The signed message could also contain the description of the purchased good, and maybe the shipping address of the customer (in that case, customers would lose anonymity if they publish the proof).

Are there online sellers interested in such a solution?
The "signmessage" and "verifymessage" RPC commands of the bitcoin daemon should make this easy. For example, you could use a bitcoin address of your wallet in order to sign messages with it.

This is also a good way of stopping various attacks by an attacker substituting their bitcoin address in a bitcoin payment request URI for the merchant's real bitcoin URI.

The bitcoin URI a merchant uses is likely to have a 'one-time' address but by signing it with a private key which has a well known public key it gives it veracity.

Of course the user has to have confidence in the advertised public key of the merchant which is probably best served by a locked down server via SSL.

indeed, a merchant could sign with a certified SSL public key, but I don't think that this is what jim618 was saying...

The main thing about publicising your public key / address from a locked down SSL server is to to make attacks such as the following more difficult:

Webmaster: this is a great Javascript utility to 'insert something neat here' I will just pop that on my website.
Behind the scenes, utility code swops out real bitcoin payment address for attacker's.

Buyer sees authentic looking bitcoin payment URI with right amount, label etc. The address is one-time so would not be in buyer's address book. Buyer pays happily. Attacker receives bitcoin. Merchant just sees 'no purchase'. Several days later buyer complains to merchant - where's my stuff ? Merchant : What stuff ? You never paid.

You *could* sign with an SSL cert but I think using the bitcoin crypto is better. It is defence in depth. The signed payment request and payment are effectively a key exchange that you could then use for, say, secure chat between the two parties.

I have been thinking about it a bit more.
I believe that URI Scheme is indeed the best way to do this.
I have added URI support to Electrum, similar to what Multibit does. now I need to add a 'verifymessage' capability.

Here is how I think we should implement identity verification:
 - the browser should verify that the Bitcoin address used to sign a bitcoin: URI matches the address provided by the website (i.e. the identity of the merchant).
 - the bitcoin client should verify that the provided signature matches the address and message. it will show a warning if the URI is unsigned.
 - if the user accepts the transaction, the bitcoin client will store the message and the signature in its records, so that the user keeps a proof of identity.
 - I guess the URI should contain the signature AND the bitcoin address corresponding to the signing key. Even though the public key can be recovered from the signature, this is not something that can be done easily by a browser extension

(reference: https://bitcointalk.org/index.php?topic=6430.0)

subscribed.  interesting ideas. 

A system which implements proof of payment and assurance payment is going to the right entity is a great step forward.

If we sign the URI with a bitcoin address, then the verification will need ecdsa, and it is better to do it with the bitcoin client. Thus, we need to send the merchant's public address to the bitcoin client. The easiest way to do it is to include the merchant's address in the URI, but this means that the browser needs to verify that the URI contains a public address that matches the public address of the website.

Another solution, as you suggest, is to lookup the merchant address from a standard location on the website. But in that case too, we will need to make sure that the bitcoin client gets the correct public address. I assume that the URI is the only information passed to the bitcoin client; this means that the URI would need to contain the hostname of the web server, so that the client can request the public key; and again, we need to verify that the hostname is correct.

This is why I wrote that two things need to be verified: the public address and the signature. It seems that a web browser extension is necessary in order to perform the first verification.

We could also use the ssl public key of the website in order to sign the URI. This might fit better with the existing infrastructure.

I don't get this.
You are trying to verify that bitcoin address on sellers website belogns to seller ?

Maybe I missed something, but stores still need TLS to transport bitcoin addresses so they cannot be tampered with.

Proof of payment is easy - customer provides a bitcoin address (any) at registration. Merchant presents a receipt (arbitrary string associated with purchase details) at checkout. Customer sends Bitcoins and signs receipt to complete the purchase.

Sorry, I didn't quite think that through... When you register, you could be required to pay a small random amount micropayment to register your key with the merchant. From that point, this key would be required to sign a receipt.

How's that?