[ mapping conformité ]
Nous signons le moment où le payload est lié.
Le dynamic linking acquiert un témoin device-side.
Mapping de l'événement signé d'assemblage du payload sur l'Article 5 (dynamic linking) et l'Article 4 (code d'authentification) du Règlement délégué (UE) 2018/389 de la Commission.
Banques européennes, PISP, acquéreurs travaillant avec des émetteurs européens, architectes scheme.
L'authentification forte du client PSD2 est l'obligation de l'opérateur. L'infrastructure SCA de l'opérateur reste le chemin porteur des Articles 4 et 5 de (UE) 2018/389 — connaissance, possession, inhérence, code d'authentification, cap de tentatives, protection transport. Nous ne la remplaçons pas.
À l'intérieur de cette obligation, une clause est singulièrement device-side : le dynamic linking. L'Article 5 lie le code d'authentification au couple (montant, bénéficiaire) exact que le payeur a vu. La question : qu'a-t-on réellement affiché et assemblé au moment de la confirmation ?
L'événement signé d'assemblage du payload répond à cette question par un énoncé cryptographique, ancré dans une clé résidente TEE, vérifiable par l'opérateur sans vendor dans le chemin. C'est cela, le moment du dynamic linking. L'Article 5 ouvre cette page parce qu'il est l'obligation PSD2 porteuse qu'EEI renforce singulièrement. L'Article 4 suit.
L'événement signé d'assemblage comme témoin device-side du dynamic linking.
Texte officiel cité en anglais ; la version française autoritative est publiée sur EUR-Lex sous le même numéro CELEX 32018R0389.
Le texte cité est verbatim de l'Article 5 du Règlement délégué (UE) 2018/389 (CELEX 32018R0389). La force du binding côté EEI est annotée par ligne (TEE-bound lorsqu'une clé résidente TEE ou Trusted UI est dans le chemin ; attestation software-only sinon).
| Article 5 (verbatim) | Obligation en clair | Événement signé d'assemblage EEI |
|---|---|---|
| Article 5(1)(a) the payer is made aware of the amount of the payment transaction and of the payee; | Avant l'authentification, le payeur doit voir le montant et le bénéficiaire. | L'événement signé d'assemblage du payload enregistre l'état de surface de l'écran de confirmation — overlay.detected, accessibility.active, code.integrity, runtime.environment — au moment où le payeur voit le montant et le bénéficiaire. TEE-bound lorsque le device expose une primitive Trusted UI au TRP ; attestation software-only sinon (la classe de signal indique le chemin emprunté). |
| Article 5(1)(b) the authentication code generated is specific to the amount of the payment transaction and the payee agreed to by the payer when initiating the transaction; | Le code d'authentification doit être lié à ce montant exact + ce bénéficiaire exact. | EEI ne génère pas lui-même le code d'authentification SCA — c'est l'infrastructure SCA de l'opérateur. L'événement signé d'assemblage est adjacent : il porte un hash cryptographique du tuple (montant, bénéficiaire) tel qu'observé sur le device au moment de l'assemblage, signé par la paire ZTBP résidente dans la TEE. TEE-bound. |
| Article 5(1)(c) the authentication code accepted by the payment service provider corresponds to the original specific amount of the payment transaction and to the identity of the payee agreed to by the payer; | Ce que le PSP accepte doit correspondre à ce que le payeur a accepté. | Vérification indépendante côté vérifieur : l'opérateur vérifie l'événement signé d'assemblage contre la clé publique enregistrée du device et compare le hash (montant, bénéficiaire) signé au tuple (montant, bénéficiaire) livré avec le code d'authentification. Un écart est un témoignage device-side de substitution entre l'écran de confirmation et le fil. Vérification souveraine — aucun vendor dans le chemin. |
| Article 5(1)(d) any change to the amount or the payee results in the invalidation of the authentication code generated. | Toute modification du montant ou du bénéficiaire doit invalider le code. | Hors périmètre EEI en obligation primaire — l'invalidation du code d'authentification est appliquée par l'infrastructure SCA de l'opérateur. L'événement signé d'assemblage renforce le côté détection : toute divergence entre le hash signé (montant, bénéficiaire) et le code accepté est observable indépendamment côté vérifieur. |
| Article 5(2)(a) the amount of the transaction and the payee throughout all of the phases of the authentication; | Confidentialité, authenticité, intégrité du couple (montant, bénéficiaire) sur toutes les phases du flux d'authentification. | L'événement signé d'assemblage couvre la phase device-side : assemblage, affichage au payeur, liaison à l'authentification. Chaque entrée Evidence Token est appendée au Local Evidence Ledger résident sur le device (append-only, hash-linked). Le TRP observe le chemin d'appel framework / libc / syscall pendant cette fenêtre. TEE-bound pour la garde de la clé de signature ; observation runtime continue. |
| Article 5(2)(b) the information displayed to the payer throughout all of the phases of the authentication including the generation, transmission and use of the authentication code. | Ce que le payeur voit, sur toutes les phases, doit rester confidentiel, authentique et intègre. | L'événement signé d'assemblage enregistre les classes de signaux d'état de surface — overlay.detected, accessibility.active — au moment de la confirmation. Une interposition par overlay ou par service d'accessibilité qui modifie ce que le payeur voit devient une observation signée et rejouable, et non un jugement de crédibilité. TEE-bound si Trusted UI est disponible ; attestation software-only sinon. |
| Article 5(3)(a) in relation to a card-based payment transaction for which the payer has given consent to the exact amount of the funds to be blocked pursuant to Article 75(1) of that Directive, the authentication code shall be specific to the amount that the payer has given consent to be blocked and agreed to by the payer when initiating the transaction; | Cas carte avec blocage de fonds : le code est spécifique au montant bloqué consenti. | L'événement signé d'assemblage capture le montant consenti à bloquer tel qu'affiché et accepté sur le device. Le hash (montant-à-bloquer, bénéficiaire) signé est vérifiable contre ce que l'infrastructure SCA de l'opérateur a accepté — un témoignage device-side de l'intégrité du consentement dans le chemin de blocage de fonds. |
| Article 5(3)(b) in relation to payment transactions for which the payer has given consent to execute a batch of remote electronic payment transactions to one or several payees, the authentication code shall be specific to the total amount of the batch of payment transactions and to the specified payees. | Cas batch : le code est spécifique au montant total du batch + aux bénéficiaires spécifiés. | Dans un contexte batch, l'événement signé d'assemblage enregistre le montant total du batch et la liste ordonnée des bénéficiaires tels qu'affichés et acceptés sur le device. Le hash porté par l'événement couvre le tuple batch complet, vérifiable indépendamment contre ce que l'infrastructure SCA de l'opérateur a accepté. TEE-bound. |
Le dynamic linking est l'obligation qu'un témoin device-side renforce singulièrement.
Chaque clause de l'Article 5 repose sur le même fait : le payeur a confirmé un (montant, bénéficiaire), et ce couple doit rester lié au code d'authentification que le PSP accepte. L'infrastructure SCA de l'opérateur gère le code ; le device gère l'affichage et l'assemblage.
L'événement signé d'assemblage est le témoin device-side naturel. Émis à l'assemblage, ancré dans une paire ZTBP résidente TEE, il porte un hash du tuple (montant, bénéficiaire) affiché — accompagné des signaux d'état de surface et de la trajectoire runtime. L'opérateur le vérifie contre la clé publique enregistrée.
C'est cela, la contribution de la couche témoin au dynamic linking : pas satisfaire l'Article 5 seul — l'infrastructure SCA de l'opérateur s'en charge — mais rendre la moitié device-side de l'obligation cryptographiquement observable plutôt qu'un jugement de crédibilité.
Où l'événement signé d'assemblage renforce l'Article 4 — et où il ne le fait pas.
Texte officiel cité en anglais ; la version française autoritative est publiée sur EUR-Lex sous le même numéro CELEX 32018R0389.
EEI ne génère pas le code d'authentification — l'infrastructure SCA de l'opérateur s'en charge. Les lignes ci-dessous montrent où l'événement signé d'assemblage renforce une propriété du code ou une clause de protection de session, et où la clause est hors périmètre par construction.
| Article 4 (verbatim) | Obligation en clair | Événement signé d'assemblage EEI |
|---|---|---|
| Article 4(2)(a) no information on any of the elements referred to in paragraph 1 can be derived from the disclosure of the authentication code; | Le code d'authentification ne doit pas révéler d'information sur les éléments SCA sous-jacents. | L'événement signé d'assemblage ne porte aucun des éléments de connaissance / possession / inhérence — seulement le payload assemblé, la trajectoire runtime, et les classes de signaux. La divulgation d'un Evidence Token ne fuit donc pas d'élément SCA. Renforcement indirect. |
| Article 4(2)(b) it is not possible to generate a new authentication code based on the knowledge of any other authentication code previously generated; | Connaître un code ne doit pas permettre d'en générer un autre. | Chaque Evidence Token est signé indépendamment par la paire ZTBP résidente dans la TEE et porte un numéro de séquence ainsi que le hash de l'entrée précédente du Local Evidence Ledger. Les tokens ne se dérivent pas l'un de l'autre ; capturer un Evidence Token ne permet pas de forger le suivant. Renforcement, pas substitution. |
| Article 4(2)(c) the authentication code cannot be forged. | Le code d'authentification ne doit pas être falsifiable. | EEI ne protège pas le code d'authentification SCA lui-même — c'est l'infrastructure SCA de l'opérateur. EEI renforce la preuve environnante : l'événement signé d'assemblage est ancré à une clé privée résidente dans la TEE, générée et enregistrée via ZTBP, et vérifié contre la moitié publique stockée chez l'opérateur, sans vendor dans le chemin. Falsifier l'événement device-side exigerait un compromis de la TEE. |
| Article 4(3)(b) the number of failed authentication attempts that can take place consecutively, after which the actions referred to in Article 97(1) of Directive (EU) 2015/2366 shall be temporarily or permanently blocked, shall not exceed five within a given period of time; | Cap des tentatives échouées consécutives à cinq dans une fenêtre définie. | hors périmètre EEI Hors périmètre EEI. Le décompte des tentatives, les blocages temporaires et permanents sont régis par l'infrastructure SCA de l'opérateur. La couche témoin n'applique pas de cap de tentatives. |
| Article 4(3)(c) the communication sessions are protected against the capture of authentication data transmitted during the authentication and against manipulation by unauthorised parties in accordance with the requirements in Chapter V; | Les sessions de communication doivent être protégées contre la capture et la manipulation non autorisée. | EEI ne remplace pas les exigences de protection transport du Chapitre V (TLS, intégrité de canal). Il renforce le bout device-side de la session : l'événement signé d'assemblage rend toute manipulation post-affichage du tuple (montant, bénéficiaire) observable côté vérifieur, indépendamment du transport. Renforcement. |
| Article 4(3)(d) the maximum time without activity by the payer after being authenticated for accessing its payment account online shall not exceed 5 minutes. | Timeout d'inactivité de cinq minutes pour l'accès en ligne authentifié au compte. | hors périmètre EEI Hors périmètre EEI. Le timeout d'inactivité de session est appliqué par la plateforme banque-en-ligne de l'opérateur. La couche témoin ne gère pas le cycle de vie de session. |
| Article 4(4) Where the block referred to in paragraph 3(b) is temporary, the duration of that block and the number of retries shall be established based on the characteristics of the service provided to the payer and all the relevant risks involved, taking into account, at a minimum, the factors referred to in Article 2(2). The payer shall be alerted before the block is made permanent. Where the block has been made permanent, a secure procedure shall be established allowing the payer to regain use of the blocked electronic payment instruments. | Gestion du blocage : durée, retries, alertes, procédure de déblocage. | hors périmètre EEI Hors périmètre EEI. Le cycle de vie du blocage, l'alerte du payeur, et la procédure de déblocage sont régis par l'infrastructure SCA de l'opérateur et le processus customer-operations. |
Ce qu'EEI ne fait pas pour PSD2 SCA.
La couche témoin renforce la couverture probante du moment du dynamic linking. L'infrastructure SCA de l'opérateur reste le chemin porteur des Articles 4 et 5.
- ·01
EEI n'est pas un facteur SCA
- EEI ne satisfait pas seul connaissance, possession, ou inhérence. L'exigence de deux-éléments-ou-plus de l'Article 4(1) est satisfaite par l'infrastructure SCA de l'opérateur, pas par l'événement signé d'assemblage.
- ·02
EEI ne remplace pas la vérification du facteur possession
- Le binding device via ZTBP n'est pas équivalent à la vérification du facteur possession au sens de l'Article 4(1). La stack SCA de l'opérateur continue de vérifier le facteur possession ; EEI signe le contexte d'assemblage adjacent à cette vérification.
- ·03
EEI ne satisfait seul ni l'Article 4 ni l'Article 5
- Aucune clause de l'Article 4 ou de l'Article 5 n'est satisfaite par EEI isolément. L'événement signé d'assemblage renforce la couverture probante device-side du moment du dynamic linking ; l'obligation reste celle du PSP, remplie par l'infrastructure SCA du PSP.
- ·04
EEI n'applique ni cap de tentatives, ni timeouts, ni cycle de blocage
- L'Article 4(3)(b), 4(3)(d) et 4(4) — cap à cinq tentatives, timeout d'inactivité de cinq minutes, gestion du blocage — sont des obligations opérateur. La couche témoin ne gère pas le cycle de vie de session.
Attestation de source.
Article 4 et Article 5 sont cités verbatim depuis le Règlement délégué (UE) 2018/389 de la Commission (CELEX 32018R0389), édition EN publiée sur EUR-Lex.
https://eur-lex.europa.eu/eli/reg_del/2018/389/oj/eng
La publication fait également foi dans toutes les langues officielles de l'UE ; l'édition EN est citée ici.
Nous nous asseyons avec vos architectes SCA et mappons le moment du dynamic linking à une preuve device-side signée.
Soixante minutes. Apportez une revue Article 5 récente et un flux d'authentification échantillon. Nous mappons le moment d'assemblage du payload à l'événement signé ; le reste de votre stack SCA reste tel quel.
Demander un mapping PSD2 SCA