FR3114714A1 - Procédé d’accès à un ensemble de données d’un utilisateur. - Google Patents

Abstract

L’invention concerne un procédé d’accès pour obtenir un droit d’accès (JTN) à au moins une donnée personnelle (DID) d’un propriétaire (PRO) de données identifié par un identifiant unique (IDPRO) et possédant une pluralité de données personnelles (MDID). Le procédé est mis en œuvre par une application, dite application utilisateur (APPU) s’exécutant en liaison avec un terminal (TUSR) d’un utilisateur (USR) disposant d’au moins d’un identifiant d’utilisateur (IDUSR). Le procédé est caractérisé en ce qu’il comporte les étapes suivantes : - ouverture d’un canal de communication de proximité (CP) avec un terminal du propriétaire de données ; - transmission (E2) au terminal du propriétaire dudit identifiant d’utilisateur (IDUSR) via la communication de proximité ;- obtention (E4), via la communication de proximité, d’une autorisation d’accès à ladite au moins une donnée personnelle (LDID’). Figure pour l’abrégé : 1

Description

Procédé d’accès à un ensemble de données d’un utilisateur.

Domaine de l'invention

L’invention se situe dans le domaine de l’accès aux données privées d’un utilisateur. Plus précisément, l’invention porte sur un procédé de gestion d’identité numérique et de partage de données personnelles comme des informations d’identité.

Art Antérieur

Récemment, des méthodes ont émergé pour permettre à un serveur d’application de collecter des données personnelles d’un utilisateur localisées sur un ou des serveurs de stockage dédiés de confiance, sous le contrôle de l’utilisateur propriétaire des données. Ces protocoles respectent, pour les plus usuels, la législation en cours, dont le RGPD, règlement adopté au niveau européen. Lors de la demande d’accès aux données personnelles, l’utilisateur propriétaire accepte l’accès à tout ou partie de ses données, après identification ou authentification auprès d’un serveur de gestion d’identité. En retour, le serveur d’application peut accéder, à l’aide d’un jeton d’accès émis par le serveur de gestion d’identité, au serveur de stockage des données personnelles, pour obtenir les informations demandées et acceptées par l’utilisateur propriétaire. Le protocole OIDC (pour OpenID Connect) est souvent utilisé dans ce contexte. Il propose une couche d'identification fondée par exemple sur le protocole OAuth 2.0, qui permet de vérifier l'identité d'un utilisateur propriétaire en se basant sur l'authentification fournie par un serveur d'autorisation après obtention d'une information de profil de l'utilisateur ; le protocole OAuth2.0, normalisé via les recommandations de l’IETF (RFC 6749 et RFC 6750), est un protocole de délégation d'autorisation qui permet d'autoriser un site web, un logiciel ou une application à utiliser l’accès sécurisé d'un autre site web (par exemple via une API) pour le compte de l’utilisateur. Ces protocoles fonctionnent dans l’espace d’une session informatique ou dans un temps limité à la validité d’un jeton d’accès.

Lorsque l’utilisateur propriétaire des données personnelles n’est pas physiquement présent, une application particulière nécessitant ces informations, par exemple celle d’un employé d’une administration, peut y accéder en utilisant d’autres protocoles tels UMA (pour User-Managed Access, un protocole standard de gestion d'accès basé sur également sur OAuth 2.0) ou OIDC. Dans de tels protocoles, l’utilisateur propriétaire des données personnelles définit au préalable une politique d’accès à ses informations, celle-ci étant gérée par le serveur d’autorisation. Après identification et authentification de l’application, la politique d’accès aux informations d’identité de l’utilisateur propriétaire est évaluée pour donner accès ou non à l’application à tout ou partie des données personnelles de l’utilisateur propriétaire.

Cependant, dans une relation en vis-à-vis, par exemple lorsque le propriétaire des données se trouve dans une administration, la notion de session informatique n’existe pas au sens où l’utilisateur propriétaire des informations d’identité n’est pas en relation informatique avec l’utilisateur de l’application (selon l’exemple, l'employé de l’administration), et ne connaît pasà priorila teneur de la requête de l’utilisateur de l’application.

L'invention vient améliorer l'état de la technique.

Elle concerne à cet effet un procédé d’accès pour obtenir un droit d’accès à au moins une donnée personnelle d’un propriétaire de données identifié par un identifiant unique et possédant une pluralité de données personnelles.

Un tel procédé est mis en œuvre par une application, dite application utilisateur, s’exécutant en liaison avec un terminal d’un utilisateur disposant d’au moins d’un identifiant d’utilisateur, le procédé étant caractérisé en ce qu’il comporte les étapes suivantes :

- ouverture d’un canal de communication de proximité avec un terminal du propriétaire de données ;

- transmission au terminal du propriétaire dudit identifiant d’utilisateur via la communication de proximité ;

- obtention, via la communication de proximité, d’une autorisation d’accès à ladite au moins une donnée personnelle.

L’invention propose un mécanisme simple pour autoriser un utilisateur d’application qui se trouve à proximité physique du propriétaire des données, ou informations, personnelles, à accéder à ces informations sous le contrôle direct de leur propriétaire. Elle est particulièrement avantageuse lorsque le propriétaire (par exemple, un administré d’une mairie) est à proximité de l’utilisateur des données (par exemple, l’employé de la mairie).

Selon l’invention, l’utilisateur propriétaire des données établit avec l'utilisateur une communication de proximité. Cette communication peut être verbale, ou emprunter un canal de communication électronique. L’utilisateur peut alors enclencher le procédé lui permettant d’obtenir des données personnelles (par exemple d’identité) du propriétaire (par exemple, son numéro de sécurité sociale et sa ville de naissance) complémentaires de son identifiant unique (par exemple son numéro de téléphone). À cet effet, il lui transmet un identifiant d’utilisateur. À partir de cet identifiant d’utilisateur, et éventuellement de données complémentaires, le propriétaire peut valider les données personnelles qu’il consent à échanger avec l’utilisateur.

On entend ici par "données personnelles" une ou plusieurs données appartenant au propriétaire des données, notamment mais non exclusivement des données d’identité : nom, prénom, adresse, n° de sécurité sociale, lieu de naissance, etc.

On entend par « utilisateur » un représentant d’une organisation (par exemple, une mairie) et possédant au moins un identifiant (son identifiant propre, par exemple son nom, ou son rôle dans l’organisation, etc.) Un tel utilisateur dispose de droits d’accès sur l’application et est autorisé, au travers d’un serveur d’autorisation, à demander des données personnelles particulières au propriétaire.

On entend par « application utilisateur » une application permettant de rendre un service à l’utilisateur. Ce peut être par exemple une application permettant de compléter une fiche et effectuer une demande administrative particulière, à l’intérieur d’une mairie. Cette application est généralement fournie par un fournisseur d’applications. L’utilisateur y accède typiquement au travers d’un réseau de télécommunications à partir de son poste de travail, communément équipé d’un système d’accès de type Internet. Une fois lancée, l’application, par exemple hébergée sur le fournisseur d’application de l’utilisateur et s’exécutant en partie sur son terminal, nécessite des données personnelles du propriétaire (numéro de sécurité sociale, de permis, etc.) de façon à lui rendre le service.

Par « communication de proximité » on entend toute communication impliquant une proximité physique entre le propriétaire et l’utilisateur, par exemple une communication en champ proche, connue sous le sigle « NFC » (pour « Near Field Communication »), fondée principalement sur la norme ISO (International Standard Organisation) 14443, utilisent des technologies sans fils pour permettre un échange d'informations entre deux périphériques éloignés d’une courte distance, ou encore une technologie radio (Bluetooth, Wi-Fi, Li-Fi, etc.). Une telle communication de proximité peut aussi consister en la présentation d’un code graphique (code QR, code à barres, etc.) affiché sur le mobile et lu par un dispositif de lecture associé au terminal de l’utilisateur.

À la différence de l’état de l’art, qui exige une session applicative pour la demande d’accès aux ressources protégées du propriétaire, l’invention permet ainsi avantageusement au propriétaire de partager via son terminal des éléments d’identité avec un utilisateur dûment identifié, en déléguant à l’utilisateur, par une action de proximité, un droit d’accès à tout ou partie de ses données personnelles.

Selon un mode particulier de réalisation, le procédé d’accès comporte en outre une étape d’obtention de l'identifiant unique du propriétaire de données via la communication de proximité établie, par exemple en NFC.

Avantageusement selon ce mode, l'identifiant unique, c'est à dire un identifiant qui permet d'identifier l'utilisateur de manière unique, comme son numéro de téléphone ou son numéro de sécurité sociale, est transmis dans une relation de proximité sur un canal de communication (par exemple NFC) qui peut être sécurisé.

Selon un mode particulier de réalisation de l’invention, le procédé comporte en outre une étape de transmission, vers le terminal du propriétaire, d’une requête de validation de l’accès à ladite au moins une donnée personnelle parmi la pluralité de données personnelles.

Avantageusement selon ce mode, l’utilisateur demande explicitement les données personnelles qu’il souhaite recevoir de la part du propriétaire. Cette requête peut être transmise sous forme d’une liste de données souhaitées qui peut prendre la forme d’un formulaire, d’un tableau, d’une catégorie de données, etc. Sur réception de la requête explicite, l’utilisateur peut valider ou non la liste des données qui lui sont demandées.

Selon un mode particulier de réalisation de l’invention, le procédé comporte en outre les étapes de :

- requête d’accès à ladite donnée personnelle, ladite requête comportant au moins ledit identifiant d’utilisateur et ledit identifiant du propriétaire ;

- réception d’une donnée d’accès à ladite donnée personnelle ;

- réception de ladite au moins une donnée personnelle du propriétaire si la donnée d’accès est valide.

Avantageusement selon ce mode, l’utilisateur accède aux données du propriétaire grâce notamment à l’identifiant du propriétaire, qu’il a obtenu localement, et à son propre identifiant. Cette requête d’accès est typiquement réalisée auprès d’un serveur d’autorisation.

On entend par "serveur d’autorisation" un serveur dont le rôle est d’accréditer l’utilisateur pour que celui-ci effectue une demande auprès du propriétaire. Le serveur d’autorisation mémorise une politique d’accès aux données. Si la requête de l’utilisateur est correcte, il lui transmet une donnée d'accès, ou jeton, pour l’accès effectif aux données. Ce serveur peut être associé à un serveur fournisseur d’identité permettant d’identifier et d’authentifier l’utilisateur pour le compte de l’application. Il peut être aussi associé à un serveur de ressources dont le rôle consiste, après vérification des droits de l’utilisateur, à donner l’accès aux données du propriétaire demandées par l’utilisateur.

Selon un mode particulier de réalisation de l’invention, l’identifiant d’utilisateur comporte un identifiant d’une organisation.

On entend par "identifiant d’organisation"l’identifiant unique d’une organisation (par exemple, la mairie de Rennes) qui possède des droits d’accès à l’application qui fournit les données personnelles de ses administrés.

Avantageusement selon ce mode, les droits d’accès aux données du propriétaire peuvent être conditionnés par le type d’organisation. Par exemple, une mairie peut avoir le droit d’accéder à certains éléments de ses administrés (le numéro de sécurité sociale), alors qu’un utilisateur d’une autre administration, par exemple une poste, n’y aura pas accès. La sélection des données personnelles peut donc être automatisée en fonction de l’organisation.

L’invention concerne aussi un procédé de partage d’une donnée personnelle au moins d’un propriétaire de données possédant une pluralité de données personnelles et identifié par un identifiant unique. Un tel procédé est mis en œuvre par une application s’exécutant sur un terminal mobile du propriétaire, dite application mobile, le procédé étant caractérisé en ce qu’il comporte les étapes suivantes :

- établissement d’un canal de communication de proximité avec un terminal de l’utilisateur ;

- réception d’un identifiant d’utilisateur via la communication de proximité ;
- émission, vers un serveur d’autorisation, d’une politique d’accès à ladite au moins une donnée personnelle pour ledit utilisateur identifié ;

- émission, via la communication de proximité, d’une autorisation d’accès à ladite au moins une donnée personnelle.

Ce procédé propose un mécanisme simple permettant à un propriétaire qui se trouve à proximité physique de l’utilisateur qui doit lui fournir un service, d’autoriser l’accès à une ou plusieurs de ses données personnelles. Comme il l'a été mentionné précédemment, cette communication de proximité peut être de type NFC, ou Bluetooth, Wi-Fi, ou réalisée par lecture d'un code graphique, etc.

L’utilisateur propriétaire des données reçoit un identifiant d’utilisateur. À partir de cet identifiant d’utilisateur, et éventuellement de données complémentaires, il peut valider les données personnelles qu’il consent à échanger avec l’utilisateur. Il émet vers un serveur d’autorisation une politique d'accès correspondant à cette validation pour cet utilisateur.

On entend par politique d’accès une représentation informatique d’une autorisation d’accès à certaines informations personnelles du propriétaire. Elle peut par exemple, pour chaque donnée personnelle parmi la pluralité des données personnelles, en autoriser ou non l’accès en fonction d’un paramètre (par exemple un identifiant de l’utilisateur qui souhaite y accéder, l’identifiant de l’organisation de l’utilisateur, etc.) L’accès peut être conditionnel (dans le temps, dans l’espace, etc.) Cette politique est définie par le propriétaire, par exemple sur son mobile, et déposée sur le serveur d’autorisation par le mobile du propriétaire, ou une application intermédiaire.

Avantageusement selon ce procédé de partage, le propriétaire des données choisit d’en partager une ou plusieurs avec l’utilisateur, en fonction des droits de cet utilisateur, en déposant sur le serveur d’autorisation la politique associée. Par exemple si l’utilisateur est l’employé d’une mairie, il peut choisir de lui donner accès à sa date de naissance et de permis de conduire, mais pas à son numéro de sécurité sociale, et seulement pour une durée limitée dans le temps.

L’émission d’une telle politique, en relation avec l’identifiant de l’utilisateur, permet ultérieurement à l’utilisateur, via son identifiant unique et celui du propriétaire, d’accéder aux données du propriétaire.

Une telle politique peut être déposée à l’avance sur le serveur d’autorisation (le propriétaire autorise a priori la mairie de Rennes à accéder à certaines de ses données), ou au cours de la transaction (le propriétaire, pendant la communication de proximité avec l’employé de la mairie, dépose la politique d’accès sur le serveur).

Selon un mode particulier de réalisation de l’invention, un tel procédé comporte en outre une étape de transmission de l’identifiant unique du propriétaire de données via la communication de proximité.

Avantageusement selon ce mode, l’identifiant du propriétaire est transmis sur un canal de proximité, ce qui limite les pertes et augmente la sécurité.

Selon un mode particulier de réalisation de l’invention, un tel procédé de partage comporte en outre une étape de décision, en fonction de l’identifiant utilisateur reçu, d’une validation ou non du partage de ladite au moins une donnée personnelle.

Avantageusement selon ce mode, la validation de certaines données personnelles ou non dépend de l’identifiant utilisateur reçu. En effet, selon le type de l’utilisateur et/ou de son organisation, les droits d’accès aux données du propriétaire peuvent être différents. Par exemple une mairie peut avoir le droit d’accéder à certains éléments de ses administrés (le numéro de sécurité sociale), alors qu’un utilisateur d’une autre administration n’y aura pas accès. La sélection et validation des données personnelles peut donc être automatisée en fonction de l’organisation qui les requiert.

Selon un mode particulier de réalisation de l’invention, un tel procédé de partage comporte en outre une étape de réception d’une requête de validation de l’accès à ladite au moins une donnée personnelle de la pluralité de données personnelles.

Avantageusement selon ce mode, la validation de certaines données personnelles ou non dépend d'une requête explicite reçue de l’utilisateur. En effet, l’utilisateur peut insérer dans un message associé à la requête de validation un certain nombre de données auxquelles il souhaiterait avoir accès. La sélection et validation de l'accès à tout ou partie des données personnelles peut alors être laissée au propriétaire.

Selon un mode de réalisation, un tel procédé de partage comporte en outre une étape de restitution, sur le terminal du propriétaire, d’un ensemble de données propriétaires parmi la pluralité, pour validation par le propriétaire.

Avantageusement selon ce mode, les données sont restituées sur le terminal via une interface homme-machine, par exemple elles sont affichées à l’écran du smartphone de l’utilisateur. Il peut s’agir de données demandées explicitement, ou déterminées implicitement en fonction de l’identifiant de l’utilisateur. Dans les deux cas, la restitution à l’écran du terminal permet au propriétaire de valider ou non, via une interface utilisateur, par exemple en sélectionnant une case à cocher sur l’écran, l’accès à certaines des données parmi celles qui sont restituées.

L’invention concerne également un terminal d’accès d’un utilisateur disposant d’au moins d’un identifiant d’utilisateur, configuré pour accéder à au moins une donnée personnelle d’un propriétaire de données identifié par un identifiant unique et possédant une pluralité de données personnelles, le terminal comprenant un processeur et une mémoire configurés pour exécuter les étapes d’un procédé d’accès tel que décrit ci-dessus.

L’invention concerne également un terminal propriétaire d’un propriétaire de données possédant une pluralité de données personnelles et identifié par un identifiant unique, configuré pour partager au moins une donnée personnelle, le terminal comprenant un processeur et une mémoire configurés pour exécuter les étapes d’un procédé de partage tel que décrit ci-dessus.

Corrélativement, l’invention concerne également unsystème d’accèscomprenant :
- un terminal utilisateur et un terminal propriétaire tels que décrits ci-dessus, caractérisés en ce que les deux terminaux établissent ensemble le canal de communication de proximité pour échanger l’identifiant d’utilisateur et l’autorisation d’accès à ladite au moins une donnée personnelle du propriétaire ;

- un serveur d’autorisation configuré pour :

• recevoir en provenance du terminal propriétaire une politique d’accès aux données personnelles du propriétaire en relation avec l’identifiant de l’utilisateur ;
• recevoir une requête en provenance du terminal utilisateur pour accéder à ladite au moins une donnée du propriétaire ;
• si la requête est correcte, transmettre au terminal utilisateur un droit d’accès d’accès à ladite au moins une donnée du propriétaire ;

- un serveur de ressources configuré pour :

- recevoir un droit d’accès en provenance du terminal utilisateur ;

- si le droit d’accès est correct, transmettre audit terminal utilisateur ladite au moins une donnée du propriétaire.

L'invention concerne également un programme d'ordinateur comportant des instructions pour la mise en œuvre du procédé d’accès ou de partage cités ci-dessus selon l'un quelconque des modes particuliers de réalisation décrits précédemment, lorsque ledit programme est exécuté par un processeur. Ces procédés peuvent être mis en œuvre de diverses manières, notamment sous forme câblée ou sous forme logicielle.

Ces programmes peuvent utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable.

L'invention vise aussi un support d'enregistrement ou support d'informations lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus. Les supports d'enregistrement mentionnés ci-devant peuvent être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD-ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple un disque dur. D'autre part, les supports d'enregistrement peuvent correspondre à un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Les programmes selon l'invention peuvent être en particulier téléchargés sur un réseau de type Internet.

Alternativement, les supports d'enregistrement peuvent correspondre à un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question.

Liste des figures

D’autres caractéristiques et avantages de l’invention apparaîtront plus clairement à la lecture de la description suivante de modes de réalisation particuliers, donnés à titre de simples exemples illustratifs et non limitatifs, et des dessins annexés, parmi lesquels :

La figure 1 illustre le contexte de mise en œuvre d’un procédé selon un mode particulier de réalisation de l’invention.

La figure 2 illustre la validation d’un accès aux données propriétaires, selon un mode particulier de réalisation de l’invention.

La figure 3 illustre des étapes d’un procédé selon un mode particulier de réalisation de l’invention.

La figure 4 illustre la structure simplifiée d’un dispositif configuré pour mettre en œuvre des étapes du procédé d’accès selon un mode particulier de réalisation de l’invention.

Description d'un mode de réalisation de l'invention

Principe général de l'invention

L’invention permet d’organiser un ensemble d’échanges permettant à un propriétaire (noté dans la suite PRO) d’autoriser l’accès à tout ou partie de ses données personnelles (DID) à un utilisateur (USR) ou à l’organisation qu’il représente, dans une relation de proximité.

Modes particuliers de réalisation de l'invention.

Lafigure 1illustre le contexte de mise en œuvre d’un procédé selon un mode particulier de réalisation de l’invention. Ce contexte comporte notamment :

• Un terminal mobile (TPRO) détenu par un propriétaire (PRO). Le mobile (TPRO) comprend une application mobile (APPM) permettant au propriétaire, après réception d’une requête de l’application utilisateur, d’autoriser l’accès à tout ou partie de ses données personnelles DID. L'ensemble des données personnelles est noté MDID. À cet effet, il établit une liste de données qu’il consent à partager avec l’utilisateur (notée dans la suite LDID'). L’application mobile peut être contrôlée par un élément de sécurité de type carte SIM. Les informations du propriétaire, DID, peuvent être stockées en local sur un terminal du propriétaire, par exemple son mobile, ou sur un élément sécurisé de son terminal, comme une carte SIM, ou sur un serveur de stockage externe de confiance, etc. Les données personnelles ne sont accessibles que du seul serveur de ressources SRES.
• Un terminal (TUSR) d’un utilisateur (USR) représentant une organisation. Par exemple l’utilisateur USR est employé d’une administration. Le terminal de cet utilisateur dispose d'une application (APPU) livrée par le fournisseur d’applications de l’utilisateur, représenté par un serveur SAP. Il est autorisé au travers d’un serveur d’autorisation (SAUTH) à demander des informations particulières au propriétaire.
• Un serveur fournisseur d’Application (SAP) de l’utilisateur, gérant le service rendu à l’utilisateur, par exemple sous la forme d’une application permettant de compléter une fiche et d’effectuer une demande administrative particulière. L’utilisateur y accède au travers d’un réseau à partir du terminal TUSR, communément équipé d’un système d’accès de type Internet. L’application hébergée sur le fournisseur d’application de l’utilisateur nécessite des informations personnelles du propriétaire de façon à lui rendre un service. Pour cela, l’utilisateur peut requérir l’autorisation d’accès aux données dont il a besoin ainsi que leurs justificatifs auprès du propriétaire et initier leur obtention via une communication de proximité.
• Un serveur Fournisseur d’Identité (FID) permettant d’identifier et d’authentifier l’utilisateur pour le compte de l’application. Ce service peut être partagé avec d’autres services existants au sein de l’organisation, d’autres applications, etc.
• Un Serveur d’Autorisation (SAUTH) dont le rôle est d’accréditer l’utilisateur pour que celui-ci effectue une demande auprès du propriétaire. L’appartenance de l’utilisateur à l’organisation, voire son affectation particulière dans l’organisation (par exemple, une hiérarchie dans l’organisation qui permet certaines autorisations d’accès à certaines données de certains utilisateurs seulement) est vérifiée par le serveur d’autorisation SAUTH, qui délivre un droit d’accès à tout ou partie des informations du propriétaire, généralement sous forme d’un jeton, ou droit d'accès.
• Un Serveur de Ressources (SRES) contrôle l’accès aux données personnelles du propriétaire ; il peut donner, après vérification des droits de l’utilisateur, accès aux informations du propriétaire demandées par l’utilisateur au travers de son application. Il permet au propriétaire de déclarer à tout moment de nouvelles ressources liées à son identité, ainsi que leur localisation, et les utilisateurs à qui il les réserve, etc.

Lafigure 2illustre la validation de l’accès aux données propriétaires, selon un mode particulier de réalisation de l’invention.

Selon cet exemple, la structure ou liste LDID des données DID du propriétaire PRO, choisies parmi la pluralité MDID des donnés du propriétaire, est affichée, en cours de transactions, sur l’écran de son terminal TPRO, selon l’exemple un smartphone. Les données DID sont au nombre de cinq selon cet exemple : le nom (NAME) du propriétaire, son adresse (ADD), son numéro de sécurité sociale (SS), sa date de naissance (DB) et sa ville de naissance (CB). La liste LDID est affichée à l’écran sous forme de cases à cocher.

Selon cet exemple, le propriétaire pourra donner accès à l’une ou plusieurs de ses données personnelles, en cochant leur désignation sur l’écran du terminal. Par exemple s’il se trouve dans une mairie, il pourra donner accès à toutes les données sauf son numéro de sécurité sociale. Lorsque le propriétaire a validé l’accès à un certain nombre de données pour cet utilisateur, par exemple le nom (NAME) et l’adresse (ADD), une seconde liste LDID’, sous-ensemble de la première, est générée. Cette liste LDID’ correspond donc aux données personnelles parmi la pluralité de données personnelles que le propriétaire consent à partager avec l'utilisateur. Cette liste peut prendre toute forme connue de représentation informatique (liste, structure, chaîne, etc.) Elle peut correspondre à l’ensemble des données (MDID) ou à un sous-ensemble (LDID) par exemple requis par l’utilisateur.

Lafigure 3illustre des étapes d’un procédé selon un mode particulier de réalisation de l’invention.

Selon ce mode de réalisation, le propriétaire peut partager des éléments d’identité avec un utilisateur dans le cadre du service qu’il rend au propriétaire au travers de son application, dans une relation de proximité.

Dans un premier temps, le propriétaire PRO fournit à l’utilisateur de l’application (par exemple un employé de la mairie) un identifiant unique IDPRO, qui peut être par exemple son numéro de mobile, ou sa date de naissance, etc. Il obtient une donnée contextualisée de l’utilisateur USR et/ou de l’organisation qu’il représente. Il peut s’agir par exemple du nom de l’organisation (Mairie de Caen). Cette donnée contextualisée est notée IDUSR. Au travers de son application mobile, le propriétaire délègue à l’utilisateur un droit d’accès à tout ou partie de ses informations d’identité. Selon une autre terminologie, il consent à partager certaines de ses données, ou encore il en autorise l’accès. La représentation de cette délégation de droit est appelée politique d’accès (POL). Elle est stockée sur le serveur d’autorisation, soit a priori, soit ultérieurement au cours de l’échange.

L’utilisateur USR utilise ensuite l’identifiant principal fourni par le Propriétaire (IDPRO) pour accéder, via son application utilisateur (APPU), aux données dont il a besoin pour rendre le service de l’application au propriétaire. L’accès aux données est vérifié par le serveur d’autorisation (SAUTH) qui le valide après vérification de la politique d’accès (POL) telle que définie par le propriétaire. Par la suite, le serveur d’autorisation donne un droit d’accès (jeton JTN) à l’application de l’utilisateur (APPU) pour accéder au serveur de ressources (SRES), qui accède aux informations d’identité et les fournit à l’application utilisateur.

Ce mécanisme est illustré en figure 3 par les étapes suivantes :

Lors d’une étapeE10, donnée à titre d’exemple, le propriétaire dépose auprès du serveur de ressources SRES une pluralité de données personnelles le concernant (MDID), par exemple via une application de dépôt de ressources installée sur son mobile. Cette étape a pour nom enrôlement. Selon un autre exemple, c’est une application tierce qui renseigne les données d’informations personnelles. Les données peuvent être physiquement stockées sur le serveur, ou être stockées ailleurs et accessibles depuis le serveur.

Lors d’une étapeE0, l’utilisateur s’enregistre auprès du serveur d’autorisation (par exemple via un formulaire). La spécification OAuth 2.0 susmentionnée précise les paramètres standards que le client, ici l’utilisateur, doit renseigner lors du processus d’enregistrement (nom de l’application, adresse (URI) de redirection, types d’autorisation qui pourront être utilisés par le client, etc.) Le serveur d’autorisation délivre classiquement en retour une donnée appeléecredential, notée CRED, correspondant par exemple selon le protocole OAuth2 à un couple comportant l’identifiant du client (client_id) et un secret (client_secret).

Lors d’une étapeE11, le propriétaire lance son application mobile et initie une communication de proximité. Selon un mode de réalisation, il s’agit d’une communication en champ proche, connue sous le sigle « NFC » (pour « Near Field Communication »), fondée principalement sur la norme ISO (International Standard Organisation) 14443, utilisent des technologies sans fils pour permettre un échange d'informations entre deux périphériques éloignés d’une courte distance. Selon une variante, la communication peut être de type « IBC » (de l’anglais : Intra-Body Communication) le corps humain agissant alors comme un conducteur pour transmettre des informations d’un point à un autre, en l’occurrence le terminal TPRO du propriétaire de données (qui peut rester placé dans sa poche, son sac, etc.) et le terminal de l’utilisateur. Selon une autre variante, il peut s’agir d’une communication radio de type Bluetooth, ou encore Wi-Fi, Li-Fi, Zigbee, etc. Il peut encore s'agir d'une communication par lecture de code graphique. Optionnellement, le propriétaire s’identifie et/ou s’authentifie préalablement, soit en local, soit à l’aide d’un fournisseur d’identité qui peut être par exemple le fournisseur d’identité FID décrit dans le système de la figure 1. Le propriétaire fournit sur le canal de communication en champ proche (NFC, IBC, etc.) un identifiant unique IDPRO à l’application utilisateur. Cet identifiant peut être un identifiant stable dans le temps tel que le numéro de mobile du propriétaire, ou un identifiant généré pour ce seul échange avec l’utilisateur. De préférence, cet identifiant fait partie de la pluralité de données d’identification MDID du propriétaire. La donnée d’identification IDPRO peut par exemple être contenue dans un code de type QR, ou encore dans une trame de message NFC, etc.

Selon une variante, cet identifiant est transmis oralement du propriétaire à l’utilisateur.

Lors d’une étapeE1, l’utilisateur récupère cette donnée IDPRO sur son terminal TUSR (ou éventuellement la saisit dans son application). Il est connecté à cet instant à son fournisseur d’application, représenté ici sous la forme du serveur SAP. Classiquement, il présente l’identifiant du propriétaire au fournisseur d’application de l’utilisateur (SAP) pour initier une session applicative. L’application APPU en charge du procédé d’accès s’exécute sur le terminal de l’utilisateur et le serveur SAP du fournisseur de l’application.

Lors d’une étapeE2, l’utilisateur demande au propriétaire ses données personnelles via la communication de proximité initiée, par exemple NFC, IBC ou Bluetooth, ou par présentation d’un QR code représentant les données demandées, et lu par le mobile du propriétaire, etc. Cette demande correspond à une requête de consentement à l’accès à certaines données du propriétaire. Selon ce mode de réalisation, l’utilisateur transmet lors de cette requête un identifiant noté IDUSR associé à une liste de données personnelles requises (nom, prénom, date de naissance, numéro de sécurité sociale, de permis, etc.) sous forme d’une liste de données notée LDID. Cet identifiant peut être un objet stable dans le temps, définitivement établi, ou établi pour une certaine période de temps, ou défini par session d’accès ou encore défini à chaque nouvel échange avec un propriétaire. Selon un autre mode de réalisation, l’identifiant IDUSR comprend un identifiant d’organisation (IDO) qui permet une génération automatique des données personnelles souhaitées, selon le type de l’organisation. Par exemple, la norme OpenID précitée définit un certain nombre de portées (scopes) associées à des données d’identité spécifiques ; l’identifiant IDUSR/IDO peut être implicitement ou explicitement associé à l’un ou plusieurs de ces « scopes ».

• « scope profile » : nom, prénom, surnom, date de naissance …

• « scope email » : email, email vérifié
• « scope address » : adresse
• « scope phone » : numéro de téléphone, numéro de téléphone vérifié

Selon une variante, l’utilisateur demande verbalement au propriétaire les données souhaitées pour satisfaire les besoins de l’application utilisateur.

Lors d’une étapeE12, Le terminal du propriétaire reçoit la requête de validation d’accès et établit une liste des données personnelles qu’il consent à partager avec l’application de l’utilisateur parmi la pluralité de ses données personnelles MDID. De préférence ces informations correspondent à celles qui ont été demandées par l’utilisateur, en relation avec l’identifiant IDUSR reçu, c’est-à-dire qu’elles forment une liste LDID’ correspondant à un sous-ensemble des données désignées dans la liste LDID, elle-même sous-ensemble de la liste de données MDID.

Selon un exemple, les informations établies sont sélectionnées parmi l’ensemble des données personnelles qui peuvent être par exemple affichées pour sélection sur l’écran du smartphone du propriétaire, comme représenté en figure 2.

Selon un autre exemple, la liste des données LDID demandées par l’utilisateur est présentée au propriétaire via l’application de son mobile ; le propriétaire consent à donner l’accès à tout ou partie de ses données, c’est-à-dire qu’il effectue une sélection dans la liste LDID qui est elle-même un sous-ensemble de la liste MDID.

Selon un mode de réalisation, lors de l’étapeE13, l’application du mobile du propriétaire (APPM) accède au Serveur d’Autorisation (SAUTH) pour autoriser à l’utilisateur l’accès aux données pour lesquelles il vient de consentir le partage, représentées par la liste LDID’. Cette autorisation prend la forme d’une politique d’accès aux informations du propriétaire, notée POL.

La politique d’accès peut être statique, acquise pour l’utilisateur indéfiniment jusqu’à sa suppression par le propriétaire.

Selon un autre mode de réalisation, cette politique d’accès est dynamique au sens où :

- elle est effacée sur le serveur d’autorisation après évaluation des droits d’accès de l’utilisateur qui se présente,

- elle est effacée sur le serveur d’autorisation après un laps de temps déterminé par avance.

Un tel mécanisme est particulièrement intéressant lors d’une session d’accès de proximité, puisque le propriétaire peut régénérer une politique d’accès à la volée lorsqu’il se trouve face à l’utilisateur.

Selon un autre mode de réalisation, qui sera décrit plus tard à l’appui de l’étape E13’, c’est sur requête du serveur d’autorisation (SAUTH) que la politique d’accès est déposée pour évaluation immédiate.

De manière générale, le propriétaire dépose sur le serveur d’autorisation une politique d’accès décrivant les données personnelles le concernant accessibles à un utilisateur et son application, ainsi que les restrictions qui s’y appliquent (accès libre, accès réservé à un certain type d’utilisateur, accès limité dans le temps, etc.). Les restrictions sont définies lors de l’enrôlement. Le dépôt se fait par exemple via une application de dépôt de ressources installée sur le terminal mobile. Cette étape est antérieure à la mise en place du service. Par exemple, le propriétaire peut utiliser la norme UMA précitée, qui offre la possibilité, pour un propriétaire de ressources, de consentir à l'émission de jetons en temps réel, ou de définir la politique d'accès à l'avance par l’intermédiaire d’un serveur d’autorisation, ce qui permet à un utilisateur de tenter un accès asynchrone aux données.

Lors d’une étapeE14, le propriétaire valide pour l’utilisateur (via son application mobile) les données personnelles auxquelles il a consenti (représentées par la liste LDID’).

Lors d’une étapeE5, l’application utilisateur effectue une requête d’accès auprès du serveur d’autorisation (SAUTH), en incluant dans sa requête :

• Son identifiant (IDUSR) et sescredentialsCRED (qui peuvent inclure par exemple son profil d’utilisateur ou sa qualité : médecin, agent certifié de niveau 2, etc.),
• l’identifiant du propriétaire IDPRO, et
• la liste des données requises pour rendre le service (LDID’ = sous-ensemble de la liste LDID).

Selon une variante, lescredentialsCRED comportent l’identifiant IDUSR, c’est-à-dire que l’identifiant utilisateur fourni au propriétaire est le même que celui fourni auparavant par le fournisseur d’identité. Selon une autre variante, c’est l’identifiant IDUSR qui contient lescredentialsCRED.

Le serveur d’autorisation évalue la politique déposée par le propriétaire au cours de l’étape E13, à l’aide des données de l’utilisateur (données requises,credentialset IDUSR) dans le cas où le propriétaire a approuvé à l’avance la requête par le dépôt de la politique d’accès, et génère un jeton, ou donnée d’accès (JTN), lors d’une étapeE36,en cas de succès de l’évaluation.

Lors d’une étapeE6, le terminal utilisateur reçoit ce jeton d’accès (en anglais, Access Token). Un tel jeton est par exemple défini par la norme susmentionnée OpenID. Il comporte la liste des informations auxquelles l’accès est autorisé et l’adresse du serveur de ressources.

Puis lors d’une étapeE7,l’application de l’utilisateur peut demander l’accès aux ressources consenties au serveur de ressources en présentant son jeton. Il peut y avoir plusieurs serveurs de ressources acceptant le jeton.

Le Serveur de Ressources reçoit la requête avec le jeton lors d’une étapeE47. Si le jeton d’accès fourni est valide (c’est éventuellement le serveur d’autorisation qui vérifie la validité du jeton JTN), les données personnelles demandées sont renvoyées à l’application de l’utilisateur lors d’une étapeE48.

On notera que le(s) serveur(s) de ressources peuvent prendre de multiples formes : il peut accéder aux informations demandées stockées sur le mobile du propriétaire, ou sur une carte SIM du propriétaire, ou encore sur un serveur de stockage externe, ou toutes combinaisons appropriées. Il les transmet à l’application utilisateur.

Lors d’une étapeE8, l’application utilisateur reçoit les données personnelles autorisées à l’accès et peut mettre en œuvre le service au cours d’une étapeE9.

Selon un autre mode de réalisation, si l’étape E13 n’a pas eu lieu, l’utilisateur fait une requête vers le serveur d’autorisation alors que la politique n’a pas encore été déposée sur le serveur d’autorisation par le propriétaire. Dans ce cas, le serveur d’autorisation contacte à l’aide de son identifiant IDPRO le mobile du propriétaire (par exemple, via une notification) et la politique d’accès peut être établie « à la volée » au cours d’une étape E13’. Le propriétaire valide les données pour lesquelles il consent le partage, transmet la politique au serveur d’autorisation qui peut alors l’évaluer au cours d’une étape E33’.

Selon un autre mode de réalisation, non représenté, le serveur de ressources a déposé au préalable une politique d’accès aux informations du propriétaire ou des propriétaires qu’il fédère pour les divers utilisateurs de l’application du fournisseur d’application de l’utilisateur. Cette possibilité est par exemple fournie dans la norme UMA 2.0. Dans ce cas, il autorisea prioriles utilisateurs appartenant à une organisation donnée, ou un profil donné, sous condition d’identité (liste d’utilisateurs potentiels par exemple), de qualité et/ou de rôle dans l’organisation à requérir un ensemble de données personnelles . Cette déclaration peut relever d’une action contractuelle entre l’organisation gérant le serveur de ressources et l’organisation gérant l’application du fournisseur d’application de l’utilisateur et à laquelle appartient l’utilisateur, ou d’un passage d’ordre émis par le propriétaire au travers de son application mobile.

Lafigure 4illustre la structure simplifiée d’un terminal mobile (TPRO) configuré pour mettre en œuvre des étapes du procédé de partage.

Selon ce mode particulier de réalisation de l'invention, le terminal a l'architecture classique d'un terminal mobile, et comprend notamment une mémoire MEM, une unité de traitement UT, équipée par exemple d'un processeur PROC, et pilotée par le programme d'ordinateur APPM stocké en mémoire MEM. Le programme d'ordinateur APPM comprend des instructions pour mettre en œuvre les étapes du procédé de partage de données selon l’un quelconque des modes de réalisation décrits précédemment, lorsque le programme APPM est exécuté par le processeur PROC de l’unité de traitement.

A l'initialisation, les instructions de code du programme d'ordinateur APPM sont par exemple chargées dans une mémoire avant d'être exécutées par le processeur PROC.

Le terminal mobile (TPRO) comprend également un module de communication de proximité CPROX, par exemple NFC, ou radio de type Bluetooth, etc. destiné notamment à échanger des données avec le terminal de l'utilisateur TUSR.

Le terminal mobile (TPRO) comprend aussi une interface de communication COM permettant au terminal mobile (TPRO) d’établir des communications via un réseau de données Internet ou cellulaire, notamment pour communiquer avec les différents serveurs (serveur de ressources, d’autorisation, etc.)

Selon un mode particulier de réalisation de l’invention, le terminal mobile (TPRO) comprend un module d’affichage AFF, par exemple un écran et un module d’interaction utilisateur UI, permettant notamment d’afficher à l’écran des données du propriétaire et de recevoir les signaux de sélection des différentes données.

Selon un mode particulier de réalisation de l’invention, le terminal mobile (TPRO) comprend un module de sécurité SIM.

Claims (15)

1. Procédé d’accès pour obtenir un droit d’accès (JTN) à au moins une donnée personnelle (DID) d’un propriétaire (PRO) de données identifié par un identifiant unique (IDPRO) et possédant une pluralité de données personnelles (MDID), mis en œuvre par une application, dite application utilisateur (APPU) s’exécutant en liaison avec un terminal (TUSR) d’un utilisateur (USR) disposant d’au moins d’un identifiant d’utilisateur (IDUSR), le procédé étant caractérisé en ce qu’il comporte les étapes suivantes :
   - ouverture d’un canal de communication de proximité (CP) avec un terminal (TPRO) du propriétaire de données;
   - transmission (E2) au terminal du propriétaire dudit identifiant d’utilisateur (IDUSR) via la communication de proximité ;
   - obtention (E4), via la communication de proximité, d’une autorisation d’accès à ladite au moins une donnée personnelle (LDID’).
2. Procédé selon la revendication 1, caractérisé en ce qu’il comporte en outre une étape d’obtention (E1) de l’identifiant unique du propriétaire de données via la communication de proximité (CP).
3. Procédé selon la revendication 1, caractérisé en ce qu’il comporte en outre une étape de transmission (E2), vers le terminal du propriétaire, d’une requête de validation de l’accès à ladite au moins une donnée personnelle (DID) parmi la pluralité de données personnelles (MDID).
4. Procédé selon la revendication 1, caractérisé en ce qu’il comporte en outre les étapes de :
   - requête (E5) d’accès à ladite donnée personnelle, ladite requête comportant au moins ledit identifiant d’utilisateur (IDUSR) et ledit identifiant (IDPRO) du propriétaire ;
   - réception d’une donnée d’accès (JTN) à ladite donnée personnelle ;
   - réception (E8) de ladite au moins une donnée personnelle du propriétaire (DID) si la donnée d’accès est valide.
5. Procédé selon la revendication 1, caractérisé en ce que l’identifiant d’utilisateur (IDUSR) comporte un identifiant d’une organisation (IDO).
6. Procédé de partage d’une donnée personnelle au moins (DID) d’un propriétaire (PRO) de données possédant une pluralité de données personnelles(MDID) et identifié par un identifiant unique (IDPRO), mis en œuvre par une application (APPM) s’exécutant sur un terminal mobile du propriétaire, dite application mobile, le procédé étant caractérisé en ce qu’il comporte les étapes suivantes :
   - établissement d’un canal de communication de proximité (CP) avec un terminal de l’utilisateur ;
   - réception (E12) d’un identifiant d’utilisateur (IDUSR) via la communication de proximité ;
   - émission (E13, E13’),vers un serveur d’autorisation (SAUTH), d’une politique d’accès (POL) à ladite au moins une donnée personnelle pour ledit utilisateur identifié ;
   - émission (E14), via la communication de proximité, d’une autorisation d’accès à ladite au moins une donnée personnelle.
7. Procédé de partage selon la revendication 6, comportant en outre une étape de transmission (E11) d’un identifiant unique du propriétaire de données via la communication de proximité (CP).
8. Procédé de partage selon la revendication 6, comportant en outre une étape de décision, en fonction de l’identifiant utilisateur reçu (IDUSR), d’une validation ou non de ladite au moins une donnée personnelle.
9. Procédé de partage selon la revendication 6, comportant en outre une étape de réception (E12) d’une requête de validation de l’accès à ladite au moins une donnée personnelle (DID) de la pluralité de données personnelles (MDID).
10. Procédé de partage selon l’une des revendications précédentes, caractérisé en ce qu’il comporte en outre une étape de restitution (E12), sur le terminal du propriétaire, d’un ensemble de données propriétaires parmi la pluralité, pour validation par le propriétaire.
11. Terminal d’accès d’un utilisateur (USR) disposant d’au moins d’un identifiant d’utilisateur (IDUSR), configuré pour accéder à au moins une donnée personnelle (DID) d’un propriétaire (PRO) de données identifié par un identifiant unique (IDPRO) et possédant une pluralité de données personnelles (MDID), le terminal (TUSR) comprenant un processeur et une mémoire configurés pour :
    - ouvrir un canal de communication de proximité (CP) avec un terminal du propriétaire ;
    - transmettre (E2) au terminal du propriétaire ledit identifiant d’utilisateur (IDUSR) via la communication de proximité ;
    - obtenir (E4), via la communication de proximité, une autorisation d’accès à ladite au moins une donnée personnelle, de la part du terminal du propriétaire.
12. Terminal propriétaire (TPRO) d’un propriétaire (PRO) de données possédant une pluralité de données personnelles (MDID) et identifié par un identifiant unique (IDPRO), configuré pour partager au moins une donnée personnelle (DID) avec un utilisateur, le terminal (TPRO) comprenant un processeur et une mémoire configurés pour :
    - établir un canal de communication de proximité (CP) avec un terminal de l’utilisateur ;
    - recevoir (E12) un identifiant d’utilisateur (IDUSR) via la communication de proximité ;
    - émettre (E14), via la communication de proximité, une autorisation d’accès à ladite au moins une donnée personnelle.
13. Système d’accès comprenant :
    - un terminal d’accès et un terminal propriétaire selon les revendications 11 et 12, caractérisé en ce que les deux terminaux établissent ensemble le canal de communication de proximité pour échanger l’identifiant d’utilisateur et l’autorisation d’accès à ladite au moins une donnée personnelle du propriétaire ;
    - un serveur d’autorisation configuré pour :
    - recevoir (E33, E33’) en provenance du terminal propriétaire une politique d’accès (POL) aux données personnelles du propriétaire en relation avec l’identifiant de l’utilisateur ;
    - recevoir (E35) une requête en provenance du terminal utilisateur pour accéder à ladite au moins une donnée du propriétaire ;
    - si la requête est correcte, transmettre (E36) au terminal utilisateur un droit d’accès (JTN) à ladite au moins une donnée du propriétaire.
    - un serveur de ressources configuré pour :
    - recevoir (E47) un droit d’accès (JTN) en provenance du terminal utilisateur ;
    - si le droit d’accès (JTN) est correct, transmettre (E48) audit terminal utilisateur ladite au moins une donnée du propriétaire.
14. Système d’accès selon la revendication précédente, dans lequel le serveur d’autorisation est configuré de surcroît pour effacer la politique d’accès après transmission du droit d’accès (JTN).
15. Programme d'ordinateur comportant des instructions pour la mise en œuvre du procédé d’accès selon l'une quelconque des revendications 1 à 5, ou de partage selon l'une quelconque des revendications 6 à 10, lorsque le programme est exécuté par un processeur.