UCP Mandate Evaluation — profil de cycle de vie
com.merchantstamp.mandate-evaluation
Cette page est la référence canonique du profil de cycle de vie mandate-evaluation que MerchantStamp propose pour la capacité Checkout du Universal Commerce Protocol (UCP). Elle définit ce qu’un marchand doit faire lorsque le TTL d’un mandat AP2 expire pendant la finalisation du paiement. La contribution d’UCP, ce sont les sémantiques de cycle de vie et le point d’évaluation — pas un nouveau format de reçu. Le résultat s’exprime via la construction de reçus AP2/FIDO existante.
Statut et namespace
Extension proposée à la capacité Checkout d’UCP, publiée sous le namespace fournisseur com.merchantstamp.mandate-evaluation selon la règle UCP du namespace-fournisseur-d’abord, en attente de promotion vers le core. Elle définit uniquement des sémantiques de cycle de vie et réutilise la construction de reçus AP2/FIDO — elle n’introduit pas de famille de reçus propre à UCP. Les mots-clés normatifs suivent RFC 2119 / RFC 8174. La proposition résout l’issue UCP #512 et a été affinée après les retours de revue de l’issue #515.
La lacune comblée
Le cycle de vie Checkout comporte un état de traitement — complete_in_progress — atteint après qu’un marchand accepte Complete Checkout et avant que la commande passe à completed. Si le TTL du mandat expire alors que la session est déjà en complete_in_progress, la spécification actuelle ne dit pas ce qui se passe. AP2/UCP Mandates indique seulement que le marchand vérifie l’expiration à la requête complete, et mandate_expired signifie seulement que le timestamp exp est passé. Aucun des deux ne traite le cas en vol. C’est une question de machine à états Checkout, et c’est ce que ce profil spécifie.
Autorisation vs validité (liveness)
Le profil sépare deux propriétés habituellement confondues sous « validité du TTL » :
Autorisation
L’acheteur a-t-il permis ce débit ? Réglée à l’instant où le marchand accepte Complete Checkout contre un mandat valide à cet instant. Un délai de traitement non imputable à l’acheteur ne la remet pas en cause. L’irrévocabilité de l’art. 80 DSP2 est la limite.
Validité (liveness)
Le mandat est-il dans sa fenêtre maintenant ? La liveness conditionne si un paiement PEUT entrer en traitement ; elle ne détermine pas si un travail déjà admis reste autorisé. Le TTL est une borne convenue d’avance sur le moment où le droit peut s’exercer, pas un signal de retrait en direct.
Le modèle
Évaluer la validité du mandat exactement une fois, au point d’usage (réception de Complete Checkout), contre des données de transaction contraignantes, et y geler l’autorisation. Un mandat valide à cet instant va jusqu’à un reçu AP2 terminal quelle que soit l’expiration ultérieure ; un mandat déjà expiré à cet instant n’entre jamais en traitement. Cela reflète la façon dont Checkout traite déjà l’Eligibility Verification at Completion : une propriété résolue une fois, à un point défini, sur des données contraignantes. Aucun nouveau statut de cycle de vie n’est introduit — l’extension contraint seulement la transition prise depuis ready_for_complete.
Deux issues
Le marchand DOIT geler l’autorisation de la session, DOIT enregistrer l’évaluation comme attestation vérifiable, PEUT passer en complete_in_progress, et DOIT aller jusqu’à un état terminal. Une expiration ultérieure NE DOIT PAS interrompre le traitement ni raccourcir la fenêtre de règlement.
La session NE DOIT PAS entrer en complete_in_progress. Elle DOIT se terminer canceled avec un message mandate_expired et DOIT exposer l’expiration comme artefact terminal. Invariant : mandate_expired NE DOIT PAS être rapporté une fois la session entrée en complete_in_progress.
Les reçus réutilisent AP2/FIDO
Les deux issues s’expriment via la construction de reçu Checkout/Payment AP2 existante (ou un profil minimal aligné sur AP2) — pas une famille de reçus UCP séparée. La seule exigence normative d’UCP ici est le liage et l’exclusion mutuelle : l’évaluation enregistrée (cas positif) et l’issue d’expiration terminale (cas d’annulation) sont la même forme probante sur un seul chemin de vérification, distinguées par le type/raison du reçu ; un vérifieur DOIT pouvoir lier les deux au même flux via la référence du mandat + checkout_id ; et pour un même checkout_id, un marchand NE DOIT PAS émettre à la fois une évaluation positive enregistrée et un artefact terminal d’expiration/annulation. La signature et la vérification réutilisent la construction de reçu et de signature AP2/UCP (ES256 recommandé, canonicalisation JCS RFC 8785, JWS détaché) plutôt qu’un mécanisme propre à UCP.
Profil de capacité
Le marchand annonce son support pour que les plateformes rafraîchissent un mandat avant la finalisation plutôt que de courir contre la limite :
mandate_evaluationBooléen — si le marchand évalue la validité du mandat au point d’usage selon ce profil.min_remaining_ttlDurée ISO 8601 — le TTL résiduel minimum qu’un mandat doit porter à Complete Checkout pour que le marchand l’admette.profil reçu/signatureLe profil de reçu et de signature AP2 émis par le marchand, pour que la plateforme sache quelle forme probante attendre.Où se place MerchantStamp
MerchantStamp implémente un serveur marchand UCP pour les marchands de longue traîne. Dans la pile du commerce agentique, MCP gère le liage agent-vers-outil, AP2/FIDO fournit l’autorité cryptographique et le reçu probant, et UCP porte le cycle de vie commercial. Ce profil se situe précisément sur la couche cycle de vie d’UCP : il spécifie une transition de machine à états et réutilise AP2/FIDO pour le reçu, en évitant délibérément tout recouvrement avec les couches au-dessus et en dessous.