Résumé

  • WebFinger a transformé un nom de compte familier en requête. Avec le RFC 7033 de 2013, une application interroge /.well-known/webfinger sur le domaine inscrit après @ et reçoit des liens en JSON. Le nom circule ; le domaine tient le répertoire.
  • Le RFC 7565 a ensuite défini acct: comme identifiant de compte indépendant du protocole d’accès. Un rapport de groupe communautaire W3C de 2024 a décrit son usage pour trouver un acteur ActivityPub. L’adresse lisible dépend toujours du serveur qui répond pour elle.

Un nom facile à dire, une destination à chercher

Dire « Carol chez example.com » suffit à une conversation. Une application doit encore savoir où trouver son fournisseur d’identité ou son document de profil. Selon le service, la page peut se trouver sous /carol, /users/carol ou un identifiant opaque. Deviner le chemin à partir du nom impose à chaque logiciel de connaître les habitudes de chaque site.

Le RFC 7033, publié en septembre 2013, installe un guichet commun chez le domaine du compte. Un client demande à example.com l’adresse /.well-known/webfinger en indiquant l’identifiant acct: de Carol chez example.com dans le paramètre resource. La réponse est un JSON Resource Descriptor : sujet, éventuels alias, propriétés et liens dotés d’un type de relation. Un paramètre rel peut limiter la recherche. L’exemple du RFC retrouve ainsi le fournisseur OpenID Connect de Carol. L’application ne calcule pas la destination ; elle la demande au domaine.

Ce guichet détient la décision discrète. Le nom reste identique même si son opérateur change le lien renvoyé. Cette souplesse a son envers : si le serveur du domaine ne répond plus, le client distant n’obtient aucune réponse WebFinger pour ce nom. La norme uniformise la question, sans établir un carnet central qui parlerait à la place des domaines.

acct n’était pas une page à ouvrir

En mai 2015, le RFC 7565 a défini le schéma acct: pour identifier un compte chez un prestataire, indépendamment du protocole utilisé pour communiquer avec lui. l’identifiant acct: de Carol chez example.com n’est pas l’URL HTTP que le navigateur peut simplement ouvrir comme page de profil. WebFinger prend cet identifiant comme objet d’une question adressée à l’hôte désigné, puis le serveur fournit des liens réellement consultables.

La distinction sert plusieurs applications. L’une cherche un fournisseur de connexion, une autre une page d’auteur ou un profil. Elles commencent pourtant toutes au domaine situé après @. Une écriture commune pour l’identifiant ne remet pas au titulaire du compte la gestion du domaine. L’opérateur de ce dernier conserve la correspondance vivante entre nom et ressources.

Un rapport final du groupe communautaire Social Web du W3C, daté de 2024, décrit l’usage pour ActivityPub. À partir de user@domain, le client construit une ressource acct:, interroge le point WebFinger de ce domaine et reçoit un lien vers le document HTTPS de l’acteur, dont le chemin peut varier selon les services. Le rapport traite aussi la vérification en sens inverse. C’est un rapport communautaire qui consigne un usage ultérieur, pas une recommandation W3C.

Le répertoire ouvert répond également aux visiteurs moins bien intentionnés. Le RFC 7033 relève qu’une requête peut confirmer l’existence d’un compte et associer des informations à une adresse. Cela facilite la collecte d’identifiants ou des messages de fraude mieux ciblés. Le texte discute le contrôle d’accès et la limitation du nombre de demandes. Pour un site réel, il faut donc regarder ce que le guichet publie, y compris alias et propriétés, au lieu de célébrer seulement la découverte.

WebFinger a évité aux applications de mémoriser tous les modèles d’URL des services. Sa première instruction révélait aussi où se trouvait le pouvoir : aller au domaine du nom et lui demander la suite. Le pseudonyme voyageait ; le carnet d’adresses restait chez lui.