Résumé

  • Le RFC 9577 lie un jeton à un type, un émetteur, un contexte de rédemption, un ensemble d’origines, une clé et le condensat du défi exact.
  • Pour un service ouvert, même un client capable peut ignorer le défi avec une probabilité non négligeable. Son silence est donc volontairement indéterminé.
  • La conformité exige des reçus distincts pour validation du défi, disponibilité, choix de répondre, émission, vérification, rejeu, autorisation, effet et livraison.

Le tableau de bord avait inventé la cause

Une équipe voit cent défis envoyés et soixante jetons présentés. Elle inscrit « 40 % de clients incompatibles ». Le calcul paraît propre ; le dénominateur est faux. Les quarante silences peuvent contenir des types inconnus, des défis invalides, aucun jeton en cache, une émission indisponible, une politique locale, un abandon réseau ou un choix aléatoire prescrit pour préserver la vie privée.

Le RFC 9577 va plus loin qu’une simple permission de ne pas répondre. Dans les services qui fonctionnent sans jeton et l’utilisent seulement pour réduire une friction telle qu’un CAPTCHA, il recommande que des clients capables ignorent parfois le défi. Ils doivent alors être impossibles à distinguer, depuis l’Origine, d’un client incapable de produire le jeton.

Le silence n’est donc pas une erreur à expliquer après coup. Il fait partie de la propriété recherchée. Le transformer automatiquement en indice de fraude ou d’inéligibilité détruit cette propriété au niveau de la politique, même si chaque octet du protocole reste conforme.

Quatre champs bornent la question

Le token_type sélectionne le protocole d’émission et la sémantique de la structure. issuer_name désigne l’émetteur autorisé. redemption_context peut être vide, aléatoire pour une requête ou dérivé d’un état de session. origin_info est vide ou contient l’ensemble exact des Origines habilitées à accepter le jeton. L’en-tête fournit aussi la token-key.

Avant toute émission ou rédemption, le client vérifie le type, la forme et la présence de l’Origine dans origin_info lorsque ce champ n’est pas vide. Un échec interdit d’aller plus loin. Un succès ne contraint toujours pas le client : il peut appliquer des restrictions supplémentaires.

Chaque étape réduit un ensemble de possibilités. Aucune ne crée une dette. Le défi prouve la demande de l’Origine ; il ne prouve ni le support du client, ni sa confiance dans l’émetteur, ni la présence d’un jeton compatible, ni son consentement à exposer un signal.

Le jeton répond à une question étroite

Le jeton par défaut inclut un nonce généré par le client, le condensat SHA-256 du défi complet, l’identifiant de clé et un authentificateur. Sa validité cryptographique établit que ces éléments ont été correctement liés selon le type choisi. Les jetons mis en cache ne correspondent que si tous les champs du défi correspondent.

Cette exactitude empêche de convertir le jeton en certificat général de bonne conduite. Une liste d’Origines réordonnée, élargie ou réduite forme un autre défi. Un changement de réseau ou l’effacement des cookies peut rendre dangereux un jeton lié à l’ancien contexte, car sa rédemption recréerait un lien que le nouvel état voulait supprimer.

Le protocole peut attester la cohérence d’une présentation. Il ne dit pas qui est la personne, si elle est humaine, pourquoi elle n’a pas répondu auparavant, ni si l’application doit exécuter son action.

Une question plus coûteuse reçoit moins de réponses

L’Origine peut envoyer plusieurs défis pour différents types, émetteurs ou contextes. Leur ordre n’est qu’une indication ; le client choisit. Le RFC demande des propriétés fonctionnelles équivalentes et met en garde contre une quantité qui submerge le client.

Un contexte unique par requête bloque l’usage d’un jeton déjà en cache. Il impose alors le coût et la latence d’une nouvelle émission. L’opérateur qui augmente la spécificité du défi peut mesurer moins de réponses et conclure, à tort, que le parc a régressé. Son propre choix a changé la friction.

Les valeurs réservées de graissage rendent ce principe testable. L’Origine doit parfois proposer un type aléatoire que le client ignore proprement. Lorsqu’un jeton n’est pas obligatoire, elle doit aussi parfois ne rien demander. Ces branches entretiennent le comportement de repli avant qu’une dépendance implicite ne se transforme en panne.

Le rejeu dépend de l’effet

La rédemption n’achève pas la chaîne. L’Origine doit vérifier l’authentificateur et décider du traitement du nonce. Le RFC recommande une prévention de double dépense, mais distingue les contextes : un rejeu peut être acceptable si la requête est déjà corrélable et si la rédemption ne déclenche aucun effet ; il devient dangereux quand une action irréversible suit, notamment avec les données 0-RTT.

Il faut donc conserver trois décisions : jeton valide, rejeu acceptable, action autorisée. Les fusionner masque les responsabilités. Un validateur cryptographique ne connaît pas nécessairement la valeur économique de l’effet. Une application ne doit pas deviner l’histoire du nonce à partir d’un simple succès de signature.

Le même raisonnement vaut en sens inverse : absence de jeton, refus de service et soupçon de risque doivent demeurer trois événements différents.

Partager des Origines, c’est partager une dette opérationnelle

Une portée multi-Origines facilite la pré-émission, mais exige une égalité exacte des défis et un état de double dépense partagé. Une désynchronisation permet qu’un même jeton soit accepté à plusieurs endroits. Une Origine du groupe peut aussi épuiser le stock du client.

Le client peut cesser de présenter des jetons après une rédemption dans une fenêtre donnée. Ce silence protège son inventaire. Un système qui le punit incite précisément à l’épuisement que la protection cherchait à éviter.

L’accord réel entre Origines doit donc documenter la portée, la synchronisation, la consommation maximale, le traitement des pannes et la responsabilité. Le fait qu’elles affichent la même clé ne suffit pas à prouver cet accord en fonctionnement.

Le registre n’est pas une mesure de terrain

Les registres IANA donnent un nom stable au schéma et aux types. Les RFC 9576 et 9578 décrivent l’architecture et l’émission. Les primitives VOPRF et RSA aveugle définissent les preuves cryptographiques. Rien de cela ne mesure le déploiement d’un navigateur, la disponibilité d’un émetteur, l’indépendance des rôles ou l’égalité d’accès du chemin sans jeton.

La doctrine du code en fonctionnement impose de demander le reçu local. La norme définit ce qui peut arriver. Les traces bornées et respectueuses de la vie privée montrent ce qui est arrivé. Entre les deux, aucune institution ne doit transformer une coordonnée mondiale en verdict central sur un client.

Sources

Sources