nexo FAST appelle ça les Terminal Configuration Data : une pile de tables, une par sujet. Chaque bloc de premier niveau du fichier – e2, eb, f0… – est l'une de ces tables, et à l'intérieur, un même tag DFxx ne veut pas dire la même chose d'une table à l'autre. L'outil résout chaque champ dans son bloc, cite la section dont il vient, et décode ceux qui portent une table de bits.
Format lu : sepaConfig (XML).
La configuration est une pile de tables. Chaque bloc de premier niveau est l'une des tables définies par nexo FAST, et son nom XML est le tag de la spécification : <e2> dans le fichier, c'est le tag E2 dans le dictionnaire. Voici à quoi sert chacune.
Trois vocabulaires se superposent sur le même objet, et un seul des trois vient de nexo. Ça vaut la peine de savoir lequel on emploie devant qui.
catm.003 AcceptorConfigurationUpdate, découpée en jeux de données et groupée en TerminalParameters, ApplicationParameters, AcquirerParameters, MerchantParameters, SecurityParameters. Quand elle voyage en fichier, la convention de nommage nexo la préfixe même « PA », pour Acceptor Configuration.Un champ peut aussi venir d'une autre spécification nexo sans être dans nexo FAST : le numéro de version du jeu de paramètres, présent sur chaque enregistrement, est une notion de télégestion décrite par le TMS Message Usage Guide. L'inspecteur le signale « nexo TMS », pas « champ éditeur ».
Pourquoi le préciser : appeler « sepaConfig » ce que la norme appelle Terminal Configuration Data marche très bien entre gens qui manipulent le même outil, et ne marche plus du tout dès qu'on ouvre la spécification ou qu'on parle à un autre fournisseur.
Trois blocs que vous verrez dans un fichier ne correspondent à aucune table de la spécification. Mais c'est le contenant qui n'est pas nexo, pas le contenu : les champs qu'ils portent sont, eux, presque tous normatifs. L'inspecteur distingue les deux au lieu de tout marquer « éditeur ».
Chaque bloc a sa propre table d'entrée, donc les tags DFxx sont locaux au bloc. Le même tag change de sens d'une table à l'autre, et rien à l'écran ne vous en avertit. Un décodeur qui résout les tags à plat se trompe sans rien signaler : c'est le piège principal de ces fichiers.
DF03 vaut Supported Services dans la table de sélection des profils applicatifs, mais CA Public Key Algorithm Indicator dans la table des clés publiques, et Application Label dans la table des kernels par AID.DF01 a quatorze sens différents selon le bloc : AID du profil, RID du terminal, numéro d'acquéreur, identifiant de jeu de plafonds, préfixe DCC…DF10 seul désigne Service Settings, mais DF10 dans la table de sélection désigne Application Profile Kernel ID. Le même tag, deux définitions, dans le même fichier.Un tag est un identifiant BER-TLV (ISO/IEC 8825-1, repris par EMV Book 3 Annexe B). Son premier octet dit sa classe et s'il est primitif ou construit, et ça se lit sans dictionnaire. Mais l'attribution des tags de classe privée n'est normalisée nulle part : c'est l'éditeur de l'application qui les choisit. Un DFxx qu'aucun dictionnaire ne connaît n'est donc pas un trou, c'est un tag propriétaire.
Les tables ci-dessus disent où un paramètre est rangé dans le fichier. La spécification, elle, dit à quel niveau il est défini, ce qui n'est pas la même chose. Deux niveaux portent presque tout (§4.2) :
Règle de préséance : quelques paramètres existent aux deux niveaux. Dans ce cas le profil applicatif l'emporte et remplace la valeur du terminal. Terminal Capabilities est l'exemple donné par la spécification. Lire la seule valeur au niveau terminal peut donc donner une réponse fausse.
Les intitulés normatifs restent en anglais : ce sont les identifiants avec lesquels on retrouve la ligne dans la spécification. Sources : dictionnaire de données de pour les tables et les sens, ISO/IEC 8825-1 et EMV 4.3 Book 3 Annexe B pour le codage des tags.