May 4, 2021

Document technique – Partie 4

5 MIN READ – TEAM XSL LABS

Document technique – Partie 4

“I am not one and simple, but complex and many.”

“Verifiable Request” 

Nous avons vu à la fin du billet précédent comment un fournisseur de service pouvait demander à un utilisateur de fournir un Verifiable Credential en présentant plusieurs informations comme un nom de domaine, le type de Credential demandé et un “challenge”. Ces informations sont présentées à l’utilisateur via l’interface de son portefeuille d’identité pour prendre la décision de fournir (ou non) un Verifiable Credential en ayant connaissance du contexte de la demande. C’est déjà une première étape satisfaisante et peu complexe mais il est possible d’aller plus loin si le demandeur de Verifiable Credential fait partie de l’écosystème et possède déjà lui aussi sa propre identité décentralisée.

La requête initiale peut alors être enrichie :
– d’une référence au DID du demandeur
– d’une date
– d’une référence de contexte (ex : un texte) choisie par le demandeur, présentée à l’utilisateur
– d’une signature de cette requête.

Illustration 4-1 : Les liens possibles intégrables dans la requête d’un VC 
Illustration 4-1 : Les liens possibles intégrables dans la requête d’un VC 

Il devient alors possible pour l’utilisateur de vérifier l’identité du demandeur à travers cette authentification devenue mutuelle.
Cette signature possible de la requête peut apporter d’autres avantages qu’une simple identification du demandeur et il devient alors possible :
– de vérifier la légitimité (voir la légalité) d’une telle requête en fonction de cette identité.
– d’associer cette requête à un contrat de conditions d’utilisation via la référence de contexte (ce contrat peut aussi contenir des références à des contreparties offertes)
– de prouver qu’une telle requête a existé (à une date signée par le demandeur et vérifiée par l’utilisateur du portefeuille).

Sans entrer ici dans les détails, ce cadre “signé” d’utilisations contractualisées des demandes de Verifiable Credentials permet si besoin à l’utilisateur de vérifier d’éventuelles récompenses liées à la fourniture de ces Verifiable Credentials, voire même de les réclamer si nécessaire.

Requête et fourniture de VC entre applications

Une application tierce peut appeler l’application portefeuille d’identité pour effectuer une requête locale. L’application tierce envoie donc une requête (en la liant ou pas à sa propre identité décentralisée) pour demander par exemple un Verifiable Credential prouvant que l’utilisateur de One est majeur (VC “+de 21 ans”).

Illustration 4-2 : Une application tierce demande un Verifiable Credential via un appel local au wallet

Illustration 4-2 : Une application tierce demande un Verifiable Credential via un appel local au wallet

Le wallet peut renvoyer le VC sous la forme d’une Verifiable Presentation, directement à l’application qui fait la requête ou à un service web passé en paramètre.

Requête et fourniture de VC depuis un site web

Un service web peut effectuer une demande de Verifiable Credential à l’application portefeuille d’identité en présentant sa requête sous la forme d’un QR Code affiché sur son propre site web ou en passant par un serveur intermédiaire qui effectue cet affichage à sa place (ou qui pousse la requête si le wallet est déjà à l’écoute de ce serveur intermédiaire).

Le wallet traite la demande faite via le QR code et renvoie le Verifiable Credential sous la forme d’une Verifiable Presentation, directement au site web demandeur au via un serveur intermédiaire.

Illustration 4-3 : Un service web demande un Verifiable Credential via un QR Code et/ou un serveur intermédiaire

Illustration 4-3 : Un service web demande un Verifiable Credential via un QR Code et/ou un serveur intermédiaire

Anonymous Credential & Identité multiples 

En vue d’améliorer le respect de la vie privée, limiter le recoupement d’information par des acteurs extérieurs et permettre une “divulgation sélective” (selective disclosure) plus stricte, nous suivons des près les travaux relatifs aux Anonymous Credentials (parfois aussi appelés “AnonCred”). Certaines implémentations cryptographiques ne sont malheureusement pas forcément disponibles sur les éléments sécurisés (Secure Element) présents dans les téléphones mobiles. Nous partagerons le résultat de nos recherches dans de futurs articles.

Il est aussi possible de limiter les mises en relation non souhaitées entre différents attributs d’identités en créant différentes sous-identités dont certaines ne sont disponibles que sous une forme “pseudonyme”.

Une partie de l’étude de ces méthodes et d’autres, parfois non-excluantes, sera confiée à un laboratoire de recherche qualifié.

Un Wallet actif qui connaît l’identité de son porteur (les prémices de Cortex)

On évoque souvent l’identité décentralisée comme un moyen d’empêcher ou du moins limiter la dispersion de ses informations personnelles et il est en effet souhaitable pour l’utilisateur de ne pas voir son profil complet échapper à son contrôle. Pour autant, il existe des situations où l’utilisateur pourrait considérer qu’il est dans son intérêt de fournir quelques informations aux fabricants de contenus ou aux outils de campagnes publicitaires ciblées.

Il n’est pas forcément évident de poser une juste limite au consentement du partage d’informations personnelles, même partielles. Il est également absurde pour l’utilisateur de partager une information dans la première étape du contact commercial que constitue l’affichage d’une publicité si une fois qu’il y est exposé l’utilisateur n’y trouve aucun intérêt.

Il est toutefois possible de renverser la situation si c’est le wallet (ou un navigateur / une autre application connectée à ce wallet) qui connaît localement les attributs de son utilisateur et qui va chercher sur un espace non traçable le message publicitaire qui le concerne le mieux.

Comme les acteurs du secteur publicitaires sont attachés à mesurer le succès du ciblage de ces publicités, il est quand même possible d’avoir un retour statistique indirect sur ces affichages ciblés, sur la réussite des engagements qui suivent, sans pour autant trahir la volonté de respecter la vie privée des personnes qui acceptent d’être “ciblés”.

Pour éviter le recoupement d’informations indirectes, les campagnes ciblées ne seront toutefois réalisées qu’auprès des personnes correspondant aux filtres souhaités. D’autres contre-mesures sont aussi possibles pour conserver une exposition qui brouille les pistes des techniques habituelles de tracking.

Ce type de canal de communication isolé et renversé permet a priori de recevoir des messages ciblés sans pour autant dévoiler des informations inutiles dans cette première étape.

Illustration 4-4 : Un canal de communication publicitaire limitant le tracking et le partage de données personnelles

Illustration 4-4 : Un canal de communication publicitaire limitant le tracking et le partage de données personnelles

La seconde étape qui consiste en une prise de contact consentie plus rapproché pour une prise d’informations pourrait elle aussi préserver les informations personnelles à l’avenir avec la mise en place de messagerie / chat / chatbot sans utilisation de cookies, prise d’adresse IP, etc.

Il est même possible à l’avenir que les informations les plus sensibles comme les adresses personnelles pour les livraisons physiques ne soient pas condamnées à être partagées inutilement comme le permettent maintenant en partie les livraisons en magasins, relais-colis, lockers/consignes, centres de retrait, etc.

Punir et récompenser les “publicités” via des avis vérifiés et une réputation fiabilisée

Pour peu que vous soyez habitués aux réseaux sociaux ne faisant jamais le ménage par eux-mêmes (comme facebook ou YouTube), vous avez certainement déjà soupiré devant l’invraisemblable multiplication des publicités pour des escroqueries notoires (vendeurs de produits de mauvaise qualité, formations sectaires, faux air-drop de Vitalik, etc.).

Ces nouveaux canaux de communication avec des identités fiabilisées mais préservées, rendent possible de faire davantage confiance aux refus et aux alertes rapportées par les utilisateurs exposés à ces campagnes frauduleuses.

Cette notion même d’avis vérifiés dépasse le simple cadre de l’exposition à une campagne publicitaire et peut intervenir bien plus tard dans la relation client (après-vente). Il existe bien d’autres moments et situations où le wallet peut changer le rapport de confiance entre la population ciblée dont il fait partie et la campagne publicitaire mais aussi entre la population d’acheteurs vérifiés dont est amené à faire partie et son vendeur. Le canal de communication peut être entretenu, et pour une fois, au bénéfice des deux parties.

Copyright © 2020 XSL Labs – All rights reserved