I predict that these problems will be finally solved when commodity webcams are good enough for secure retina/iris scanning.
To do iris-scanning security, there must be a back-end database with the characteristics ("fingerprint") of each user's iris.
This database will be secured as strongly/effectively as a password database because it contains authentication credentials.
Unfortunately, password databases get broken into, and similarly iris databases will also get broken into.
The attacker then has to simply convert the iris fingerprint back into an image to replay to the authentication process.
This is probably easier than reversing a password hash (because the fingerprinting algorithm is unlikely to be optimised against reversing), and certainly no harder.
(This is assuming untrusted client-side hardware.)
Rather, a good solution would involve deriving a (site-specific) token from the fingerprint and handing it off to the remote service, which then deals with it in much the same way we expect sites to deal with passwords.
This, of course, presupposes that we can retrieve a consistent and unique fingerprint from the same iris from various different images of it, and breaks down if all we can do is check an iris image to see if it matches a fingerprint.
Biometrics are pretty much useless in consumers hands; they're more security theater than anything else. I do mean "pretty much"; if you fiddle around the edges of the problem you can with some work construct a use case where they really are the best solution to a problem, but as something that can just be deployed on a wide scale for general purposes? No.
It's not clear how using iris fingerprints rather than passwords really adds anything other than to increase the risk of a false negative, and introducing a third party dependency.
(I do take your point about storing a hash of the iris fingerprint, though. How this would intefere with the matching process is, I guess, outside of both our areas.)
And if you could consistently derive the key from the biometric data entirely on the client, then you wouldn't even need an authentication provider, instead transparently treating the resulting authentication token as a password.
If a password database is compromised, you have a problem, but you can change everyone's passwords.
If an iris database is compromised, you really have a problem.
Biometrics are also susceptible to replay attacks, where sort-of-alternatives (such as tokens) aren't.
Hash + Salt on the client, submit the result. Unique salt for each remote service, and you can change it for a particular remote service if it turns out they do stupid shit with it.