Une carte NFC pour les portefeuilles d’identités décentralisées (DID)

myDid
6 min readJan 3, 2022

--

TL;DR : Une carte NFC peut servir d’ extension à l’application mobile faisant office de portefeuille d’identité décentralisée pour permettre -entre autres choses- une reconnaissance faciale simple et décentralisée.

Les cartes NFC myDid : extensions physiques de l’application mobile (portefeuille d’identité décentralisée)

Cette semaine, deux sujets en un :
- L’introduction d’une première extension physique à notre application mobile sous la forme d’une carte NFC
- Un exemple d’utilisation de cette carte dans le cadre d’un système de reconnaissance faciale décentralisée

Une carte NFC : pourquoi et comment

Sans revenir dans le détail sur les notions d’identité décentralisée (DID) et d’identité souveraine (SSI), rappelons que l’utilisateur crée et contrôle lui même directement son/ses identité(s) et que le cœur de la sécurité de ses identités réside dans un ensemble de clés secrètes générées au sein d’une application mobile dédiée, appelée portefeuille d’identité (DID Wallet).

Outre ses clés secrètes (dont la gestion complexe est heureusement cachée à l’utilisateur), l’application portefeuille d’identité (DID Wallet) accumule des données vérifiables associées à son propriétaire. L’utilisateur peut ensuite décider de présenter ces données (plus ou moins personnelles) aux différents services et contacts qui les lui demandent.

Exemple de parcours : Un utilisateur télécharge l’application mobile, crée son identifiant DID (et le document DID associé) puis passe par un service de KYC pour obtenir une information vérifiable (Verifiable Credential) attestant qu’il a plus de 18 ans. Plus tard, à l’entrée d’une boite de nuit ou sur un service de loterie en ligne, il pourra représenter cette information vérifiable (“j’ai plus de 18 ans”). Concrètement, la page web, la machine ou l’humain souhaitant effectuer ce contrôle présente un QR code que l’utilisateur doit scanner. L’application portefeuille indiquera les informations vérifiables demandées et le contexte de cette requête (qui le demande, pourquoi, etc.) pour obtenir le consentement du partage de ces informations.

Dans les cas d’un service en ligne, les informations sont directement envoyées, après consentement, au serveur spécifié dans la requête. Dans le cas d’un contrôle effectué par un humain ou par une machine (un portique par exemple) en vis à vis, la présentation des informations vérifiables se fait généralement par l’affichage d’un QR Code que l’humain ou la machine doit pouvoir lire.

Cette technique de QR code pour présenter une information vérifiable en vis à vis comporte néanmoins quelques inconvénients :
- La quantité de données transmissible est limitée (même s’il est possible de l’augmenter en utilisant des QR Codes animés).
- Il faut que le lecteur du contrôleur / scanneur soit de bonne qualité, stable et bien positionné pour lire le QR code
- Il faut que le smartphone soit allumé et l’application ouverte pour interagir avec ce contrôleur

Même si ce n’est pas envisageable dans tous les cadres d’utilisation, la communication de ces informations vérifiables pourrait s’effectuer non pas en présentant un QR Code mais en utilisant la technologie “sans contact” NFC. Dans ce cas précis, on peut même penser que l’application mobile pourrait se servir directement des capacités NFC du smartphone de l’utilisateur.

Nous avons effectué quelques tests d’envoi direct de ces informations vérifiables en NFC sur des téléphones Android mais Apple limite encore une fois l’accès aux fonctionnalités de ses smartphones (NFC HCE / Host Card Emulation) pour les réserver à ses propres applications (ex: Apple Pay), empêchant ainsi arbitrairement son utilisation par des développeurs d’applications tierces. De nombreux acteurs privés et législateurs nationaux¹ font pression² sur Apple pour mettre fin à ce monopole abusif, pour le moment sans résultat.

Un téléphone peut donc faire office de lecteur NFC, comme le ferait une machine (distributeur de snacks, rechargement de pass Navigo, etc.) mais ne peut pas toujours être lu sur un lecteur comme s’il était une carte NFC (Host Card Emulation).

Pour contourner ce problème de compatibilité mais aussi pour réduire la contrainte de disponibilité du smartphone et de son application portefeuille, il est possible dans certains cas d’utiliser une carte NFC associée au DID initial.

Il est peu souhaitable que la puce sans contact (carte NFC) contiennent les mêmes clés que celle du wallet mobile, en effet :
- La carte doit être considérée comme une extension du DID original
- Plusieurs cartes différentes doivent pouvoir être associées au portefeuille
- Une carte perdue doit pouvoir être répudiée
- Les cartes doivent être clairement identifiables selon leurs usages
- La notion de consentement est limitée, l’utilisateur approche sa carte d’un lecteur mais ne peut être certain des infos demandées (le contrôle détaillé est meilleur via l’application mobile), il faut donc idéalement que les données présentes dans la carte soit limitées à un usage probable.

Heureusement, le propriétaire du DID peut utiliser son application mobile pour faire le lien entre une clé contenue dans la carte NFC et son DID Document (ce lien pourrait être aussi renforcé via une déclaration de service dans le DID document) comme ci-dessous :

{
"@context": "https://w3id.org/did/v1",
"id": "did:syl:SwuBV8xRoAnwWsdvktH",
"publicKey": [{
"id": "did:syl:SwuBV8xRoAnwWsdvktH#NFCTicketKey1",
"type": "EcdsaSecp256k1VerificationKey2019",
"controller": "did:syl:jSwuBV8xRoAnwWsdvktH",
"publicKeyBase58": "A1342NYF8RrR3h41TDCTJojY59usg3mbtbu"
}],
"authentication":
...

L’utilisateur peut donc acquérir une carte NFC, lui faire générer une clé qui lui sera propre puis utiliser l’application mobile pour associer la clé contenue dans cette carte à son DID en l’ajoutant à son DID Document. Evidemment, cette complexité est cachée à l’utilisateur à qui l’on demande simplement d’approcher sa nouvelle carte NFC.

Cas d’usage : Portail biométrique décentralisé

Nous n’allons pas nous attarder ici sur le détail du fonctionnement de la reconnaissance faciale. Rappelons sommairement que les caractéristiques du visage d’un usager sont extraits d’une ou plusieurs photographies au moyen d’un réseau neuronal pré-entrainé.

Les étapes de la transformation d’une photographie de visage en un ensemble d’informations caractéristiques (illustration partiellement reprise du projet OpenFace)

Seul un ensemble de caractéristiques (embeddings) est extrait et utilisé. Cet ensemble de données (qui, à l’inverse, ne permet pas de reconstituer la photo du visage de l’utilisateur) est généralement conservé sur un serveur central ou dupliqué au niveau des points de contrôle. Quand un utilisateur se présente normalement à un portique de reconnaissance faciale, le portique reconstruit à la volée l’ensemble des caractéristique liée à la personne présente devant l’appareil puis effectue une requête de comparaison avec d’autres données précédemment enregistrées.

Nous allons voir ici comment permettre d’utiliser la reconnaissance faciale sans avoir besoin d’interroger une base existante quelconque dans le cas d’un portique de reconnaissance faciale à l’entrée d’une salle de concert pour faciliter le contrôle automatique des possesseurs de billets.

Dans ce scenario, l’acheteur de billet en ligne peut demander à profiter d’un “coupe-file” à travers un portail biométrique, en utilisant son portefeuille d’identité associé à une carte NFC.

Voici le détail du parcours de l’utilisateur lors de la phase d’achat :

L’acheteur reçoit son billet et son empreinte biométrique sous la forme d’Attestations Vérifiables

À la fin de cette procédure, l’utilisateur a bien reçu deux Attestations vérifiables : son billet et son empreinte biométrique. Le serveur de la plateforme “Biom Service” qui a fourni ces informations à l’acheteur n’a même plus besoin de les conserver et peut les supprimer.

Le portique biométrique n’aura alors besoin que des clés publiques de la plateforme de vente sur les lecteurs pour pouvoir contrôler les billets et le visage des acheteurs. Voici le détail des étapes :

Contrôle des tickets et données biométriques sur le portique d’accès du concert

Quelques-uns des avantages de cette solution décentralisée :

  • Aucun stockage des données biométriques
    (ni en base de données, ni sur blockchain)
  • Aucune connexion internet nécessaire au niveau des portiques de contrôle

Nous travaillons maintenant sur les vrais démonstrateurs… mais ce ne sera probablement pas le sujet de notre prochain billet hebdomadaire.

--

--