Résumé

  • RFC 3506 modélisait un bon comme le triplet <émetteur, promesse, détenteur> appartenant à un ensemble logique de bons valides, et non comme un simple document copiable.
  • Émission, transfert, présentation et consommation produisaient quatre effets différents ; XML, signature et API ne prouvaient à eux seuls ni la propriété actuelle ni l’exécution de la promesse.

Le siège A-24 n’accepte qu’un spectateur. Pourtant, le fichier qui le décrit peut être copié sans effort. C’est dans cet écart entre une représentation reproductible et un droit exclusif que se place RFC 3506. Publié en mars 2003 avec le statut Informationnel, le texte cherchait un modèle commun aux coupons, points de fidélité, chèques-cadeaux, titres de transport, billets et bons de livraison.

Son abstraction tient en trois termes. I désigne l’émetteur, P sa promesse et H le détenteur. Le bon est <I,P,H>. La promesse peut accorder une réduction, réserver une place ou ouvrir un service pendant un mois. Elle peut être écrite en langage naturel ou encodée par des attributs XML. Mais décrire P ne suffit pas à établir qui détient encore le droit.

RFC 3506 attribue donc des pouvoirs distincts. L’émetteur crée le bon et garantit son contenu. Le détenteur le possède et peut engager son transfert ou son utilisation. Le collecteur l’examine et fournit le bien ou le service. Le fournisseur du système VTS maintient l’unicité : un même bon ne doit pas être attribué simultanément à plusieurs détenteurs ni utilisé au-delà de ses règles.

L’état commun est l’ensemble VVS, le Valid Voucher Set. Il contient les triplets reconnus comme valides et commence vide. Cette définition est logique, non topologique. Une base centrale, plusieurs serveurs d’émetteurs ou des cartes à puce distribuées peuvent mettre en œuvre le même invariant. Le document ne transforme aucune architecture particulière en autorité universelle.

L’émission ajoute <I,P,H> au VVS avec l’intention de l’émetteur. Le transfert remplace H par H' avec l’intention du détenteur initial. Il ne crée pas une seconde valeur parce qu’une seconde copie existe. Les octets anciens peuvent subsister ; c’est la réécriture de l’état valide qui déplace le droit.

La remise au collecteur se divise ensuite. La présentation montre le triplet sans supprimer la propriété, comme pour une licence utilisable plusieurs fois. La consommation retire le triplet, annule le droit ou diminue son nombre d’usages, comme pour un billet d’événement. Le verbe « utiliser » ne doit donc jamais masquer la question : le droit existe-t-il encore après l’opération ?

Les exigences de sécurité suivent cette grammaire. Seul l’émetteur peut provoquer une émission valide. Seul le détenteur actuel peut déclencher transfert ou remise. La circulation ne doit pas permettre une modification autre que le changement autorisé de détenteur. Une consommation ne doit pas laisser renaître un droit déjà épuisé.

Une signature ne résout pas tout. Le RFC observe qu’un certificat signé par l’émetteur convient à un bon non transférable. Mais un transfert modifie H et brise la signature d’origine. Surtout, empêcher une double utilisation exige encore une vérification d’état en ligne ou un dispositif résistant à l’altération. L’authenticité d’une phrase et l’exclusivité d’un droit sont deux preuves différentes.

Le texte refuse aussi l’hypothèse d’un courtier ou authentificateur mondial unique. Une organisation centrale serait fragile. Cette critique ne débouche pourtant pas sur l’obligation d’une technique décentralisée précise : cartes hors ligne et serveurs en ligne ont des contraintes distinctes. En 2003, les auteurs jugent prématuré de fixer un protocole de transfert universel.

Cette retenue ouvre trois plans : protocole de transfert, interface VTS et langage générique de bon. Le point commun minimal est le cycle de l’état valide. Les choix futurs doivent rester révisables et prouver leur utilité au lieu d’être imposés par la seule élégance d’un schéma.

RFC 4153 précise en 2005 le plan descriptif. Son Voucher Component XML contient valeur, restrictions, émetteur et fournisseur. Mais il énonce qu’un composant n’est pas un bon. Plusieurs instances peuvent partager la même description. Copier le composant ne multiplie donc pas les droits.

Le composant doit être protégé, car une modification malveillante peut faire paraître légitime une promesse falsifiée. Un canal sûr ou une signature XML protège cette racine descriptive. Il ne prouve toujours pas l’existence d’une instance non consommée, son détenteur actuel ni l’absence d’une remise antérieure.

RFC 4154 ajoute une interface uniforme. issue, transfer, consume et present donnent aux portefeuilles une manière commune de parler à des VTS différents. Les opérations conservent la logique : ajouter, déplacer, retirer ou montrer sans retirer. L’interface ne remplace pas l’état qu’elle manipule.

La note de l’IESG est décisive : l’API suppose que l’utilisateur fait confiance au module VTS, mais ne définit pas l’authentification de l’application. Une méthode appelée correctement n’est donc pas une preuve d’autorisation. Une réponse positive ne suffit pas davantage à prouver la validation durable, la remise au collecteur ou la livraison du bien.

La chaîne de preuves comporte au moins sept marches : description de la promesse, confiance dans l’émetteur et le fournisseur, instance présente dans le VVS, détenteur authentifié, transition engagée, état validé, prestation effectivement rendue. Sauter d’une marche à la dernière revient à confondre le symbole et le résultat.

Le mot voucher apparaît aujourd’hui dans les protocoles d’amorçage d’équipements. Cette homonymie ne relie pas les machines d’état. RFC 3506 vise des droits commerciaux transférables ; les vouchers BRSKI lient d’autres assertions dans un autre environnement. Un mot commun ne crée ni filiation technique ni preuve commune.

Enfin, la publication du RFC ne démontre aucun déploiement. Son statut Informationnel atteste une proposition structurée, non l’adoption par les marchands, l’interopérabilité de fournisseurs ou la satisfaction des utilisateurs. Il faut pour cela des traces d’implémentation, d’exploitation et d’issue réelle.

L’héritage de RFC 3506 est cette sobriété. Le document décrit la promesse. La signature protège une déclaration. L’API demande une action. Le VVS établit quel droit reste valide. Le collecteur, seulement ensuite, accomplit ou non la promesse. Deux fichiers identiques peuvent exister ; ils ne créent pas deux sièges A-24.

Sources