Résumé

  • RFC 9560 permet aux serveurs RDAP d’identifier un utilisateur et de valider un jeton via OpenID Connect et OAuth, sans multiplier les comptes locaux.
  • Les déclarations facultatives de finalité et de non-traçage alimentent une politique locale ; elles ne certifient ni l’intention, ni le droit attaché à la requête, ni l’absence universelle de traces, ni la qualité du registre interrogé.
  • Une preuve exploitable relie la validation du jeton à la version de la politique, aux champs divulgués, à la provenance de la donnée et au résultat ultérieur de l’enquête.

Le serveur vient d’accepter le Bearer Token. Il a contrôlé assez d’éléments — émetteur, audience, expiration, structure — pour poursuivre. Cette réussite est précise. Le vocabulaire opérationnel l’est souvent moins : « utilisateur authentifié » devient « requête autorisée », puis « finalité légitime », puis « réponse vérifiée ». RFC 9560 ne permet aucun de ces raccourcis.

Publié en avril 2024 sur la voie de normalisation de l’IETF, RFC 9560 introduit l’authentification fédérée dans le Registration Data Access Protocol. Le client découvre les OpenID Providers acceptés et choisit un parcours par session ou par jeton. La couche commune réduit la prolifération des identifiants ; elle ne retire pas au serveur RDAP sa décision locale d’accès.

L’authentification ferme une seule question

Dans le parcours par jeton, le serveur doit vérifier, selon sa politique, qu’il s’agit bien d’un jeton d’accès légitime. Il peut recourir à l’introspection de RFC 7662 ou analyser un JWT. L’audience compte : un jeton destiné à un autre relying party peut être refusé, tandis qu’un échange conforme à RFC 8693 peut produire une audience adaptée.

Ce contrôle dit que le serveur accepte de s’appuyer sur ce justificatif dans cette interaction. Il ne fixe pas encore les données accessibles. Après validation, le serveur compare les claims à sa politique, détermine le niveau d’autorisation et tranche chaque requête. Refus, omission, masquage et divulgation sont des résultats distincts.

Une finalité attribuée n’est pas une lecture de l’intention

Le claim facultatif rdap_allowed_purposes énumère les finalités qu’une identité est autorisée à invoquer. L’Identity Provider ne doit les attribuer qu’aux identités habilitées. Pour une requête donnée, farv1_qp exprime la finalité choisie ; une finalité hors de l’ensemble permis conduit à un 403.

Cette discipline est utile sans être omnisciente. Elle prouve l’attribution d’une catégorie d’usage, pas la raison intime de la requête, ni la conformité de l’usage futur. Le serveur peut ignorer finalité déclarée et claim s’ils contredisent sa politique locale. En l’absence de farv1_qp, il doit encore décider à partir des autres informations disponibles.

Un badge d’entreprise peut identifier son porteur et ouvrir une porte. Il ne prouve ni le motif du passage, ni la nécessité de chaque dossier consulté, ni le traitement ultérieur de l’information. La fédération d’identité a la même limite saine.

Le non-traçage échange une assurance contre une autre

Avec rdap_dnt_allowed, le serveur peut être tenu de ne pas relier l’identité de l’utilisateur à la requête dans ses journaux. Il faut que l’utilisateur soit identifié et autorisé, que le claim vaille true et que l’acceptation respecte les règles locales. Le RFC précise que cette promesse dépend de la bonne volonté du serveur et des proxys, ainsi que de relations de confiance établies hors bande ; la perte d’information peut sérieusement réduire les capacités d’audit.

Une enquête sensible peut légitimement exiger cette discrétion. Il faut alors nommer l’autorité qui accorde le privilège, les intermédiaires couverts, la preuve de substitution et l’échéance. « Non-traçage accepté » décrit un choix de politique, pas une preuve cryptographique qu’aucun système n’a conservé de corrélation.

La réponse porte sa propre charge de preuve

La valeur farv1 annonce la conformité à l’extension. Elle ne garantit pas le dossier d’enregistrement sous-jacent. Une réponse techniquement correcte peut être un sous-ensemble imposé par la politique ; la source possède sa date, sa méthode de vérification, ses corrections et ses ambiguïtés. HTTP 200 n’atteste ni exhaustivité ni utilité. HTTP 403 n’établit aucune faute du demandeur.

La couche commune minimale doit normaliser découverte, jetons, noms de claims et paramètres. Elle ne doit pas simuler une norme mondiale de finalité licite, de seuil de divulgation ou de conclusion d’enquête. Dans les termes des couches de réalité de Lu Heng, identité, jeton, habilitation de finalité, décision, donnée révélée et résultat réel existent tous ; aucun ne peut emprunter la force probante du suivant.