Digital Credentials API

Un site web appelle navigator.credentials.get() avec une demande d'attestation numérique qui indique un protocole de présentation et transporte, comme charge utile, la demande propre à ce protocole. Le navigateur transmet la demande au système d'exploitation, qui affiche un sélecteur natif des portefeuilles installés sur l'appareil, et le portefeuille choisi par le détenteur renvoie sa réponse protocolaire par ce même appel. L'API ne fait que transporter l'échange : ce qui est demandé, ce qui est divulgué et la façon dont la réponse est vérifiée restent définis par le protocole qu'elle contient. Un appel associé, navigator.credentials.create(), fait de même pour l'émission, de sorte qu'un site peut transmettre un Credential Offer à un portefeuille de la même manière.

Auparavant, une présentation sur l'appareil que le détenteur utilisait déjà passait soit par un code QR que le téléphone qui l'affichait ne pouvait pas scanner, soit par un lien profond qui devait deviner quel portefeuille était installé. Faire transiter la demande par le système d'exploitation règle ces deux problèmes : le détenteur dispose d'un seul sélecteur natif couvrant tous les portefeuilles de l'appareil, et le site n'a jamais à détecter ni à nommer lui-même un portefeuille. Le navigateur ajoute aussi l'origine appelante à la demande, ce qui permet au portefeuille d'indiquer au détenteur quel site fait la demande et de rejeter une demande copiée depuis ailleurs. C'est ce qui rend le flux résistant au phishing et aux attaques par relais.

L'API est volontairement neutre vis-à-vis des protocoles, et deux liaisons comptent dans l'écosystème EUDI Wallet : OpenID4VP définit son propre profil pour l'API, et ISO/IEC 18013-7 Annex C y rattache le même échange mdoc. L'EUDI ARF la présente comme un moyen d'améliorer la présentation à distance, à condition que le navigateur fournisse l'origine de la partie utilisatrice pour qu'une Wallet Unit puisse déterminer qui fait la demande, et qu'un flux cross-device conserve une vérification de proximité entre les deux appareils. Le device retrieval d'ISO/IEC 18013-5 reste ainsi le canal de présentation en personne, et l'API de navigateur ne le remplace pas.

La prise en charge n'est plus expérimentale. L'API est activée par défaut dans Chrome sur Android et sur ordinateur, ainsi que dans Safari sur les versions récentes d'Apple, tandis que Firefox ne l'a pas activée. Les navigateurs diffèrent encore quant aux protocoles et formats d'attestation qu'ils acceptent, et sur ordinateur, le fonctionnement repose généralement sur l'appairage avec un téléphone qui contient le portefeuille, et non sur le stockage d'attestations dans le navigateur. Considérez-la comme une amélioration pour les navigateurs et appareils qui la prennent en charge, et conservez le flux par code QR ou par redirection pour les autres.