Résumé

  • La révision 20 du projet RATS, datée du 28 octobre, ajoute un exemple de récupération de déclarations d'endossement et de valeurs de référence au moyen d'une poignée implicite : l'URL de la requête.
  • CoSERV garde la requête identique afin de permettre le cache. La réponse signée associe les données à cette requête et fixe leur expiration ; le vérificateur conserve la décision d'appréciation.

Une même adresse, plusieurs âges possibles

Le mot « récent » n'a pas la même portée pour toutes les pièces d'une attestation à distance. La preuve émise par un appareil doit renseigner le vérificateur sur son état au moment pertinent. Une valeur de référence peut servir à de nombreux contrôles avant que le fournisseur ne la modifie. L'architecture RATS sépare l'émetteur de la preuve, le fournisseur de références, le vérificateur et l'acteur qui exploite finalement le résultat.

Le texte du groupe de travail RATS reste un Internet-Draft destiné à la filière des normes. Sa nouvelle annexe B montre un circuit possible de récupération. Elle n'annonce ni service déployé ni obligation générale ajoutée à CoSERV. Son intérêt tient à une difficulté prosaïque : si chaque demande contient un identifiant unique, le cache voit à chaque fois une question différente.

CoSERV évite précisément les horodatages et autres données volatiles dans la requête. Des identifiants d'environnement et une sélection de déclarations identiques produisent une séquence encodée identique, puis une URL stable. Cette URL peut devenir une clé de cache. Les références restent alors accessibles sans faire repasser chaque vérification par la porte du fournisseur.

Dans l'exemple ajouté le 28 octobre, attEnvIDs et claimSelection forment la requête par environnement. L'URL du GET joue le rôle de poignée implicite au début d'une époque. Le producteur signe les recommandations et valeurs de référence avec la requête et une date d'expiration ; cette date borne l'autre extrémité de la période. Le modèle suppose une source temporelle fiable, par exemple une Epoch Bell. L'adresse désigne le casier. La réponse porte la signature et le calendrier de ce qu'on en retire.

La limite est vérifiable. CoSERV impose une expiration pour chaque ensemble de résultats ; le consommateur cesse de l'accepter après cette heure. Le cache HTTP ne peut afficher une durée de fraîcheur supérieure. Quand des intermédiaires non fiables existent, la signature lie les données à la requête. Un consommateur peut aussi demander Cache-Control: no-cache pour repasser à l'origine. Voilà une économie de requêtes assortie d'une date de fin, pas une délégation éternelle au cache.

Le fournisseur choisit les références et l'échéance qu'il signe. Le vérificateur choisit sa politique d'appréciation et confronte ces références à la preuve de l'appareil. Une partie utilisatrice décide ensuite de l'effet opérationnel du résultat. La révision 20 dessine leur passage de relais ; l'URL n'acquiert aucun pouvoir de jugement sur l'état actuel de la machine.

Sources : projet RATS -20 ; version -19 ; statut Datatracker ; CoSERV -07 ; Epoch Markers -06 ; RFC 9334.