La Digital Credentials API expliquée
La Digital Credentials API est le mécanisme convenu qui permet à un site web de demander une attestation directement à votre portefeuille, via le navigateur et le système d'exploitation de l'appareil que vous avez déjà en main. Sur le téléphone qui contient votre portefeuille, aucun code QR n'apparaît et vous n'êtes pas renvoyé vers une autre application puis ramené. Vous touchez l'écran une fois, votre téléphone vous montre qui demande, et vous décidez. Sur un ordinateur portable, le navigateur affiche son propre code QR pour joindre votre téléphone.
Le détour qu'elle supprime
Jusqu'ici, un site web qui voulait obtenir quelque chose d'un portefeuille devait trouver un moyen de lui faire parvenir la demande. En pratique, cela voulait dire afficher un code QR sur la page, ou ouvrir un lien qui envoie le visiteur vers une application en espérant qu'il revienne. Les deux fonctionnent, et les deux font perdre des utilisateurs à chaque étape.
C'est pire sur un téléphone, où le code QR s'affiche sur le même écran que la caméra censée le scanner. La Digital Credentials API comble ce fossé en faisant de la demande quelque chose que le navigateur et le système d'exploitation peuvent transmettre eux-mêmes, puisqu'ils savent déjà quels portefeuilles se trouvent sur l'appareil.
Sur le même appareil
Le visiteur utilise le téléphone qui contient le portefeuille. C'est là que la Digital Credentials API supprime purement et simplement le code QR et le passage par une autre application.
Entre deux appareils
Le visiteur est sur un ordinateur portable et le portefeuille sur un téléphone, il faut donc toujours un moyen de relier les deux. La différence, c'est que le navigateur peut désormais afficher et gérer ce code lui-même.
Ce que cela donne en pratique
Pour le visiteur, c'est un seul geste sur la page où il se trouvait déjà. En coulisses, le navigateur transmet la demande au système d'exploitation, le système d'exploitation trouve les portefeuilles capables d'y répondre, et le portefeuille présente la demande pour approbation avant que quoi que ce soit ne soit partagé.
1. Site web
Demande une attestation au navigateur au lieu d'afficher un code QR ou d'ouvrir une application
2. Navigateur et système d'exploitation
Déterminent quels portefeuilles de l'appareil contiennent une attestation correspondante, et ne proposent que ceux-là
3. Titulaire
Voit qui demande et quoi, choisit un portefeuille, puis accepte ou refuse
4. Retour au site web
Reçoit la réponse approuvée sur la page même que le visiteur n'a jamais quittée
Pourquoi l'implication du navigateur compte
Un code QR est un morceau de papier ou une image sur un écran, et il ne peut pas vous dire qui l'a placé là. C'est tout le principe du phishing par code QR : un attaquant remplace le code, le portefeuille s'ouvre, et la demande paraît tout à fait normale, car rien dans le parcours ne sait d'où elle vient vraiment.
Quand la demande passe par le navigateur, c'est lui qui indique au portefeuille quel site fait la demande, et on ne peut pas lui faire dire autre chose. Le portefeuille peut montrer le vrai site au titulaire, et la réponse peut être liée à ce site, si bien qu'une copie interceptée ailleurs ne sert à personne. C'est une réduction réelle de l'exposition à la fraude, pas seulement un écran plus fluide.
Comment elle s'articule avec OpenID4VP et l'EUDI Wallet
On pourrait y voir un standard de plus entre lesquels il faudrait choisir. Ce n'est pas le cas. OpenID4VP reste la langue qu'utilise une partie utilisatrice pour dire ce dont elle a besoin et lire la réponse qu'elle reçoit, et la Digital Credentials API est simplement un meilleur chemin pour cet échange, surtout quand tout se passe sur un seul appareil.
Il en va de même pour l'attestation elle-même. Une attestation EUDI Wallet ou un mdoc arrive exactement au même format que via un code scanné, de sorte que les contrôles qu'un vérificateur effectue déjà restent inchangés. Une équipe y gagne la possibilité d'éviter le détour, sans rien reconstruire derrière.
La prise en charge arrive navigateur par navigateur et plateforme par plateforme, pas partout à la fois. C'est pourquoi les parties utilisatrices l'adoptent en complément du parcours par code scanné, et non à sa place. L'approche pragmatique consiste à utiliser l'API là où l'appareil la propose, à revenir à un code là où ce n'est pas le cas, et à laisser cette solution de repli s'effacer à mesure que la couverture progresse.
Ce que cela signifie pour vous
Partie utilisatrice
Moins d'abandons, car les étapes où les utilisateurs décrochaient ont disparu, et le navigateur indique au portefeuille qui vous êtes vraiment, ce qui ferme une porte au phishing.
Titulaire du portefeuille
Un seul geste sur la page où vous êtes déjà, le vrai nom de celui qui demande, et aucun moyen pour un site de savoir quels portefeuilles vous utilisez, sauf si vous dites oui.
Fournisseur de portefeuille
Le système d'exploitation propose votre portefeuille dès qu'il contient une attestation adaptée. Être trouvé ne dépend donc plus de la décision d'une partie utilisatrice de proposer un lien vers vous.
Approfondissement technique
Cette page explique ce que fait la technologie et qui elle concerne. Notre documentation pour développeurs couvre la mise en œuvre elle-même : les messages, les champs et les exemples détaillés dont une équipe d'intégration a besoin.
Lire la documentation techniqueTermes associés
Questions fréquentes
Est-ce la fin des codes QR ?
Non, mais leur usage se restreint et ce n'est plus le même acteur qui les produit. Faire passer une demande d'un ordinateur portable à un téléphone exige toujours un pont entre les deux, et l'API couvre aussi ce cas : c'est le navigateur qui affiche le code, au lieu que chaque site construise le sien. Ce qui disparaît complètement, c'est le code sur un téléphone qui contient déjà le portefeuille. Là, il n'a jamais été qu'un pis-aller.
Le site web peut-il voir quels portefeuilles j'ai installés ?
Non. Le site décrit ce qu'il demande, et le système d'exploitation effectue la correspondance sur l'appareil. Le site n'apprend jamais quels portefeuilles sont installés ni lesquels contenaient une attestation correspondante. Si vous refusez, il sait seulement que rien n'est revenu, ce qui, de son point de vue, est exactement pareil que si vous n'aviez aucune attestation correspondante.
Est-ce que cela remplace OpenID4VP ?
Non, les deux fonctionnent ensemble. OpenID4VP est la langue dans laquelle la demande et la réponse sont rédigées, et elle ne change pas. La Digital Credentials API est le canal d'acheminement sur l'appareil, à la place d'un code QR ou d'un lien spécifique. Une partie utilisatrice qui parle déjà OpenID4VP conserve sa logique de demande et de vérification existante.
Que doit concrètement développer une partie utilisatrice ?
Moins que la plupart des équipes ne le pensent, car seul le front-end change. La demande produite par votre backend et les contrôles qu'il applique à la réponse restent identiques. Vous ajoutez l'appel dans le navigateur et, tant que la prise en charge progresse, une solution de repli par code QR pour les visiteurs dont le navigateur ou l'appareil ne peut pas encore utiliser l'API.
Sources
Cette page est fournie à titre informatif et ne constitue pas un avis juridique. La Digital Credentials API évolue encore : consultez directement la spécification du W3C pour la formulation qui fait foi.