DC API, OpenID4VP, ZKP : la matrice de repli à l'exécution que tout vérificateur d'âge doit implémenter

Il y a une seule décision de conception qui sépare un vérificateur d'âge fonctionnant pour tout le monde de celui qui fonctionne pour la plupart des gens : la façon dont il bascule en repli. Les recommandations relatives au vérificateur de vérification d'âge de l'UE ne laissent pas cela au goût de chacun. Elles énoncent clairement qu'un vérificateur doit prendre en charge plus d'un mécanisme de présentation et doit sélectionner la meilleure option disponible à l'exécution. Implémentez uniquement le chemin nominal et vous exclurez discrètement chaque utilisateur dont le navigateur ou l'appareil ne le prend pas en charge.

Cet article expose la matrice de repli, sa raison d'être, et la manière de raisonner à son sujet sans sur-revendiquer les propriétés de confidentialité au sommet de la pile.

Deux mécanismes, deux types de preuve

La matrice comporte deux axes.

Mécanisme de présentation — comment la requête atteint le portefeuille et comment la réponse revient :

• DC API (Digital Credentials API) — une API intégrée au navigateur. Le navigateur médie directement la requête de justificatif, offrant l'expérience utilisateur la plus fluide. C'est la méthode principale, et elle est de plus en plus disponible dans les systèmes d'exploitation et navigateurs modernes.
• OpenID4VP (OpenID for Verifiable Presentations) — le protocole fondé sur OpenID pour demander et recevoir des présentations vérifiables. C'est le repli, utilisé lorsque le navigateur de l'utilisateur ne prend pas en charge la DC API. Si vous voulez d'abord les fondamentaux du protocole, commencez par Comprendre le protocole OpenID4VP.

Type de preuve — quelle forme cryptographique prend la preuve :

• Attestation mdoc standard — le mso_mdoc Proof of Age signé, rendu à usage unique et émis par lots pour limiter la traçabilité.
• ZKP (preuve à divulgation nulle de connaissance) — un type de preuve renforcé offrant des propriétés de confidentialité plus fortes, traité comme l'option préférée lorsqu'elle est disponible.

Les recommandations présentent cela comme un ordre de préférence à l'exécution — confidentialité la plus forte + meilleure UX en premier, avec une dégradation progressive :

Votre vérificateur doit prendre en charge les combinaisons, et pas seulement celle qu'il préfère, et choisir l'option de plus haute priorité que chaque appareil peut réellement satisfaire.

Pourquoi le repli n'est pas optionnel

Il est tentant de livrer uniquement la DC API et de dire à la longue traîne de mettre à jour son navigateur. Trois raisons de ne pas le faire :

1. Couverture. La DC API est de plus en plus disponible — ce qui est précisément la formulation signifiant qu'elle n'est pas encore universellement disponible. Chaque utilisateur sur un navigateur ou un OS qui en est dépourvu représente une vérification d'âge échouée si vous n'avez pas de repli. Pour une barrière d'âge, une vérification échouée n'est pas une expérience dégradée ; c'est une transaction bloquée.
2. Les recommandations l'exigent. « Votre vérificateur doit prendre en charge toutes les combinaisons » n'est pas un conseil. Un vérificateur d'âge conforme aux exigences de l'UE implémente le repli.
3. La dégradation progressive est une propriété de fiabilité. La même discipline que nous appliquons à toute intégration résiliente — supposer que le meilleur chemin peut être indisponible et disposer d'un second chemin testé — s'applique ici. Le repli OpenID4VP est votre second chemin.

L'ordre de confidentialité, énoncé honnêtement

Placer la ZKP en priorité 1 est correct, mais c'est dans la façon dont vous la décrivez aux parties prenantes que les équipes se mettent en difficulté. Soyez précis sur ce qui est livré par rapport à ce qui est préféré :

• Livré et réel : la preuve mdoc standard est à usage unique et émise par lots, et elle ne divulgue que le statut au-dessus du seuil — pas la date de naissance, pas l'identité. Cela seul déjoue l'attaque naïve de corrélation consistant à présenter « deux fois le même justificatif ».
• Préférée, pas universelle : la ZKP est listée comme un type de preuve pris en charge et préféré. Ne documentez pas votre système comme « à divulgation nulle de connaissance, donc non corrélable par construction » à moins que le déploiement spécifique avec lequel vous vous intégrez ne fournisse réellement une ZKP pour la transaction concernée. La phrase exacte est : « Lorsque la ZKP est disponible, nous la préférons ; sinon, la non-corrélation repose sur des preuves mdoc à usage unique, émises par lots. »

Nous faisons la même distinction prudente dans notre guide du développeur sur l'attestation de preuve d'âge et dans Vérification d'âge respectueuse de la vie privée. Cela compte parce qu'une revendication de confidentialité est une revendication de conformité, et qu'une revendication exagérée est un risque.

Implémenter la sélection à l'exécution

La logique que votre vérificateur exécute, conceptuellement, à chaque transaction :

1. Détectez la présence de la DC API. Ce navigateur l'expose-t-il ? Si oui, privilégiez-la.
2. Négociez le type de preuve. Au sein de la DC API, demandez une preuve ZKP ; acceptez un mdoc standard si la ZKP est indisponible.
3. Basculez en repli sur OpenID4VP lorsque la DC API est absente, avec une preuve mdoc standard.
4. Validez avant d'accorder l'accès. Quel que soit le chemin, la preuve présentée doit être validée par rapport à l'Age Verification Trusted List de l'UE avant que vous ne laissiez passer l'utilisateur. Cette étape de validation est un sujet à part entière — voyez notre article compagnon sur la validation de la preuve d'âge par rapport à la liste de confiance.
5. Traitez la preuve comme étant à usage unique. Ne la stockez pas, ne la rejouez pas, n'en dérivez pas d'identifiant stable. Le faire réintroduirait la traçabilité même que la conception par lots vise à empêcher.

Notez que les étapes 1 à 3 concernent le fait d'atteindre le portefeuille et que les étapes 4 et 5 concernent le fait de faire confiance à la réponse et de la traiter. Un vérificateur correct fait les deux. Un mode d'échec courant est celui des équipes qui maîtrisent le chemin de requête puis manipulent mal la preuve — en la stockant « pour audit », ce qui convertit discrètement une vérification respectueuse de la vie privée en un enregistrement de traçage.

Comment cela s'inscrit dans le tableau d'ensemble

La matrice de repli, ce sont les mécaniques côté vérificateur du même flux qui, côté identité de la partie utilisatrice, dépend de l'enregistrement WRPAC : votre vérificateur s'authentifie en tant que partie utilisatrice enregistrée, formule la requête via la DC API ou OpenID4VP, reçoit une preuve, la valide par rapport à la liste de confiance, et accorde ou refuse l'accès. Pour une comparaison plus complète de la façon dont ce modèle de vérificateur diffère des contrôles d'identité hérités, notre comparaison développeur EUDI Wallet vs KYC met les deux côte à côte.

En résumé

Les recommandations relatives au vérificateur vous donnent un ordre de préférence — DC API + ZKP, puis DC API + mdoc, puis OpenID4VP + mdoc — et une instruction : prendre en charge les combinaisons et choisir la meilleure à l'exécution. La DC API vous donne l'expérience ; OpenID4VP vous donne la couverture ; l'ordre des types de preuve vous donne la confidentialité. Livrez uniquement le sommet de la matrice et vous livrez une barrière d'âge qui échoue pour les utilisateurs les moins susceptibles d'être sur un navigateur de pointe. Livrez l'ensemble de la matrice, décrivez honnêtement la propriété ZKP, et traitez chaque preuve comme étant à usage unique, et vous obtenez un vérificateur correct, inclusif et défendable.

Cet article reflète les recommandations relatives au vérificateur de vérification d'âge de l'UE en date de juin 2026. Le repli à l'exécution et l'ordre des types de preuve reposent sur le guide officiel du vérificateur ; vérifiez par rapport à la spécification en vigueur avant d'implémenter.