[go: up one dir, main page]

FR3113347A1 - Procede et dispositif de mise a jour de donnees d’un document dematerialise pour l’execution d’un service ou d’un controle - Google Patents

Procede et dispositif de mise a jour de donnees d’un document dematerialise pour l’execution d’un service ou d’un controle Download PDF

Info

Publication number
FR3113347A1
FR3113347A1 FR2008355A FR2008355A FR3113347A1 FR 3113347 A1 FR3113347 A1 FR 3113347A1 FR 2008355 A FR2008355 A FR 2008355A FR 2008355 A FR2008355 A FR 2008355A FR 3113347 A1 FR3113347 A1 FR 3113347A1
Authority
FR
France
Prior art keywords
data
document
user
service
dematerialized
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
FR2008355A
Other languages
English (en)
Other versions
FR3113347B1 (fr
Inventor
Fabien Combret
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Imprimerie Nationale
Original Assignee
Imprimerie Nationale
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Imprimerie Nationale filed Critical Imprimerie Nationale
Priority to FR2008355A priority Critical patent/FR3113347B1/fr
Publication of FR3113347A1 publication Critical patent/FR3113347A1/fr
Application granted granted Critical
Publication of FR3113347B1 publication Critical patent/FR3113347B1/fr
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/32—User authentication using biometric data, e.g. fingerprints, iris scans or voiceprints
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • G06F21/645—Protecting data integrity, e.g. using checksums, certificates or signatures using a third party
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/352—Contactless payments by cards
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3821—Electronic credentials
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3821—Electronic credentials
    • G06Q20/38215—Use of certificates or encrypted proofs of transaction rights
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G06Q20/4014—Identity check for transactions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Finance (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Health & Medical Sciences (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

L’invention concerne un procédé et un système pour mettre à jour ou créer un ensemble de données d’un document dématérialisé mémorisé au sein d’un terminal mobile d’un usager et pour utiliser lesdites données pour exécuter un service en ligne, le terminal mobile comprenant des moyens de communication avec un dispositif de service (31) et avec un serveur comprenant plusieurs registres métiers contenant un ensemble d’informations propres à un document dématérialisé. Figure pour l’abrégé : Fig. 4

Description

PROCEDE ET DISPOSITIF DE MISE A JOUR DE DONNEES D’UN DOCUMENT DEMATERIALISE POUR L’EXECUTION D’UN SERVICE OU D’UN CONTROLE
L’invention concerne un procédé et un dispositif pour la mise à jour des données personnelles d’un usager, notamment lorsque les données sont requises pour l’exécution d’un service. Les données nécessaires à la réalisation de ce service sont stockées dans un document dématérialisé au niveau du terminal mobile de l’usager. Par document dématérialisé, on entend un document au format numérique, un fichier qui contient les mêmes informations que le document physique.
Le service est, par exemple, un contrôle de données contenues dans une pièce d’identité, un passeport, un permis de conduire, un certificat de circulation, etc., l’accès par un titulaire à un service public en ligne de gestion de son permis de conduire, la consultation de son compte en banque en ligne.
Actuellement, le contrôle de données propres à un individu s’effectue généralement à l’aide de documents physiques. Ces documents peuvent prendre de multiples formes : vignette, papier imprimé sur et avec des formats divers, sans intégration de fonctions de sécurité, document fiduciaire imprimé avec des fonctions de sécurité (telles que des encres spécifiques, des hologrammes, des fibres spécifiques pour le papier, etc.). Actuellement, les autorités de contrôle s’intéressent à distribuer des versions numériques de ces documents, en complément ou en substitution des supports physiques pour le futur. Ceci conduit à définir de nouveaux formats et de nouvelles règles de contrôle.
Actuellement, l’organisation internationale de standardisation ISO (International Standard Organisation), l’Organisation de l’Aviation Civile Internationale (OACI) ou encore l’Association Française pour la NORmalisation (AFNOR) contribuent à cet effort de développement. Leur mandat consiste notamment à garantir l’interopérabilité des produits qui seront commercialisés sous l’étiquette « document numérique » ou « application mobile d’identité ». Ces normes s’intéressent à l’échange entre le contrôleur (ou un service requis) et l’usager lors d’un contrôle (ou d’un service demandé par l’usager).
Depuis plusieurs années, il est déconseillé de mettre à jour les documents physiques imprimés notamment du fait des inconvénients résultant de la manipulation des documents. Une des seules exceptions qui subsistent à ce jour est l’apposition d’un Visa sur les passeports ou les tampons sur la carte d’électeur.
La figure 1 illustre une succession d’étapes de mise à jour des données personnelles d’un usager sur un document physique. Lors d’une première étape 11, afin de mettre à jour son document, le porteur ou usager doit se déplacer chez un représentant d’une autorité afin que cette dernière apporte les modifications nécessaires aux données personnelles. A défaut de pouvoir se déplacer, l’usager peut se faire représenter. L’autorité va vérifier, 12, qu’elle est en capacité de réaliser la mise à jour des documents et demander au porteur de lui fournir différents justificatifs, ainsi que le paiement de la prestation pour la mise à jour. Dans l’exemple d’un vote, le porteur de la carte d’électeur doit présenter sa carte d’identité et être muni d’un bulletin de vote. Si l’autorité possède les éléments pour la mise à jour, elle réalise les modifications, 13. Dans le cas contraire, elle peut vérifier s’il y a d’autres documents à mettre à jour, 14, avant de mettre fin à l’opération de mise à jour.
Cette solution exige la présence du porteur du document et celle du représentant de l’autorité pour effectuer chaque mise à jour requise. De plus, dans la plupart des cas, le document à mettre à jour est confié à l’autorité le temps de sa mise à jour. Par exemple, lors d’une suspension de permis de conduire, l’autorité compétente va convoquer le titulaire pour confisquer son permis. Cela nécessite donc une prise de rendez-vous, des locaux pour recevoir le titulaire du permis, un délai pour la mise à jour et une éventuelle indisponibilité temporelle du document. Une mise à jour de documents peut aussi requérir le déplacement du titulaire dans des zones géographiques différentes.
La mise à jour nécessite, dans certains cas, d’apposer un tampon, de coller une vignette. Elle fait donc appel à une filière et une chaîne spécifique pour que les personnes responsables des mises à jour disposent du matériel nécessaire.
Lorsque le support du document est en polycarbonate et/ou recouvert d’un laminât de sécurité protégeant les données, la mise à jour demande des manipulations techniques spécifiques, un matériel approprié.
La figure 2 illustre un autre exemple de mise à jour des données personnelles propres à un individu par un gestionnaire d’application.
Lors d’une première étape 21, le porteur du document à mettre à jour démarre une application mobile installée sur un terminal, un ordinateur personnel ou un téléphone intelligent ou Smartphone. L’application mobile contient un ou plusieurs documents qui ont été préalablement dématérialisés. Le porteur va ensuite s’identifier, 22, afin de garantir qu’il est autorisé à accéder à l’application mobile. Pour cela, il va utiliser un moyen de reconnaissance comme un code personnel d’authentification ou code PIN (Personal Identification Number), la vérification d’empreintes digitales, la vérification de son iris ou encore sa voix. Le porteur ayant été identifié, l’application mobile vérifie qu’elle est utilisable, 23. Pour cela, elle doit se connecter à un gestionnaire d’application qui a comme rôle de vérifier que l’application respecte différentes règles définies par l’émetteur de l’application mobile. Lors de cette connexion, un canal sécurisé est créé entre l’application mobile et le gestionnaire d’application, 24. L’authentification mutuelle garantit que l’application est autorisée à se connecter au gestionnaire d’application et elle garantit aussi que le gestionnaire d’application est autorisé à apporter des modifications à l’application mobile. L’application interroge, 25, le gestionnaire d’application afin de mettre à jour ses données. L’application vérifie si les données sont à jour 26. Dans le cas où les données ne sont pas à jour, le gestionnaire d’application envoie à l’application, pour chaque document, les données à mettre à jour, 27.
Pour pouvoir être mise à jour, l’application doit être conforme au gestionnaire d’application et sa mise à jour effectuée simultanément à celle de l’application. Cette solution nécessite donc la mise en place d’un gestionnaire d’application qui garde en mémoire l’état de l’application et qui récupère, à partir d’autres services, des informations à lui transmettre. Ce mode basé sur un serveur centralisant les données à envoyer à l’application est pénalisant car il réplique plus ou moins les données d’autres services.
Dans l’éventualité où la mise à jour doive être réalisée au moment de l’utilisation de l’application mobile pour des services qui lui sont propres, par exemple le contrôle de qualité ou de droits, il est possible que le gestionnaire d’application soit indisponible. Ainsi, certaines données des documents qui auraient nécessité une mise à jour ne sont pas disponibles pour cet usage.
Le processus de mise à jour n’est pas automatique.
La mise à jour des données doit être régie par une politique qui évite la surcharge du gestionnaire d’application.
La mise à jour n’est pas forcément nécessaire.
La validité d’une donnée n’est jamais garantie. En cas d’utilisation d’un service qui nécessite l’usage d’une application mobile, il se peut que la donnée ne soit pas à jour et qu’une donnée inconsistante soit utilisée. De même, certains usagers mal intentionnés, pourraient vouloir interrompre toute connexion au gestionnaire d’application, afin que ce dernier ne transmette pas toutes les informations mises à jour à l’application mobile.
Le gestionnaire d’application est accessible à une même adresse. Le gestionnaire d’application représente un point de contact unique dans l’architecture décrite. En particulier, l’application doit sauvegarder les paramètres suffisants et nécessaires pour pouvoir échanger avec le gestionnaire d’application. Un point de contact unique est une faiblesse de conception, car il peut concentrer des attaques par déni de service ou tout autre mécanisme évolué mis en œuvre par des pirates pour nuire à cette application.
La suite de la description utilise la terminologie suivante :
Autorité : une personne physique ou morale qui a le droit d’agir sur les documents du citoyen : délivrance, mise à jour de données, suspension ou retrait du document.
Service : désigne une interaction entre deux entités physiques ou immatérielles pendant laquelle une entité rend service à l’autre ou une interaction qui est rendue nécessaire par la Loi. Un service peut être de proximité ou distant. Par exemple, la vente de certains produits est un service de proximité encadré par la Loi et nécessite la présentation d’une preuve de majorité rendue possible par la présentation d’un document d’identité. Egalement, la gestion d’un permis de conduire est un service distant encadré par la Loi. Pour accéder à ce service, le citoyen doit s’identifier. Un des moyens d’identification repose sur la présentation d’une identité dématérialisée stockée dans une application mobile.
Registre métier : il s’agit d’un ensemble d’informations, généralement regroupées sous forme de base de données, qui constituent le référentiel des informations liées à un droit, une qualité, un document. Par exemple, en France, la base baptisée TES regroupe l’ensemble des données des personnes ayant fait une demande de carte d’identité. Les registres d’Etat Civil qui, dès la naissance d’une personne, stockent des données relatives à cette personne. Ces registres sont aujourd’hui très majoritairement informatisés et il est ainsi possible d’y accéder à distance.
Contrôleur : un contrôleur est une personne physique. Il a la légitimité pour vérifier qu’un usager ou un objet utilisé par l’usager possède un ensemble de qualités requises au droit qu’il réclame. Par exemple, un contrôleur vérifie que l’usager a le droit de circuler dans un véhicule en s’assurant de la qualité de conducteur de l’usager et que le véhicule détient un certificat de contrôle technique valide.
Dispositif de contrôle : un moyen permettant à un contrôleur de valider qu’un usager possède une qualité, un droit ou qu’un objet dont il a la propriété possède un droit. Le dispositif peut être matériel ou immatériel.
Qualité : un attribut ou un ensemble d’attributs propres à un ensemble de personnes ou d’objets. Pour une personne il s’agit d’un métier, d’une compétence, de son nom, de son prénom, de sa date de naissance, par exemple. Pour un objet, il s’agit d’une caractéristique physique telle que la forme, la couleur, le poids. Une qualité est donc nécessaire mais rarement suffisante pour distinguer une personne ou un objet de manière unique. Exemple de qualité : médecin, majeur / mineur, Indice de Masse Corporelle, taille.
Usager : une personne physique qui possède une identité. Cet usager possède des objets qui doivent être munis de qualité.
Administrateur de Registre métier : personne en charge d’apporter des modifications au registre métier. En particulier, elle a la charge de créer les documents dématérialisés stockés dans le registre métier.
Un fichier dit miroir est un fichier qui comporte des informations, données ou paramètres de même type que le fichier origine, les valeurs de ces données pouvant être différentes si elles n’ont pas été mises à jour.
L’un des objectifs de la présente invention est de fournir un procédé et un dispositif qui vont permettre de mettre à jour des données personnelles à un individu sans nécessiter la chaîne de mise à jour complexe connue de l’art antérieur, tout en assurant que le contrôle ou la mise à jour des données sera effectué avec les données les plus fidèles aux registres métiers.
L’idée de la présente invention repose sur une nouvelle approche qui évite l’utilisation d’un gestionnaire d’application en fonctionnement normal. Le procédé repose sur l’utilisation d’un service, distant ou local, qui a notamment pour fonction de communiquer les informations à mettre à jour, ainsi que les adresses des services qui contiennent les données à jour. Le procédé permet aussi une authentification entre le service de mise à jour et une application mobile, qui lui confère une sécurité élevée.
L’invention concerne un procédé pour mettre à jour ou créer un ensemble de données d’un document dématérialisé mémorisé au sein d’un terminal mobile d’un usager et pour utiliser lesdites données pour exécuter un service en ligne, le terminal mobile comprenant des moyens de communication avec un dispositif de service et avec un serveur comprenant plusieurs registres métiers contenant un ensemble d’informations propres à un document caractérisé en ce qu’il comporte au moins les étapes suivantes:
  • L’usager s’authentifie au niveau de son terminal mobile afin d’accéder à un plusieurs documents dématérialisés stockés au niveau du terminal, et active une application mobile configurée pour la mise à jour de données,
  • L’application mobile et le service interrogé s’authentifient mutuellement, afin d’établir une connexion sécurisée,
  • Le service interrogé transmet à l’application mobile de l’usager un fichier contenant un identifiant pour l’usager et des données propres au service interrogé,
  • L’application mobile de l’usager se connecte à au moins un registre métier correspondant au service requis, grâce à l’identifiant et transmet une requête de mise à jour de données ou de création de documents aux registres métiers,
  • Le registre métier interrogé transmet les données à mettre à jour ou pour la création d’un document dématérialisé à l’application mobile de l’usager, afin de mettre à jour ou de créer le ou les documents dématérialisés stockés dans le terminal mobile de l’usager,
  • L’usager utilise ensuite les données mises à jour pour exécuter le service.
Pour mettre à jour les données mémorisées au niveau de l’usager, l’application mobile vérifie que la donnée possède une date de validité et dans le cas où cette date existe, l’application mobile compare les données mémorisées dans un document dématérialisé aux données transmises par le registre métier de ce document dématérialisé afin de remplacer les données mémorisées au niveau de l’usager par les données fournies par le registre métier.
Lorsque la requête générée par l’application mobile est une requête de création de documents dématérialisés, le registre métier correspondant à ce document dématérialisé transmet l’ensemble des informations qu’il contient pour la création d’un document dématérialisé.
L’usager s’authentifie, par exemple, en utilisant un code d’authentification personnelle PIN.
L’usager peut aussi s’authentifier en utilisant un moyen biométrique.
Les données mises à jour peuvent être utilisées pour un contrôle d’un document dématérialisé par un dispositif sécurisé et assermenté ou par l’usager pour exécuter un service en ligne.
L’invention concerne aussi un système pour la mise à jour ou la génération de données d’un document dématérialisé au sein d’un terminal mobile d’un usager équipé d’une application mobile, d’un moyen d’authentification et de moyens de communication. Le système comprend un serveur stockant un ou plusieurs registres métiers contenant un ensemble d’informations relatives à un ou plusieurs documents dématérialisés, un dispositif comprenant un ou plusieurs services, des moyens d’authentification de l’usager, des moyens de communications et des informations structurées dans une base de données. L’application mobile est configurée pour exécuter les étapes du procédé selon l’invention afin de mettre à jour les données d’un ou de plusieurs documents dématérialisés stockés dans une zone de stockage et d’utiliser lesdites données pour exécuter un service requis.
L’application mobile est configurée pour exécuter les étapes du procédé selon l’invention afin de mettre à jour les données d’un ou de plusieurs documents dématérialisés stockés dans une zone de stockage et d’utiliser lesdites données pour exécuter un service requis
Le terminal mobile de l’usager est, par exemple, un téléphone mobile intelligent.
Le document dématérialisé est, par exemple, un titre d’identité
D’autres caractéristiques, détails et avantages de l’invention ressortiront à la lecture de la description faite en référence aux dessins annexés donnés à titre d’exemple illustratifs et non limitatifs et qui représentent, respectivement :
une succession d’étapes d’un procédé de mise à jour de documents selon l’art antérieur,
un deuxième exemple de procédé de mise à jour de données selon l’art antérieur,
un exemple de structure ou dispositif pour la mise en œuvre du procédé selon l’invention,
un organigramme représentant les étapes du procédé selon l’invention,
un schéma illustrant l’ajout de documents dématérialisés dans un registre par un administrateur,
un exemple d’étapes exécutées par un service interrogeant un registre.
L’exemple qui suit est donné à titre illustratif et nullement limitatif. La mise en œuvre du procédé et du système selon l’invention mettent en œuvre des technologies connues qui ne seront pas détaillées, dont :
Les protocoles de réseau de type http, HTTPS, SSL, Web, TCP/IP, etc.
Le formatage de données, de type XML, JSON (JavaScript Object Notation),
Les protocoles de sécurité : authentification mutuelle basée sur un algorithme de chiffrement symétrique 3DES, AES (Advanced Encryption Standard), l’algorithme de cryptographique asymétrique RSA.
Le procédé de mise à jour de données selon l’invention, pour l’exécution d’un service en ligne ou d’un contrôle, repose sur l’utilisation d’un service distant ou local qui est configuré pour communiquer les informations à mettre à jour et les adresses de service qui contiennent les données à jour. Seules les données nécessaires à la réalisation d’un service seront mises à jour. Le procédé offre la possibilité d’ajouter de manière dynamique des documents ou des données dans l’application mobile. De plus, l’authentification entre le service et l’application mobile confère au procédé un niveau de confiance élevé dans les échanges de données et la réalisation du service.
La figure 3 illustre un exemple de structure d’un système pour la mise en œuvre du procédé de mise à jour des données selon l’invention. Un usager possède un terminal mobile 30, par exemple un téléphone mobile intelligent connu sous la dénomination Smartphone. Le terminal mobile est équipé de moyens de communication 303 connus de l’homme du métier ayant pour fonction d’échanger des données avec d’autres dispositifs. Une application mobile 301 est implémentée sur le terminal mobile. Cette application mobile possède différentes fonctions qui seront explicitées ci-après. Une zone de stockage 302 permet de mémoriser les données à mettre à jour et mises à jour. Des moyens d’authentification 304 sont configurés pour authentifier l’usager, ces moyens peuvent être la reconnaissance vocale, une reconnaissance par iris, par empreinte digitale, une interface pour l’introduction d’un code PIN ou tout autre moyen connu de l’homme du métier.
La zone de stockage comprend plusieurs fichiers de données, chaque fichier correspondant à un document dématérialisé.
Le système comprend aussi un dispositif 31 comprenant un ou plusieurs services 311. Le dispositif 31 comporte aussi des moyens de communication 312 permettant d’échanger des informations avec l’application mobile 301 de l’usager via les moyens de communication 303 de l’usager et des moyens de validation 313 de l’authentification de l’usager pour l’exécution d’un service.
Le système comporte aussi plusieurs registres métiers 32 stockés sur un serveur 38. Chaque registre métier contient des données propres à un document dématérialisé ou un document physique. Un registre métier comprend aussi des moyens de communication 322 permettant d’échanger des données avec l’application mobile et des moyens de validation de l’authentification 323. Un registre métier comprend aussi une base de données 324. Cette base de données va permettre de mémoriser des données propres à un métier qui serviront notamment pour la mise à jour des données existantes au niveau du terminal mobile de l’usager ou pour la création d’un document dématérialisé au niveau du terminal mobile.
Pour chaque registre métier, il existe un document dématérialisé miroir au niveau du terminal mobile de l’usager, ce document se présente sous la forme d’un fichier et contient des données similaires à celles du registre métier.
La figure 4 illustre les étapes exécutées par le procédé selon l’invention.
Lors d’une première étape 41, l’usager démarre son application mobile 301 afin d’accéder à un ou plusieurs documents dématérialisés et stockés dans son téléphone mobile.
Lors d’une deuxième étape 42, l’usager va s’authentifier afin d’obtenir l’autorisation d’accéder à l’application mobile 301. Pour cela, il utilise un moyen de reconnaissance de son identité, comme un code PIN, la vérification d’empreintes digitales, la vérification de son Iris, de sa voix.
L’application mobile étant activée, lors d’une troisième étape 43, l’usager se connecte, via son application mobile, à un service qui est distant ou à un service de proximité qui utilise les données de l’application pour la bonne exécution du service requis par l’usager. Par exemple, le service appelé est le service de déclaration d’impôts en ligne qui va demander à l’application d’utiliser le nom, le prénom, la date de naissance et l’adresse de l’usager pour l’identifier. Egalement, une fois l’identification réalisée, il peut demander le nombre d’enfants et le statut marital au document « livret de famille » dématérialisé de l’application mobile. L’exécution du service fait appel à deux documents dématérialisés stockés au niveau du terminal mobile de l’usager.
Grâce à un mécanisme cryptographique lors d’une quatrième étape 44, l’application mobile de l’usager et le service interrogé s’authentifient mutuellement. Cela permet d’établir une connexion sécurisée et de créer une relation de confiance entre l’usager et le service. La connexion sécurisée est établie selon des échanges connus de l’homme du métier. Par exemple, le protocole de sécurité plus connu sous l’acronyme anglo-saxon TLS (Transport Layer Security) est une solution très répandue à l’établissement de cette connexion sécurisée.
La connexion sécurisée étant établie, lors d’une cinquième étape 45, le service envoie à l’application mobile de l’usager, les informations détaillant les documents et les données qui vont être utilisés pour l’exécution du service. Ces informations incluent aussi les identifiants de connexion de l’usager aux différents registres métiers, afin que l’application mobile de l’usager vérifie si elle possède les documents dématérialisés requis par le service et qu’elle puisse récupérer les données pour une éventuelle mise à jour ou pour la création des documents dématérialisés.
Le service indique à l’application mobile les informations dont il a besoin à l’aide d’une requête. Les informations requises par le service sont contenues dans les registres métiers.
L’application mobile 301 de l’usager dialogue avec les registres métiers 32 dont elle a besoin pour exécuter le service, en transmettant des requêtes de mise à jour ou de création de documents dématérialisés, lors d’une sixième étape 46.
Les documents dématérialisés sont stockés dans l’application mobile selon un référentiel géré par chaque registre métier incluant l’ensemble des paramètres techniques nécessaires à l’interopérabilité entre les services et l’application mobile. Le référentiel a pour fonction d’identifier de manière unique les documents dématérialisés et d’indiquer les règles métiers afférentes à chaque donnée, en particulier la durée de validité d’une donnée. Les données des documents sont stockées dans l’application avec au moins les deux paramètres suivants : la date de dernière mise à jour Dmajet la durée Tvpendant laquelle les données peuvent être stockées sans effectuer de mise à jour.
La connexion est réalisée grâce aux identifiants de connexion d’un usager aux registres métiers. En cas d’échec de connexion, les données ne seront pas mises à jour.
En cas de connexion établie, une requête est émise par l’application mobile 301 de l’usager vers un ou plusieurs registres métiers, étape 47.
Si le document dématérialisé n’existe pas au niveau du terminal mobile, l’application mobile va le générer. Pour cela, l’application mobile émet une requête vers un registre métier dans laquelle il est indiqué qu’il s’agit de la création d’un document Rq(création) 47a pour la différencier de la requête de mise à jour Rq(mise à jour), 47b. De même, une réponse d’un registre métier est indiquée comme Rp(métier) 47c. La réponse contient les données pour la mise à jour ou la création d’un document dématérialisé. Pour chaque accès à un registre métier, on génère une requête, donc un fichier par requête avec des données qui sont propres au service.
Chaque registre métier 32 va analyser la requête qu’il reçoit, requête de création de documents dématérialisés au niveau du terminal mobile d’un usager ou requête de mise à jour de données, 48, et va retourner une réponse Rp(métier), contenant les données requises.
Pour une requête de mise à jour Rq(mise à jour, type de document), le registre métier transmet les données mises à jour pour le document indiqué dans la requête.
Pour la mise à jour de données, l’application mobile compare, 49a, les données transmises par le registre métier avec les données stockées et effectue si besoin les modifications en remplaçant les données mémorisées par les nouvelles données reçues du registre métier. Par exemple, le statut d’un permis de conduire peut être modifié de la valeur « suspendu » à la valeur « valide », la date d’échéance d’un certificat d’assurance d’un véhicule prolongée ou raccourcie.
Pour une requête de création de documents dématérialisés Rq(création, type de documents), le registre métier qui a reçu la requête transmet l’ensemble des informations qu’il possède pour générer ce document.
Pour chaque requête reçue de l’application mobile, un registre métier envoie une requête unique à l’application mobile de l’usager.
L’application mobile 301 récupère les données transmises par le registre métier et met à jour ses données contenues dans la base de données et qui correspondent à un document matérialisé, 49, ou crée le document dématérialisé.
La requête ayant été traitée par l’application mobile, les données ont été mises à jour ou créées au niveau de l’application mobile, 49. L’usager va pouvoir répondre à la demande d’un contrôle ou d’un service, 50 en utilisant les données qu’il a mis à jour dans sa base de données.
Les échanges entre le service requis et l’usager s’effectuent selon des protocoles de préférence sécurisés connus de l’homme du métier.
Le service peut être un contrôle des droits du porteur du terminal mobile effectué au moyen d’un dispositif de contrôle électronique détenu par une autorité. Le service de contrôle peut alors vérifier les données associées au droit selon un protocole d’échange à distance connu de l’homme du métier.
La figure 5 illustre une succession d’étapes permettant l’ajout de documents dématérialisés dans un registre métier.
Un administrateur ayant les droits requis accède à un registre dans lequel on souhaite ajouter un ou plusieurs documents dématérialisés. L’administrateur se connecte, 61, au registre en utilisant une technique connue de l’homme du métier, par exemple, par un couple d’identification de connexion/mot de passe, l’utilisation d’une carte à puce, d’un code PIN, etc.
L’administrateur va ajouter au registre, 62, un ensemble de paramètres qui décrivent un document dématérialisé. Ces paramètres sont, par exemple, le nom du document, son identifiant et ses données. Chaque donnée est associée à un descriptif, à un identifiant et à une durée de validité. La durée de validité sert à l’application mobile à savoir si une donnée peut être communiquée à un service ou si l’application doit effectuer une mise à jour. Cet ajout est réalisé à l’aide d’une interface homme/machine connue de l’homme du métier.
La figure 6 illustre les étapes d’interrogation du registre par un service.
Le service va se connecter, 71, à un registre. Le service émet une requête de demande de données relatives aux documents, 72. Le registre répond ensuite au service avec les informations dont il a besoin, 73. Ces informations sont stockées au niveau du service.
L’étape de connexion peut se faire avec ou sans identification du service. Si l’identification est utilisée, elle peut être réalisée grâce à un couple identifiant de connexion/mot de passe. La connexion peut être établie selon le protocole http avec une protection en confidentialité TLS (Transport Layer Security).
La requête de demande de données peut être émise sous la forme d’un fichier xml ayant la structure suivante :
Balise Paramètres Détail
Service name La balise Service regroupe les informations demandées par un service à une application mobile. Le nombre de balise Service est égal à un. La balise n’est rattachée à aucune autre.
  • Le paramètre name identifie en langage naturel le service à l’origine de la demande
La réponse se présente, par exemple, sous la forme d’un fichier xml dont la structure est la suivante :
Balise Paramètres Détail
Register name La balise Register regroupe les informations stockées dans un registre. Le nombre de balise Register est égal à un. La balise n’est rattachée à aucune autre.
  • Le paramètre name identifie en langage naturel le registre métier
Document name
idUnique La balise Document regroupe les informations concernant un document stocké dans le registre. Le nombre de balise Document est supérieur ou égal à un. Une balise Document est hiérarchiquement rattachée à une balise Service.
  • Le paramètre name identifie en langage naturel le document
  • Le paramètre idUnique est un identifiant technique transmis par le service
 Data name
id La balise Data définit une donnée du document stockée dans le registre. Le nombre de balise Data est supérieur ou égal à un. Une balise Data est hiérarchiquement rattachée à une balise Document.
  • Le paramètre name identifie en langage naturel la donnée
  • Le paramètre id est un identifiant technique transmis par le service
 RegisterConnexion name La balise RegisterConnexion définit un moyen de connexion au Registre. Une balise RegisterConnexion est hiérarchiquement rattachée à une balise Register. Le nombre de balise RegisterConnexion est supérieur ou égal à un.
  • Le paramètre name identifie en langage naturel le registre métier
 IPAddress value La balise IPAddress définit l’adresse réseau du registre métier auquel l’application mobile doit se connecter. Une balise IPAddress est hiérarchiquement rattachée à une balise Register. Le nombre de balise IPAddress est égal à un.
  • Le paramètre value indique la valeur de l’adresse réseau
 ConnexionPort value La balise ConnexionPort définit le port du registre métier auquel l’application mobile doit se connecter. Une balise ConnexionPort est hiérarchiquement rattachée à une balise Register. Le nombre de balise ConnexionPort est égal à un.
  • Le paramètre value identifie la valeur du port
 Token value La balise Token définit un jeton technique utilisé lors de la connexion au registre. Une balise Token est hiérarchiquement rattachée à une balise Register. Le nombre de balise Token est égal à un.
  • Le paramètre value identifie la valeur du jeton technique
Comme indiqué précédemment, le service exécuté peut être la déclaration en ligne des impôts avec la mise à jour des données personnelles de l’individu.
Une autre application peut être la mise à jour des données d’un passeport, avec la modification d’une adresse.
Après avoir décrit de manière générique les étapes exécutées par le procédé selon l’invention, quelques exemples détaillés de mise en œuvre du procédé selon l’invention vont être donnés.
L’exemple détaillé qui suit est donné à titre illustratif et nullement limitatif dans le cadre d’un contrôle routier pour lequel le service de contrôle, réalisé par un agent assermenté, nécessite que l’usager lui transmette les données du permis de conduire et du certificat de circulation de son véhicule mises à jour par le procédé selon l’invention.
L’agent qui souhaite contrôler le permis de conduire d’un automobiliste et le certificat de circulation de son véhicule transmet une requête de contrôle Rq(contrôle) à l’application mobile de l’usager afin que ce dernier lui transmette les informations requises, après éventuellement avoir mis à jour ces informations. La requête de contrôle est émise par le service 311 du dispositif de contrôle 31 et transmise vers l’application mobile 301 de l’usager via les moyens de communication 352 du dispositif de contrôle et ceux du terminal mobile de l’usager.
La requête Rq(contrôle) peut se présenter sous la forme d’un fichier FcRq).
Le fichier Fc(Rq) envoyé par le service de contrôle à l’application mobile 301 contient les données requises par le service de contrôle, ici des informations relatives au permis de conduire et au certificat de circulation du véhicule, ainsi que les identifiants de connexion de l’usager aux deux Registres métiers correspondant. En effet, l’automobiliste aura peut-être besoin de mettre à jour les informations, s’il ne l’a pas encore fait, et a donc besoin de données permettant de s’identifier.
Le fichier Fu(Rq) mémorisé au niveau du terminal mobile de l’usager par l’application mobile comprend, dans cet exemple, des données propres au permis de conduire et au certificat de circulation du véhicule conduit par l’automobiliste. On dispose de deux fichiers correspondant aux deux documents dématérialisés.
Détail de l’étape des échanges entre les registre s métier s et l’ application mobile pour la mise à jour de données .
Les registres métier sollicités, registre des permis de conduire et registre des certificats de circulation, transmettent chacun un fichier de données à l’application mobile du porteur du terminal mobile. Le fichier transmis comprend les données requises par le service qui doivent être éventuellement mises à jour, ainsi que les identifiants de connexion pour le titulaire aux registres du permis de conduire et de certificat de circulation.
Les données requises par le service de contrôle du permis de conduire et de contrôle du certificat de circulation, comprennent au moins :
Pour le permis de conduire, un fichier Fc(permis de conduire), le nom de famille et le prénom, la date de naissance, le numéro, la date d’obtention, les permis obtenus, la date d’expiration du permis de conduire, les restrictions éventuelles de circulations.
Pour le certificat de circulation un fichier Fc(certificat immatriculation), l’identité (nom et prénom) du propriétaire du véhicule, les caractéristiques techniques du véhicule, poids, largeur, la marque, la date de production, la date de mise en service, la date d’acquisition, le numéro de la plaque d’immatriculation, l’adresse du propriétaire, etc.
Ces deux fichiers ont des fichiers miroirs stockés dans le terminal mobile de l’usager, dont les données vont être utilisées lors du contrôle, après leur mise à jour à l’aide des données transmises par le registre métier. Dans le cas où l’un des fichiers est absent du terminal mobile, le procédé selon l’invention va le créer en utilisant les données qui seront transmises par un registre métier.
Chaque donnée mémorisée dans un fichier ou un registre métier est associée à une date de mise à jour et une durée de validité. Certaines données ne comportent pas de durée de validité car elles n’ont pas à être mises à jour, par exemple, la date de naissance du titulaire du permis de conduire.
Un exemple de format de fichier contenant les données demandées par un service ainsi que les identifiants de connexion au registre métier, transmis par le service interrogé à l’application mobile est donné ci-après :
Balise Paramètres Détail
Service Nom du service La balise Service regroupe les informations demandées par un service à une application mobile. Le nombre de balise Service est égal à un. La balise n’est rattachée à aucune autre.
Document nom
idUnique		 La balise Document regroupe les informations que l’application mobile devra communiquer au service lors de la transaction à venir. Le nombre de balise Document est supérieur ou égal à un. Une balise Document est hiérarchiquement rattachée à une balise Service.
  • Le paramètre nom identifie en langage naturel le document
  • Le paramètre idUnique est un identifiant technique transmis par le service
Données Nom
id La balise Données définit la ou les données que l’application mobile devra communiquer au service lors de la transaction à venir. Le nombre de balise Données est supérieur ou égal à un. Une balise Données est hiérarchiquement rattachée à une balise Document.
  • Le paramètre nom identifie en langage naturel la donnée
  • Le paramètre id est un identifiant technique transmis par le service
 Registre nom La balise Registre définit le registre métier auquel l’application mobile doit se connecter Une balise Registre est hiérarchiquement rattachée à une balise Document. Le nombre de balise Registre est supérieur ou égal à un.
  • Le paramètre nom identifie en langage naturel le registre métier
 IPAddress valeur La balise IPAddress définit l’adresse réseau du registre métier auquel l’application mobile doit se connecter. Une balise IPAddress est hiérarchiquement rattachée à une balise Registre. Le nombre de balise IPAddress est égal à un.
  • Le paramètre valeur indique la valeur de l’adresse réseau
 ConnexionPort valeur La balise ConnexionPort définit le port du registre métier auquel l’application mobile doit se connecter. Une balise ConnexionPort est hiérarchiquement rattachée à une balise Registre. Le nombre de balise ConnexionPort est égal à un.
  • Le paramètre valeur identifie la valeur du port
 Jeton ou Token valeur La balise Token définit un jeton technique utilisé lors de la connexion au registre. Une balise Token est hiérarchiquement rattachée à une balise Registre. Le nombre de balise Token est égal à un.
  • Le paramètre valeur identifie la valeur du jeton technique
L’application mobile de l’usager, lors de l’étape de mise à jour de données dans un document dématérialisé stocké au niveau de sa base de données ou de création de document dématérialisé, 47, transmet une requête par Registre Métier pour récupérer les informations à mettre à jour.
Le fichier stocké par l’application mobile 31 peut respecter le format suivant :
Balise Paramètres Détail
MobileApplication nom La balise MobileApplication regroupe les informations stockées dans l’application. Le nombre de balise MobileApplication est égal à un. La balise MobileApplication n’est rattachée à aucune autre.
  • Le paramètre nom identifie en langage naturel l’application
Document nom
idUnique
creationDate La balise Document regroupe les informations d’un document dématérialisé stocké par une application mobile. Le nombre de balise Document est supérieur ou égale à un. Une balise Document est hiérarchiquement rattachée à une balise MobileApplication.
  • Le paramètre nom identifie explicitement le nom du document
  • Le paramètre idUnique est un identifiant technique du document
  • Le paramètre creationDate indique la date à laquelle le document a été créé
 Donnée nom
id
validityPeriod
updateDate
valeur La balise Donnée définit une donée stockée dans un document dématérialisé. Le nombre de balise Donnée est supérieur ou égale à un. Une balise Donnée est hiérarchiquement rattachée à une balise Document.
  • Le paramètre nom identifie en langage naturel la donnée
  • Le paramètre id est un identifiant technique de la donnée
  • Le paramètre validityPeriod indique le nombre de jour pendant lesquels la donnée est valide. 0 signifie qu’il n’y a pas de limite de validité
  • Le paramètre updateDate indique la Donnée à laquelle la donnée a été mise à jour
  • Le paramètre valeur indique la valeur de la donnée dans la mémoire du téléphone
L’algorithme exécuté par l’application mobile pour récupérer les données à mettre à jour ou pour la création d’un document dématérialisé au niveau de l’application mobile comprend par exemple les étapes suivantes :
Début CréationRequêteRegistreMétier(ApplicationMobile, DonéesService)
PourChaqueBalise DonnéesService.Document
REM L'algorithme recherche si le document est déjà stocké dans le mobile
Résultat = ChercheDocument(ApplicationMobile, DonéesService.Document)
REM La fonction CréerEntêteXML(DonnéesService) crée le fichier de requête. Si le document existe déjà, ce sera une requête de mise à jour, sinon, l’application va créer le document.
REM L'information est passée au Registre.
CréerEntêteXML(DonnéesService, Résultat), résultat = présence ou absence d’un fichier au niveau du terminal mobile
REM Donnée regroupe l'ensemble des balise XML qui sont subalternes à la balise Document
PourChaqueBalise Document.Donnée
Si validityPeriod <> 0 et Date() – update Date > validityPeriod alors
REM la fonction CréerBaliseDonnée(Donnée) crée la balise XML qui correspond au champ de donnée
REM à mettre à jour dans l’application.
CréerBalise(Donnée)
Fin si
FinPourChaqueBalise
REM cette fonction finalise le fichier XML de requête
CréerPiedXML()
Fin PourChaqueBalise
REM Cette fonction envoie la requête (mise à jour ou création d’un document dématérialisé paramétré lors de la création de l’entête) au registre métier
EnvoyerRequête(Document)
Fin
A l’issue de cet algorithme exécuté par l’application mobile de l’usager, la requête de mise à jour des informations du permis du conduire ou de création d’un permis de conduire dématérialisé et la requête relative aux informations du certificat de circulation ont été transmises respectivement au registre métier qui gère les permis de conduire et au registre métier qui gère les certificats de circulation.
La requête de mise à jour des données transmise de l’application mobile vers le registre métier qui gère les permis de conduire peut comprendre les informations suivantes : Le nom du titulaire du permis de conduire, la nature du document, la date d’expiration ou de validité du permis de conduire, la date d’obtention, le statut, etc.
La requête de mise à jour des données transmise vers le registre des certificats de circulation pourra comprendre les données suivantes : Les données propres au modèle du véhicule, la nature du document, le numéro de la plaque, la date d’acquisition du véhicule, etc.
Une possibilité de format pour la requête issue de l’algorithme décrit ci-dessus et transmise vers un registre métier est donnée ci-après à titre d’exemple.
Balise Paramètres Détail
Registre nom La balise Registre définit le registre auquel la requête est adressée. Le nombre de balise Registre est égal à un. La balise Registre n’est rattachée à aucune autre.
  • Le paramètre nom identifie en langage naturel le nom du registre
Document nom
idUnique
appStatus La balise Document regroupe les informations d’un document qui doivent être retournée par le registre. Le nombre de balise Document est supérieur ou égal à un. Une balise Document est hiérarchiquement rattachée à une balise Registre.
  • Le paramètre nom identifie en langage naturel le document
  • Le paramètre idUnique est un identifiant technique transmis par le service
  • Le paramètre appStatus indique s’il s’agit d’une mise à jour d’application ou d’une création
 Donnée nom
id
 La balise Donnée définit une donnée à mettre à jour. Le nombre de balise Donnée est supérieur ou égal à un. Une balise Donnée est hiérarchiquement rattachée à une balise Document.
  • Le paramètre nom identifie en langage naturel la donnée.
  • Le paramètre id est un identifiant technique relatif à la donnée
Le registre métier des permis de conduire et le registre métier des certificats de circulation reçoivent chacun une requête et génèrent en retour chacun un fichier qui répond à ces deux requêtes. Ces fichiers comprendront les données pour la mise à jour éventuelle des données stockées en local au niveau du terminal mobile ou d’un ensemble de données pour la création d’un fichier correspondant au permis de conduire dématérialisé.
Par exemple, le fichier généré par le registre métier des permis de conduire qui va être retourné à l’application mobile de l’usager peut comporter les informations mises à jour suivantes : Le nom du titulaire du permis de conduire, la date d’obtention, la date d’expiration, qui vont permettre la mise à jour des données stockées au niveau de l’application mobile de l’usage et qui sont utilisées par le service de contrôle.
De même, le registre des certificats de circulation, transmettra à l’application mobile un fichier contenant les données mises à jour du véhicule : nom du propriétaire, etc.
Les deux fichiers F(permis) et F (certificat) sont reçus par l’application mobile de l’usager. L’application mobile va mettre à jour ses fichiers.
La réponse des registres à l’application mobile se présente par exemple sous le format suivant :
Balise Paramètres Détail
Registre nom La balise Registre définit le registre répondant à la requête. Le nombre de balise Registre est égal à un. La balise Registre n’est rattachée à aucune autre.
  • Le paramètre nom identifie en langage naturel le registre
Document nom
idUnique
appStatus La balise Document regroupe les informations d’un document qui sont retournées par le registre. Le nombre de balise Document est supérieur ou égal à un. Une balise Document est hiérarchiquement rattachée à une balise Registre.
  • Le paramètre nom identifie explicitement le nom du document
  • Le paramètre idUnique est un identifiant technique transmis par le service
  • Le paramètre appStatus indique s’il s’agit d’une mise à jour d’application ou d’une création
 Donnée nom
id
validityPeriod
updateDate
valeur La balise Donnée définit une donnée à mettre à jour. Le nombre de balise Donnée est supérieur ou égal à un. Une balise Donnée est hiérarchiquement rattachée à une balise Document.
  • Le paramètre nom identifie en langage naturel la donnée
  • Le paramètre id est un identifiant technique de la donnée
  • Le paramètre validityPeriod ou période de validité indique le nombre de jours pendant lesquels la donnée est valide. 0 signifie qu’il n’y a pas de limite de validité
  • Le paramètre updateDate indique la Donnée à laquelle la donnée a été mise à jour
  • Le paramètre valeur indique la valeur de la donnée retournée par le registre
Détail de l’étape de mise à jour des données au niveau de l’application mobile 49. Pour la mise à jour des données au sein de l’application mobile, le procédé peut utiliser l’algorithme explicité ci-après.
Début MiseAJourApplicationMobile(ApplicationMobile, DonéesRegistre)
PourChaqueBalise DonnéesRegistre.Document
REM On crée le document s'il n'existe pas, sinon on récupère sa référence
Si DonnéesRegistre.Document.UpdateStatus = "Créer" alors
REM Cette fonction crée le document dans l'application mobile
CréerDocument(DonnéesRegistre.Document, ApplicationMobile)
Sinon
REM L'algorithme recherche le document
DocumentApplication = ChercheDocument(ApplicationMobile, DonéesRegistre.Document)
Fin Si
REM Donnée regroupe l'ensemble des balises XML qui sont subalternes à la balise Document
PourChaqueBalise DocumentRegistre.Document.Donnée
Si DonnéesRegistre.Document.UpdateStatus = "Créer" alors
REM L'algorithme crée l'élément dans l'arborescence du document
CréerDonnée(ApplicationMobile, DonnéesRegistre.Document.Données)
Sinon
REM L'algorithme met à jour la donnée dans l'application mobile
MiseAJour(ApplicationMobile, DonnéesRegistre.Document.Données)
Fin Si
FinPourChaqueBalise
REM cette fonction finalise le fichier XML
CréerPiedXML()
Fin PourChaqueBalise
REM Cette fonction envoie la requête au registre métier
EnvoyerRequête(Document)
Fin
Le procédé selon l’invention permet notamment à un usager de mettre à jour les données lorsqu’il en a besoin pour un service sans faire appel à un gestionnaire d’application. Ce service peut être le contrôle d’un document d’identité, du certificat de circulation d’un véhicule, de l’établissement d’un passeport.

Claims (10)

  1. Procédé pour mettre à jour ou créer un ensemble de données d’un document dématérialisé mémorisé au sein d’un terminal mobile (30) d’un usager et pour utiliser lesdites données pour exécuter un service en ligne, le terminal mobile (30) comprenant des moyens de communication (303) avec un dispositif de service (31) et avec un serveur (38) comprenant plusieurs registres métiers (32) contenant un ensemble d’informations propres à un document dématérialisé caractérisé en ce qu’il comporte au moins les étapes suivantes :
    • L’usager s’authentifie au niveau de son terminal mobile afin d’accéder à un plusieurs documents dématérialisés stockés au niveau du terminal, (41) et active (42) une application mobile configurée pour la mise à jour de données,
    • L’application mobile (301) et le service interrogé s’authentifient mutuellement, afin d’établir une connexion sécurisée, (43, 44),
    • Le service interrogé transmet à l’application mobile de l’usager un fichier contenant un identifiant pour l’usager et des données propres au service interrogé, (45),
    • L’application mobile de l’usager se connecte à au moins un registre métier correspondant au service requis, grâce à l’identifiant (46) et transmet une requête de mise à jour de données ou de création de documents (47) aux registres métiers,
    • Le registre métier interrogé transmet les données à mettre à jour ou pour la création d’un document dématérialisé (48) à l’application mobile de l’usager, afin de mettre à jour ou de créer le ou les documents dématérialisés stockés dans le terminal mobile de l’usager (49),
    • L’usager utilise ensuite les données mises à jour pour exécuter le service (50).
  2. Procédé selon la revendication 1 caractérisé en ce que pour mettre à jour les données mémorisées au niveau de l’usager, l’application mobile vérifie que la donnée possède une date de validité et dans le cas où cette date existe, l’application mobile compare les données mémorisées dans un document dématérialisé aux données transmises par le registre métier de ce document dématérialisé afin de remplacer les données mémorisées au niveau de l’usager par les données fournies par le registre métier.
  3. Procédé selon La revendication 1 caractérisé en ce que lorsque la requête générée par l’application mobile est une requête de création de documents dématérialisés, le registre métier correspondant à ce document dématérialisé transmet l’ensemble des informations qu’il contient pour la création d’un document dématérialisé.
  4. Procédé selon l’une des revendications 1 à 3 caractérisé en ce que l’usager s’authentifie en utilisant un code d’authentification personnelle PIN.
  5. Procédé selon l’une des revendications 1 à 3 caractérisé en ce que l’usager s’authentifie en utilisant un moyen biométrique.
  6. Procédé selon l’une des revendications 1 à 5 caractérisé en ce que les données mises à jour sont utilisées pour un contrôle d’un document dématérialisé par un dispositif sécurisé et assermenté.
  7. Procédé selon l’une des revendications 1 à 5 caractérisé en ce que les données du document dématérialisé sont utilisées par l’usager pour exécuter un service en ligne.
  8. Système pour la mise à jour ou la génération de données d’un document dématérialisé au sein d’un terminal mobile d’un usager équipé d’une application mobile (301), d’un moyen d’authentification (304) et de moyens de communication (303), le système comprenant :
    • un serveur stockant un ou plusieurs registres métiers (32) contenant un ensemble d’informations relatives à un ou plusieurs documents dématérialisés,
    • un dispositif (31) comprenant un ou plusieurs services (311), des moyens de communication (312) et des moyens d’authentification (312),
    caractérisé en ce que l’application mobile (301) est configurée pour exécuter les étapes du procédé selon l’une des revendications 1 à 7 afin de mettre à jour les données d’un ou de plusieurs documents dématérialisés stockés dans une zone de stockage (302), et d’utiliser lesdites données pour exécuter un service requis.
  9. Système selon la revendication 8 caractérisé en ce que le terminal mobile de l’usager est un téléphone mobile intelligent.
  10. Système selon l’une des revendications 8 ou 9 caractérisé en ce que le document dématérialisé est un titre d’identité.
FR2008355A 2020-08-07 2020-08-07 Procede et dispositif de mise a jour de donnees d’un document dematerialise pour l’execution d’un service ou d’un controle Active FR3113347B1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
FR2008355A FR3113347B1 (fr) 2020-08-07 2020-08-07 Procede et dispositif de mise a jour de donnees d’un document dematerialise pour l’execution d’un service ou d’un controle

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR2008355 2020-08-07
FR2008355A FR3113347B1 (fr) 2020-08-07 2020-08-07 Procede et dispositif de mise a jour de donnees d’un document dematerialise pour l’execution d’un service ou d’un controle

Publications (2)

Publication Number Publication Date
FR3113347A1 true FR3113347A1 (fr) 2022-02-11
FR3113347B1 FR3113347B1 (fr) 2022-10-07

Family

ID=73497915

Family Applications (1)

Application Number Title Priority Date Filing Date
FR2008355A Active FR3113347B1 (fr) 2020-08-07 2020-08-07 Procede et dispositif de mise a jour de donnees d’un document dematerialise pour l’execution d’un service ou d’un controle

Country Status (1)

Country Link
FR (1) FR3113347B1 (fr)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150063655A1 (en) * 2013-08-27 2015-03-05 Morphotrust Usa Inc. Digital Identification Document
US20150312251A1 (en) * 2012-02-16 2015-10-29 France Telecom Ensuring the security of a data transmission
WO2019074366A1 (fr) * 2017-10-10 2019-04-18 Morpho B.V. Authentification d'une personne à l'aide d'une carte d'identité virtuelle

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150312251A1 (en) * 2012-02-16 2015-10-29 France Telecom Ensuring the security of a data transmission
US20150063655A1 (en) * 2013-08-27 2015-03-05 Morphotrust Usa Inc. Digital Identification Document
WO2019074366A1 (fr) * 2017-10-10 2019-04-18 Morpho B.V. Authentification d'une personne à l'aide d'une carte d'identité virtuelle

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
TAUBER ARNE ET AL: "Towards Interoperability: An Architecture for Pan-European eID-Based Authentication Services", 2 September 2010, ADVANCES IN DATABASES AND INFORMATION SYSTEMS; [LECTURE NOTES IN COMPUTER SCIENCE; LECT.NOTES COMPUTER], SPRINGER INTERNATIONAL PUBLISHING, CHAM, PAGE(S) 120 - 133, ISBN: 978-3-319-10403-4, XP047495842 *

Also Published As

Publication number Publication date
FR3113347B1 (fr) 2022-10-07

Similar Documents

Publication Publication Date Title
US10657233B1 (en) Extending electronic ID information
US9730065B1 (en) Credential management
KR20210024992A (ko) 블록체인 내에서 코드와 이미지를 사용하는 시스템과 방법
US20190327228A1 (en) Identity credential verification techniques
US11423133B2 (en) Managing travel documents
US12099776B2 (en) Visual verification of virtual credentials and licenses
US20250104174A1 (en) Systems and methods of generating user identity packets using biometrics
CN109446259A (zh) 数据处理方法及装置、处理机及存储介质
FR3029665A1 (fr) Procede mis en œuvre dans un document d&#39;identite et document d&#39;identite associe
US11928201B2 (en) Mobile credential with online/offline delivery
CN113688362B (zh) 身份证信息安全处理方法及装置
EP3352994B1 (fr) Impression de marque à distance sur un document de sécurité
FR3113347A1 (fr) Procede et dispositif de mise a jour de donnees d’un document dematerialise pour l’execution d’un service ou d’un controle
US20230105171A1 (en) Identity Vault System Using Distributed Ledgers for Event Processing
AU2023219787A1 (en) Identity verification and associated platform
US11283956B2 (en) Methods, systems, and storage media for issuing and verifying a secondary cryptographic photo ID
EP4193283B1 (fr) Procédé pour générer un document numérique sécurisé stocké sur un terminal mobile et associé à une identité numérique
BE1031409B1 (fr) Méthode, mise en œuvre par des moyens de traitement numérique, d’exploitation d’informations d’identification d’un ou plusieurs individus
US12147967B2 (en) Dynamic NFT-based frictionless transaction system
EP3916687A1 (fr) Procédé et système d&#39;accès conditionnel
EP2911083B1 (fr) Méthode d&#39;accès aux données d&#39;au moins une personne physique ou morale ou d&#39;un objet
WO2023001845A1 (fr) Procédé d&#39;enrôlement d&#39;un utilisateur par un organisme sur une chaîne de blocs
AU2023201493A1 (en) A method for electronic identity verification and management
FR3129744A1 (fr) Procédé de traitement d’une transaction impliquant l’utilisation d’un identifiant public, dispositif, système et programmes d&#39;ordinateurs correspondants.
WO2024044293A1 (fr) Plateforme de document de jeton non fongible

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLSC Publication of the preliminary search report

Effective date: 20220211

PLFP Fee payment

Year of fee payment: 3

PLFP Fee payment

Year of fee payment: 4

PLFP Fee payment

Year of fee payment: 5

PLFP Fee payment

Year of fee payment: 6