Resumen

  • WebFinger convirtió un nombre de cuenta en una consulta. Según el RFC 7033 de 2013, el programa pregunta al /.well-known/webfinger del dominio que sigue a @ y recibe enlaces en JSON. El nombre puede circular entre aplicaciones; el dominio conserva la libreta de direcciones.
  • El RFC 7565 definió después acct: como identificador de cuenta independiente del protocolo. Un informe comunitario de W3C de 2024 documentó su uso para hallar un actor de ActivityPub. El destino sigue dependiendo de la respuesta del servidor nombrado.

El nombre se recuerda; la ruta se pregunta

«Carol en example.com» funciona bien entre personas. Una aplicación todavía necesita saber dónde está el proveedor de acceso o el documento que representa a Carol. Un sitio usa /carol, otro /users/carol, otro un identificador largo. Cada programa tendría que adivinar las costumbres de cada servicio para convertir el nombre en URL.

El RFC 7033, publicado en septiembre de 2013, situó una ventanilla común en el dominio de la cuenta. El cliente envía a example.com un GET a /.well-known/webfinger con el identificador acct: de Carol en example.com codificado como resource. El servidor devuelve un JSON Resource Descriptor: asunto, posibles alias, propiedades y enlaces con su relación. Un parámetro rel permite preguntar solo por una relación. El propio RFC muestra cómo descubrir al emisor de OpenID Connect de Carol. El cliente no fabrica la dirección del servicio: la obtiene del dominio.

Ahí estaba la autoridad práctica. El operador puede cambiar el enlace devuelto sin cambiar la forma del nombre. Si su ventanilla deja de responder, otro programa no obtiene una respuesta WebFinger para esa cuenta. El estándar hizo común la pregunta; no instaló una agenda universal capaz de contestar por todos los dominios.

Identificar una cuenta no es abrir su página

El RFC 7565 de mayo de 2015 definió acct: para identificar una cuenta en un proveedor, al margen del protocolo con que se interactúe con ella. el identificador acct: de Carol en example.com no es una dirección HTTP que el navegador pueda abrir directamente como perfil. WebFinger lo convierte en el objeto de una consulta al servidor de example.com; la respuesta aporta los enlaces web utilizables.

Esa separación permite que una aplicación busque un proveedor de identidad y otra una página de autor. El punto de partida no cambia: manda el dominio después de @. Un identificador escrito de manera común no entrega al usuario el control del servidor que mantiene el mapa.

En 2024, un informe final del grupo comunitario Social Web de W3C describió el mismo recorrido para ActivityPub. Se construye acct:user@domain, se pregunta al endpoint WebFinger del dominio y se obtiene un enlace al documento HTTPS del actor, aunque su ruta interna sea distinta en cada servicio. El informe también explica la comprobación inversa. Registra una práctica posterior del entorno social; es un informe comunitario, no una Recomendación W3C.

Una libreta pública acepta preguntas de cualquiera. El RFC 7033 advirtió que una consulta puede confirmar si existe una cuenta y vincular datos personales con una dirección. Ese conocimiento sirve para recopilar cuentas o afinar mensajes fraudulentos. El texto plantea controles de acceso y límites de consultas. En una instalación real importa qué alias y propiedades se entregan, además de que la búsqueda funcione.

WebFinger evitó que cada aplicación tuviera que conocer la forma de las URL de todos los sitios. La condición quedó escrita en el primer paso: ir al dominio del nombre y pedirle el siguiente enlace. El usuario podía llevar su identificador a muchas conversaciones; la libreta seguía en la casa del dominio.