Otro cambio importante es el de dejar que el proceso de registro se desarrolle normalmente. De esta forma funcionarán TODOS los proveedores Openid. Y si no es así, que me quede más delgado :-)
Si el proveedor no es capaz de enviar el nick y el mail del usuario (como pasaba con getopenid y Yahoo!) de forma automática, aparece un aviso para que los complete el usuario, a partir de ahí ya podrá entrar siempre solo con su openid.

1. Conseguir obtener el mail del usuario durante el alta, bien pidiéndoselo manualmente o cogerlo automáticamente si el proveedor lo permite.
2. Permitir las altas normales mediante nick y mail y después que los usuarios añadan sus cuentas openid asociadas. Esto funciona seguro.

Ésto tiene como consecuencia el que se deba replicar siempre y sin excepción el típico formulario de datos básicos de registro (email y nombre de usuario como mínimo) una y otra vez en todas las webs del mundo, aunque se use OpenID. El formulario de registro no va a desaparecer fácilmente. Nunca te puedes fiar de que el proveedor de OpenID te envíe esos datos, así que, en el registro de usuario, debes gestionarlos tu mismo como si no hubieran usado OpenID.
Después para el login ya usas OpenID, pero a todos los efectos, no considero que, a día de hoy, OpenID haya simplificado el registro, sino más bien lo contrario: ha añadido un paso más que luego sí tiene su beneficio en posteriores logins a la web (no tener que acordarte de un nuevo par de usuario+contraseña).

$response['openid.sreg.nickname']
$response['openid.sreg.email']

y otros no lo hacen. Me encontré un proveedor que detectaba la petición de drupal y junto a los botones de “permitir una vez” y “permitir siempre” aparecían las cajas de nick y mail para completarlas con una etiqueta “The website requires this data”.

El caso es que Drupal necesita un mail y un nick para crear una cuenta, son los datos mínimos. He solucionado el problema del nick (he probado con el proveedor de José María getopenid), cuando un proveedor devuelve como nick la URL openid esta contiene caracteres que no son válidos para nombre de usuario en Drupal, lo he modificado para que trate esa URL antes de pasarla como nick.
El problema que tengo ahora es el mail, creo que puedo eliminar el mail como dato de usuario aunque me gustaría tenerlo en las cuentas openvatar para notificaciones de administración.
Otra opción, menos elegante y más segura para mi gusto, es la de dejar que Drupal pida los datos restantes (o que no puede obtener automáticamente) al usuario. En realidad es así como funciona normalmente pero intenté que no fuese necesario para que registrarse en Openvatar fuera más rápido y sencillo, solo meter tu url Openid.
La verdad es que pensaba que Openid era más standard, que lo és, pero parece que cada proveedor lo trata de forma diferente. Drupal también tiene que avanzar más en la integración con Openid.

Es decir, no esperes email, no esperes nick, ni tan siquiera esperes que el identificador que te devuelva sea igual a la URL que han usado para identificarse.
Queda a opción del proveedor, y sobre todo, a opción del usuario, el permitir la transmisión de dicha información (email, nick, etc.)

En el caso de yahoo (lo he probado y no funciona con Openvatar) para identificarte tan sólo se introduce en la “cajita”: yahoo.com
Después Yahoo devuelve a la web el identificador del usuario, que es un chorro del estilo:
https://me.yahoo.com/a/XQ6F2Sd_uAU8RCuiOp7OWX6Q–
No devuelve nada más. Ni un email ni un nick.

Deberá de ser la web (en este caso Openvatar) la que se encargue de pedir los datos adicionales al usuario en caso de que no se los envíe el proveedor (o sea, la mayoría de las veces).