Client to Authenticator Protocol (CTAP) v2.3

Remarque

Spécification de la FIDO Alliance qui décrit un protocole applicatif de communication entre un authentificateur itinérant et un client ou une plateforme, avec ses liaisons de transport (CTAP 2.3).

Résumé

Objet

Le Client to Authenticator Protocol (CTAP) de la FIDO Alliance, version 2.3, publié comme Proposed Standard le 26 février 2026, organise le dialogue entre un authentificateur « itinérant », par exemple un smartphone, et la plateforme cliente, par exemple un PC, sur laquelle l’utilisateur s’adresse à une partie utilisatrice CTAP 2.3, Proposed Standard, February 26, 2026 CTAP 2.3, § 1. Introduction[](#intro) :

Pour eIDAS 2, la partie utile est celle des transports hybrides. Ils séparent la preuve que l’appareil client est physiquement proche de l’authentificateur, apportée par des annonces Bluetooth Low Energy (BLE), du canal qui transporte les messages. Ce canal passe soit par un service réseau appelé tunnel service, soit par une communication locale (BLE, ultra-large bande…) CTAP 2.3, § 11.5. Hybrid transports[](#sctn-hybrid).

À qui ça s’applique

Le texte même de l’annexe II du règlement d’exécution 2024/2982 ne nomme CTAP 2.3 que dans deux remarques, rédigées au conditionnel Annexe II. Cette annexe rend aussi applicable, avec des adaptations, le paragraphe 6 de la spécification ETSI TS 119 472-2 V1.2.1 Annexe II, qui nomme CTAP dans une exigence (voir ci-dessous). Les remarques accompagnent deux exigences qui, elles, visent le portefeuille : dans les flux entre deux appareils, il vérifie, au moyen de l’API de médiation, que l’appareil qui interagit est à proximité physique immédiate. Il le fait par un canal de communication local sécurisé, direct et qui demande une action de l’utilisateur Annexe II. L’obligation générale pèse sur les fournisseurs de portefeuille, qui veillent à la prise en charge des spécifications de cette annexe Art. 5 §1.

Les remarques visent d’autres acteurs : les systèmes d’exploitation, les navigateurs, les API de médiation et toute autre couche qui échappe au contrôle du portefeuille Annexe II :

C’est ce canal local que ces couches « devraient » utiliser, à la fois pour vérifier la proximité et pour transférer les données entre les deux appareils. Selon les mêmes remarques, CTAP 2.3 permet d’utiliser le BLE pour la vérification de proximité et, si les deux appareils le mettent en œuvre, pour transporter les données Annexe II.

Points clés

• Dans le texte de l’annexe, une recommandation. Les deux remarques emploient le verbe « devraient » Annexe II.
• Dans la spécification ETSI rendue applicable, une exigence. L’annexe donne un nouveau texte aux exigences OIDFVP-HAIP-ADD-API-01, -04 et -05 de la clause 6.5.2, mais ne modifie pas l’exigence -06 Annexe II. Celle-ci vise les navigateurs et les systèmes d’exploitation :

L’article qui renvoie à l’annexe oblige, lui, les fournisseurs de portefeuille Art. 5 §1.

• Un changement par rapport à la norme intermédiaire. Dans la version V1.2.1 de la spécification ETSI TS 119 472-2, l’exigence OIDFVP-HAIP-ADD-API-05 imposait au portefeuille, quand le navigateur et le système le permettent, le flux hybride de CTAP 2.2 décrit à la section 11.5 du document CTAP qu’elle cite ETSI TS 119 472-2 V1.2.1, § 6.5.2 Additional requirements. L’annexe II donne un nouveau texte à cette exigence : la vérification de proximité par un canal local Annexe II.
• Des références datées différemment. La spécification ETSI cite CTAP comme un Review Draft du 21 mars 2023 ETSI TS 119 472-2 V1.2.1, § 2.1 Normative references ; l’annexe, qui n’ajoute que d’autres références normatives, ne remplace pas celle-ci et dit « CTAP 2.3 », sans date Annexe II. Le règlement d’exécution 2026/1731, qui a ajouté cette annexe, date CTAP 2.3 du 26 février 2026 dans une note de ses considérants modifiant les règlements d’exécution (UE) 2024/2977, (UE) 2024/2979, (UE) 2024/2980 et (UE) 2024/2982 en ce qui concerne les normes et spécifications applicables. C’est la version que contient le corpus CTAP 2.3, Proposed Standard, February 26, 2026.
• Les contrôleurs d’accès. Selon un considérant du même règlement, les contrôleurs d’accès « devraient privilégier », dans les flux en ligne entre deux appareils, un canal de communication local tel que prévu par CTAP 2.3 plutôt que les services de transport hybride CTAP modifiant les règlements d’exécution (UE) 2024/2977, (UE) 2024/2979, (UE) 2024/2980 et (UE) 2024/2982 en ce qui concerne les normes et spécifications applicables. Un considérant explique l’acte ; il ne crée pas d’obligation à lui seul.
• Le canal BLE local. Dans CTAP 2.3, un canal de transfert BLE peut être établi en plus du canal WebSocket ; la spécification recommande de toujours garder les WebSockets en repli CTAP 2.3, § 11.5.1.1.2. Bluetooth Low Energy[](#hybrid-ble-channel).

Passages des actes qui s’y rattachent

• Annexe II : exigences ISO/IEC 18013-ADD-API-05 et OIDFVP-HAIP-ADD-API-05 et leurs remarques ; exigence OIDFVP-HAIP-ADD-API-06 de la spécification ETSI, non modifiée. La clause 5.4, d’où vient la première exigence, figure dans l’annexe ; dans la spécification ETSI V1.2.1, la clause 5 s’arrête à la clause 5.3.3 ETSI TS 119 472-2 V1.2.1, § 5.3.3 ISO/IEC-mdoc EAAP Response profile. Cette annexe a été ajoutée par le règlement d’exécution 2026/1731 Art. 4.

Liens

• Normes liées : OpenID4VC-HAIP OpenID4VC HAIP 1.0, ISO/IEC 18013-7 ISO/IEC TS 18013-7:2025.
• Norme intermédiaire : ETSI TS 119 472-2 ETSI TS 119 472-2 V1.2.1.
• Parcours : étape 3, le portefeuille européen.

Rédaction Asphalia.