Résumé

  • La révision 03 de RVP retire la cascade obligatoire de cinq méthodes et la somme de confiance portable qui structuraient la révision 02.
  • Un jeton ancien signé autour d’un simple défi peut rester une archive ; il ne prouve pas que son signataire a approuvé l’opération et la cible désormais exigées.

Un service reçoit une réponse cryptographiquement valide. Peut-il en déduire que la personne a accepté l’accès à un équipement donné ? Pas si elle n’a signé qu’un défi de transport dont le sens pouvait changer ensuite. La version datée du 29 septembre de RVP déplace l’objet de la vérification : au lieu de faire circuler une note de confiance, elle attache le résultat à la question complète posée au répondant.

Le déplacement est vérifiable dans les deux textes. La version 02 proposait une vérification continue à chaque interaction, avec cinq couches successives et un seuil calculé à partir des scores. Elle réservait déjà l’exécution à la politique locale : la version 03 n’a donc pas inventé la distinction entre preuve et décision. Elle a supprimé l’obligation de cette cascade et l’idée qu’une session authentifiée ne puisse jamais garder de valeur. Une session de travail peut rester valable tandis qu’une présence humaine récente est exigée pour une transition sensible. C’est la politique du consommateur qui doit établir la combinaison.

Pour empêcher qu’une règle glisse après coup, l’exigence de preuve porte un identifiant, une version immuable et l’empreinte de son contenu canonique. La demande indique l’opération, la cible, le sujet, l’acteur distinct s’il existe, le consommateur, la finalité, la fenêtre et la date limite. L’engagement sur la question couvre ces données avec le défi. Le transporteur peut présenter la question et rapporter une réponse ; son défi technique seul ne décrit pas ce que la personne a vu. Le vérificateur recalcule l’engagement depuis sa propre demande.

L’annexe consacrée à la migration trace une limite parfois gênante pour les systèmes existants. Les jetons de première génération peuvent être conservés comme preuves historiques. En revanche, là où la nouvelle exigence impose le lien à l’opération et à la cible, ces jetons ne peuvent être acceptés. Le vérificateur ne doit pas reconstruire les champs absents à partir de son état actuel puis attribuer au signataire l’acceptation de ce contexte. Le passage silencieux d’un engagement complet de version 2 à une signature ne couvrant qu’un défi de version 1 est également écarté.

La séparation continue après l’obtention de la réponse. match clôt la voie de vérification en indiquant une conformité à l’exigence figée, mais pas une utilisation. Quand le consommateur emploie effectivement cette preuve pour une finalité et un état de cible, il produit un bind distinct, vérifie fraîcheur et actualité de la cible, et évite les consommations concurrentes. Plusieurs consommateurs ne sont possibles que si l’exigence les nommait au préalable. L’admission reste une décision du système cible.

Daniel Kade recommande, pour une migration, de conserver côte à côte la version du jeton, les champs réellement signés, l’empreinte de l’exigence, la cible, le consommateur et la décision finale. Ce registre est une recommandation éditoriale, non un formulaire imposé par le projet. Il révèle le risque d’un raccourci administratif : transformer « score élevé autrefois » en « consentement signé aujourd’hui ».

Datatracker classe le texte comme Internet-Draft individuel actif, sans filière RFC indiquée. La demande d’enregistrer le type application/rvp+json ne prouve pas son enregistrement. Ni adoption, ni incident, ni interopérabilité réelle ne sont établis ici. La nouvelle porte sur la portée que les auteurs veulent donner à une preuve, et sur celle qu’ils refusent désormais de lui prêter.

Sources