I just released version 1.1.0 of the extension. Some parts were rewritten for this release in order to simplify the code and to fix some other (mainly not user-visible) issues:
The format of the stored identifiers has changed. 1.0.x stored the user-supplied identifier in the database, while 1.1.x now uses the claimed identifier which is used for authentication at the OP and is thus closer to the OpenID specification. The old user-supplied identifier and the claimed identifier may actually be the same, but they can differ, if for example the user-supplied identifier redirects to some other URL. According to the OpenID specification the claimed identifier is the URL reached after following all redirects, while the user-supplied identifier was the URL before following any redirects. The installation procedure takes care of these changes and converts the identifiers when upgrading. If an identifier can not be converted automatically, you'll see a notice, and have to change it manually, but this may only happen, if the user-supplied identifier is invalid (e.g. because the OP is unreachable) and the user could not use it for login anyway.
This release now also supports login using XRIs, which was broken in all previous releases and has been fixed by the identifier format change. XRIs are only stored and displayed in the persistent i-number format, not as i-names. I-names can be used for login though. I didn't come up with a clean solution to display i-names while internally using i-numbers, but I assume that XRIs are scarcely used anyway and therefore not worth the effort needed for a nicer implementation. Please let me know, if I'm wrong here.
I considered adding OpenID icons at some spots, but here again I didn't find the ideal solution. Maybe this will be in one of the next releases.
While testing the new version, I discovered why some providers (e.g. ClaimID) cannot be used and fail with "server denied check_authentication". They use SSL to secure the connection between the forum and the provider (which is a good thing!), but my server fails to validate their certificate because he does not trust their certificate authority (CA). The simple (but insecure) fix is to deactivate certificate validation, which can be done by setting the appropriate cURL options in Auth/Yadis/ParanoidHTTPFetcher.php (I did not try the PlainHTTPFetcher.php, which is used, if cURL is not available). The better solution is to install the missing CA certificates, but this process depends on your environment, so I cannot provide instructions here.