Brevet FR3072802A1 — publié le 20190426

Vérification d'identité préservant la confidentialité Le commerce électronique et d'autres activités sur internet impliquent souvent une partie vérifiant l'identité d'une autre partie. La vérification peut être réalisée de différentes façons. Dans un exemple, une autorité de certification Internet ou une autorité de certification peut émettre un certificat numérique qui contient des informations de justificatif d'identité pour aider une personne ou un commerce pour des transactions en ligne. Cependant, ce type d'approche peut avoir besoin des différentes parties pour réaliser des opérations cryptographiques avancées. Cela peut aussi nécessiter le stockage des informations sensibles allant au-delà de ce qui est normalement requis pour le travail quotidien, ou autrement cela implique des frais généraux supplémentaires des ressources ou de gestion qui sont inefficaces ou fastidieux. Ainsi, ce type d'approche peut ne pas être réalisable pour certaines parties, qu'elles soient des particuliers, des petits commerces ou d'autres entités. Les techniques de vérification d'identité décrites dans la présente invention sont simples à mettre en oeuvre tout en préservant la vie privée d'une partie (une entité demandeuse) qui souhaite s'identifier à une autre partie (une entité d'authentification). L'approche générale se base sur les facteurs suivants. Premièrement, un intermédiaire (un fournisseur de confiance) peut déjà identifier l'entité demandeuse (telle qu'une personne ou un commerce), par exemple, selon une relation préexistante. Deuxièmement, le fournisseur de confiance ne peut pas partager les données lisibles à propos de l'entité demandeuse avec l'entité d'authentification. Ces dernières peuvent être des accords contractuels ou légaux qui empêchent un tel partage d'informations. Et troisièmement, le fournisseur de confiance devrait réaliser le moins de travail possible 2 pour assister au processus de vérification. Cela peut inclure de garder un tableur ou de calculer des calculs de base, mais cela n'inclut pas de calculer des signatures numériques ou de stocker des informations très sensibles à propos des affaires. 5 Les aspects de la technologie décrits ci-dessous permettent au fournisseur de confiance d'utiliser leurs informations spécifiques à propos d'une entité demandeuse pour permettre une identification ou une authentification instantanée de cette entité demandeuse avec une entité d'authentification particulière. Le fournisseur de confiance peut 10 être un fournisseur de services inter-entreprises (B2B) tel qu'une banque ou une entreprise de télécommunication. Les informations spécifiques du fournisseur de confiance à propos d'une personne, d'un négociant, d'un commerce donné ou d'une autre entité demandeuse peuvent inclure son adresse, son point de contact et d'autres données 15 d'identification qui dépendent des transactions normales avec ce commerce. Ces informations sont hachées de manière particulière visant à les partager avec une entité donnée d'authentification. L'entité d'authentification génère un jeton sécurisé sur base des informations hachées qu'utilise le fournisseur de confiance pour créer un lien de 20 vérification. L'entité demandeuse est alors capable d'utiliser le lien de vérification, qui met à disposition une identification instantanée de l'entité demandeuse par l'entité d'authentification. Selon les aspects de la technologie, un procédé inclut le traitement, par un ou plusieurs dispositifs de processeur, d'un message 25 en texte clair à l'aide d'une fonction de hachage pour générer une valeur de hachage du message en texte clair. Le message en texte clair inclut des informations de contact à propos d'une entité demandeuse. Le procédé inclut également l'envoi, par une unité de communication, de la valeur générée de hachage à un deuxième dispositif externe d'une 30 entité d'authentification, et la réception, par l'unité de communication, d'un jeton sécurisé depuis le deuxième dispositif externe de l'entité d'authentification en réponse à l'envoi de la valeur générée de hachage. Le procédé inclut en outre la création, par l'un ou plusieurs dispositifs de traitement et en réponse à la réception du jeton sécurisé 3 depuis le deuxième dispositif externe de l'entité d'authentification, d'une indication de vérification sur base du jeton sécurisé et du message en texte clair. Le procédé inclut également l'envoi, par l'unité de communication, de l'indication de vérification au premier dispositif 5 externe de l'entité demandeuse. Dans un exemple, le processus est réalisé en réponse à la réception du message en texte clair à partir d'un premier dispositif externe d'une entité demandeuse, le message en texte clair comprenant les informations de contact de l'entité demandeuse. Dans un autre 10 exemple, le message en texte clair comprend les informations de contact qui incluent une adresse physique d'un commerce ou d'une personne associée à l'entité demandeuse. Dans un exemple supplémentaire, le message en texte clair comprend une notification d'objet javascript (JSON) d'identité des informations de contact. 15 Dans un autre exemple, le procédé inclut en outre l'ajout d'un élément SALT au message en texte clair et le traitement du message en texte clair avec l'élément SALT prédéfini en utilisant la fonction de hachage. Ici, l'envoi de l'indication de vérification au premier dispositif externe de l'entité demandeuse comprend l'envoi d'une URL 20 de vérification incorporant le jeton sécurisé et l'information du message en texte clair au premier dispositif externe. Selon les autres aspects de la technologie, un dispositif est fourni et comprend une unité de communication et un ou plusieurs processeurs. L'un ou plusieurs processeurs sont configurés pour la 25 récupération, dans la mémoire, d'un message en texte clair contenant des informations d'une entité demandeuse, le traitement du message en texte clair à l'aide d'une fonction de hachage pour générer une valeur de hachage du message en texte clair et la création d'une indication de vérification sur base du message en texte clair et d'un jeton sécurisé 30 reçu d'un deuxième dispositif externe d'une entité d'authentification. Le message en texte clair inclut des informations de contact à propos de l'entité demandeuse. L'unité de communication est en outre configurée pour envoyer l'indication de vérification à un premier dispositif externe de l'entité demandeuse en réponse à la réception du 4 jeton sécurisé depuis le deuxième dispositif externe de l'entité d'authentification. Dans un exemple, le message en texte clair comprend les informations de contact de l'entité demandeuse. Dans un autre 5 exemple, le message en texte clair comprend les informations de contact incluant une adresse physique d'un commerce ou d'une personne associée a l'entité demandeuse. Dans un exemple supplémentaire, le message en texte clair comprend une notification d'objet javascript (JSON) d'identité des informations de contact. 10 Dans un autre exemple, l'un ou plusieurs processeurs sont en outre configurés pour l'ajout d'un élément SALT au message en texte clair et pour le traitement du message en texte clair avec l'élément SALT prédéfini en utilisant la fonction de hachage. Ici, le dispositif peut envoyer l'indication de vérification au premier dispositif externe 15 de l'entité demandeuse en envoyant une URL de vérification qui incorpore le jeton sécurisé et l'information du message en texte clair au premier dispositif externe. Selon les aspects additionnels de la technologie, l'invention concerne un procédé. Le procédé inclut, en réponse à la réception 20 d'une valeur de hachage à partir d'un dispositif informatique d'un fournisseur de confiance, le stockage de la valeur de hachage dans la mémoire. La valeur de hachage correspond à des informations en texte clair associées à une entité demandeuse. Les informations en texte clair incluent des informations de contact à propos de l'entité 25 demandeuse. Le procédé inclut également la génération, par un ou plusieurs dispositifs de processeur, d'un jeton sécurisé associé à un emplacement de stockage de la valeur de hachage. En réponse à la réception d'un message de vérification à partir d'un premier dispositif externe de l'entité demandeuse, le procédé inclut le traitement, par 30 l'un ou plusieurs dispositifs de processeur, du message de vérification à l'aide d'une fonction de hachage pour générer une valeur de hachage, la récupération de la valeur de hachage stockée dans la mémoire, la comparaison d'une valeur générée de hachage avec la valeur de hachage extraite à partir de la mémoire et la comparaison du jeton 5 sécurisé généré avec les informations du jeton dans le message de vérification, en vue de vérifier une identité de l'entité demandeuse. Dans un exemple, la génération du jeton sécurisé associé à l'emplacement de stockage comprend la génération d'une chaîne de 5 jetons aléatoires et l'enregistrement d'une association entre la chaîne de jetons aléatoires et l'emplacement de stockage. Dans un autre exemple, une longueur de la chaîne de jetons aléatoires est d'au moins 16 bits. Dans un exemple supplémentaire, le procédé inclut en outre le stockage du jeton sécurisé dans une base de données et l'association 10 du jeton sécurisé avec la valeur stockée de hachage. Dans encore un autre exemple, le procédé inclut en outre l'un ou plusieurs dispositifs de processeur pré-remplissant un modèle d'inscription avec des détails du compte de l'entité demandeuse. Ici, les détails du compte peuvent être reçus via un paramètre de chaîne de requête d'identification 15 associé à l'entité demandeuse. Et selon les autres aspects de la technologie, un dispositif qui est fourni inclut une unité de communication et un ou plusieurs processeurs configurés pour réaliser les opérations sélectionnées. En particulier, en réponse à la réception d'une valeur de hachage à partir 20 d'un dispositif informatique d'un fournisseur de confiance, l'un ou plusieurs processeurs sont configurés pour le stockage de la valeur de hachage dans la mémoire. La valeur de hachage correspond à des informations en texte clair associées à une entité demandeuse. Les informations en texte clair incluent des informations de contact à 25 propos de l'entité demandeuse. L'un ou plusieurs processeurs sont aussi configurés pour la génération d'un jeton sécurisé associé à un emplacement de stockage de la valeur de hachage. En réponse à la réception d'un message de vérification à partir d'un premier dispositif externe de l'entité demandeuse, l'un ou plusieurs processeurs sont 30 configurés pour le traitement du message de vérification à l'aide d'une fonction de hachage pour générer une valeur de hachage, la récupération de la valeur de hachage stockée dans la mémoire, la comparaison d'une valeur générée de hachage avec la valeur de hachage extraite à partir de la mémoire et la comparaison du jeton 6 sécurisé généré avec les informations du jeton dans le message de vérification, en vue de vérifier une identité de l'entité demandeuse. Dans un exemple, le jeton sécurisé associé à l'emplacement de stockage est créé en générant une chaîne de jetons aléatoires et 5 l'enregistrement d'une association entre la chaîne de jetons aléatoires et l'emplacement de stockage. Dans ce cas-ci, une longueur de la chaîne de jetons aléatoires peut être au moins de 16 bits. Dans un autre exemple, l'un ou plusieurs processeurs sont en outre configurés pour stocker le jeton sécurisé dans une base de données et pour 10 associer le jeton sécurisé avec la valeur stockée de hachage. Dans un exemple supplémentaire, l'un ou plusieurs processeurs sont aussi configurés pour le pré-remplissage d'un modèle d'inscription avec des détails du compte de l'entité demandeuse. Dans cette situation, les détails du compte peuvent être reçus via un paramètre de chaîne de 15 requête d'identification associé à l'entité demandeuse. Un ensemble de figures accompagnant cette description illustrent diverses caractéristiques et différents aspects de la technologie. Sur ces figures, les mêmes numéros de référence se réfèrent aux mêmes éléments. Une brève discussion de chaque figure 20 est fournie ci-dessous. La figure 1 montre un exemple de procédé selon les aspects de l'invention. La figure 2A un exemple de disposition du fournisseur de confiance selon les aspects de l'invention. 25 La figure 2B est un exemple de disposition d'entité d'authentification selon les aspects de l'invention. La figure 3 montre un exemple de réseau selon les aspects de l'invention. La figure 4 montre un exemple de procédé de requête selon les 30 aspects de l'invention. La figure 5 montre un exemple de procédé de vérification selon les aspects de l'invention. La description suivante se base sur des modes de réalisation des revendications et ne devrait pas être interprétée comme une 7 restriction aux revendications par rapport à des modes de réalisation alternatifs qui ne sont pas décrits explicitement dans la présente invention. Le protocole d'authentification discuté dans la présente 5 invention inclut une interaction entre une entité demandeuse, un fournisseur de confiance et une entité d'authentification. L'entité demandeuse dépend du fournisseur de confiance pour effectivement se porter garant de l'entité demandeuse avec l'entité d'authentification, mais sans partager directement avec l'entité d'authentification des 10 informations confidentielles ou d'autres informations personnelles de l'entité demandeuse. Cette approche ne nécessite aucune entité pour réaliser des opérations cryptographiques avancées ou pour stocker des informations sensibles allant au-delà de ce qui est normalement requis pour le travail quotidien. Les frais généraux des ressources ou de 15 gestion sont ainsi maintenus à un minimum, par exemple via un tableur ou une base de données simplifiée. Cela peut être attractif aux yeux des particuliers, des petits commerces et d'autres entités demandeuses, ainsi qu'aux fournisseurs de confiance qui sont liés aux entités délivrant l'autorisation. 20 Un exemple du protocole d'authentification est illustré à la figure 1. Ici, comme exposé plus en détails ci-dessous, un flux du procédé est présenté allant d'une entité demandeuse à un fournisseur de confiance à une entité d'authentification et puis de nouveau au fournisseur de confiance et à l'entité demandeuse. À un niveau élevé, 25 le protocole permet au fournisseur de confiance de générer des codes de vérification - de préférence des URL de vérification - sans partager les données confidentielles de l'entité demandeuse avec l'entité d'authentification. Par exemple, le protocole implique le fournisseur de confiance de mettre en oeuvre certaines tâches et une 30 interaction avec l'entité d'authentification et d'être ainsi capable de livrer l'URL de vérification directement à l'entité demandeuse. Lorsque quelqu'un se trouvant à l'entité demandeuse reçoit l'URL et clique sur celle-ci, il y a une vérification automatique avec l'entité d'authentification. L'entité d'authentification prend ainsi connaissance 8 de l'existence de l'entité demandeuse au moment où l'entité demandeuse active le lien, pas avant. En particulier, tel qu'illustré à la figure 1, l'entité demandeuse fournit initialement certaines informations (« informations d'entité ») 5 au fournisseur de confiance. Cela peut être réalisé via un déroulement normal d'affaires avec ce fournisseur de confiance. Par exemple, une personne ou un commerce peut ouvrir un compte dans une institution bancaire ou un service mis en place avec un fournisseur de télécommunications. Les informations d'entité seraient, par exemple, 10 un nom et une adresse ou d'autres informations de contact à propos de l'entité demandeuse. Les informations d'entité sont stockées par le fournisseur de confiance comme des informations d'identité sous un enregistrement d'identité. À titre d'exemple, les détails de l'entité demandeuse 15 (« informations d'entité ») stockés par le fournisseur de confiance peuvent être désignés comme une identité de l'entité demandeuse. L'identité peut inclure typiquement le nom d'un point de contact (par exemple, le chef d'entreprise) et une adresse physique d'une rue associés au commerce ou à une autre entité demandeuse. Les 20 informations d'identité peuvent être stockées par le fournisseur de confiance, par exemple, comme faisant partie d'un tableur ou d'un enregistrement dans une base de données de la gestion de la relation client (GRC). Les informations d'identité peuvent être agencées comme un message en texte clair (« enregistrement d'identité ») dans 25 le format de notation d'objet JavaScript (JSON). À un certain point, l'entité demandeuse peut faire la demande au fournisseur de confiance de se porter garant pour cette entité avec une entité d'authentification. Cela peut être fait, par exemple, de telle sorte que l'entité demandeuse peut accéder aux services offerts par 30 l'entité d'authentification. Le fournisseur de confiance crée et partage un hachage sécurisé (hachage de message) des détails de l'entité demandeuse (enregistrement d'identité) avec l'entité d'authentification. En particulier, le hachage de message est envoyé à l'entité d'authentification par le fournisseur de confiance. L'entité 9 d'authentification génère un jeton sécurisé qui est renvoyé au fournisseur de confiance et sert d'accusé de réception de message pour le hachage de message fourni. Le hachage de message et le jeton sécurisé sont stockés par l'entité d'authentification pour une 5 vérification ultérieure de l'entité demandeuse concernée. Une fois que le fournisseur de confiance reçoit l'accusé de réception, le jeton sécurisé est utilisé pour créer un lien de vérification. Par exemple, une URL de vérification est créée au niveau du fournisseur de confiance pour l'entité demandeuse pour s'inscrire 10 directement avec l'entité d'authentification. L'URL se crée sur base, à la fois, du jeton sécurisé reçu de l'entité d'authentification et de l'enregistrement d'identité stockés par le fournisseur de confiance. L'URL de vérification est ensuite envoyée à l'entité demandeuse. Tel qu'illustré à la figure 1, lorsque l'entité demandeuse 15 désire s'inscrire ou sinon s'enregistrer avec l'entité d'authentification, l'URL de vérification est cliquée ou sinon activée. Cela permet l'ouverture d'une connexion au site web de l'entité d'authentification. À ce niveau, l'entité d'authentification détecte si les données qu'elle reçoit de l'entité demandeuse hachent la même valeur fournie par le 20 fournisseur de confiance et stockée dans la mémoire par l'entité d'authentification. En supposant que les informations soient correctes, l'entité demandeuse est instantanément validée avec l'entité d'authentification. La figure 2A montre un exemple de configuration d'un 25 fournisseur de confiance 200 qui peut être employé avec le protocole d'authentification décrit dans la présente invention. Tel qu'il est illustré, la configuration 200 inclut un module de traitement 202 ayant un ou plusieurs processeurs informatiques tels qu'une unité centrale de traitement 204 et/ou des processeurs graphiques 206, ainsi qu'un 30 module de mémoire 208 configurés pour stocker des instructions 210 et des données 212. Une base de données 214 peut ou ne peut pas être séparée du module de mémoire 208. Les processeurs peuvent ou ne peuvent pas fonctionner en parallèle, et peuvent inclure des ASIC, des contrôleurs et d'autres types de circuit matériel. Les processeurs sont 10 configurés pour recevoir des informations d'un utilisateur à travers le module d'interface utilisateur 216 et pour présenter des informations à l'utilisateur sur un dispositif d'affichage du module d'affichage 218 présentant une interface d'affichage. 5 Le module d'interface utilisateur 216 peut recevoir des commandes d'un utilisateur via des entrées utilisateur et les convertir en présentation à un processeur donné. Les entrées utilisateur peuvent inclure un ou plusieurs parmi un écran tactile, un clavier, une souris, un stylet, un microphone ou d'autres types de dispositifs d'entrée. Le 10 module d'affichage 218 peut comprendre un circuit approprié pour commander le dispositif d'affichage pour présenter des informations graphiques et d'autres informations à l'utilisateur. À titre d'exemple, les informations graphiques peuvent être générées par le(s) processeur(s) graphique(s) 206, tandis que le CPU 204 dirige le 15 fonctionnement général de la configuration d'un fournisseur de confiance 200. Le module de mémoire 208 peut être mis en oeuvre sous la forme d'un ou de plusieurs parmi un support ou des supports lisible(s) par ordinateur, une ou des unité(s) de mémoire volatile ou une ou des 20 unité(s) de mémoire non volatile. Le module de mémoire 208 peut inclure, par exemple, une mémoire flash et/ou une NVRAM et peut être réalisé par un disque dur ou une carte mémoire. Autrement, le module de mémoire 208 peut également inclure un DVD, un CD-ROM et des mémoires en lecture seule et capables d'écriture. Dans un mode 25 de réalisation, un produit de programme informatique est concrètement matérialisé dans un support d'information. Le produit de programme informatique contient des instructions, telles que les instructions 210 qui, lorsqu'elles sont exécutées par un ou plusieurs processeurs, réalisent un ou plusieurs procédés tels que ceux décrits dans la 30 présente invention. Le support d'information est un support lisible par un ordinateur ou par une machine, tel que le module de mémoire 208. Bien que la figure 2A montre de manière fonctionnelle le(s) processeur(s), le module de mémoire, et d'autres éléments du dispositif 200 comme étant à l'intérieur du même bloc global, de tels 11 composants peuvent ou ne peuvent pas être stockés dans le même boîtier physique. Par exemple, certaines ou toutes les instructions et données peuvent être stockées sur un support d'information qui est un support de stockage démontable (par exemple, un lecteur optique ou 5 un lecteur USB) et d'autres sont stockées dans une puce informatique à lecture seule. Autrement, la base de données 214 peut stocker des enregistrements d'identité dans une configuration physiquement séparée du reste de la disposition du fournisseur de confiance 200. Les données 212 peuvent être récupérées, stockées ou 10 modifiées par les processeurs conformément aux instructions 210. Par exemple, bien que l'objet revendiqué ne soit pas limité à une quelconque structure de données particulière, les données peuvent être stockées dans des registres de dispositifs informatiques, dans une base de données relationnelle sous la forme d'une table ayant une pluralité 15 de différents champs et enregistrements, des documents XML ou dans des fichiers plats. Les données 212 peuvent aussi être formatées dans un quelconque format lisible par un dispositif informatique. Les instructions 210 peuvent être n'importe quel ensemble d'instructions devant être exécutées directement (telles qu'un code 20 machine) ou indirectement (telles que des scripts) par le(s) processeur(s). Par exemple, les instructions peuvent être stockées comme code de dispositif informatique sur le support lisible par un dispositif informatique. À cet égard, les termes « instructions » et « programmes » peuvent être utilisés ici de manière interchangeable. 25 Les instructions peuvent être stockées sous format de code objet pour un traitement direct par le(s) processeur(s), ou dans tout autre langage de dispositif informatique, y compris des scripts ou des collections de modules de code source indépendants qui sont interprétés sur demande ou compilés d'avance. Les fonctions, procédés et routines des 30 instructions sont expliqués d'une manière plus détaillée ci-dessous. Tel qu'il est également montré à la figure 2A, la configuration d'un fournisseur de confiance 200 inclut un module de communication 220 pour la communication avec d'autres dispositifs et systèmes, y compris des entités demandeuses et une ou plusieurs entités délivrant 12 l'autorisation. Le module de communication 220 inclut un émetteur-récepteur sans fil ; Autrement, le module peut inclure un émetteur-récepteur doté d'un câble, ou les deux. La configuration d'un fournisseur de confiance 200 peut communiquer avec d'autres 5 dispositifs à distance via le module de communication 220 à l'aide de divers protocoles et de différentes configurations, incluant un protocole de communication à courte portée tel qu'une communication en champ proche, BluetoothTM, BluetoothTM de faible énergie (LE), ou d'autres réseaux ad-hoc, l'Internet, l'intranets, des réseaux privés 10 virtuels, des réseaux à zone étendue, des réseaux locaux, des réseaux privés à l'aide de protocoles de communication de marque déposée d'une ou de plusieurs entreprises, d'Ethernet, de WiFi et d'HTTP, et des combinaisons des éléments précédents. De plus, la configuration d'un fournisseur de confiance 200 tel qu'il est illustré inclut un module 15 de puissance 222. Dans un exemple, le fournisseur de confiance applique une fonction de hachage sécurisé pour hacher les informations d'identité de l'entité demandeuse. Comme indiqué plus haut, l'enregistrement d'identité peut être sous format de notation d'objet JavaScript (JSON). 20 Par exemple, le fournisseur de confiance peut « ficeler » la JSON d'enregistrement d'identité, par exemple, avec le codage UTF-8. Il peut alors facultativement le coder en base 64. Ces données peuvent être alors fournies à la fonction de hachage, par exemple, une fonction de hachage SHA-256. Le résultat du procédé de hachage est un 25 hachage de message. Le hachage de message est une représentation spécifique des données mais ne sont pas les données en elles-mêmes. Pour plus de sécurité du fournisseur de confiance contre la réingénierie du hachage, les données aléatoires (« salt ») peuvent être ajoutées à la JSON d'enregistrement d'identité avant l'exécution du 30 procédé de hachage. Uniquement à titre d'exemple, le salt peut inclure un ou plusieurs octets de données aléatoires. Le fournisseur de confiance peut alors partager le hachage de message avec l'entité d'authentification via une requête POST du HTTP ou une autre transmission. 13 Un exemple de configuration d'entité d'authentification 250 est illustré à la figure 2B. Cette configuration est similaire à la configuration d'un fournisseur de confiance 200. Par exemple, la configuration 250 inclut un module de traitement 252 ayant un ou 5 plusieurs processeurs informatiques tels qu'une unité centrale de traitement 254 et/ou des processeurs graphiques 256, ainsi qu'un module de mémoire 258 configuré pour stocker des instructions 260 et des données 262. Une base de données 264 peut ou ne peut pas être séparée du module de mémoire 208. Cette base de données est agencée 10 afin de stocker les hachages de messages reçus et les jetons sécurisés créés par l'entité d'authentification. Les processeurs peuvent ou ne peuvent pas fonctionner en parallèle et peuvent inclure des ASIC, des contrôleurs et d'autres types de circuit matériel. Les processeurs sont configurés pour recevoir des 15 informations d'un utilisateur à travers le module d'interface utilisateur 266 et pour présenter des informations à l'utilisateur sur un dispositif d'affichage du module d'affichage 268 présentant une interface d'affichage. Les processeurs, le module de mémoire, le module d'interface utilisateur et le module d'affichage fonctionnent de la 20 même manière que celle décrite plus haut pour la configuration d'un fournisseur de confiance 200. Et de manière similaire à la base de données 214, la base de données 264 peut stocker des hachages de messages et les jetons sécurisés dans une configuration physiquement séparée du reste de la configuration d'entité d'authentification 250. 25 Tel qu'il est également montré à la figure 2B, la configuration d'entité d'authentification 250 inclut un module de communication 270 pour la communication avec d'autres dispositifs et systèmes, y compris des entités demandeuses et un ou plusieurs fournisseurs de confiance. Le module de communication 270 peut avoir une configuration 30 équivalente à celle décrite pour le module de communication 220. De plus, la configuration d'entité d'authentification 250 comme il est montré inclut un module de puissance 272. Lors de la réception du hachage de message, l'entité d'authentification réalise diverses choses. Premièrement, elle peut 14 valider que le fournisseur de confiance est lui-même autorisé de se porter garant pour l'entité demandeuse. Si la validation échoue, le procédé devra s'arrêter et l'entité demandeuse devra utiliser un procédé de vérification plus formel et direct avec l'entité demandeuse. 5 En supposant que la validation du fournisseur de confiance est réussie, l'entité d'authentification crée le jeton sécurisé afin de servir comme récepteur du hachage de message. Le jeton sécurisé ne devrait pas avoir de lien avec le hachage de message reçu. Par exemple, le jeton sécurisé peut être un nonce aléatoire (par exemple, 16 octets ou 10 davantage). L'entité d'authentification stocke le hachage de message et le jeton sécurisé dans la base de données 264 et renvoie une copie du jeton sécurisé au fournisseur de confiance. Ainsi, on peut constater que le fournisseur de confiance ne fournit pas une version de texte clair de la JSON d'enregistrement d'identité à l'entité 15 d'authentification et l'entité d'authentification ne peut pas réaliser l'ingénierie inverse des informations d'identité de l'entité demandeuse. À ce niveau, une fois que le fournisseur de confiance a le jeton sécurisé, le fournisseur de confiance peut partager efficacement l'enregistrement d'identité et le jeton sécurisé avec l'entité 20 demandeuse. Cela peut être réalisé, par exemple, par le fournisseur de confiance en générant une URL de vérification pour l'entité demandeuse sur base de l'enregistrement d'identité et du jeton sécurisé reçu. Dans un exemple, l'URL de vérification incorpore la version ficelée de l'enregistrement d'identité et du jeton sécurisé, avec un 25 pointeur indiquant le site web de l'entité d'authentification. Le fournisseur de confiance peut stocker le jeton sécurisé reçu dans la base de données 214, par exemple en liaison ou séparément avec l'enregistrement d'identité associé. Autrement, le fournisseur de confiance peut ne pas stocker le jeton sécurisé reçu une fois que l'URL 30 de vérification ait été générée. Une fois cette génération réalisée, l'URL de vérification est envoyée à l'entité demandeuse directement à partir du fournisseur de confiance. Cela, à son tour, permet à la personne ou à un utilisateur au niveau de l'entité demandeuse de cliquer sur le lien ou autrement de 15 débuter la vérification. Lorsque l'URL de vérification est activée, le navigateur internet de l'entité demandeuse est pris pour le site web de l'entité d'authentification, où l'utilisateur de l'entité demandeuse peut être automatiquement vérifié lui-même ou son commerce par l'entité 5 d'authentification. En particulier, l'entité d'authentification valide les informations reçues via l'URL de vérification selon le hachage de message reçu précédemment par l'entité d'authentification à partir du fournisseur de confiance. Lorsque l'entité demandeuse clique sur le 10 lien de l'URL de vérification, l'entité d'authentification validera la version ficelée des informations d'identité et du jeton sécurisé. Pour ces derniers, le jeton sécurisé stocké par l'entité d'authentification dans la mémoire est comparé au jeton sécurisé reçu pour confirmer une correspondance. Pour les informations d'identité, le système 15 d'entité d'authentification réalisera un procédé de hachage et comparera le résultat avec le hachage de message qui a été précédemment reçu du fournisseur de confiance. L'entité d'authentification peut pré-remplir un écran d'inscription avec les détails de la personne ou du commerce. Cette 20 inscription est possible car les détails sont codés en texte clair dans un paramètre de chaîne de requête d'identification associé aux détails de l'entité demandeuse, selon le hachage de message reçu précédemment du fournisseur de confiance. L'entité d'authentification peut également vérifier que les 25 informations d'identité correspondent à quelque chose que le fournisseur de confiance a le droit de fournir. Par exemple, il peut y avoir des restrictions géographiques ou d'autres restrictions sur lesquelles le fournisseur de confiance peut réaliser la certification. Une fois que les vérifications sont réalisées avec satisfaction, 30 l'entité d'authentification détermine que l'URL de vérification est légitime et a été générée par un fournisseur de confiance qui est autorisé par l'entité d'authentification. S'il en est ainsi, les données de l'entité demandeuse peuvent être immédiatement vérifiées. Ainsi, de cette façon, le système permet aux fournisseurs de confiance de se 16 porter garant pour les identités de leurs utilisateurs à une entité d'authentification, et pour permettre aux utilisateurs d'être vérifiés de manière instantanée par l'entité d'authentification sans avoir a échanger des informations sensibles à propos d'eux-mêmes ou de leur 5 commerce. La figure 3 montre un exemple d'agencement dans lequel les différents dispositifs d'entité demandeuse 300, par exemple, 3001, 3002, 3003 et 3004 peuvent solliciter un contenu ou d'autres informations d'un fournisseur de confiance 320 et d'une entité 10 d'authentification 340 via un système de communication 310. Les dispositifs d'entité demandeuse 300 peuvent inclure certains composants ou tous les composants discutés plus haut dans la présente invention en fonction de la configuration d'un fournisseur de confiance 200 et de la configuration d'entité d'authentification 250. 15 Les dispositifs d'entité demandeuse peuvent inclure des ordinateurs portables (3001), des tablettes (3002), des téléphones cellulaires ou des assistants personnels à fonctions (PDA) (3003) ou des PC de bureau (3004). Cependant, d'autres dispositifs d'entité demandeuse peuvent être également utilisés par une entité demandeuse telle qu'un 20 particulier, un petit commerce ou une société. De tels dispositifs d'entité demandeuse peuvent envoyer des informations à un fournisseur de confiance, recevoir des URL de vérification et solliciter une vérification d'une entité d'authentification telle qu'illustrée à la figure 1. 25 Comme il est montré, le fournisseur de confiance 320 peut se connecter à la base de données 322 via un lien 324. Le fournisseur de confiance 320 et la base de données 322 correspondent à la configuration d'un fournisseur de confiance 200 comme il a été décrit plus haut par rapport à la figure 2A. De manière similaire, l'entité 30 d'authentification peut se connecter à la base de données 342 via un lien 344. L'entité d'authentification 340 et la base de données 342 correspondent à la configuration d'entité d'authentification 250 comme il a été décrit plus haut en fonction de la figure 2B. Tandis que seulement un fournisseur de confiance 320 et seulement une entité 17 d'authentification 340 sont montrés à la figure 3, n'importe quel nombre de fournisseurs de confiance et d'entités délivrant l'autorisation peuvent y être inclus. Un scénario faisant office d'exemple du fonctionnement du 5 fournisseur de confiance est illustré en relation avec le diagramme des opérations 400 de la figure 4. Ici, dans le bloc 402, le procédé inclut des informations d'authentification de l'entité demandeuse, par exemple un nom et une adresse ou d'autres informations de contact. Celui-ci peut être réalisé en se basant sur l'interaction préexistante du 10 fournisseur de confiance avec l'entité demandeuse, par exemple en confirmant un nom de contact et une adresse postale pour lesquels des avis ont été envoyés à l'entité demandeuse. Ces informations sont stockées en tant qu'enregistrement d'identité dans le bloc 404. Cela peut être réalisé sous format JSON ou sous un autre format, en 15 fonction de la configuration de la base de données du fournisseur de confiance. Ces opérations peuvent être exécutées à un moment où l'entité demandeuse ouvre un compte ou sinon engage les services du fournisseur de confiance. Le fournisseur de confiance peut recevoir une demande de 20 l'entité demandeuse au bloc 406. Cela peut inclure une demande que le fournisseur de confiance se porte garant de l'entité demandeuse avec une entité d'authentification particulière. Ou, autrement, le fournisseur de confiance peut agir de manière prospective. En se basant sur soit une demande soit sur une action potentielle, le fournisseur de 25 confiance génère un hachage de message de l'enregistrement d'identité au bloc 408. Pour y arriver, des approches réalisées par les processeurs du fournisseur de confiance sont analysées ci-dessus. Le hachage de message est transmis à l'entité d'authentification particulière au niveau du bloc 410. Alors, en réponse à cela, le 30 fournisseur de confiance reçoit un jeton sécurisé au bloc 412. Le jeton sécurisé, tel qu'un nonce ou une autre information, fait office d'accusé de réception du hachage de message par l'entité d'authentification. Une fois le jeton sécurisé reçu, le(s) processeur(s) du fournisseur de confiance créent l'URL de vérification à l'aide du jeton 18 sécurisé et de l'enregistrement d'identité stocké au bloc 414. Cette information est ensuite transmise à l'entité demandeuse au bloc 416. À ce niveau, le fournisseur de confiance a achevé sa partie du procédé de vérification. 5 La figure 5 montre un exemple du procédé 500 pour l'opération de l'entité d'authentification. Au bloc 502, l'entité d'authentification reçoit un hachage de message d'un fournisseur de confiance. En se basant sur cela, un jeton sécurisé est généré par un ou plusieurs processeurs de l'entité d'authentification au bloc 504. Comme indiqué 10 plus haut, le jeton sécurisé peut être un nonce aléatoire. Ensuite, au bloc 506, le hachage de message reçu et le jeton sécurisé généré sont stockés dans la mémoire, par exemple dans la base de données 264 de la figure 2B (ou la base de données équivalente 342 de la figure 3). Le jeton sécurisé est transmis au fournisseur de confiance dans le bloc 15 508. Ensuite, lorsque l'entité demandeuse active (par exemple, en réalisant un clic) l'URL de vérification, l'entité d'authentification reçoit cette information de l'entité demandeuse au bloc 510. À ce niveau, les processeurs de l'entité d'authentification réalisent une opération de vérification au bloc 512. Cette opération inclut la 20 comparaison des informations de l'URL de vérification reçue avec le hachage de message stocké, ainsi que la confirmation que les informations reçues du jeton sécurisé de l'URL de vérification correspondent au jeton sécurisé stocké dans la base de données de l'entité d'authentification. Le bloc 514 analyse si la vérification est 25 réussie. S'il en est ainsi, au bloc 516, l'entité demandeuse reçoit l'autorisation d'accès de l'entité d'authentification. En fonction du type d'entité d'authentification et du type d'entité demandeuse, cela peut permettre à l'entité demandeuse de réaliser certaines opérations ou lui permettre de fournir des biens ou des services sélectionnés. Si le 30 procédé de vérification échoue, l'entité demandeuse se voit refuser l'accès au bloc 518. Les flux logique et du procédé présentés dans les figures et décrits dans la présente invention ne se limitent pas à un ordre particulier ou à une séquence particulière, sauf indication contraire. 19 De plus, d'autres étapes peuvent être fournies ou peuvent être éliminées, issues des flux décrits et d'autres composantes peuvent être ajoutées ou retirées aux systèmes décrits de ces derniers. Bien que la technologie de cette présente invention ait été 5 décrite en faisant référence à des modes de réalisations particuliers, il doit être entendu que ces modes de réalisations ont un caractère purement illustratif des principes et des applications de la présente technologie. Il est donc entendu que plusieurs modifications peuvent être réalisées aux modes de réalisations représentatifs et que d'autres 10 dispositions peuvent être conçues sans s'écarter ni de l'esprit ni de la portée de la présente technologie tel qu'il REVENDICATIONS1. Procédé comprenant : le traitement, par un ou plusieurs dispositifs de processeur, d'un message en texte clair à l'aide d'une fonction de hachage pour générer une valeur de hachage du message en texte clair, dans lequel le message en texte clair inclut des informations de contact à propos d'une entité demandeuse ; l'envoi, par une unité de communication, de la valeur générée de hachage à un deuxième dispositif externe d'une entité d'authentification ; la réception, par l'unité de communication, d'un jeton sécurisé depuis le deuxième dispositif externe de l'entité d'authentification en réponse à l'envoi de la valeur générée de hachage ; en réponse à la réception du jeton sécurisé depuis le deuxième dispositif externe de l'entité d'authentification, la création, par l'un ou plusieurs dispositifs de traitement, d'une indication de vérification sur base du jeton sécurisé et du message en texte clair ; et l'envoi, par l'unité de communication, de l'indication de vérification au premier dispositif externe de l'entité demandeuse. 2. Procédé selon la revendication 1, dans lequel le processus est réalisé en réponse à la réception du message en texte clair à partir d'un premier dispositif externe d'une entité demandeuse, le message en texte clair comprenant les informations de contact de l'entité demandeuse. 3. Procédé selon la revendication 1 ou selon la revendication 2, dans lequel le message en texte clair comprend les informations de contact qui incluent une adresse physique d'un commerce ou d'une personne associée à l'entité demandeuse. 4. Procédé selon l'une quelconque revendication précédente, dans lequel le message en texte clair comprend une notification d'objet javascript (JSON) d'identité des informations de contact. 5. Procédé selon l'une quelconque revendication précédente, dans lequel : 21 le traitement du message en texte clair comprend en outre l'ajout d'un élément SALT au message en texte clair et le traitement du message en texte clair avec l'élément SALT prédéfini en utilisant la fonction de hachage ; et 5 l'envoi de l'indication de vérification au premier dispositif externe de l'entité demandeuse comprend l'envoi d'une URL de vérification incorporant le jeton sécurisé et l'information du message en texte clair au premier dispositif externe. 6. Dispositif comprenant : 10 une unité de communication ; et un ou plusieurs processeurs configurés pour : la récupération, dans la mémoire, d'un message en texte clair contenant des informations d'une entité demandeuse ; le traitement du message en texte clair à l'aide d'une fonction 15 de hachage pour générer une valeur de hachage du message en texte clair ; et la création d'une indication de vérification sur base du message en texte clair et d'un jeton sécurisé reçus d'un deuxième dispositif externe d'une entité d'authentification ; 20 dans lequel : le message en texte clair inclut des informations de contact à propos de l'entité demandeuse ; et l'unité de communication est en outre configurée pour envoyer l'indication de vérification à un premier dispositif externe de l'entité 25 demandeuse en réponse à la réception du jeton sécurisé depuis le deuxième dispositif externe de l'entité d'authentification. 7. Dispositif selon la revendication 6, dans lequel le message en texte clair comprend les informations de contact de l'entité demandeuse. 30 8. Dispositif selon la revendication 6 ou selon la revendication 7, dans lequel le message en texte clair comprend les informations de contact incluant une adresse physique d'un commerce ou d'une personne associée à l'entité demandeuse. 22 9. Dispositif selon l'une quelconque des revendications 6 à 8, dans lequel le message en texte clair comprend une notification d'objet javascript (JSON) d'identité des informations de contact. 10. Dispositif selon l'une quelconque des revendications 6 5 à 9, dans lequel l'un ou plusieurs processeurs sont en outre configurés pour : l'ajout d'un élément SALT au message en texte clair et le traitement du message en texte clair avec l'élément SALT prédéfini en utilisant la fonction de hachage ; et 10 l'envoi de l'indication de vérification au premier dispositif externe de l'entité demandeuse en envoyant une URL de vérification incorporant le jeton sécurisé et des informations du message en texte clair au premier dispositif externe. 11. Procédé comprenant : 15 en réponse à la réception d'une valeur de hachage à partir d'un dispositif informatique d'un fournisseur de confiance : le stockage de la valeur de hachage dans la mémoire, la valeur de hachage correspondant à des informations en texte clair associées à une entité demandeuse, les informations en texte clair incluant des 20 informations de contact à propos de l'entité demandeuse, et la génération, par un ou plusieurs dispositifs de processeur, d'un jeton sécurisé associé à un emplacement de stockage de la valeur de hachage ; et en réponse à la réception d'un message de vérification à partir 25 d'un premier dispositif externe de l'entité demandeuse : le traitement, par l'un ou plusieurs dispositifs de processeur, du message de vérification à l'aide d'une fonction de hachage pour générer une valeur de hachage, la récupération de la valeur de hachage stockée dans la 30 mémoire, la comparaison d'une valeur générée de hachage avec la valeur de hachage extraite à partir de la mémoire, et 23 la comparaison du jeton sécurisé généré avec les informations du jeton dans le message de vérification, en vue de vérifier une identité de l'entité demandeuse. 12. Procédé selon la revendication 11, dans lequel la 5 génération du jeton sécurisé associé à l'emplacement de stockage comprend la génération d'une chaîne de jetons aléatoires et l'enregistrement d'une association entre la chaîne de jetons aléatoires et l'emplacement de stockage. 13. Procédé selon la revendication 12, dans lequel une 10 longueur de la chaîne de jetons aléatoires est d'au moins 16 bits. 14. Procédé selon l'une quelconque des revendications 11 à 13, comprenant en outre le stockage du jeton sécurisé dans une base de données et l'association du jeton sécurisé avec la valeur stockée de hachage. 15 15. Procédé selon l'une quelconque des revendications 11 à 14, comprenant en outre l'un ou plusieurs dispositifs de processeur pré-remplissant un modèle d'inscription avec des détails du compte de l'entité demandeuse. 16. Procédé selon la revendication 15, dans lequel les 20 détails du compte sont reçus via un paramètre de chaîne de requête d'identification associé à l'entité demandeuse. 17. Dispositif comprenant : une unité de communication ; et un ou plusieurs processeurs configurés pour : 25 en réponse à la réception d'une valeur de hachage à partir d'un dispositif informatique d'un fournisseur de confiance : le stockage de la valeur de hachage dans la mémoire, la valeur de hachage correspondant à des informations en texte clair associées à une entité demandeuse, les informations en texte clair incluant des 30 informations de contact à propos de l'entité demandeuse, et la génération d'un jeton sécurisé associé à un emplacement de stockage de la valeur de hachage ; et en réponse à la réception d'un message de vérification à partir d'un premier dispositif externe de l'entité demandeuse : 24 le traitement du message de vérification à l'aide d'une fonction de hachage pour générer une valeur de hachage, la récupération de la valeur de hachage stockée dans la mémoire, 5 la comparaison d'une valeur générée de hachage avec la valeur de hachage extraite à partir de la mémoire, et la comparaison du jeton sécurisé généré avec les informations du jeton dans le message de vérification, en vue de vérifier une identité de l'entité demandeuse. 10 18. Dispositif selon la revendication 17, dans lequel le jeton sécurisé associé à l'emplacement de stockage est créé en générant une chaîne de jetons aléatoires et l'enregistrement d'une association entre la chaîne de jetons aléatoires et l'emplacement de stockage. 15 19. Dispositif selon la revendication 18, dans lequel une longueur de la chaîne de jetons aléatoires est d'au moins 16 bits. 20. Dispositif selon l'une quelconque des revendications 17 à 19, dans lequel l'un ou plusieurs processeurs sont en outre configurés pour stocker le jeton sécurisé dans une base de données et 20 pour associer le jeton sécurisé à la valeur stockée de hachage. 21. Dispositif selon l'une quelconque des revendications 17 à 20, dans lequel l'un ou plusieurs processeurs sont en outre configurés pour pré-remplir un modèle d'inscription avec des détails du compte de l'entité demandeuse. 25 22. Dispositif selon la revendication 21, dans lequel les détails du compte sont reçus via un paramètre de chaîne de requête d'identification associé à l'entité demandeuse.