This is an interesting question. I would like to address the first question: "one of the problems that I can think of is if the QR reader is compromised, to display www.google.com instead of www.nsa-super-secret-place.gov/123":

The master key is used as the seed into HMAC together with the website address (FQDN). So although the QR code may encode completely different URL the protocol will NOT reveal the authentication code that would normally be sent to www.google.com (in the example).

Second, many of the contributors forget about the key objectives Steve had when working this idea out:

1. anonymity by not using 3rd party
2. ease of use
3. no need to type secret credential on untrusted computers

I believe the protocols addresses these in full!

However, there are compromises that actually come from the the first obectjivu. If no 3rd party is involved in the authentication, how can one revoke their authentication details? Additionally, the security of the master key is an obvious concern. I envisage this to be well protected by future mobile devices in a HSM like chip. Until then, the key is just a file pin mobile device, protected by a password, though PBDKF2 ensures that it is very slow to actually brute force it.

Finally, let's not be judgmental of Steve's capabilities and ideas unless one has come up with a smarter idea!

I would like to address the first question: "one of the problems that I can think of is if the QR reader is compromised, to display www.google.com instead of www.nsa-super-secret-place.gov/123":

The master key is used as the seed into HMAC together with the website address (FQDN). So although the QR code may encode completely different URL the protocol will NOT reveal the authentication code that would normally be sent to www.google.com (in the example).

Second, many of the contributors forget about the key objectives when working this idea out:

1. anonymity by not using 3rd party
2. ease of use
3. no need to type secret credential on untrusted computers

I believe the protocols addresses these in full!

However, there are compromises that actually come from the the first obectjive. If no 3rd party is involved in the authentication, how can one revoke their authentication details? Additionally, the security of the master key is an obvious concern. I envisage this to be well protected by future mobile devices in a HSM like chip. Until then, the key is just a file pin mobile device, protected by a password, though PBDKF2 ensures that it is very slow to actually brute force it.