EP4695933A1 - Procédé de renouvellement automatique d'un attribut vérifiable et système associé - Google Patents

Procédé de renouvellement automatique d'un attribut vérifiable et système associé

Info

Publication number
EP4695933A1
EP4695933A1 EP24721707.8A EP24721707A EP4695933A1 EP 4695933 A1 EP4695933 A1 EP 4695933A1 EP 24721707 A EP24721707 A EP 24721707A EP 4695933 A1 EP4695933 A1 EP 4695933A1
Authority
EP
European Patent Office
Prior art keywords
verifiable
attribute
vci
request
renewal
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.)
Pending
Application number
EP24721707.8A
Other languages
German (de)
English (en)
Inventor
Thomas Fleury
Stéphanie LION
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
Publication of EP4695933A1 publication Critical patent/EP4695933A1/fr
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
    • H04L9/3213—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority using tickets or tokens, e.g. Kerberos
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0891—Revocation or update of secret information, e.g. encryption key update or rekeying
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures

Definitions

  • the invention relates to the field of online verification of a verifiable attribute, i.e. one with high probative force, characterizing a person or an entity. More specifically, the invention addresses the problem of proof of majority that any person must present to a provider of digital content, goods or services reserved for adults.
  • the invention will be described primarily, without this creating any limitation to the present invention, in the context of the proof of majority that a subject must provide to be authorized to access adult content.
  • the invention could however be used to attest to the truth of any other attribute characterizing a person, such as a place of residence, obtaining a level of education without a subscription to a provider of goods or services requiring such proof obliging the subscriber to transmit elements that are unnecessarily too intimate or precise.
  • CNIL National Commission for Information Technology and Civil Liberties
  • French law like other regulations in force around the world, subjects the provision of certain services or goods to age conditions, requiring online sites of suppliers of such goods and services to verify the age of the customer prior to any supply. This is the case, for example, for sites selling alcohol, games money, online betting, adult photos or videos.
  • the CNIL recommends using an independent trusted third party to prevent the direct transmission of identifying data relating to the user to a site or application offering, for example, pornographic content.
  • the CNIL in its opinion of June 3, 2021, recommends that the age or majority check consist of two separate operations:
  • the issuer of proof of majority knows the identity or a pseudonym of the Internet user concerned without knowing the supplier(s) of goods and services requiring such certified proof of majority;
  • the requested service or goods provider does not know the identity of the Internet user but only the majority of the latter and the verifier of the required proof.
  • the use of an independent verifier is clearly recommended by the CNIL to best protect individuals' data.
  • suppliers of goods or services subject to an age verification obligation do not carry out the age verification operations themselves but rely on a trusted third party responsible for these verification operations, thus taking up the "trust triangle" as defined in the approach known under the Anglo-Saxon name Self-Sovereign Identity or SSI, popularized with the emergence of Web3 technologies, including blockchain.
  • Figure 1 illustrates an example of a known system for verifying proof of majority of an Internet user wishing to contact a provider of digital content reserved for adults (adult content, gambling or online betting, for example).
  • a system S comprises an electronic object Om held by a person Um wishing to solicit a supplier of goods or services SP, in this case pornographic multimedia content.
  • Said electronic object Om may consist of a smart mobile phone ("smartphone” according to Anglo-Saxon terminology), an electronic tablet, a personal computer or any other suitable electronic object.
  • a supplier SP being subject to a verification of the majority of any client, it relies on a verifier Vn to attest or not to such a majority.
  • a verifier in the form of a computer server, transmits a confirmation or a rejection of the proof of majority to the supplier SP by transmitting a verification message V_M.
  • such a verifier Vn uses a structured set of data VC defining a certified and verifiable attribute (“verifiable credential” according to English terminology) conveyed by a presentation message PV_M (“verifiable presentation” according to English terminology) emanating from the electronic device Om used by the person Um in response to a request for presentation of such a verifiable attribute VC_PR addressed by the verifier Vn to the electronic object Om.
  • a certified and verifiable attribute (“verifiable credential” according to English terminology) conveyed by a presentation message PV_M (“verifiable presentation” according to English terminology) emanating from the electronic device Om used by the person Um in response to a request for presentation of such a verifiable attribute VC_PR addressed by the verifier Vn to the electronic object Om.
  • verifiable attribute VC includes a plurality of information relating to the person concerned by the proof, the attested attribute, the issuing entity Ij having constituted and issued said verifiable attribute VC, or even contextual operating elements Ctx, including a creation or issue date CD, an end of validity date, EVD, etc.
  • a verifiable attribute VC is generally stored in the memory M of the electronic object Om. It is administered by an electronic wallet Wm ("wallet" according to Anglo-Saxon terminology) of verifiable attributes in the form of an application or, more generally, a computer program, the program instructions of which are recorded in the memory M of the electronic object Om.
  • such an electronic wallet Wm of verifiable attributes may be called a "wallet" in the remainder of this document.
  • said Wm wallet can decode a VC_PR presentation request and issue a PV_M presentation message in response.
  • Such a verifiable attribute VC is generally created and issued by an electronic entity Ij, which we can call “issuer” for the sake of simplification.
  • an issuer Ij may consist of a computer server capable of receiving a VC_CR request for the creation of a verifiable attribute initiated by the electronic wallet Wm and transmitted by the electronic object Om.
  • the issuer Ij Upon receipt of such a VC_CR creation request, the issuer Ij requests a third party or trusted authority TA that has precise knowledge of the user Um.
  • a trusted authority TA may consist of a banking institution, a public or private administration, or even a service operated by such an institution or administration. For example, we can cite the “Live Identity” service operated by Orange Business Service. Such a service is open to any mobile telephone operator and makes it possible to verify the digital identity of a subscriber.
  • Such a trusted authority TA could also consist of a computer server operated by an energy supplier with knowledge of its users.
  • the issuer Ij In response to a request to create a verifiable attribute, the issuer Ij requests an investigation YES from such a third party or authority TA to determine, by example, if said llm user is of legal age or if he resides in a particular locality, depending on the verifiable attribute concerned.
  • the TA authority in the form of a banking server, knowing the date of birth of its llm client, can send back to the issuer information confirming or refuting the majority of the llm user. If so, the issuer Ij develops the verifiable attribute VC.
  • the CUI investigation can consist of a request conveying public information of the digital identity of the llm subject.
  • the authority TA can submit to the wallet Wm, a request for knowledge of information characterizing the bank account or telephone subscription of the subject user of the electronic object Om with the authority TA as well as the consent of the user of said electronic object Om.
  • said wallet Wm In response to such a request, after solicitation of the user llm to confirm his request for a verifiable attribute, said wallet Wm returns the signed bank account or subscription information to the authority TA which can verify its authenticity and prepare the response to the issuer Ij who is unaware of said information characterizing the telephone subscription or bank account of the bearer of the object Om.
  • a request for knowledge of information characterizing the bank account of the user llm can consist of a bank transaction of a zero debited amount or any other suitable solution.
  • an emitted verifiable attribute VC includes contextual information Ctx, for example describing the cryptographic scheme used to sign said attribute prior to its emitting to the wallet Wm.
  • a verifiable attribute VC may also include public digital identity information (unique identifier, public cryptographic key, etc.) of the user Um and the issuer Ij respectively, a creation date of said verifiable attribute, or even an end of validity date of the latter.
  • Such a verifiable attribute VC could contain any other information necessary for the implementation of the online proof system S.
  • the issuer Ij develops and sends a message VC_M to transmit said verifiable attribute VC to the wallet Wm via the electronic object Om.
  • the online proof system S may comprise a plurality of issuers, verifiers and wallets of verifiable attributes. To distinguish the electronic and computer entities from each other, they are associated with digital identity information. Thus, the wallet Wm is associated with a unique identifier IDWm, the issuer Ij with a unique identifier IDIj and the verifier Vn with a unique identifier IDVn. To certify that the messages or contents are indeed issued by a first entity to a second entity, an online proof system S generally relies on an asymmetric signature/verification cryptographic scheme. Thus, each entity comprises a set of keys, respectively public PK and private SK. The public keys are symbolized by white keys in Figure 1 and the private keys are symbolized by black keys.
  • the digital identity of each entity comprises, in addition to a unique identifier, such a set of public and private keys which is specific to said entity.
  • the digital identity llj of the issuer Ij comprises the identifier IDIj, the public key PKIj and the private key SKIj.
  • the digital identity IWm of the wallet Wm comprises the identifier IDWm, the public key PKWm and the private key SKWm.
  • the digital identity IVn of the verifier Vn comprises the identifier IDVn, the public key PKVn and the private key SKVn.
  • each electronic entity of the online proof system S of which the wallet Wm is a part is associated with a digital identity formed of a public digital identity and a private digital identity, said digital identity being recorded in a memory M of each electronic entity.
  • a message, a request or content can be signed by a first electronic entity using its private digital identity, said signature being able to be verified by any second electronic entity by exploiting the public digital identity of said first electronic entity.
  • said first entity can encrypt messages, requests or content using the public digital identity of a second determined electronic entity, so that the latter is the only electronic entity capable of decrypting said messages, requests or content using its own private digital identity unknown to the other electronic entities.
  • the IWm digital identity of the Wm wallet consists of:
  • PIWm public digital identity
  • IDWm unique identifier
  • PKWm public key
  • a private key SKWm jointly developed with said public key PKWm to ensure an asymmetric signature cryptographic scheme.
  • the digital identity llj of the issuer Ij of the attribute VCi, subject to automatic renewal, consists of:
  • PI Ij a public digital identity
  • IDIj a unique identifier
  • PKIj a public key
  • SKIj a private digital identity, in this case a private key SKIj jointly developed with said public key PKIj to ensure an asymmetric signature cryptographic scheme.
  • PI lj a public digital identity PI lj’, in this case a unique identifier IDIj’ and a public key PKIj’;
  • a private key SKIj’ jointly developed with said public key PKIj’ to ensure an asymmetric signature cryptographic scheme.
  • PIVn a public digital identity PIVn, in this case a unique identifier IDVn and a public key PKVn;
  • a private key SKVn jointly developed with said public key PKVn to ensure an asymmetric signature cryptographic scheme
  • said system S includes a trusted register TR, in the form of a computer server itself associated with a digital identity ITR whose public digital identity consists of a unique identifier IDTR and a public key PKTR and whose private identity consists of a private key SKTR.
  • Said trusted register TR includes a data memory TRM comprising a directory of the public digital identities of the entities lj, Vn, Wm of said system S, or even those of the authority TA and/or the service provider SP.
  • All the electronic entities of the online proof system S can thus request said trusted register TR by requests for consultation of public digital identities PI_R to know in response, via a transmission message PI_M one or more public digital identities (i.e. the values of the unique identifiers IDVn, IDIj, IDWm and/or the public keys PKIj, PKWm, PKVn) of specific electronic entities and thus be able to verify the signatures of the requests VC_PR, VC_CR, PI_R and the messages VC_M, PV_M, or even to encrypt, if necessary, said requests and said messages.
  • public digital identities i.e. the values of the unique identifiers IDVn, IDIj, IDWm and/or the public keys PKIj, PKWm, PKVn
  • the trust register TR is thus a repository, to date, of the legitimate electronic entities making up said online proof system S.
  • a PI_R request can be signed using the private digital identity (in this case a private key) of the requesting entity.
  • Said trusted register TR can thus verify said signature using the public digital identity (in this case a public key) of the requesting entity and ensure that the latter does indeed have an entry in its repository of legitimate electronic entities of the system S.
  • the message PI_M conveying the result of a request PI_R can, in turn, be signed by the trusted register TR using its own private digital identity (private key SKTR) before transmission.
  • DIDs decentralized and secure ID identifiers
  • a decentralized identifier is inherited or derived from the public key associated with it.
  • a second entity can recover the public key PK of said first entity from the decentralized identifier or vice versa.
  • the trust register TR can thus store in the data memory TRM, only the identifiers IDIj, IDVn, IDWm, in the form of decentralized identifiers DIDs, or only the public keys PKIj, PKVn, PKWm instead of pairs [clear identifiers and public keys] to list the public digital identities of the entities of the online proof system S.
  • a verifiable attribute VC can only include the identifier IDIj of the issuer Ij, when said identifier is a decentralized identifier or alternatively only the public key PKIj of the latter, when said identifier IDIj is inherited from said public key PKIj.
  • the same applies to the public digital identity IWM [IDWm, PKWm] of the wallet Wm which is included in said verifiable attribute VC.
  • the online proof system S comprises a plurality of electronic entities, in this case electronic objects Om, transmitters Ij, verifiers Vn, a trust register TR, etc.
  • each of said electronic entities consists of an instance of an electronic object or a computer server comprising a central processing unit 11 controlling, by signals routed by a communication bus symbolized in Figure 2 by double arrows in single lines, electronic elements including a memory M.
  • the latter comprises a data memory 12 and a program memory 13, said memories 12 and 13 being able to form only one and the same physical entity M.
  • Non-volatile memory means any computer memory, whether volatile or not.
  • Non-volatile memory is computer memory whose technology retains its data in the absence of an electrical power supply. It may contain data resulting from inputs, calculations, measurements and/or program instructions.
  • the main Non-volatile memories currently available are electrically writable such as EPROM technology ("Erasable Programmable Read-Only Memory”) or electrically writable and erasable such as EEPROM (“Electrically-Erasable Programmable Read-Only Memory”), flash, SSD (“Solid-State Drive”), etc.
  • Non-volatile memories are distinguished from so-called “volatile” memories, the data of which is lost in the absence of a power supply.
  • RAM Random Access Memory
  • DRAM dynamic random access memory, requiring regular updating
  • SRAM static random access memory requiring such updating during a power shortage
  • DPRAM dynamic random access memory requiring such updating during a power shortage
  • VRAM dynamic random access memory
  • an electronic entity of an online proof system further comprises means 14 of communication with the outside world in the form of an input unit and an output unit. Said means of communication 14 cooperate with the processing unit 11 and provide wireless or wired proximity communication with any other electronic entity of said system S.
  • an electronic entity generally comprises a source of electrical energy 15, external or internal in the form of one or more batteries for example.
  • the processing unit 11 may also comprise means 16 of controlling an input and/or output human-machine interface 17.
  • output human-machine interface means any device, used alone or in combination, making it possible to output or deliver a graphic, haptic, sound or, more generally, human-perceptible representation.
  • Such an output human-machine interface may consist, in a non-exhaustive manner, of one or more screens, speakers or other suitable alternative means.
  • Human-machine input interface means a computer keyboard, a pointing device, a touch screen, a microphone or, more generally, any interface designed to translate a gesture or instruction issued by a human into control or parameter data.
  • the input and output human-machine interfaces may constitute a single physical entity.
  • Such an online proof system S may be adapted by loading into the program memory 13 of each electronic entity a computer program P comprising instructions for causing, upon their execution, the implementation of an appropriate method.
  • This program may use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in an interpreted, partially or fully compiled form, or in any other desirable form.
  • pseudonyms identifiers/public keys
  • DIDs centralized identifiers
  • the invention preserves the anonymity of the bearer or user of an electronic object hosting a portfolio of verifiable attributes and limits, or even prevents, any traceability of the public digital identities of the user and/or of his electronic object implementing the portfolio of verifiable attributes, without this requiring any action by said user or complicating the latter's task;
  • the verifiable attributes issued or reissued according to the invention are issued by legitimate issuers since they are known to the trusted register, limiting the risk that certain valid verifiable attributes will prosper while an issuer of verifiable attributes may have been revoked or deleted from the online proof system;
  • the invention integrates perfectly into a state-of-the-art online proof system (figure 1) thus offering a guarantee in terms of interoperability; the implementation of the invention in fact only requires an update of portfolios of verifiable attributes and that of certain issuers or the contribution of specific issuers without calling into question or modifying the principle of the creation of verifiable attributes, of presentations of the latter to verification entities with a view to obtaining content or goods and services.
  • the invention provides a method for automatically renewing an attribute of a user that can be verified by an electronic verification entity of an online proof system, such a system comprising a plurality of electronic entities respectively arranged to communicate with each other within said system including, in addition to said electronic verification entity, a portfolio of verifiable attributes implemented by a processing unit of an electronic object held by a user, an electronic entity issuing verifiable attributes, any verifiable attribute issued having been previously developed and transmitted by an electronic entity issuing said online proof system in response to a request for creation of a verifiable attribute initiated by a portfolio of verifiable attributes of said system.
  • such an automatic renewal process includes:
  • a first sub-process implemented by a portfolio of verifiable attributes, comprising: o a step of detecting an event triggering a renewal of an already verifiable attribute issued by an electronic entity issuing said online proof system; o a step of developing and triggering the issue of a request for renewal of a verifiable attribute already issued, to an electronic entity issuing the online proof system distinct from the one that issued said verifiable attribute that is the subject of the renewal request; o a step of managing a new verifiable attribute resulting from such a renewal request and transmitted by said issuing entity;
  • a second sub-method implemented by a processing unit of an issuing entity of the online proof system comprising: o a step of processing a request for renewal of a verifiable attribute transmitted by a portfolio of verifiable attributes; o in response to such processing of a renewal request, since said verifiable attribute has been issued by one of the issuing entities of the online proof system, a step of renewing such a verifiable attribute and transmitting a new verifiable attribute to the portfolio of verifiable attributes requiring said renewal of a verifiable attribute already issued.
  • Such a step of renewing such a verifiable attribute and transmitting a new verifiable attribute to the portfolio of verifiable attributes comprises:
  • such a method according to the invention can be arranged so that the step of developing and triggering the issue of a request for renewal of a verifiable attribute already issued can include, prior to the development as such of said request, a suitable selection of an electronic entity issuing the online proof system from among those contained in a list of available issuing entities capable of carrying out such a renewal of verifiable attributes.
  • Such an online proof system may comprise numerous electronic entities, each electronic entity of said online proof system may advantageously be associated with a digital identity formed of a public part, called “public digital identity” and a private part), called “private digital identity”, said digital identity being recorded in a data memory of said each electronic entity.
  • Said online proof system then comprises a trust register arranged for:
  • the first sub-process of a process according to the invention can then be arranged so that the step of managing a new verifiable attribute resulting from such a renewal request comprises: - a step of verifying the signature of the new attribute verifiable by the entity issuing the latter, using the public digital identity of said issuing electronic entity;
  • the second sub-process can be arranged so that:
  • the step of processing a request for renewal of a verifiable attribute already issued includes: o a step of receiving such a renewal request and reading the information conveyed by the latter, including the verifiable attribute already issued and the public digital identity of the portfolio of verifiable attributes, respectively the subject and issuer of said renewal request; o a step of verifying the signature of the verifiable attribute to be renewed by the electronic entity issuing the latter, using the latter's public digital identity;
  • the step of renewing a verifiable attribute already issued and transmitting a new verifiable attribute o is only implemented if said step of verifying the signature of the verifiable attribute to be renewed confirms the authenticity of the latter; o the step of developing the new verifiable attribute consists of signing said new verifiable attribute using the private digital identity of the entity issuing said new verifiable attribute.
  • the first sub-process of an automatic renewal method according to the invention may be arranged such that the step of developing and triggering the issue of a renewal request may include a step of signing said renewal request using the private digital identity of the portfolio of verifiable attributes.
  • the second sub-process may be arranged such that:
  • the step of processing a request for renewal of a verifiable attribute already issued includes a step of verifying the signature of said renewal request by the portfolio of verifiable attributes, using the latter's public digital identity;
  • step of renewing a verifiable attribute already issued and transmitting a new verifiable attribute is only implemented if said step of signing the renewal request confirms the authenticity of said signature.
  • the first sub-method of the latter may be arranged so that the step of detecting an event triggering an automatic renewal of a verifiable attribute may consist of:
  • said first sub-process can further be arranged so that the step of managing a new verifiable attribute resulting from a query in renewal may also consist of an initialization of the value of a counter of presentation messages conveying said new verifiable attribute in a data memory accessible in reading and writing by the portfolio of verifiable attributes.
  • the step of developing and triggering the issue of a request for renewal of a verifiable attribute already issued of the first sub-process may include a step of producing a new digital identity of the portfolio of verifiable attributes to replace the previous one.
  • the step of developing the request for renewal of the verifiable attribute already issued to the issuing entity is then arranged so that said renewal request includes the verifiable attribute to be renewed and the new public digital identity of the portfolio of verifiable attributes.
  • the step of developing and triggering the issue of a request for renewal of a verifiable attribute already issued from the first sub-process may include:
  • the step of developing the request for renewal of the verifiable attribute already issued to the issuing entity can be arranged so that the public digital identity of said issuing entity is taken from the transmission message emanating from said trusted register.
  • the step of producing a new digital identity from the portfolio of verifiable attributes may further consist of developing a request for updating the public digital identity to the trusted registry, said request conveying the new public digital identity resulting from the new digital identity signed using the previous private digital identity of said portfolio of verifiable attributes.
  • the invention makes it possible to prevent any future exploitation of a prior instance of a verifiable attribute that has been renewed, said prior instance being subject to public revocation within the online proof system. To do this:
  • the trusted registry may be arranged to store any revoked verifiable attribute or information characteristic of such a revoked verifiable attribute in response to receipt of a request for revocation of a verifiable attribute;
  • the step of managing a new verifiable attribute resulting from a renewal request may include a step of developing such a request for revocation of a verifiable attribute conveying the verifiable attribute which has been the subject of a renewal to the trusted register or a characteristic IT system of the latter.
  • the step of preparing such a revocation request may further consist of signing said request using the private digital identity of said portfolio of verifiable attributes.
  • the step of verifying the signature of the verifiable attribute to be renewed of the second sub-process can in turn be preceded:
  • - a step of developing a request for consultation of public digital identities of electronic entities of the online proof system and triggering the sending of said request to the trusted register; - a step of receiving a transmission message from said trusted register and searching, within it, for the public digital identity of the electronic entity issuing the verifiable attribute to be renewed.
  • step of verifying the signature of the renewal request by the portfolio of verifiable attributes of the second sub-process can be advantageously preceded by:
  • the verifiable attribute which can be the subject of a renewal process according to the invention can characterize the majority of the user of the electronic object hosting the portfolio of verifiable attributes.
  • the public digital identity may consist of a public key and an identifier
  • the private digital identity consists of a private key produced jointly with said public key, by the implementation of an asymmetric cryptographic algorithm.
  • the identifier may be a decentralized identifier derived from said public key by the implementation of a reversible cryptographic algorithm, said public digital identity thus being reduced to said decentralized identifier or to said public key.
  • the invention further relates to a first product computer program comprising one or more program instructions executable by a processing unit of an electronic object hosting a portfolio of verifiable attributes of an online proof system, said program instructions being:
  • an electronic object comprising a processing unit, means of communication with the outside world and a memory recording the program instructions of such a first computer program product.
  • the invention further relates to a second computer program product comprising one or more program instructions executable by a processing unit of an electronic entity issuing verifiable attributes of an online proof system, said program instructions being:
  • the invention then also concerns: - a computer-readable storage medium containing the instructions of such a second computer program product;
  • an electronic entity emitting verifiable attributes comprising a processing unit, means of communication with the outside world and a memory recording the program instructions of such a second computer program product.
  • the invention relates to any online proof system comprising a plurality of electronic entities respectively arranged to communicate with each other within said system including:
  • FIG. 3 illustrates an example of a method for automatic renewal of verifiable attributes in accordance with the invention and implemented by an online proof system of verifiable attributes;
  • FIG 4 illustrates a functional flowchart of a first sub-method of a method for automatic renewal of verifiable attributes in accordance with the invention and described by figure 3, said first sub-process being intended to be implemented by a portfolio of verifiable attributes of an online proof system such as that illustrated by figure 1;
  • FIG. 5 illustrates a functional flowchart of a second sub-process of a method for automatic renewal of verifiable attributes in accordance with the invention and described in Figure 3, said second sub-process being intended to be implemented by an electronic entity issuing verifiable attributes of an online proof system illustrated in Figure 1.
  • Figure 3 thus illustrates a method 300 for automatic renewal of a verifiable attribute VCi, intended to be verified by a verifier Vn of an online proof system S according to Figure 1.
  • a verifier Vn is not involved in the method 300 and therefore does not appear in Figure 3.
  • a verifiable attribute obtained after the implementation of a renewal method 300 in accordance with the invention is similar to any other verifiable attribute obtained after the implementation of a process known by an emitter Ij in response to a request for creation VC CR according to the state of the art.
  • Such a method 300 according to the invention is mainly arranged in the form of two sub-methods, respectively referenced 100 and 200 in FIG. 3. These two sub-methods 100 and 200 will be detailed later, respectively in connection with FIGS. 4 and 5.
  • the first sub-method 100 is arranged to be implemented by a wallet Wm hosted by an electronic object Om, in the advantageous form of a smart mobile phone according to the non-limiting example illustrated by FIG. 3, said wallet Wm being arranged in the form of a software application (computer program adapted to the operating systems of such phones). More precisely, such a sub-method 100 can be designed, in the form of a computer sub-program or be integrated into the computer program P installed in the program memory M, 13, of the electronic object Om and whose program instructions, when executed by the processing unit 11 of said object Om, cause the implementation of the wallet Wm by said electronic object Om.
  • the second sub-process 200 is, for its part, arranged to be implemented in the form of a computer program or sub-program P, by a processing unit of an electronic entity emitting verifiable attributes or transmitter lj'.
  • said method 300 can also use a trusted register TR recording the public digital identities of the electronic entities of the system S, including in particular those of the wallet Wm and the issuer lj’ thus adapted.
  • said trusted register TR can be advantageously requested during the implementation of the method 300 by means of conventional and known requests PI_R in consultation of public digital identities emanating from any electronic entity of an online proof system S such as that described in connection with FIG. 1.
  • a trust register TR can, according to the state of the art, develop a transmission message PI_M conveying one or more public digital identities and send such a message to the electronic entity at the initiative of said PI_R request for consultation of public digital identities.
  • a verifiable attribute VC attests to the majority of the bearer Urn of the electronic object Om.
  • An instance of this attribute, referenced VCi in FIG. 3 has been created and issued in response to a request to create a verifiable attribute, said creation request VC_CR being in accordance with the current state of the art and having been addressed by the wallet Wm to a first transmitter lj such as that already described in connection with the online proof system S according to FIG. 1.
  • Said transmitter lj is not shown in FIG. 3 because said step of creating and transmitting said verifiable attribute VCi is not part of the invention.
  • said verifiable attribute VCi like the current state of the art, includes the following information: - Ctx context data specific to the implementation of the online proof system S;
  • the attested attribute in this case “the user is of legal age” - this attribute could be optional within the framework of an online proof of majority system dedicated to this attribute alone;
  • Such a verifiable attribute can be used by the Wm wallet to respond to any VC_PR presentation request from Vn verifiers.
  • Vn verifiers Although possibly using a pseudonym in the form of a decentralized IDWm identifier, the latter can be traced by said Vn verifiers. It is therefore possible to consist of a history of PV_M presentation messages, a history that can be detrimental to the Internet user, certain verifiers or transmitters being able to cross-reference and share their information in connection with the use of said verifiable attribute. There is currently no solution to prevent this risk.
  • the method 300 illustrated by FIG. 3 solves this difficulty in an elegant and transparent manner for the Internet user.
  • a Wm wallet can decide, according to different criteria, to cause a joint renewal of the digital identity of the Wm wallet and verifiable attributes already legitimately issued, without requiring iteration of a VC CR creation procedure of verifiable attributes.
  • Said sub-process 100 is arranged to address an innovative request for renewal of a verifiable attribute already issued VC RR to any issuer lj' of the online proof system S which would have been adapted or arranged to implement the sub-process 200.
  • Such a request VC_RR mainly conveys the attribute VCi already issued by the issuer lj and the new public digital identity of the wallet Wm.
  • the issuer lj' creates a copy of the verifiable attribute VCi in the form of a new verifiable attribute VCi+i retaining all or part of the content of the attribute VCi, that is to say, in this case:
  • the attested attribute in this case “the user is of legal age” - this attribute may be optional within the framework of an online proof of majority system dedicated to this attribute alone;
  • the new verifiable attribute VCi+i a quasi-clone of the verifiable attribute VCi, differs only in its content in that:
  • the new verifiable attribute VCi+i resulting from the renewal process reproduces the same EVD validity end date as the initial verifiable attribute VCi.
  • the transmitter lj’ transmits said new verifiable attribute VCi+i, by a transmission message VC_M, to the wallet Wm which replaces, in the data memory M, 12 of the electronic object Om, the verifiable attribute VCi with the verifiable attribute VCi+i.
  • Such a method 300 can be iterated as many times as necessary, so that said new verifiable attribute VCi+i can, in turn, be the subject of a renewal request to an issuer of the system S to give rise to a new verifiable attribute VCi+ n , like the initial verifiable attribute VCi.
  • tracing for the purpose of creating a history is limited. It becomes totally impossible in the case where the requests for renewal of a verifiable attribute are addressed to separate issuers within the online proof system S. Indeed, an issuer requested for a renewal would no longer have the capacity to enrich a chain of renewals, if the verifiable attribute to be renewed has been renewed by a second issuer, except by creating coalitions with its peers.
  • the invention thus provides an advantageous embodiment of a method 300 according to which a transmitter requested for a renewal of a verifiable attribute is systematically or randomly different from that which was the origin of the issue (creation or renewal) of the verifiable attribute being renewed.
  • FIG. 3 also illustrates that the sub-methods 100 and 200 can request the trust register TR of the online proof system by means of PI_R requests for consultation of public digital identities, said TR register communicating, in response, such public digital identities by PI_M transmission messages.
  • This advantageous variant of a method 300 according to the invention allows the wallet Wm and the issuer lj’ requested for a renewal of a verifiable attribute to mutually ensure the legitimacy of the requests and messages exchanged as well as the authenticity of the verifiable attribute to be renewed. Indeed, prior to the emission of a renewal request VC_RR, the wallet Wm can consult the trust register to select a legitimate issuer satisfying certain constraints, such as that mentioned above to prevent monitoring of renewals by a malicious issuer or target of an attack.
  • an issuer receiving said request may request said TR trust register to have the respective public digital identities of said wallet and of the issuer whose public digital identity is recorded in the verifiable attribute subject to a renewal.
  • Said issuer receiving the renewal request may thus verify, on the one hand, the signature of the Wm wallet if it has signed the renewal request using its own private digital identity and, on the other hand, the signature of the issuer of the verifiable attribute concerned by the renewal, if the latter includes such a signature developed from the private digital identity of its issuer.
  • FIG. 3 illustrates a method 300 for automatic renewal of a verifiable attribute for which the sub-method 100 allows the development of a revocation request VC_RKR of a renewed verifiable attribute VCi, i.e. the one on which a renewal request VC_RR was made, at the end of the production of a new verifiable attribute VCi+i.
  • a revocation request is arranged to be interpreted by the trusted register. TR or any other register dedicated to this purpose, to record the verifiable attributes thus revoked after renewal or, in place of such revoked verifiable attributes, record information characteristic of the latter, such as the result of a cryptographic hash function of such a verifiable attribute for example.
  • an issuer lj' recipient of a request for renewal of a verifiable attribute can further verify, by requesting said register, that the verifiable attribute subject to a renewal is not a revoked verifiable attribute. If not, the sub-process 200 does not proceed with the renewal and can return an error message to the wallet requesting the renewal.
  • Figure 4 illustrates in detail advantageous embodiments of a sub-method 100 of a method for automatic renewal of verifiable attributes according to the invention.
  • a sub-method 100 is arranged to be implemented, or to be part of, a portfolio Wm adapted accordingly and belonging to an online proof system S of which at least one transmitter lj’ is adapted to implement a sub-method 200 exploiting a request for renewal of a verifiable attribute.
  • Such a sub-process 100 consists of three distinct major steps referenced 110, 120, 130 in FIG. 4, said steps being dedicated respectively to:
  • each electronic entity of the online proof system of which the Wm wallet is a part is associated with a digital identity formed of a public digital identity and a private digital identity, said digital identity being recorded in a data memory 12 of each electronic entity.
  • a message, a request or content can be signed by a first electronic entity using its private digital identity, said signature being able to be verified by any second electronic entity by exploiting the public digital identity of said first electronic entity.
  • said first entity can encrypt messages, requests or content using the public digital identity of a second determined electronic entity, so that the latter is the only electronic entity capable of decrypting said messages, requests or content using its own private digital identity unknown to the other electronic entities.
  • the IWm digital identity of the Wm wallet consists of:
  • PIWm public digital identity
  • IDWm unique identifier
  • PKWm public key
  • a private key SKWm jointly developed with said public key PKWm to ensure a cryptographic signature and/or asymmetric encryption scheme.
  • the digital identity llj of the issuer Ij of the attribute VCi, subject to automatic renewal, consists of:
  • PI Ij a public digital identity PI Ij, in this case a unique identifier IDIj (possibly decentralized) and a public key PKIj;
  • a private key SKIj jointly developed with said public key PKIj to ensure a cryptographic signature and/or asymmetric encryption scheme.
  • the digital identity llj' of the transmitter Ij' consists of:
  • PI Ij a public digital identity PI Ij’, in this case a unique identifier IDIj’ (possibly decentralized) and a public key PKIj’;
  • a private key SKIj’ jointly developed with said public key PKIj’ to ensure a cryptographic signature and/or asymmetric encryption scheme.
  • the online proof system S of which the wallet Wm and the issuers Ij and Ij’ are part, comprises a trusted register TR designed to record, in a data memory TRM specific to it, the public digital identities PIWm, Pllj, Pllj’, respectively of the electronic entities Wm, Ij, and Ij’ of said online proof system S.
  • Said register is capable of receiving a request PI_R for consultation of public digital identities emanating from an electronic entity of said system S and of producing, in response to such a request PI_R, a transmission message PI_M conveying one or more public digital identities intended for the electronic entity issuing said request PI_R for consultation of public digital identities.
  • the sub-process 100 therefore comprises a first detection step 110 of an event triggering a renewal of a verifiable attribute, in this case the verifiable attribute VCi previously emitted by the transmitter Ij.
  • the invention provides in fact that a renewal of a verifiable attribute can be triggered automatically following a predetermined number of responses to requests for presentation VC_PR of such a verifiable attribute emanating from verifiers of the online proof system such as the verifier Vn described in connection with FIG. 1.
  • a renewal of a verifiable attribute could also occur automatically after a certain period of time elapsed from the creation date CD of such a verifiable attribute, whether said creation results from a creation request VC_CR according to the state of the art or from a renewal request CV_RR specific to the invention.
  • Such an attribute renewal verifiable could further be triggered automatically and randomly by the implementation of an algorithm exploiting all or part of the content of said verifiable attribute as a seed for the production of a random variable ultimately compared to a threshold, etc.
  • the invention provides that the detection of a triggering event is not reduced to these examples alone or in combination.
  • Figure 4 describes an embodiment according to which the Wm wallet associates with each verifiable attribute VCi that it manages, a nPV counter for sending messages in presentation PV_M conveying said verifiable attribute VCi in response to requests in presentation VC_PR emanating from verifiers.
  • each verifiable attribute VCi is therefore associated with such a counter jointly recorded in data memory 12 of the electronic object hosting said wallet Wm.
  • Step 110 can then consist first of all in a reading 111, in such a data memory 12 accessible in reading and writing by the wallet Wm, of the current value of a counter nPV of presentation messages PV_M conveying the verifiable attribute VCi addressed to a verifier of the online proof system S.
  • Said step 110 can then consist in the comparison 112 of the current value of said counter nPV with a predetermined maximum threshold of presentations, for example between two and ten, preferably equal to five so as not to generate renewals too frequently while preserving the desired technical effect of non-traceability.
  • a predetermined maximum threshold of presentations for example between two and ten, preferably equal to five so as not to generate renewals too frequently while preserving the desired technical effect of non-traceability.
  • said step 110 concludes with the detection of an event triggering an automatic renewal if said value of said counter nPV reaches said predetermined threshold.
  • Such a situation is represented by link 112-y in Figure 4.
  • no renewal of the verifiable attribute is triggered (situation represented by link 112-n in Figure 4).
  • Such processing 120 mainly comprises a step 125 of developing a renewal request VC_RR to be sent to an issuer of the online proof system.
  • the processing 120 may comprise a step 121 of producing a new digital identity IWm of the wallet of verifiable attributes Wm to replace the current digital identity, like a creation of such a digital identity during the installation of the “wallet of verifiable attributes” application in the electronic object Om.
  • This step consists of producing a new set of public keys PKVm and private keys SKWm, for example by deriving a mother key and a random seed.
  • a step 121 further consists of producing a new identifier IDWm, either from scratch for example via the generation of a random number or by deriving it from the public key PKWm if it is a decentralized identifier.
  • the public digital identities PIWm and private SKWm forming the new digital identity IWm of the wallet Wm are thus recreated.
  • the invention provides that said step 121 may further consist of developing a request PI JJ for updating the public digital identity intended for the trusted register TR.
  • Such a request PIJJ is arranged by the wallet Wm to convey the new public digital identity PIWm resulting from the new digital identity IWm and to be signed using the previous private digital identity SKm of said wallet Wm.
  • the trusted register TR can then, in response to such an update request, verify said signature by exploiting the future old public digital identity of said wallet Wm and accept, if so, said update of the public identity of the wallet Wm.
  • Said step 121 of producing a new digital identity IWm nevertheless remains advantageous but optional.
  • the invention provides in fact that a wallet Wm can keep the same digital identity IWm to implement a plurality of renewal requests VC_RR.
  • an implementation of step 121 can be triggered, asynchronously, with regard to the implementation of the detection step 110 of an event triggering a renewal of a verifiable attribute VC.
  • a setting in implementation of step 121 could be triggered, according to any criterion, such as, by way of non-limiting examples, a count, compared to a threshold, of requests for renewal VC RR of a determined verifiable attribute or even a random trigger.
  • the invention provides in fact that a Wm wallet can comprise a plurality of digital identities IWm respectively associated with distinct verifiable attributes VC managed by said Wm wallet.
  • step 125 In order for the Wm wallet to be able to develop the VC_RR renewal request in step 125, this being arranged to convey the verifiable attribute VCi, the subject of the renewal, as well as the new public identity of the Wm wallet, it is necessary to select an issuer to whom to address said VC_RR renewal request.
  • the invention provides different embodiments for selecting the future sender recipient of the VC RR renewal request.
  • the processing 120 comprises a step 122 for reading, within the verifiable attribute VCi (subject to a renewal and recorded in the data memory 12), the public digital identity Pllj of the issuer Ij of said verifiable attribute VCi, in order to address said renewal request VC_RR, in step 125, to said issuer Ij previously responsible for the creation (or a previous renewal) of said verifiable attribute VCi.
  • the invention provides that the wallet Wm has, in the data memory 12, a table of the public digital identities of the known issuers of said wallet Wm.
  • the selection of the public digital identity of the issuer receiving the renewal request VC_RR can be carried out according to a random or cyclic reading according to a determined step of said table.
  • the processing 120 comprises a step 123 of developing a PI_R request in consultation of public digital identities of issuer entities of the proof-of-concept system. line S and triggering the transmission of said request PI_R to the trusted register TR. Said processing 120 then comprises a step 124, subsequent to step 123, of receiving a transmission message PI_M emanating from said trusted register TR and reading within the latter one or more public digital identities of issuers conveyed by said message PI_M.
  • Such a systematic solicitation of the trusted register TR to constitute a list of issuers allows the wallet Wm to know, to date, the issuers available and able to carry out such a renewal of verifiable attributes.
  • the final selection of said issuer recipient of the renewal request VC_RR can also be carried out randomly within said list obtained or in a directed manner to prohibit itself from transmitting said request CV_RR to the issuer Ij of the verifiable attribute VCi subject to the renewal. In this case, the selection of the recipient is carried out by choosing a public digital identity distinct from that of the sender Ij.
  • Step 125 of processing 120 then consists of developing the VC_RR request for renewal of the verifiable attribute VCi, then causing it to be sent to the issuing entity Ij’ whose public digital identity Pllj’ has been selected, said renewal request comprising the verifiable attribute VCi to be renewed and the new public digital identity PIWm of the wallet Wm.
  • said step 125 may advantageously consist of signing said request VC_RR, prior to the issue of the latter, using the private digital identity SKWm of the wallet Wm.
  • said recipient issuer Ij' will be able to verify its legitimacy, as will be explained in connection with FIG. 5.
  • said step 125 could consist, as a variant or in addition to said signature, of encrypting the content of said request VC_RR, prior to its issue, using the public digital identity Pllj' (more precisely the public key PKIj' resulting from it) so that said issuer Ij' can be the only one to decrypt said renewal request.
  • the sub-process 100 in addition to the processing 110 for detecting an event triggering a renewal of a verifiable attribute VCi and the processing 120 for producing and issuing a renewal request VC RR of the latter, comprises a processing or management step 130 of a new verifiable attribute VCi+i resulting from such a renewal request VC_RR and transmitted by a transmission message VC_M prepared by the sender lj' recipient of said renewal request VC_RR.
  • Such processing 130 comprises a step 131 of receiving and reading a transmission message of a new verifiable attribute VCi+i emanating from the sender lj’ receiving the renewal request VC_RR developed in processing 120.
  • Such a step 131 may further consist of verifying the signature of the new verifiable attribute VCi+i by the sending entity lj’ of the latter, using the public digital identity Pllj’ of said sending entity lj’, if said new attribute has been signed by the latter.
  • the new verifiable attribute VCi+i is rejected if the verification of the signature fails and a new iteration of processing 120 is implemented, advantageously by selecting a sender lj’ distinct from the previous iteration to send it a renewal request VC_RR.
  • the processing 130 includes a step 132 of recording the new verifiable attribute VCi+i, in the data memory 12, M, accessible in reading and writing by the wallet Wm.
  • This recording of the new verifiable attribute VCi+i is carried out by overwriting the verifiable attribute VCi thus renewed or followed by the erasure of the latter.
  • said step 132 may further consist of the initialization of the value of such a counter nPV of presentation messages PV_M conveying said new verifiable attribute VCi+i in a data memory 12 of the electronic object Om hosting the wallet Wm, said memory being accessible in reading and writing by said wallet Wm.
  • the sub-process 100 may provide for the preparation of a VC_RKR revocation request of a renewed verifiable attribute VCi, i.e. the one on which a renewal request VC RR was made, following the production of a new verifiable attribute VCi+i.
  • the processing 130 comprises, upstream of the destruction (by overwriting or erasure) of a renewed verifiable attribute VCi, a step for developing such a revocation request VC_RKR arranged to be interpreted by the trust register TR or any other register dedicated to this purpose.
  • Said request VC_RKR comprises the renewed and thus revoked verifiable attribute VCi or information characteristic thereof, for example the result of the implementation of a cryptographic hash function of said verifiable attribute VCi.
  • VC_RKR request can be signed by the Wm wallet in step 133 using the private digital identity SKWm of the Wm wallet, or even be encrypted using the public digital identity of the registry receiving the revocation request. In this way, said registry can read, accept or reject said revocation after confirming the verification of the signature of said Wm wallet using the public digital identity PIWm of the latter.
  • a method 300 for automatically renewing a verifiable attribute VCi according to the invention further consists of a second sub-method 200 arranged to be implemented by a processing unit 11 of an issuer lj’ of an online proof system S such as that Ij illustrated in FIG. 1.
  • said sub-method 200 mainly comprises two steps or processes referenced 210 and 200 in FIG. 5:
  • the first step 210 allows the processing of a renewal request VC_RR of a verifiable attribute already legitimately issued VCi, said request being transmitted by a Wm wallet adapted to implement the sub-process 100;
  • the second step 220 consists of implementing the renewal of such a verifiable attribute VCi as such as well as communicating, by a transmission message VC_M, of a new verifiable attribute VCi+i to the Wm portfolio requiring said verifiable attribute renewal.
  • the processing 210 of a renewal request VC RR of a verifiable attribute VCi comprises a first step of receiving 211 such a renewal request and reading the information conveyed by the latter, including the verifiable attribute VCi to be renewed and the public digital identity PIWm of the wallet Wm, respectively the object and issuer of said renewal request VC_RR.
  • Said processing 210 further comprises a verification step 214:
  • the verification 214 of the signature of said renewal request VC_RR by the wallet Wm may be optional. Indeed, such a signature constitutes a preferred but non-essential variant of the sub-method 100.
  • the verification 214 of the signature of the verifiable attribute to be renewed VCi by the electronic entity Ij issuing the latter is more interesting for the implementation of the invention since the legitimacy of such a verifiable attribute VCi makes it possible to bypass the solicitation of the trusted authority TA.
  • the second step 220 consisting of the implementation of the renewal as such of a verifiable attribute, is only implemented if said step 214 of the verifiable attribute VCi to be renewed confirms the authenticity of said signature of said verifiable attribute VCi (situation illustrated by the link 214-y in FIG. 5).
  • step 214 may also consist of generating a transmission message VC_M conveying content characterizing an error (symbolized by the English term “error” in FIG. 5) to the wallet Wm requiring an aborted renewal.
  • a message VC_M may be signed using the private digital identity SKIj' of the sender lj' implementing the present instance of the sub-method 200.
  • the step 214 of verifying the processing 210 of the second sub-process 200 may advantageously be preceded by:
  • the second step 220 of the second sub-method 200 consisting of the implementation of the renewal as such of a legitimately verifiable attribute already issued as well as the communication, by a transmission message VC_M, of a new verifiable attribute VCi+i to the portfolio Wm requesting said renewal of verifiable attribute, comprises a step 221 of developing the new verifiable attribute VCi+i consisting of copying all of the information contained in the verifiable attribute VCi to be renewed except for the information relating to the development as such of the latter, as mentioned previously in connection with figure 3.
  • Said step 221 further consists of developing a signature of the new verifiable attribute VCi+i using the private digital identity SKIj’ of the issuing entity lj’ of said new verifiable attribute so that it is legitimately issued, like the renewed verifiable attribute VCi.
  • a signature is an integral part of the content of the new verifiable attribute VCi+i.
  • the second step 220 of the second sub-process 200 includes a sub-step 222 to cause the emission of the new verifiable attribute VCi+i to the portfolio Wm requiring the renewal of the verifiable attribute VCi.
  • the invention has been described through different configurations of an online proof system S, so that an Internet user Um can request a supplier of goods or services SP.
  • the invention cannot be limited to this single example of an online proof system and would find full application in a system for proof of majority or any other verifiable attribute with a supplier of goods and services in the physical world (such as a distributor of alcoholic beverages, tobacco or an operator of a gambling venue) and not only digital. For this, it is sufficient that said supplier SP can establish a connection with a verifier Vn of such an online proof system S.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Debugging And Monitoring (AREA)
  • Stored Programmes (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Storage Device Security (AREA)

Abstract

L'invention concerne un procédé (300) de renouvellement automatique d'un attribut vérifiable (VCi) mis en œuvre par un système de preuve en ligne comprenant un portefeuille (Wm) d'attributs vérifiables hébergé par un objet électronique (Om) et une entité émettrice d'attributs vérifiables. Pour prévenir toute constitution, par une entité électronique émettrice malveillante ou susceptible d'être la cible d'une attaque malveillante à dessein, d'un historique d'émissions d'attributs vérifiables d'un portefeuille d'attributs vérifiables, et donc in fine de l'internaute porteur de l'objet électronique qui héberge ledit portefeuille, un tel procédé (300) comporte un sous-procédés (100) mis en œuvre par ledit portefeuille (Wm) pour produire une nouvelle identité digitale (PIWm) et émettre une requête (VC_RR) en renouvellement d'un attribut vérifiable (VCi) à destination d'une entité électronique émettrice distincte de celle ayant émis ledit attribut vérifiable objet de la requête en renouvellement.

Description

Procédé de renouvellement automatique d’un attribut vérifiable et système associé
L'invention concerne le domaine de la vérification en ligne d’un attribut vérifiable, c’est-à-dire à force probatoire élevée, caractérisant une personne ou une entité. Plus précisément, l’invention adresse le problème de la preuve de majorité que toute personne se doit de présenter à un fournisseur de contenus numériques, de biens ou de services réservés aux adultes.
L’invention sera décrite principalement, sans pour autant que cela engendre une quelconque limitation à la présente invention, dans le cadre de la preuve de majorité que doit fournir un sujet pour être autorisé à accéder à des contenus pour adulte. L’invention pourrait toutefois être exploitée pour attester de la véracité de tout autre attribut caractérisant une personne, comme une localité de résidence, l’obtention d’un niveau d’études sans qu’une souscription à un prestataire de biens ou de services exigeant une telle preuve oblige le souscripteur à une transmission d’éléments inutilement trop intimes ou précis.
On peut en effet devoir prouver :
- que l’on est majeur sans nécessairement fournir sa date et son lieu de naissance ;
- que l’on réside dans une ville ou région sans devoir communiquer son adresse complète ;
- que l’on présente un certain niveau d’études sans pour autant préciser le ou les diplômes et années d’obtention de ceux-ci.
En France, la Commission Nationale de l'informatique et des Libertés, également connue sous l’acronyme « CNIL » préconise l’utilisation de systèmes qui ne soient pas facilement contournables sans pour autant que ces derniers ne soient trop intrusifs, afin qu’ils respectent la vie privée de chacune et chacun. La loi française, au même titre que d’autres règlements en vigueur dans le monde, soumet la fourniture de certains services ou biens à des conditions d’âge, obligeant les sites en ligne de fournisseurs de tels biens et services à une vérification de l’âge du client préalablement à toute fourniture. C’est par exemple le cas pour les sites de vente d’alcool, de jeux d’argent, de paris en ligne, de photos ou de vidéos pour adultes. Ladite CNIL préconise le recours à un tiers de confiance indépendant destiné à faire obstacle à la transmission directe de données identifiantes relatives à l’utilisateur à un site ou à une application proposant par exemple des contenus pornographiques. La CNIL, dans son avis du 3 juin 2021 , recommande que le contrôle d’âge ou de majorité consiste en deux opérations distinctes :
- l’émission d’une preuve de l’âge par un système sous la forme d’une entité informatique, que nous pourrons nommer par la suite « émetteur » ou « Issuer » selon une terminologie anglo-saxonne par mesure de simplification, ledit émetteur étant chargé de valider l’information sur l’âge de la personne et d’émettre une preuve d’âge (par exemple une preuve de majorité) assortie d’un niveau de confiance ;
- la transmission de ladite preuve de l’âge certifiée à un ou plusieurs fournisseurs de biens ou de services pour que ce dernier délivre ou refuse de délivrer lesdits biens ou services à l’internaute concerné par ladite preuve certifiée.
Pour préserver les données et la vie privée dudit internaute, une triple protection de la vie privée est exigée :
- l’émetteur d’une preuve de majorité connaît l’identité ou un pseudonyme de l’internaute concerné sans pour autant connaître le ou les fournisseurs de biens et de services exigeant une telle preuve de majorité certifiée ;
- la preuve de majorité est transmise audit fournisseur de biens et de services via ledit sujet ou internaute puis via une entité électronique dite « vérifieur » de preuve ( « verifier » selon une expression anglo-saxonne), ci-après parfois nommée « vérifieur » par mesure de simplification ;
- le fournisseur de services ou de biens sollicité ne connaît pas l’identité de l’internaute mais seulement la majorité de celui-ci et le vérifieur de la preuve exigée. L’exploitation d’un vérifieur indépendant est clairement recommandée par la CNIL pour protéger au mieux les données des personnes. De cette manière, les fournisseurs de biens ou de services soumis à une obligation de vérification d’âge ne réalisent pas eux-mêmes les opérations de vérification d’âge mais s’appuient sur un tiers de confiance chargé de ces opérations de vérification, reprenant ainsi le « triangle de la confiance » tel que défini dans l’approche connue sous l’appellation anglo-saxonne Self-Sovereign Identity ou SSI, popularisée avec l’émergence des technologies Web3, dont la blockchain.
La figure 1 illustre un exemple d’un système connu de vérification de la preuve de majorité d’un internaute désirant solliciter un fournisseur de contenus numériques réservés aux adultes (contenus pour adultes, jeux d’argent ou paris en ligne, par exemple).
Selon ladite figure 1 , un système S comporte un objet électronique Om détenu par une personne Um désirant solliciter un fournisseur de biens ou de services SP, en l’espèce des contenus multimédia à caractère pornographique. Ledit objet électronique Om peut consister en un téléphone mobile intelligent (« smartphone » selon une terminologie anglo-saxonne), une tablette électronique, un ordinateur personnel ou tout autre objet électronique adapté. Un tel fournisseur SP étant soumis à une vérification de la majorité de tout client, il s’appuie sur un vérifieur Vn pour attester ou non d’une telle majorité. Un tel vérifieur, sous la forme d’un serveur informatique, transmet une confirmation ou un rejet de la preuve de majorité au fournisseur SP par la transmission d’un message de vérification V_M. Pour ce faire, un tel vérifieur Vn exploite un ensemble structuré de données VC définissant un attribut certifié et vérifiable (« verifiable credential » selon une terminologie anglo-saxonne) véhiculé par un message de présentation PV_M (« verifiable presentation » selon une terminologie anglo-saxonne) émanant du dispositif électronique Om utilisé par la personne Um en réponse à une requête en présentation d’un tel attribut vérifiable VC_PR adressée par le vérifieur Vn à l’objet électronique Om. Cette structure de données que nous nommerons « attribut vérifiable » VC comprend une pluralité d’informations en lien avec la personne concernée par la preuve, l’attribut attesté, l’entité émettrice Ij ayant constitué et émis ledit attribut vérifiable VC, voire des éléments contextuels d’exploitation Ctx, parmi lesquels une date de création ou d’émission CD, une date de fin de validité, EVD, etc. Un tel attribut vérifiable VC est généralement stocké dans la mémoire M de l’objet électronique Om. Il est administré par un portefeuille électronique Wm (« wallet » selon une terminologie anglo-saxonne) d’attributs vérifiables sous la forme d’une application ou, plus généralement, d’un programme d’ordinateur, dont les instructions de programme sont enregistrées dans la mémoire M de l’objet électronique Om. Par mesure de simplification, un tel portefeuille électronique Wm d’attributs vérifiables pourra être nommé « portefeuille » dans la suite de ce document. Ainsi, ledit portefeuille Wm peut décoder une requête en présentation VC_PR et émettre en réponse un message de présentation PV_M.
Un tel attribut vérifiable VC est généralement créé et émis par une entité électronique Ij, que nous pourrons nommer « émetteur » par mesure de simplification. Un tel émetteur Ij peut consister en un serveur informatique apte à recevoir une requête VC_CR en création d’un attribut vérifiable initiée par le portefeuille électronique Wm et transmise par l’objet électronique Om.
A réception d’une telle requête en création VC_CR, l’émetteur Ij sollicite un tiers ou autorité de confiance TA qui dispose d’une connaissance précise de l’utilisateur Um. Une telle autorité de confiance TA peut consister en un établissement bancaire, une administration publique ou privée, voire en un service opéré par un tel établissement ou administration. Nous pouvons par exemple citer le service « Live Identity » opéré par Orange Business Service. Un tel service est ouvert à tout opérateur de téléphonie mobile et permet de vérifier l’identité digitale d’un abonné. Une telle autorité de confiance TA pourrait également consister en un serveur informatique opéré par un fournisseur d’énergie ayant connaissance de ses usagers. En réponse à une requête en création d’un attribut vérifiable, l’émetteur Ij sollicite une investigation OUI auprès d’un tel tiers ou autorité TA pour déterminer, par exemple, si ledit utilisateur llm est majeur ou bien s’il réside dans telle ou telle localité, selon l’attribut vérifiable concerné. En l’espèce, dans l’exemple décrit en liaison avec la figure 1 , l’autorité TA sous la forme d’un serveur bancaire, connaissant la date de naissance de son client llm, peut remonter à l’émetteur une information confirmant ou réfutant la majorité de l’utilisateur llm. Dans l’affirmative, l’émetteur Ij élabore l’attribut vérifiable VC. Pour que l’autorité TA puisse répondre favorablement ou défavorablement audit émetteur Ij, l’investigation CUI peut consister en une requête véhiculant des informations publiques de l’identité digitale du sujet llm. Pour faire un lien entre le pseudonyme constitué par de telles informations publiques et un client ou abonné en tant que tel, l’autorité TA peut soumettre au portefeuille Wm, une requête en connaissance d’une information caractérisant le compte bancaire ou l’abonnement téléphonique du sujet utilisateur de l’objet électronique Om auprès de l’autorité TA ainsi que le consentement de l’utilisateur dudit objet électronique Om. En réponse à une telle requête, après sollicitation de l’utilisateur llm pour confirmer sa demande d’attribut vérifiable, ledit portefeuille Wm retourne l’information de compte bancaire ou d’abonnement signée à l’autorité TA qui peut en vérifier l’authenticité et élaborer la réponse à l’émetteur Ij qui ignore tout de ladite information caractérisant l’abonnement téléphonique ou le compte bancaire du porteur de l’objet Om. En variante, une telle requête en connaissance d’une information caractérisant le compte bancaire de l’utilisateur llm peut consister en une transaction bancaire d’un montant débité nul ou toute autre solution adaptée.
A titre d’exemple, comme l’indique la figure 1 , un attribut vérifiable émis VC comporte des informations contextuelles Ctx, par exemple décrivant le schéma cryptographique exploité pour signer ledit attribut préalablement à son émission à destination du portefeuille Wm. Un tel attribut vérifiable VC peut également comporter des informations publiques d’identités digitales (identifiant unique, clé cryptographique publique, etc.) respectivement de l’utilisateur Um et de l’émetteur Ij, une date de création dudit attribut vérifiable, voire une date de fin de validité de ce dernier. Un tel attribut vérifiable VC pourrait contenir toute autre information nécessaire à la mise en œuvre du système de preuve en ligne S. L’émetteur Ij élabore et envoie un message VC_M pour transmettre ledit attribut vérifiable VC au portefeuille Wm via l’objet électronique Om. Il existe des solutions pour rafraichir ou renouveler un attribut vérifiable lorsque celui-ci a expiré. A titre d’exemple, l’organisme W3C (ou World Wide Web Consortium) propose des recommandations visant à permettre un tel renouvellement après l’expiration d’un attribut vérifiable. Une telle proposition est exposée dans le document « Verifiable Credentials Data Mdel v1.1 » accessible via l’hyperlien https://www.w3.org/TR/2022/REC-vc- data-model-20220303/).
Le système de preuve en ligne S peut comporter une pluralité d’émetteurs, de vérifieurs et de portefeuilles d’attributs vérifiables. Pour distinguer les entités électroniques et informatiques les unes des autres, celles-ci sont associées à des informations d’identité digitales. Ainsi, le portefeuille Wm est associé à un identifiant unique IDWm, l’émetteur Ij à un identifiant unique IDIj et le vérifieur Vn à un identifiant unique IDVn. Pour certifier que les messages ou contenus sont bien émis par une première entité à destination d’une deuxième entité, un système de preuve en ligne S s’appuie généralement sur un schéma cryptographique de signature/vérification asymétrique. Ainsi, chaque entité comporte un jeu de clés respectivement publique PK et privée SK. Les clés publiques sont symbolisées par des clés de couleur blanche sur la figure 1 et les clés privées sont symbolisées par des clés de couleur noire.
Un couple de clés publique PKx et privée SKx d’une première entité électronique X est telle qu’une deuxième entité Y peut vérifier la signature de l’entité X en connaissant la clé publique PKx si ladite signature a été élaborée par la première entité X à l’aide de la clé privée SKx. En variante ou en complément, un message émis par l’entité X et adressé à l’entité Y peut également être chiffré de sorte que seule l’entité Y puisse lire ledit message. Dans ce cas, l’entité Y comporte également un couple de clés privée SKy et publique PKy. Connaissant la clé publique PKy, l’entité X peut chiffrer le message à l’aide de ladite clé publique PKy. Seule l’entité connaissant la clé privée SKy (en l’espèce, l’entité Y) pourra décoder ledit message chiffré en exploitant ladite clé privée SKy et obtenir le clair dudit message chiffré.
En liaison avec la figure 1 , l’identité digitale de chaque entité comporte, outre un identifiant unique, un tel jeu de clés publique et privée qui est propre à ladite entité. Sur la figure 1 , l’identité digitale llj de l’émetteur Ij comporte l’identifiant IDIj, la clé publique PKIj et la clé privée SKIj. L’identité digitale IWm du portefeuille Wm comporte l’identifiant IDWm, la clé publique PKWm et la clé privée SKWm. L’identité digitale IVn du vérifieur Vn comporte l’identifiant IDVn, la clé publique PKVn et la clé privée SKVn.
Ainsi, chaque entité électronique du système de preuve en ligne S dont fait partie le portefeuille Wm est associée à une identité digitale formée d’une identité digitale publique et d’une identité digitale privée, ladite identité digitale étant enregistrée dans une mémoire M de chaque entité électronique. Un message, une requête ou un contenu peut être signé par une première entité électronique à l’aide de son identité digitale privée, ladite signature pouvant être vérifiée par toute deuxième entité électronique en exploitant l’identité digitale publique de ladite première entité électronique. Éventuellement, ladite première entité peut chiffrer messages, requêtes ou contenus à l’aide de l’identité digitale publique d’une deuxième entité électronique déterminée, de sorte que cette dernière soit la seule entité électronique capable de déchiffrer lesdits messages, requêtes ou contenus à l’aide de sa propre identité digitale privée inconnue des autres entités électroniques.
Ainsi, l’identité digitale IWm du portefeuille Wm consiste en :
- une identité digitale publique PIWm, en l’espèce un identifiant unique IDWm et une clé publique PKWm ;
- une identité digitale privée, en l’espèce une clé privée SKWm conjointement élaborée avec ladite clé publique PKWm pour assurer un schéma cryptographique de signature asymétrique.
L’identité digitale llj de l’émetteur Ij de l’attribut VCi, objet d’un renouvellement automatique consiste en :
- une identité digitale publique PI Ij, en l’espèce un identifiant unique IDIj et une clé publique PKIj ; - une identité digitale privée, en l’espèce une clé privée SKIj conjointement élaborée avec ladite clé publique PKIj pour assurer un schéma cryptographique de signature asymétrique.
Il en serait de même pour un deuxième émetteur lj’ (non représenté sur la figure 1 ) distinct de l’émetteur lj. Ainsi, l’identité digitale I lj’ d’un tel émetteur lj’ consisterait en :
- une identité digitale publique PI lj’, en l’espèce un identifiant unique IDIj’ et une clé publique PKIj’ ;
- une identité digitale privée, en l’espèce une clé privée SKIj’ conjointement élaborée avec ladite clé publique PKIj’ pour assurer un schéma cryptographique de signature asymétrique.
Enfin, l’identité digitale IVn du vérifieur Vn consiste en :
- une identité digitale publique PIVn, en l’espèce un identifiant unique IDVn et une clé publique PKVn ;
- une identité digitale privée, en l’espèce une clé privée SKVn conjointement élaborée avec ladite clé publique PKVn pour assurer un schéma cryptographique de signature asymétrique
Selon l’exemple de la figure 1 , afin que les entités électroniques du système de preuve en ligne S puissent connaître les identités digitales publiques PI (i.e. les clés publiques PK, voire les identifiants ID desdites entités), ledit système S comporte un registre de confiance TR, sous la forme d’un serveur informatique associé lui-même à une identité digitale ITR dont l’identité digitale publique consiste en un identifiant unique IDTR et une clé publique PKTR et dont l’identité privée consiste en une clé privée SKTR. Ledit registre de confiance TR comporte une mémoire de données TRM comprenant un répertoire des identités digitales publiques des entités lj, Vn, Wm dudit système S, voire celles de l’autorité TA et/ou du fournisseur de services SP. Toutes les entités électroniques du système de preuve en ligne S (notamment les émetteurs, vérifieurs et portefeuilles) peuvent ainsi solliciter ledit registre de confiance TR par des requêtes en consultation d’identités digitales publiques PI_R pour connaître en réponse, via un message de transmission PI_M une ou plusieurs identités digitales publiques (i.e. les valeurs des identifiants uniques IDVn, IDIj, IDWm et/ou des clés publiques PKIj, PKWm, PKVn) d’entités électroniques déterminées et ainsi pouvoir vérifier les signatures des requêtes VC_PR, VC_CR, PI_R et des messages VC_M, PV_M, voire pour chiffrer, si nécessaire, lesdites requêtes et lesdits messages. Le registre de confiance TR est ainsi un référentiel, à date, des entités électroniques légitimes composant ledit système de preuve en ligne S. Une requête PI_R peut être signée à l’aide de l’identité digitale privée (en l’espèce une clé privée) de l’entité requérante. Ledit registre de confiance TR peut ainsi vérifier ladite signature en utilisant l’identité digitale publique (en l’espèce une clé publique) de l’entité requérante et s’assurer que celle-ci dispose bien d’une entrée dans son référentiel des entités électroniques légitimes du système S. Le message PI_M véhiculant le résultat d’une requête PI_R peut, à son tour, être signé par le registre de confiance TR en exploitant sa propre identité digitale privée (clé privée SKTR) avant émission.
Une exploitation incontrôlée ou non maîtrisée d’identifiants uniques indépendants, tels qu’exprimés précédemment, généralement repris en clair dans des métadonnées, peut poser des problèmes de confidentialité et de traçabilité. De tels identifiants peuvent parfois même être monétisés pour des ciblages publicitaires par exemple. Aussi, le schéma cryptographique retenu pour produire les identités digitales (identifiants et clés cryptographiques) desdites entités et assurer les échanges entre celles-ci, peut être avantageusement choisi pour utiliser des identifiants sécurisés dits « identifiants décentralisés » ou DIDs (acronyme anglo-saxon de « Decentralized Identifiers ») en lieu et place d’identifiants uniques indépendants des clés publiques et privées. Les identités digitales des entités électroniques du système de preuve en ligne S peuvent alors s’exprimer sous la forme d’identifiants ID décentralisés et sécurisés (DIDs), créés par lesdites entités pour garantir leurs authentifications et signatures. Selon les algorithmes exploités pour générer de tels identifiants sécurisés, il est ainsi possible de réduire l’identité digitale publique à un tel identifiant décentralisé ou à la seule clé publique d’une entité électronique, une relation bijective existant entre ladite clé publique et un tel identifiant décentralisé. En quelque sorte, un identifiant décentralisé est hérité ou dérivé de la clé publique qui lui est associée. Ainsi, connaissant l’identifiant (sous la forme d’un DID) d’une première entité, une deuxième entité peut recouvrer la clé publique PK de ladite première entité à partir de l’identifiant décentralisé ou réciproquement. Le registre de confiance TR peut ainsi stocker dans la mémoire de données TRM, les seuls identifiants IDIj, IDVn, IDWm, sous la forme d’identifiants décentralisés DIDs, ou bien les seules clés publiques PKIj, PKVn, PKWm en lieu et place de couples [identifiants clairs et clés publiques] pour répertorier les identités digitales publiques des entités du système de preuve en ligne S. De la même manière, un attribut vérifiable VC peut ne comporter que l’identifiant IDIj de l’émetteur Ij, lorsque ledit identifiant est un identifiant décentralisé ou en variante la seule clé publique PKIj de ce dernier, lorsque ledit identifiant IDIj est hérité de ladite clé publiques PKIj. Il en est de même, pour l’identité digitale publique IWM=[IDWm, PKWm] du portefeuille Wm qui est incluse dans ledit attribut vérifiable VC.
Comme l’indique la figure 1 , le système de preuve en ligne S comporte une pluralité d’entités électroniques en l’espèce des objets électroniques Om, des émetteurs Ij, des vérifieurs Vn, un registre de confiance TR, etc. De manière classique et comme l’illustre de manière simplifiée la figure 2, chacune desdites entités électroniques consiste en une instance d’un objet électronique ou d’un serveur informatique comportant une unité centrale de traitement 11 commandant, par des signaux acheminés par un bus de communication symbolisé sur la figure 2 par des doubles flèches en traits simples, des éléments électroniques dont une mémoire M. Cette dernière comprend une mémoire de données 12 et une mémoire de programmes 13, lesdites mémoires 12 et 13 pouvant ne former qu’une seule et même entité physique M.
On entend par « mémoire » toute mémoire informatique qu’elle soit volatile ou non. Une mémoire non volatile est une mémoire informatique dont la technologie conserve ses données en l’absence d’une alimentation en énergie électrique. Elle peut contenir des données résultant de saisies, de calculs, de mesures et/ou des instructions de programmes. Les principales mémoires non volatiles actuellement disponibles sont inscriptibles électriquement telles que la technologie EPROM (« Erasable Programmable Read-Only Memory », selon une terminologie anglo-saxonne) ou encore inscriptibles et effaçables électriquement telles que les technologies EEPROM (« Electrically-Erasable Programmable Read-Only Memory », selon une terminologie anglo-saxonne), flash, SSD (« Solid-State Drive », selon une terminologie anglo-saxonne), etc. Les mémoires non volatiles se distinguent des mémoires dites « volatiles » dont les données sont perdues en l’absence d’une alimentation électrique. Les principales mémoires volatiles actuellement disponibles exploitent les technologies RAM («. Random Access Memory » selon une terminologie anglo-saxonne ou encore nommée « mémoire vive »), DRAM (mémoire vive dynamique, nécessitant une réactualisation régulière), SRAM (mémoire vive statique nécessitant une telle réactualisation lors d’une sous-alimentation électrique), DPRAM ou VRAM (particulièrement adaptées à la vidéo), etc.
Selon la figure 2, une entité électronique d’un système de preuve en ligne comporte en outre des moyens de communication 14 avec le monde extérieur sous la forme d’une unité d'entrée et une unité de sortie. Lesdits moyens de communication 14 coopèrent avec l’unité de traitement 11 et assurent une communication de proximité sans fil ou filaire avec toute autre entité électronique dudit système S. Pour fonctionner, une telle entité électronique comporte généralement une source d’énergie électrique 15, externe ou interne sous la forme d’une ou plusieurs batteries par exemple. L’unité de traitement 11 peut également comporter des moyens de pilotage 16 d'une interface homme-machine d’entrée et/ou de sortie 17. On entend par « interface homme-machine de sortie », tout dispositif, employé seul ou en combinaison, permettant de sortir ou délivrer une représentation graphique, haptique, sonore ou, plus généralement, perceptible par l'humain. Une telle interface homme-machine de sortie peut consister de manière non exhaustive en un ou plusieurs écrans, haut-parleurs ou autres moyens alternatifs adaptés. On entend par « interface homme-machine d’entrée », un clavier informatique, un dispositif de pointage, un écran tactile, un microphone ou, plus généralement, toute interface agencée pour traduire une gestuelle ou une consigne émise par un humain en données de commande ou de paramétrage. Avantageusement, les interfaces homme-machine d'entrée et de sortie peuvent ne constituer qu'une seule et même entité physique.
Un tel système de preuve en ligne S peut être adapté en chargeant dans la mémoire de programmes 13 de chaque entité électronique un programme d'ordinateur P comportant des instructions pour provoquer, lors de leurs exécutions, la mise en œuvre d’un procédé idoine. Ce programme peut utiliser n'importe quel langage de programmation, et se présenter sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme interprétée, partiellement ou entièrement compilée, ou sous n'importe quelle autre forme souhaitable.
L’exploitation de pseudonymes (identifiants / clés publiques) en lieu et place d’informations identifiantes des internautes limite la traçabilité de ces dernières, notamment par l’emploi d’identifiants centralisés (DIDs). Toutefois, ces derniers demeurent traçables au gré des requêtes en présentations ou de créations d’attributs vérifiables.
L’invention permet de résoudre les inconvénients précédemment exprimés. Parmi les nombreux avantages procurés par la mise en œuvre de l’invention, nous pouvons mentionner que :
- l’invention conserve l’anonymat du porteur ou utilisateur d’un objet électronique hébergeant un portefeuille d’attributs vérifiables et limite, voire prévient, toute traçabilité des identités digitales publiques de l’utilisateur et/ou de son objet électronique mettant en œuvre le portefeuille d’attributs vérifiables, sans que cela nécessite une action dudit utilisateur ou alourdisse la tâche de ce dernier ;
- les attributs vérifiables émis ou réémis selon l’invention le sont par des émetteurs légitimes puisque connus du registre de confiance, limitant le risque que certains attributs vérifiables en cours de validité ne prospèrent alors qu’un émetteur d’attributs vérifiables a pu être révoqué ou supprimé du système de preuve en ligne ; - l’invention s’intégre parfaitement dans un système de preuve en ligne selon l’état de l’art (figure 1 ) offrant ainsi une garantie en matière d’interopérabilité ; la mise en œuvre de l’invention ne nécessite en effet qu’une mise à jour de portefeuilles d’attributs vérifiables et celle de certains émetteurs ou l’apport d’émetteurs spécifiques sans remettre en cause ou modifier le principe de la création d’attributs vérifiables, de présentations de ces derniers auprès d’entités vérifieurs en vue de l’obtention de contenus ou de biens et services.
A cette fin, l’invention prévoit un procédé de renouvellement automatique d’un attribut d’un utilisateur vérifiable par une entité électronique vérificatrice d’un système de preuve en ligne, un tel système comportant une pluralité d’entités électroniques respectivement agencées pour communiquer les unes avec les autres au sein dudit système dont, outre ladite entité électronique vérificatrice, un portefeuille d’attributs vérifiables mis en œuvre par une unité de traitement d’un objet électronique détenu par un utilisateur, une entité électronique émettrice d’attributs vérifiables, tout attribut vérifiable émis ayant été préalablement élaboré et transmis par une entité électronique émettrice dudit système de preuve en ligne en réponse à une requête en création d’attribut vérifiable initiée par un portefeuille d’attributs vérifiables dudit système. Pour prévenir toute constitution, par une entité électronique émettrice malveillante ou susceptible d’être la cible d’une attaque malveillante à dessein, d’un historique d’émissions d’attributs vérifiables d’un portefeuille d’attributs vérifiables, et donc in fine de l’internaute porteur de l’objet électronique qui héberge ledit portefeuille, un tel procédé de renouvellement automatique comporte :
- un premier sous-procédé, mis en œuvre par un portefeuille d’attributs vérifiables, comprenant : o une étape de détection d’un événement déclencheur d’un renouvellement d’un attribut vérifiable d’ores et déjà émis par une entité électronique émettrice dudit système de preuve en ligne ; o une étape d’élaboration et de déclenchement de l’émission d’une requête en renouvellement d’un attribut vérifiable d’ores et déjà émis, à destination d’une entité électronique émettrice du système de preuve en ligne distincte de celle ayant émis ledit attribut vérifiable objet de la requête en renouvellement ; o une étape de gestion d’un nouvel attribut vérifiable fruit d’une telle requête en renouvellement et transmis par ladite entité émettrice ;
- un deuxième sous-procédé mis en œuvre par une unité de traitement d’une entité émettrice du système de preuve en ligne comprenant : o une étape de traitement d’une requête en renouvellement d’un attribut vérifiable transmise par un portefeuille d’attributs vérifiables ; o en réponse à un tel traitement d’une requête en renouvellement, puisque ledit attribut vérifiable a été émis par l'une des entités émettrices du système de preuve en ligne, une étape de renouvellement d’un tel attribut vérifiable et de transmission d’un nouvel attribut vérifiable à destination du portefeuille d’attributs vérifiables requérant ledit renouvellement d’attribut vérifiable d’ores et déjà émis. Une telle étape de renouvellement d’un tel attribut vérifiable et de transmission d’un nouvel attribut vérifiable à destination du portefeuille d’attributs vérifiables comporte :
- une étape d’élaboration d’un nouvel attribut vérifiable consistant à copier l’intégralité des informations contenues dans l’attribut vérifiable à renouveler exception faite des informations en lien avec l’élaboration en tant que telle de ce dernier ; une étape pour provoquer l’émission du nouvel attribut vérifiable à destination du portefeuille d’attributs vérifiables requérant le renouvellement.
De manière avantageuse, afin que l’entité émettrice sélectionnée et destinataire de ladite requête en renouvellement soit distincte celle ayant émis ledit attribut vérifiable objet de la requête en renouvellement, un tel procédé selon l’invention peut être agencé de sorte que lequel l’étape d’élaboration et de déclenchement de l’émission d’une requête en renouvellement d’un attribut vérifiable d’ores et déjà émis puisse comporter, préalablement à l’élaboration en tant que telle de ladite requête, une sélection idoine d’une entité électronique émettrice du système de preuve en ligne parmi celles contenues dans une liste entités émettrices disponibles et aptes à réaliser un tel renouvellement d’attributs vérifiables.
Un tel système de preuve en ligne pouvant comporter de nombreuses entités électroniques, chaque entité électronique dudit système de preuve en ligne peut avantageusement être associée à une identité digitale formée d’une partie publique, dite « identité digitale publique » et d’une partie privée), dite « identité digitale privée », ladite identité digitale étant enregistrée dans une mémoire de données de ladite chaque entité électronique. Ledit système de preuve en ligne comprend alors un registre de confiance agencé pour :
- enregistrer, dans une mémoire de données, les identités digitales publiques respectives des entités électroniques dudit système de preuve en ligne ;
- recevoir une requête en consultation d’identités digitales publiques émanant d’une entité électronique dudit système ;
- élaborer un message de transmission véhiculant une ou plusieurs identités digitales publiques et émettre un tel message à destination de l’entité électronique émettrice de ladite requête en consultation d’identités digitales publiques.
Le premier sous-procédé d’un procédé conforme à l’invention peut alors être agencé de sorte que l’étape de gestion d’un nouvel attribut vérifiable fruit d’une telle requête en renouvellement comporte : - une étape de vérification de la signature du nouvel attribut vérifiable par l’entité émettrice de ce dernier, à l’aide de l’identité digitale publique de ladite entité électronique émettrice ;
- une étape d’enregistrement du nouvel attribut vérifiable, dans une mémoire de données accessible en lecture et en écriture par le portefeuille d’attributs vérifiables, en remplacement de l’attribut vérifiable renouvelé si et seulement si ladite étape de vérification de la signature du nouvel attribut vérifiable confirme l’authenticité de ladite signature.
Le deuxième sous-procédé peut, quant à lui, être agencé de sorte que :
- l’étape de traitement d’une requête en renouvellement d’un attribut vérifiable d’ores et déjà émis comporte : o une étape de réception d’une telle requête en renouvellement et de lecture des informations véhiculées par cette dernière parmi lesquelles l’attribut vérifiable d’ores et déjà émis et l’identité digitale publique du portefeuille d’attributs vérifiables, respectivement objet et émetteur de ladite requête en renouvellement ; o une étape de vérification de la signature de l’attribut vérifiable à renouveler par l’entité électronique émettrice de ce dernier, à l’aide de l’identité digitale publique de cette dernière ;
- l’étape de renouvellement d’un attribut vérifiable d’ores et déjà émis et de transmission d’un nouvel attribut vérifiable : o n’est mise œuvre que si ladite étape de vérification de la signature de l’attribut vérifiable à renouveler confirme l’authenticité de cette dernière ; o l’étape d’élaboration du nouvel attribut vérifiable consiste à signer ledit nouvel attribut vérifiable à l’aide de l’identité digitale privée de l’entité émettrice dudit nouvel attribut vérifiable. De manière avantageuse, le premier sous-procédé d’un procédé de renouvellement automatique selon l’invention peut être agencé de sorte que l’étape d’élaboration et de déclenchement de l’émission d’une requête en renouvellement puisse comporter une étape de signature de ladite requête en renouvellement à l’aide de l’identité digitale privée du portefeuille d’attributs vérifiables. Dans ce cas, le deuxième sous-procédé peut être agencé de sorte que :
- l’étape de traitement d’une requête en renouvellement d’un attribut vérifiable d’ores et déjà émis comporte une étape de vérification de la signature de ladite requête en renouvellement par le portefeuille d’attributs vérifiables, à l’aide de l’identité digitale publique de ce dernier ;
- l’étape de renouvellement d’un attribut vérifiable d’ores et déjà émis et de transmission d’un nouvel attribut vérifiable n’est mise œuvre que si ladite étape de signature de la requête en renouvellement confirme l’authenticité de ladite signature.
Pour provoquer à bon escient et de manière automatique une mise en œuvre d’un procédé de renouvellement automatique d’un attribut conforme à l’invention, le premier sous-procédé de ce dernier peut être agencé de sorte que l’étape de détection d’un événement déclencheur d’un renouvellement automatique d’un attribut vérifiable puisse consister en :
- une lecture, dans une mémoire de données accessible en lecture et écriture par le portefeuille d’attributs vérifiables, la valeur d’un compteur de messages de présentation véhiculant l’attribut vérifiable adressés à une entité électronique vérificatrice du système de preuve en ligne ;
- une comparaison de la valeur courante dudit compteur à un seuil maximal prédéterminé et une conclusion quant à la détection d’un événement déclencheur d’un renouvellement automatique si ladite valeur dudit compteur atteint ledit seuil prédéterminé.
Dans ce cas, ledit premier sous-procédé peut en outre être agencé de sorte que l’étape de gestion d’un nouvel attribut vérifiable fruit d’une requête en renouvellement puisse également consister en une initialisation de la valeur d’un compteur de messages de présentation véhiculant ledit nouvel attribut vérifiable dans une mémoire de données accessible en lecture et en écriture par le portefeuille d’attributs vérifiables.
Pour préserver l’anonymat des utilisateurs, l'étape d’élaboration et de déclenchement de l’émission d’une requête en renouvellement d’un attribut vérifiable d’ores et déjà émis du premier sous-procédé peut comporter une étape de production d’une nouvelle identité digitale du portefeuille d’attributs vérifiables en remplacement de la précédente. L’étape d’élaboration de la requête en renouvellement de l’attribut vérifiable d’ores et déjà émis à destination de l’entité émettrice est alors agencée de sorte que ladite requête en renouvellement comporte l’attribut vérifiable à renouveler et la nouvelle identité digitale publique du portefeuille d’attributs vérifiables.
Selon un mode de réalisation avantageux, lorsque le système de preuve en ligne comporte un registre de confiance, l'étape d’élaboration et de déclenchement de l’émission d’une requête en renouvellement d’un attribut vérifiable d’ores et déjà émis du premier sous-procédé peut comporter :
- une étape d’élaboration d’une requête en consultation d’identités digitales publiques d’entités émettrices du système de preuve en ligne et de déclenchement de l’émission de ladite requête à destination du registre de confiance ;
- une étape de réception d’un message de transmission émanant dudit registre de confiance et de lecture au sein de celui-ci d’une identité digitale publique d’entité émettrice véhiculée par ledit message.
Dans ce cas, l’étape d’élaboration de la requête en renouvellement de l’attribut vérifiable d’ores et déjà émis à destination de l’entité émettrice peut être agencée de sorte que l’identité digitale publique de ladite entité émettrice est tirée du message de transmission émanant dudit registre de confiance.
Selon ce mode de réalisation avantageux, afin de rendre accessible une telle nouvelle identité digitale publique du portefeuille d’attributs vérifiables aux autres entités électroniques du système de preuve en ligne, l’étape de production d’une nouvelle identité digitale du portefeuille d’attributs vérifiables peut consister en outre à élaborer une requête en mise à jour d’identité digitale publique à destination du registre de confiance, ladite requête véhiculant la nouvelle identité digitale publique issue de la nouvelle identité digitale signée à l’aide de la précédente identité digitale privée dudit portefeuille d’attributs vérifiables.
L’invention permet de prévenir toute exploitation future d’une instance antérieure d’un attribut vérifiable qui a fait l’objet d’un renouvellement, ladite instance antérieure pouvant faire l’objet d’une révocation publique au sein du système de preuve en ligne. Pour cela :
- le registre de confiance peut être agencé pour mémoriser tout attribut vérifiable révoqué ou une information caractéristique d’un tel attribut vérifiable révoqué en réponse à la réception d’une requête en révocation d’attribut vérifiable ;
- l’étape de gestion d’un nouvel attribut vérifiable fruit d’une requête en renouvellement peut comporter une étape d’élaboration d’une telle requête en révocation d’attribut vérifiable véhiculant l’attribut vérifiable ayant fait l’objet d’un renouvellement à destination du registre de confiance ou une informatique caractéristique de ce dernier.
Selon ce dernier mode de réalisation avantageux, afin de prévenir toute révocation illégitime, l’étape d’élaboration d’une telle requête en révocation peut consister en outre à signer ladite requête à l’aide de l’identité digitale privée dudit portefeuille d’attributs vérifiables.
Selon un mode de réalisation avantageux, l’étape de vérification de la signature de l’attribut vérifiable à renouveler du deuxième sous-procédé peut à son tour être précédée :
- d'une étape d’élaboration d’une requête en consultation d’identités digitales publiques d’entités électroniques du système de preuve en ligne et de déclenchement de l’émission de ladite requête à destination du registre de confiance ; - d’une étape de réception d’un message de transmission émanant dudit registre de confiance et de recherche, au sein de celui-ci, de l’identité digitale publique de l’entité électronique émettrice de l’attribut vérifiable à renouveler.
De la même manière, l’étape de vérification de la signature de la requête en renouvellement par le portefeuille d’attributs vérifiables du deuxième sous- procédé peut être avantageusement précédée :
- d'une étape d’élaboration d’une requête en consultation d’identités digitales publiques d’entités électroniques du système de preuve en ligne et de déclenchement de l’émission de ladite requête à destination du registre de confiance ;
- d’une étape de réception d’un message de transmission émanant dudit registre de confiance et de recherche, au sein de celui-ci, de l’identité digitale publique du portefeuille d’attributs vérifiables.
Selon un mode d’application préféré, l’attribut vérifiable pouvant faire l’objet d’un processus de renouvellement selon l’invention peut caractériser la majorité de l’utilisateur de l’objet électronique hébergeant le portefeuille d’attributs vérifiables.
Selon un mode de réalisation préféré, pour chaque entité électronique d’un système de preuve en ligne adapté selon l’invention :
- l’identité digitale publique peut consister en une clé publique et un identifiant ;
- l’identité digitale privée consiste en une clé privée produite conjointement avec ladite clé publique, par la mise en œuvre d’un algorithme cryptographique asymétrique.
Pour chaque entité électronique d’un tel système, l'identifiant peut être un identifiant décentralisé dérivé de ladite clé publique par la mise en œuvre d’un algorithme cryptographique réversible, ladite identité digitale publique se réduisant ainsi en ledit identifiant décentralisé ou en ladite clé publique.
Pour adapter un système de preuve en ligne connu de sorte qu’il préserve l’anonymat des utilisateurs et préserve toute traçabilité des activités respectives de ces derniers, l’invention concerne en outre un premier produit programme d’ordinateur comportant une ou plusieurs instructions de programme exécutables par une unité de traitement d’un objet électronique hébergeant un portefeuille d’attributs vérifiables d’un système de preuve en ligne, lesdites instructions de programme étant :
- chargeables dans une mémoire dudit objet électronique hébergeant un portefeuille d’attributs vérifiables ;
- conçues de sorte que leur exécution par ladite unité de traitement provoque la mise en œuvre par ledit portefeuille d’attributs vérifiables d’un premier sous-procédé d’un procédé de renouvellement automatique d’un attribut vérifiable selon l’invention.
L’invention concerne alors également :
- un support de mémorisation lisible par un ordinateur comportant les instructions d’un tel premier produit programme d’ordinateur ;
- un objet électronique comportant une unité de traitement, des moyens de communication avec le monde extérieur et une mémoire enregistrant les instructions de programme d’un tel premier produit programme d’ordinateur.
Pour adapter un système de preuve en ligne connu de sorte qu’il préserve l’anonymat des utilisateurs et préserve toute traçabilité des activités respectives de ces derniers, l’invention concerne en outre un deuxième produit programme d’ordinateur comportant une ou plusieurs instructions de programme exécutables par une unité de traitement d’une entité électronique émettrice d’attributs vérifiables d’un système de preuve en ligne, lesdites instructions de programme étant :
- chargeables dans une mémoire de ladite entité électronique émettrice ;
- conçues de sorte que leur exécution par ladite unité de traitement provoque la mise en œuvre d’un deuxième sous-procédé d’un procédé de renouvellement automatique d’un attribut vérifiable selon l’invention.
L’invention concerne alors également : - un support de mémorisation lisible par un ordinateur comportant les instructions d’un tel deuxième produit programme d’ordinateur ;
- une entité électronique émettrice d’attributs vérifiables comportant une unité de traitement, des moyens de communication avec le monde extérieur et une mémoire enregistrant les instructions de programme d’un tel deuxième produit programme d’ordinateur.
Enfin, l’invention concerne tout système de preuve en ligne comportant une pluralité d’entités électroniques respectivement agencées pour communiquer les unes avec les autres au sein dudit système dont :
- une entité électronique vérificatrice d’attributs vérifiables ;
- un portefeuille d’attributs vérifiables mis en œuvre par une unité de traitement d’un objet électronique détenu par un utilisateur, ledit objet électronique étant agencé selon l’invention et tel qu’exprimé précédemment ;
- une entité électronique émettrice d’attributs vérifiables agencée selon l’invention et tel qu’exprimé précédemment.
D’autres caractéristiques et avantages apparaîtront plus clairement à la lecture de la description qui suit et à l'examen des figures qui l'accompagnent parmi lesquelles :
- la figure 1 , d’ores et déjà décrite, illustre un exemple d’un système de preuve en ligne d’attributs vérifiables selon l’état de l’art ;
- la figure 2, d’ores et déjà décrite, illustre un exemple d’architecture fonctionnelle de toute entité électronique formant ledit système de preuve en ligne selon la figure 1 ;
- la figure 3 illustre un exemple d’un procédé de renouvellement automatique d’attributs vérifiables conforme à l’invention et mis en œuvre par un système de preuve en ligne d’attributs vérifiables ;
- la figure 4 illustre un organigramme fonctionnel d’un premier sous- procédé d’un procédé de renouvellement automatique d’attributs vérifiables conforme à l’invention et décrit par la figure 3, ledit premier sous-procédé étant destiné à être mis en œuvre par un portefeuille d’attributs vérifiables d’un système de preuve en ligne tel que celui illustré par la figure 1 ;
- la figure 5 illustre un organigramme fonctionnel d’un deuxième sous-procédé d’un procédé de renouvellement automatique d’attributs vérifiables conforme à l’invention et décrit par la figure 3, ledit deuxième sous-procédé étant destiné à être mis en œuvre par une entité électronique émettrice d’attributs vérifiables d’un système de preuve en ligne illustré par la figure 1 .
La figure 3 illustre ainsi un procédé 300 de renouvellement automatique d’un attribut vérifiable VCi, destiné à être vérifié par un vérifieur Vn d’un système de preuve en ligne S selon la figure 1. Un tel vérifieur Vn n’est pas impliqué dans le procédé 300 et n’apparaît donc pas sur la figure 3. En effet, un attribut vérifiable obtenu après la mise en œuvre d’un procédé de renouvellement 300 conforme à l’invention est similaire à tout autre attribut vérifiable obtenu après la mise en œuvre d’un processus connu par un émetteur Ij en réponse à une requête en création VC CR selon l’état de l’art.
Un tel procédé 300 selon l’invention est principalement agencé sous la forme de deux sous-procédés, respectivement référencés 100 et 200 sur la figure 3. Ces deux sous-procédés 100 et 200 seront détaillés ultérieurement, respectivement en liaison avec les figures 4 et 5.
Le premier sous-procédé 100 est agencé pour être mis en œuvre par un portefeuille Wm hébergé par un objet électronique Om, sous la forme avantageuse d’un téléphone mobile intelligent selon l’exemple non limitatif illustré par la figure 3, ledit portefeuille Wm étant agencé sous la forme d’une application logicielle (programme d’ordinateur adapté aux systèmes d’exploitation de tels téléphones). Plus précisément, un tel sous-procédé 100 peut être conçu, sous la forme d’un sous-programme d’ordinateur ou bien être intégré au programme d’ordinateur P installé dans la mémoire de programmes M, 13, de l’objet électronique Om et dont les instructions de programme, lors de leur exécution par l’unité de traitement 11 dudit objet Om, provoquent la mise en œuvre du portefeuille Wm par ledit objet électronique Om. Le deuxième sous-procédé 200 est, quant à lui, agencé pour être mis en œuvre sous la forme d’un programme ou sous-programme d’ordinateur P, par une unité de traitement d’une entité électronique émettrice d’attributs vérifiables ou émetteur lj’.
Pour sa mise en œuvre, l’invention ne requiert ainsi que l’adaptation ou la conception de portefeuilles et d’émetteurs d’un système de preuve en ligne S. Comme l’indique la figure 3, ledit procédé 300 peut en outre mettre en scène un registre de confiance TR enregistrant les identités digitales publiques des entités électroniques du système S, parmi lesquelles notamment celles du portefeuille Wm et de l’émetteur lj’ ainsi adaptés. En effet, ledit registre de confiance TR peut être avantageusement sollicité durant la mise en œuvre du procédé 300 au moyen de requêtes classiques et connues PI_R en consultation d’identités digitales publiques émanant de toute entité électronique d’un système de preuve en ligne S tel que celui décrit en lien avec la figure 1 . Ainsi, un tel registre de confiance TR peut, selon l’état de l’art, élaborer un message de transmission PI_M véhiculant une ou plusieurs identités digitales publiques et émettre un tel message à destination de l’entité électronique à l’initiative de ladite requête PI_R en consultation d’identités digitales publiques.
Pour illustrer un tel procédé 300 conforme à l’invention, supposons qu’un attribut vérifiable VC atteste de la majorité du porteur Urn de l’objet électronique Om. Une instance de cet attribut, référencée VCi en figure 3, a été créée et émise en réponse à une requête en création d’un attribut vérifiable, ladite requête en création VC_CR étant conforme à l’état actuel de la technique et ayant été adressée par le portefeuille Wm à un premier émetteur lj tel que celui d’ores et déjà décrit en lien avec le système de preuve en ligne S selon la figure 1 . Ledit émetteur lj n’est pas représenté sur la figure 3 car ladite étape de création et de transmission dudit attribut vérifiable VCi ne fait pas partie de l’invention. Supposons également que ledit attribut vérifiable VCi, à l’instar de l’état actuel de la technique, comporte les informations suivantes : - des données de contexte Ctx propres à la mise en œuvre du système de preuve en ligne S ;
- l’identité digitale publique PIWm (identifiant IDWm et/ou clé publique PKWm) de l’utilisateur Urn ou, plus précisément, celle du portefeuille Wm mis en œuvre par l’objet Om détenu par ledit utilisateur Urn ;
- l’attribut attesté, en l’espèce « l’utilisateur est majeur » - cet attribut pourrait être facultatif dans le cadre d’un système de preuve de majorité en ligne dédié à ce seul attribut ;
- l’identité digitale de l’émetteur Ij ayant élaboré et émis ledit attribut vérifiable VCi ;
- une date de création ou d’émission CD dudit attribut vérifiable VCi
J
- une date de fin de validité EVD au-delà de laquelle, toute demande de présentation CV_PR dudit attribut vérifiable VCi serait rejetée par tout vérifieur Vn dudit système S ;
- une signature dudit attribut vérifiable VCi par l’émetteur Ij réalisée par ce dernier à l’aide de son identité digitale privée (clé privée SKIj).
Un tel attribut vérifiable peut être exploité par le portefeuille Wm pour répondre à toute requête en présentation VC_PR émanant de vérifieurs Vn. Bien qu’exploitant éventuellement un pseudonyme sous la forme d’un identifiant décentralisé IDWm, ce dernier peut être tracé par lesdits vérifieurs Vn. Il est donc possible de consister un historique des messages de présentation PV_M, historique pouvant être préjudiciable pour l’internaute, certains vérifieurs ou émetteurs pouvant croiser et partager leurs informations en lien avec l’exploitation dudit attribut vérifiable. Il n’existe pas à cette heure de solution permettant de prévenir ce risque.
Le procédé 300 illustré par la figure 3 résout cette difficulté de manière élégante et transparente pour l’internaute. Ainsi, principalement par la mise en œuvre du sous-procédé 100, un portefeuille Wm peut décider, selon différents critères, de provoquer un renouvellement conjoint de l’identité digitale du portefeuille Wm et d’attributs vérifiables d’ores et déjà légitimement émis, sans nécessiter d’itérer une procédure de création VC CR d’attributs vérifiables. Ledit sous-procédé 100 est agencé pour adresser une requête innovante en renouvellement d’un attribut vérifiable d’ores et déjà émis VC RR à tout émetteur lj’ du système de preuve en ligne S qui aurait était adapté ou agencé pour mettre en œuvre le sous-procédé 200. Une telle requête VC_RR véhicule principalement l’attribut VCi d’ores et déjà émis par l’émetteur lj et la nouvelle identité digitale publique du portefeuille Wm. En réponse à une telle requête en renouvellement VC_RR, puisqu’un tel attribut vérifiable VCi a été mis par un émetteur lj légitime au sein du système S, l’émetteur lj’ crée une copie de l’attribut vérifiable VCi sous la forme d’un nouvel attribut vérifiable VCi+i conservant tout ou partie de la teneur de l’attribut VCi, c’est-à-dire, en l’espèce :
- les données de contexte Ctx propres à la mise en œuvre du système de preuve en ligne S ;
- l’attribut attesté, en l’espèce « l’utilisateur est majeur » - cet attribut pouvant être facultatif dans le cadre d’un système de preuve de majorité en ligne dédié à ce seul attribut ;
- la date de fin de validité EVD au-delà de laquelle, toute demande de présentation CV_PR dudit nouvel attribut vérifiable VCi+i serait rejetée par tout vérifieur Vn dudit système S.
Le nouvel attribut vérifiable VCi+i, quasi-clone de l’attribut vérifiable VCi, diffère uniquement dans son contenu en ce que :
- l’identité digitale publique PIWm (identifiant IDWm et/ou clé publique PKWm) de l’utilisateur Um ou plus précisément celle du portefeuille Wm requérant le renouvellement et mis en œuvre par l’objet Om détenu par ledit utilisateur Um ;
- une signature dudit nouvel attribut vérifiable VCi+i par l’émetteur lj’ réalisée par ce dernier à l’aide de son identité digitale privée (clé privée SKIj’) remplace la signature de l’émetteur lj de l’attribut vérifiable VCi ; - l’identité digitale publique de l’émetteur lj’ ayant élaboré et émis ledit nouvel attribut vérifiable VCi+i remplace celle de l’émetteur lj de l’attribut VCi ;
- une date de création ou d’émission CD dudit nouvel attribut vérifiable VCi+i en lieu et place de la date de création de l’attribut vérifiable VCi.
Il est à noter que lorsque l’attribut vérifiable à renouveler VCi comporte une date de fin de validité EVD au-delà de laquelle toute demande de présentation CV PR dudit nouvel attribut vérifiable VCi serait rejetée par tout vérifieur Vn dudit système S, le nouvel attribut vérifiable VCi+i issu du processus de renouvellement reproduit la même date de fin de validité EVD que l’attribut vérifiable initial VCi.
Par la mise en œuvre du sous-procédé 200 après avoir créé ledit nouvel attribut vérifiable VCi+i, sans déclencher une quelconque investigation CUI auprès d’une entité ou autorité TA, l’émetteur lj’ transmet ledit nouvel attribut vérifiable VCi+i, par un message de transmission VC_M, au portefeuille Wm qui remplace, dans la mémoire de donnée M, 12 de l’objet électronique Om, l’attribut vérifiable VCi par l’attribut vérifiable VCi+i .
Un tel procédé 300 peut être itéré autant que nécessaire, de sorte que ledit nouvel attribut vérifiable VCi+i puisse faire, à son tour, l’objet d’une requête en renouvellement auprès d’un émetteur du système S pour donner naissance à un nouvel attribut vérifiable VCi+n, à l’instar de l’attribut vérifiable initial VCi. Par la mise en œuvre de l’invention, le traçage à des fins de constitution d’historique est limité. Il devient totalement impossible dans le cas où les demandes de renouvellement d’un attribut vérifiable sont adressées à des émetteurs distincts au sein du système de preuve en ligne S. En effet, un émetteur sollicité pour un renouvellement ne disposerait plus de la capacité d’enrichir une chaîne de renouvellements, si l’attribut vérifiable à renouveler l’a été par un deuxième émetteur, sauf à créer des coalitions avec ses pairs.
L’invention prévoit ainsi un mode de réalisation avantageux d’un procédé 300 selon lequel un émetteur sollicité pour un renouvellement d’un attribut vérifiable soit systématiquement ou aléatoirement différent de celui qui a été à l’origine de l’émission (création ou renouvellement) de l’attribut vérifiable faisant l’objet du renouvellement.
La figure 3 illustre également que les sous-procédés 100 et 200 peuvent solliciter le registre de confiance TR du système de preuve en ligne au moyen de requêtes PI_R en consultation d’identités digitales publiques, ledit registre TR communiquant, en réponse, de telles identités digitales publiques par des messages de transmission PI_M. Cette variante avantageuse d’un procédé 300 selon l’invention permet au portefeuille Wm et à l’émetteur lj’ sollicité pour un renouvellement d’attribut vérifiable de s’assurer mutuellement de la légitimité des requêtes et messages échangés ainsi que de l’authenticité de l’attribut vérifiable à renouveler. En effet, préalablement à l’émission d’une requête en renouvellement VC_RR, le portefeuille Wm peut consulter le registre de confiance pour sélectionner un émetteur légitime et satisfaisant certaines contraintes, comme celle évoquée précédemment pour prévenir un suivi des renouvellements par un émetteur malveillant ou cible d’une attaque. De son côté, pour donner une suite favorable à une requête en renouvellement adressée par un portefeuille Wm, un émetteur destinataire de ladite requête peut solliciter ledit registre de confiance TR pour disposer des identités digitales publiques respectives dudit portefeuille et de l’émetteur dont l’identité digitale publique est consignée dans l’attribut vérifiable objet d’un renouvellement. Ledit émetteur destinataire de la requête en renouvellement peut ainsi vérifier, d’une part, la signature du portefeuille Wm si celui-ci a signé la requête en renouvellement à l’aide de sa propre identité digitale privée et, d’autre part, la signature de l’émetteur de l’attribut vérifiable concerné par le renouvellement, si ce dernier comporte une telle signature élaborée à partir de l’identité digitale privée de son émetteur.
Enfin, la figure 3 illustre un procédé 300 de renouvellement automatique d’un attribut vérifiable pour lequel le sous-procédé 100 permet une élaboration d’une requête en révocation VC_RKR d’un attribut vérifiable renouvelé VCi, c’est-à-dire celui sur lequel portait une requête en renouvellement VC_RR, à l’issue de la production d’un nouvel attribut vérifiable VCi+i . Une telle requête en révocation est agencée pour être interprétée par le registre de confiance TR ou tout autre registre dédié à cet effet, pour enregistrer les attributs vérifiables ainsi révoqués après renouvellement ou, en lieu et place de tels attributs vérifiables révoqués, enregistrer des informations caractéristiques de ces derniers, à l’instar du résultat d’une fonction cryptographique de hachage d’un tel attribut vérifiable par exemple. Selon cette variante, un émetteur lj’ destinataire d’une requête en renouvellement d’un attribut vérifiable peut en outre vérifier, en sollicitant ledit registre, que l’attribut vérifiable objet d’un renouvellement n’est pas un attribut vérifiable révoqué. Dans la négative, le sous-procédé 200 ne procède pas au renouvellement et peut retourner un message d’erreur au portefeuille requérant le renouvellement.
La figure 4 illustre en détail des modes de réalisation avantageux d’un sous-procédé 100 d’un procédé de renouvellement automatique d’attributs vérifiables selon l’invention. Comme indiqué précédemment, un tel sous- procédé 100 est agencé pour être mis en œuvre, ou faire partie, d’un portefeuille Wm adapté en conséquence et appartenant à un système de preuve en ligne S dont au moins un émetteur lj’ est adapté pour mettre en œuvre un sous-procédé 200 exploitant une requête en renouvellement d’un attribut vérifiable.
Un tel sous-procédé 100 consiste en trois grandes étapes distinctes référencées 110, 120, 130 sur la figure 4, lesdites étapes étant dédiées respectivement à :
- la détection 110 d’un événement déclencheur d’un renouvellement d’un attribut vérifiable VCi, c’est-à-dire un attribut vérifiable d’ores et déjà émis légitimement (simplement créé ou précédemment renouvelé) par l’émetteur lj (non représenté sur la figure 4) ;
- l’élaboration et le déclenchement 120 de l’émission d’une requête VC_RR en renouvellement d’un tel attribut vérifiable VCi à destination d’un émetteur lj’ du système de preuve en ligne S ;
- la gestion 130 d’un nouvel attribut vérifiable VCi+i fruit d’une telle requête en renouvellement VC_RR et transmis par ledit émetteur lj’ par un message de transmission VC_M. Selon la figure 4, chaque entité électronique du système de preuve en ligne dont fait partie le portefeuille Wm est associée à une identité digitale formée d’une identité digitale publique et d’une identité digitale privée, ladite identité digitale étant enregistrée dans une mémoire de données 12 de chaque entité électronique. Un message, une requête ou un contenu peut être signé par une première entité électronique à l’aide de son identité digitale privée, ladite signature pouvant être vérifiée par toute deuxième entité électronique en exploitant l’identité digitale publique de ladite première entité électronique. Éventuellement, ladite première entité peut chiffrer messages, requêtes ou contenus à l’aide de l’identité digitale publique d’une deuxième entité électronique déterminée, de sorte que cette dernière soit la seule entité électronique capable de déchiffrer lesdits messages, requêtes ou contenus à l’aide de sa propre identité digitale privée inconnue des autres entités électroniques.
Ainsi, l’identité digitale IWm du portefeuille Wm consiste en :
- une identité digitale publique PIWm, en l’espèce un identifiant unique IDWm (éventuellement décentralisé) et une clé publique PKWm ;
- une identité digitale privée, en l’espèce une clé privée SKWm conjointement élaborée avec ladite clé publique PKWm pour assurer un schéma cryptographique de signature et/ou de chiffrement asymétrique.
L’identité digitale llj de l’émetteur Ij de l’attribut VCi, objet d’un renouvellement automatique consiste en :
- une identité digitale publique PI Ij, en l’espèce un identifiant unique IDIj (éventuellement décentralisé) et une clé publique PKIj ;
- une identité digitale privée, en l’espèce une clé privée SKIj conjointement élaborée avec ladite clé publique PKIj pour assurer un schéma cryptographique de signature et/ou de chiffrement asymétrique.
Il en est de même pour l’émetteur Ij’ destinataire d’une requête en renouvellement de l’attribut vérifiable VCi, éventuellement ou avantageusement distinct de l’émetteur Ij. Ainsi, l’identité digitale llj’ de l’émetteur Ij’ consiste en :
- une identité digitale publique PI Ij’, en l’espèce un identifiant unique IDIj’ (éventuellement décentralisé) et une clé publique PKIj’ ;
- une identité digitale privée, en l’espèce une clé privée SKIj’ conjointement élaborée avec ladite clé publique PKIj’ pour assurer un schéma cryptographique de signature et/ou de chiffrement asymétrique.
Le système de preuve en ligne S, dont fait partir le portefeuille Wm et les émetteurs Ij et Ij’, comprend un registre de confiance TR agencé pour enregistrer, dans une mémoire de données TRM qui lui est propre les identités digitales publiques PIWm, Pllj, Pllj’, respectives des entités électroniques Wm, Ij, et Ij’ dudit système de preuve en ligne S. Ledit registre est apte à recevoir une requête PI_R en consultation d’identités digitales publiques émanant d’une entité électronique dudit système S et élaborer, en réponse à une telle requête PI_R, un message de transmission PI_M véhiculant une ou plusieurs identités digitales publiques à destination de l’entité électronique émettrice de ladite requête PI_R en consultation d’identités digitales publiques.
Le sous-procédé 100 comporte donc une première étape de détection 110 d’un événement déclencheur d’un renouvellement d’un attribut vérifiable, en l’espèce l’attribut vérifiable VCi émis au préalable par l’émetteur Ij.
Un tel événement peut être de différentes natures. L’invention prévoit en effet qu’un renouvellement d’un attribut vérifiable puisse être déclenché automatiquement à la suite d’un nombre prédéterminé de réponses à des requêtes en présentation VC_PR d’un tel attribut vérifiable émanant de vérifieurs du système de preuve en ligne tel que le vérifieur Vn décrit en lien avec la figure 1 . Un tel renouvellement d’attribut vérifiable pourrait également intervenir automatiquement après une certaine durée s’écoulant à compter de la date de création CD d’un tel attribut vérifiable, que ladite création découle d’une requête en création VC_CR selon l’état de l’art ou d’une requête en renouvellement CV_RR propre à l’invention. Un tel renouvellement d’attribut vérifiable pourrait en outre être déclenché automatiquement et de manière aléatoire par la mise en œuvre d’un algorithme exploitant tout ou partie du contenu dudit attribut vérifiable en qualité d’une graine pour la production d’un aléa comparé in fine à un seuil, etc. L’invention prévoit que la détection d’un éventement déclencheur ne se réduise à ces seuls exemples pris seuls ou en combinaison.
A titre d’exemple, la figure 4 décrit un mode de réalisation selon lequel le portefeuille Wm associe à chaque attribut vérifiable VCi dont il assure la gestion, un compteur nPV d’émission de messages en présentation PV_M véhiculant ledit attribut vérifiable VCi en réponse à des requêtes en présentation VC_PR émanant de vérifieurs. Selon cet exemple de réalisation, chaque attribut vérifiable VCi est donc associé à un tel compteur conjointement enregistré en mémoire de données 12 de l’objet électronique hébergeant ledit portefeuille Wm. L’étape 110 peut alors consister tout d’abord en une lecture 111 , dans une telle mémoire de données 12 accessible en lecture et écriture par le portefeuille Wm, de la valeur courante d’un compteur nPV de messages de présentation PV_M véhiculant l’attribut vérifiable VCi adressés à un vérifieur du système de preuve en ligne S. Ladite étape 110 peut alors consister en la comparaison 112 de la valeur courante dudit compteur nPV à un seuil maximal de présentations prédéterminé, par exemple compris entre deux et dix, préférentiellement égal à cinq de manière à ne pas trop fréquemment engendrer des renouvellements tout en préservant l’effet technique de non traçabilité recherché. Enfin, ladite étape 110 conclut en la détection d’un événement déclencheur d’un renouvellement automatique si ladite valeur dudit compteur nPV atteint ledit seuil prédéterminé. Une telle situation est représentée par le lien 112-y sur la figure 4. Tant que ledit compteur nPV demeure en deçà dudit seuil, aucun renouvellement de l’attribut vérifiable n’est déclenché (situation représentée par le lien 112-n sur la figure 4).
Un tel renouvellement d’attribut vérifiable VCi est détaillé à présent en lien avec l’étape 120 du sous-procédé 100. Un tel traitement 120 comporte principalement une étape 125 d’élaboration d’une requête en renouvellement VC_RR à adresser à un émetteur du système de preuve en ligne. Pour cela, au préalable, afin de prévenir la traçabilité de l’identité digitale publique du portefeuille et, par voie de conséquence, celle de l’internaute llm porteur de l’objet Om hébergeant ledit portefeuille Wm, le traitement 120 peut comporter une étape 121 de production d’une nouvelle identité digitale IWm du portefeuille d’attributs vérifiables Wm en remplacement de l’identité digitale courante, à l’instar d’une création d’une telle identité digitale lors de l’installation de l’application « portefeuille d’attributs vérifiables » dans l’objet électronique Om. Cette étape consiste en une production d’un nouveau jeu de clés publique PKVm et privée SKWm, par exemple en dérivant une clé mère et une graine aléatoire. De la même manière, une telle étape 121 consiste en outre en une production d’un nouvel identifiant IDWm, soit de toute pièce par exemple via la génération d’un aléa ou bien en le dérivant de la clé publique PKWm s’il s’agit d’un identifiant décentralisé. Les identités digitales publique PIWm et privée SKWm formant la nouvelle identité digitale IWm du portefeuille Wm, sont ainsi recréées. Lorsque le registre de confiance TR mémorise l’identité digitale publique dudit portefeuille Wm, l’invention prévoit que ladite étape 121 puisse consister en outre à élaborer une requête PI JJ en mise à jour d’identité digitale publique à destination du registre de confiance TR. Une telle requête PIJJ est agencée par le portefeuille Wm pour véhiculer la nouvelle identité digitale publique PIWm issue de la nouvelle identité digitale IWm et être signée à l’aide de la précédente identité digitale privée SKm dudit portefeuille Wm. Le registre de confiance TR peut alors, en réponse à une telle requête en mise à jour, vérifier ladite signature en exploitant la future ancienne identité digitale publique dudit portefeuille Wm et accepter, dans l’affirmative, ladite mise à jour de l’identité publique du portefeuille Wm. Ladite étape 121 de production d’une nouvelle identité digitale IWm demeure toutefois avantageuse mais optionnelle. L’invention prévoit en effet qu’un portefeuille Wm puisse conserver une même identité digitale IWm pour mettre en œuvre une pluralité de requêtes en renouvellement VC_RR. En variante, une mise en œuvre de l’étape 121 peut être déclenchée, de manière asynchrone, au regard de la mise en œuvre de l’étape de détection 110 d’un événement déclencheur d’un renouvellement d’un attribut vérifiable VC. Une mise en œuvre de l’étape 121 pourrait être déclenchée, selon tout critère, tel que, à titre d’exemples non limitatifs, un comptage, comparé à un seuil, de requêtes en renouvellement VC RR d’un attribut vérifiable déterminé ou encore un déclenchement aléatoire. L’invention prévoit en effet, qu’un portefeuille Wm puisse comporter une pluralité d’identités digitales IWm respectivement associées à des attributs vérifiables VC distincts gérés par ledit portefeuille Wm.
Pour que le portefeuille Wm puisse élaborer la requête en renouvellement VC_RR à l’étape 125, celle-ci étant agencée pour véhiculer l’attribut vérifiable VCi, objet du renouvellement, ainsi que la nouvelle identité publique du portefeuille Wm, il est nécessaire de sélectionner un émetteur à qui adresser ladite requête en renouvellement VC_RR.
Pour cela, l’invention prévoit différents modes de réalisation pour sélectionner l’émetteur futur destinataire de la requête en renouvellement VC RR.
Selon un premier mode de réalisation, le traitement 120 comporte une étape 122 pour lire, au sein de l’attribut vérifiable VCi (objet d’un renouvellement et inscrit dans la mémoire de données 12), l’identité digitale publique Pllj de l’émetteur Ij dudit attribut vérifiable VCi, afin d’adresser ladite requête en renouvellement VC_RR, à l’étape 125, à destination dudit émetteur Ij précédemment en charge de la création (ou d’un précédent renouvellement) dudit attribut vérifiable VCi.
En variante, l’invention prévoit que le portefeuille Wm dispose, dans la mémoire de données 12, d’une table des identités digitales publiques des émetteurs connus dudit portefeuille Wm. A chaque itération dudit traitement 120, la sélection de l’identité digitale publique de l’émetteur destinataire de la requête en renouvellement VC_RR peut être réalisée selon une lecture aléatoire ou cyclique selon un pas déterminé de ladite table.
Selon une alternative préférée, pour effectuer une telle sélection parmi une liste d’identités digitales publiques d’émetteurs, le traitement 120 comporte une étape 123 d’élaboration d’une requête PI_R en consultation d’identités digitales publiques d’entités émettrices du système de preuve en ligne S et de déclenchement de l’émission de ladite requête PI_R à destination du registre de confiance TR. Ledit traitement 120 comporte alors une étape 124, subséquente à l’étape 123, de réception d’un message de transmission PI_M émanant dudit registre de confiance TR et de lecture au sein de celui-ci d’une ou plusieurs identités digitales publiques d’émetteurs véhiculées par ledit message PI_M. Une telle sollicitation systématique du registre de confiance TR pour constituer une liste d’émetteurs permet au portefeuille Wm de connaître, à date, les émetteurs disponibles et aptes à réaliser un tel renouvellement d’attributs vérifiables. La sélection finale dudit émetteur destinataire de la requête en renouvellement VC_RR peut également être réalisée de manière aléatoire au sein de ladite liste obtenue ou bien de manière dirigée pour s’interdire d’émettre ladite requête CV_RR à destination de l’émetteur Ij de l’attribut vérifiable VCi objet du renouvellement. Dans ce cas, la sélection du destinataire s’effectue en choisissant une identité digitale publique distincte de celle de l’émetteur Ij.
L’étape 125 du traitement 120 consiste alors en une élaboration de la requête VC_RR en renouvellement de l’attribut vérifiable VCi, puis à en provoquer l’émission, à destination de l’entité émettrice Ij’ dont l’identité digitale publique Pllj’ a été sélectionnée, ladite requête en renouvellement comportant l’attribut vérifiable VCi à renouveler et la nouvelle identité digitale publique PIWm du portefeuille Wm.
Enfin, ladite étape 125 peut avantageusement consister à signer ladite requête VC_RR, préalablement à l’émission de cette dernière, à l’aide de l’identité digitale privée SKWm du portefeuille Wm. De cette manière, l’émetteur Ij’ destinataire pourra en vérifier la légitimité, comme il sera expliqué en lien avec la figure 5. De la même manière, ladite étape 125 pourrait consister, en variante ou en complément de ladite signature, à chiffrer le contenu de ladite requête VC_RR, préalablement à son émission, à l’aide de l’identité digitale publique Pllj’ (plus précisément de la clé publique PKIj’ issue de celle-ci) de sorte que ledit émetteur Ij’ puisse être le seul à déchiffrer ladite requête en renouvellement. Le sous-procédé 100, outre le traitement 110 pour détecter un événement déclencheur d’un renouvellement d’un attribut vérifiable VCi et le traitement 120 pour produire et émettre une requête en renouvellement VC RR de ce dernier, comporte un traitement ou étape de gestion 130 d’un nouvel attribut vérifiable VCi+i fruit d’une telle requête en renouvellement VC_RR et transmis par un message de transmission VC_M élaboré par l’émetteur lj’ destinataire de ladite requête en renouvellement VC_RR.
Un tel traitement 130 comporte une étape 131 de réception et de lecture d’un message de transmission d’un nouvel attribut vérifiable VCi+i émanant de l’émetteur lj’ destinataire de la requête en renouvellement VC_RR élaborée au traitement 120. Une telle étape 131 peut en outre consister en la vérification de la signature du nouvel attribut vérifiable VCi+i par l’entité émettrice lj’ de ce dernier, à l’aide de l’identité digitale publique Pllj’ de ladite entité émettrice lj’, si ledit nouvel attribut a été signé par cette dernière. Le nouvel attribut vérifiable VCi+i est rejeté si la vérification de la signature échoue et une nouvelle itération du traitement 120 est mise en œuvre, avantageusement en sélectionnant un émetteur lj’ distinct de la précédente itération pour lui adresser une requête en renouvellement VC_RR.
Lorsque ledit nouvel attribut vérifiable paraît légitime, le traitement 130 comporte une étape 132 d’enregistrement du nouvel attribut vérifiable VCi+i, dans la mémoire de données 12, M, accessible en lecture et en écriture par le portefeuille Wm. Cet enregistrement du nouvel attribut vérifiable VCi+i est réalisé en écrasant l’attribut vérifiable VCi ainsi renouvelé ou bien suivi par l’effacement de ce dernier.
Lorsque le sous-procédé 100 prévoit l’exploitation d’un compteur de présentations nPV, ladite étape 132 peut en outre consister en l’initialisation de la valeur d’un tel compteur nPV de messages de présentation PV_M véhiculant ledit nouvel attribut vérifiable VCi+i dans une mémoire de données 12 de l’objet électronique Om hébergeant le portefeuille Wm, ladite mémoire étant accessible en lecture et en écriture par ledit portefeuille Wm.
Comme évoqué précédemment en lien avec la figure 3, le sous-procédé 100 peut prévoir une élaboration d’une requête en révocation VC_RKR d’un attribut vérifiable renouvelé VCi, c’est-à-dire celui sur lequel portait une requête en renouvellement VC RR, à l’issue de la production d’un nouvel attribut vérifiable VCi+i . Selon ce mode de réalisation avantageux, le traitement 130 comporte en amont de la destruction (par écrasement ou effacement) d’un attribut vérifiable renouvelé VCi, une étape pour élaborer une telle requête en révocation VC_RKR agencée pour être interprétée par le registre de confiance TR ou tout autre registre dédié à cet effet. Ladite requête VC_RKR comporte l’attribut vérifiable VCi renouvelé et ainsi révoqué ou une information caractéristique de celui-ci, par exemple le résultat de la mise en œuvre d’une fonction cryptographique de hachage dudit attribut vérifiable VCi. Une telle requête VC_RKR peut être signée par le portefeuille Wm à l’étape 133 à l’aide de l’identité digitale privée SKWm du portefeuille Wm, voire être chiffrée à l’aide de l’identité digitale publique du registre destinataire de la requête en révocation. De cette manière, ledit registre peut lire, accepter ou rejeter ladite révocation après confirmation de la vérification de la signature dudit portefeuille Wm à l’aide de l’identité digitale publique PIWm de ce dernier.
Un procédé 300 de renouvellement automatique d’un attribut vérifiable VCi conforme à l’invention consiste en outre en un deuxième sous-procédé 200 agencé pour être mis en œuvre par une unité de traitement 11 d’émetteur lj’ d’un système de preuve en ligne S tel que celui Ij illustré par la figure 1 . Pour adapter le fonctionnement d’un tel émetteur lj’, ledit sous-procédé 200 comprend principalement deux étapes ou traitements référencés 210 et 200 sur la figure 5 :
- la première étape 210 permet le traitement d’une requête en renouvellement VC_RR d’un attribut vérifiable d’ores et déjà légitiment émis VCi, ladite requête étant transmise par un portefeuille Wm adapté pour mettre en œuvre le sous-procédé 100 ;
- la deuxième étape 220 consiste en la mise en œuvre du renouvellement d’un tel attribut vérifiable VCi en tant que tel ainsi qu’en la communication, par un message de transmission VC_M, d’un nouvel attribut vérifiable VCi+i au portefeuille Wm requérant ledit renouvellement d’attribut vérifiable.
Le traitement 210 d’une requête en renouvellement VC RR d’un attribut vérifiable VCi comporte une première étape de réception 211 d’une telle requête en renouvellement et de lecture des informations véhiculées par cette dernière parmi lesquelles l’attribut vérifiable VCi à renouveler et l’identité digitale publique PIWm du portefeuille Wm, respectivement objet et émetteur de ladite requête en renouvellement VC_RR.
Ledit traitement 210 comporte en outre une étape 214 de vérification :
- de la signature de ladite requête en renouvellement VC_RR par le portefeuille Wm, à l’aide de l’identité digitale publique PIWm de ce dernier ;
- de la signature de l’attribut vérifiable à renouveler VCi par l’entité électronique émettrice Ij de ce dernier, à l’aide l’identité digitale publique Pllj de cette dernière.
La vérification 214 de la signature de ladite requête en renouvellement VC_RR par le portefeuille Wm peut être optionnelle. En effet, une telle signature constitue une variante préférée mais non essentielle du sous- procédé 100. En revanche, la vérification 214 de la signature de l’attribut vérifiable à renouveler VCi par l’entité électronique émettrice Ij de ce dernier est davantage intéressante pour la mise en œuvre de l’invention puisque que la légitimité d’un tel attribut vérifiable VCi permet de déroger à la sollicitation de l’autorité de confiance TA. Ainsi, la deuxième étape 220, consistant en la mise en œuvre du renouvellement en tant que tel d’un attribut vérifiable, n’est mise œuvre que si ladite étape 214 de l’attribut vérifiable VCi à renouveler confirme l’authenticité de ladite signature dudit attribut vérifiable VCi (situation illustrée par le lien 214-y sur la figure 5).
Lorsque la vérification 214 de la signature de ladite requête VC_RR par le portefeuille Wm est prévue, alors la mise en œuvre de la deuxième étape 220 consistant en tant que telle en le renouvellement d’un attribut vérifiable est également conditionnée à la confirmation de l’authenticité de ladite signature de ladite requête VC_RR (situation illustrée par le lien 214-y sur la figure 5). Si l’étape 214 conclut à une non-authenticité de signature(s), situation symbolisée par le lien 214-n sur la figure 5, l’invention prévoit que ladite étape 214 puisse en outre consister en l’élaboration d’un message de transmission VC_M véhiculant un contenu caractérisant une erreur (symbolisée par le vocable anglo-saxon « error » sur la figure 5) à destination du portefeuille Wm requérant un renouvellement avorté. Un tel message VC_M peut être signé à l’aide de l’identité digitale privée SKIj’ de l’émetteur lj’ mettant en œuvre la présente instance du sous-procédé 200.
Pour pouvoir vérifier la ou lesdites signatures de l’attribut vérifiable à renouveler VCi et/ou de la requête en renouvellement VC_RR en tant que telles, à l’instar de ce que prévoit le premier sous-procédé 100 aux étapes optionnelles 123 et 124, l’étape 214 de vérification du traitement 210 du deuxième sous-procédé 200, peut être avantageusement précédée :
- d'une étape 212 d’élaboration d’une requête PI_R en consultation d’identités digitales publiques d’entités électroniques du système de preuve en ligne S et de déclenchement de l’émission de ladite requête à destination du registre de confiance TR ;
- d’une étape 213 de réception d’un message de transmission PI_M émanant dudit registre de confiance TR et de recherche, au sein de celui-ci, de l’identité digitale publique Pllj de l’entité électronique émettrice lj de l’attribut vérifiable VCi à renouveler, voire de celle PIWm du portefeuille Wm émetteur de la requête en renouvellement VC_RR.
La deuxième étape 220 du deuxième sous-procédé 200 consistant en la mise en œuvre du renouvellement en tant que tel d’un attribut vérifiable légitimement d’ores et déjà émis ainsi qu’en la communication, par un message de transmission VC_M, d’un nouvel attribut vérifiable VCi+i au portefeuille Wm requérant ledit renouvellement d’attribut vérifiable, comporte une étape 221 d’élaboration du nouvel attribut vérifiable VCi+i consistant à copier l’intégralité des informations contenues dans l’attribut vérifiable VCi à renouveler exception faite des informations en lien avec l’élaboration en tant que telle de ce dernier, comme évoqué précédemment en lien avec la figure 3.
Ladite étape 221 consiste en outre en une élaboration d’une signature du nouvel attribut vérifiable VCi+i à l’aide de l’identité digitale privée SKIj’ de l’entité émettrice lj’ dudit nouvel attribut vérifiable de sorte que celui-ci soit légitiment émis, à l’instar de l’attribut vérifiable renouvelé VCi. Une telle signature fait partie intégrante du contenu du nouvel attribut vérifiable VCi+i.
La deuxième étape 220 du deuxième sous-procédé 200 comporte une sous-étape 222 pour provoquer l’émission du nouvel attribut vérifiable VCi+i à destination du portefeuille Wm requérant le renouvellement de l’attribut vérifiable VCi.
L’invention a été décrite au travers de différentes configurations d’un système de preuve en ligne S, afin qu’un internaute Um puisse solliciter un fournisseur de biens ou de services SP. L’invention ne saurait être limitée à ce seul exemple de système de preuve en ligne et trouverait une pleine application dans un système de preuve de majorité ou de tout autre attribut vérifiable auprès d’un fournisseur de biens et de services dans le monde physique (tel qu’un distributeur de boissons alcoolisées, de tabac ou un opérateur d’un lieu de jeux d’argent) et non uniquement digital. Il suffit pour cela, que ledit fournisseur SP puisse établir une connexion avec un vérifieur Vn d’un tel système de preuve en ligne S.

Claims

REVENDICATIONS
1. Procédé (300) de renouvellement automatique d’un attribut d’un utilisateur (Urn) vérifiable (VC, VCi, VCi+i) par une entité électronique vérificatrice (Vn) d’un système de preuve en ligne (S),
- ledit système (S) comportant une pluralité d’entités électroniques (Vn, Wm, Ij, Ij ’) respectivement agencées pour communiquer les unes avec les autres au sein dudit système (S) dont, outre ladite entité électronique vérificatrice (Vn), un portefeuille (Wm) d’attributs vérifiables mis en œuvre par une unité de traitement (11 ) d’un objet électronique (Om) détenu par un utilisateur (Um), une entité électronique émettrice (Ij, Ij’) d’attributs vérifiables,
- tout attribut vérifiable (VC, VCi, VCi+i) émis ayant été préalablement élaboré et transmis par une entité électronique émettrice (Ij, Ij’) dudit système de preuve en ligne (S) en réponse à une requête (VC_CR) en création d’attribut vérifiable initiée par un portefeuille (Wm) d’attributs vérifiables dudit système (S), ledit procédé (300) de renouvellement automatique étant caractérisé en ce qu’il comporte :
- un premier sous-procédé (100), mis en œuvre par un portefeuille (Wm) d’attributs vérifiables, comprenant : o une étape (110) de détection d’un événement déclencheur d’un renouvellement d’un attribut vérifiable (VCi) d’ores et déjà émis par une entité électronique émettrice (Ij, Ij’) dudit système de preuve en ligne (S) ; o une étape (120, 125) d’élaboration et de déclenchement de rémission d’une requête (VC_RR) en renouvellement d’un tel attribut vérifiable (VCi) d’ores et déjà émis, à destination d’une entité électronique émettrice (Ij’) du système de preuve en ligne (S) distincte de celle ayant émis ledit attribut vérifiable (VCi) objet de la requête (VC_RR) en renouvellement ; o une étape de gestion (130) d’un nouvel attribut vérifiable (VCi+i) fruit d’une telle requête en renouvellement (VC_RR) et transmis (VC_M) par ladite entité émettrice (ij’) ;
- un deuxième sous-procédé (200) mis en œuvre par une unité de traitement (11 ) d’une entité émettrice (lj’) du système de preuve en ligne (S) comprenant : o une étape (210) de traitement d’une requête en renouvellement (VC_RR) d’un attribut vérifiable transmise par un portefeuille (Wm) d’attributs vérifiables ; o en réponse à un tel traitement d’une requête en renouvellement (VC_RR), puisque ledit attribut vérifiable a été émis par l'une des entités émettrices du système de preuve en ligne (S), une étape (220) de renouvellement d’un tel attribut vérifiable et de transmission (VC_M) d’un nouvel attribut vérifiable à destination du portefeuille (Wm) d’attributs vérifiables requérant ledit renouvellement d’attribut vérifiable d’ores et déjà émis, comportant :
■ une étape (221 ) d’élaboration d’un nouvel attribut vérifiable (VCi+i) consistant à copier l’intégralité des informations contenues dans l’attribut vérifiable (VCi) à renouveler exception faite des informations en lien avec l’élaboration en tant que telle de ce dernier ;
■ une étape (222) pour provoquer l’émission du nouvel attribut vérifiable (VCi+i) à destination du portefeuille (Wm) d’attributs vérifiables requérant le renouvellement.
2. Procédé (300) selon la revendication 1 , pour lequel l’étape (120) d’élaboration et de déclenchement de l’émission d’une requête (VC_RR) en renouvellement d’un attribut vérifiable (VCi) d’ores et déjà émis comporte, préalablement à l’élaboration (125) en tant que telle de ladite requête (VC_RR), une sélection d’une entité électronique émettrice (lj’) du système de preuve en ligne (S) parmi celles contenues dans une liste entités émettrices disponibles et aptes à réaliser un tel renouvellement d’attributs vérifiables, de sorte que l’entité émettrice sélectionnée et destinataire de ladite requête (VC_RR) en renouvellement soit distincte celle ayant émis ledit attribut vérifiable (VCi) objet de la requête (VC_RR) en renouvellement.
3. Procédé (300) selon la revendication 1 ou 2, pour lequel :
- chaque entité électronique (lj, lj’, Vn, Wm) dudit système de preuve en ligne (S) est associée à une identité digitale (llj, llj’, IVn, IWm) formée d’une partie publique (PI lj , PI lj’, PIVn, PIWm), dite « identité digitale publique » et d’une partie privée (SKIj, SKIj’, SKVn, SKWm), dite « identité digitale privée », ladite identité digitale étant enregistrée dans une mémoire de données (M, 12) de ladite chaque entité électronique ;
- ledit système de preuve en ligne (S) comprend un registre de confiance (TR) agencé pour : o enregistrer, dans une mémoire de données (TRM, 12), les identités digitales publiques (Pllj, Pllj’, PIVn, PIWm) respectives des entités électroniques (lj, lj’, Vn, Wm) dudit système de preuve en ligne (S) ; o recevoir une requête (PI_R) en consultation d’identités digitales publiques émanant d’une entité électronique dudit système (S) ; o élaborer un message de transmission (PI_M) véhiculant une ou plusieurs identités digitales publiques (Pllj, Pllj’, PIVn, PIWm) et émettre un tel message à destination de l’entité électronique (lj, lj’, Vn, Wm) émettrice de ladite requête (PI_R) en consultation d’identités digitales publiques ;
- le premier sous-procédé (100) est agencé de sorte que : o l’étape de gestion (130) d’un nouvel attribut vérifiable (VCi+i) fruit d’une telle requête en renouvellement (VC_RR) comporte :
■ une étape (131 ) de vérification de la signature du nouvel attribut vérifiable (VCi+i) par l’entité émettrice (lj’) de ce dernier (VCi+i), à l’aide de l’identité digitale publique (Pllj’) de ladite entité émettrice (lj’) ;
■ une étape (132) d’enregistrement du nouvel attribut vérifiable (VCi+i), dans une mémoire de données (M, 12) accessible en lecture et en écriture par le portefeuille (Wm) d’attributs vérifiables, en remplacement de l’attribut vérifiable (VCi) renouvelé si, et seulement si, ladite étape (131 ) de vérification de la signature du nouvel attribut vérifiable (VCi+i) confirme l’authenticité de ladite signature ;
- le deuxième procédé (200) est agencé de sorte que : o l’étape (210) de traitement d’une requête en renouvellement d’un attribut vérifiable d’ores et déjà émis comporte :
■ une étape de réception (211 ) d’une telle requête en renouvellement (VC_RR) et de lecture des informations véhiculées par cette dernière parmi lesquelles l’attribut vérifiable (VCi) d’ores et déjà émis et l’identité digitale publique (PIWm) du portefeuille (Wm) d’attributs vérifiables, respectivement objet et émetteur de ladite requête en renouvellement (VC_RR) ;
■ une étape (214) de vérification de la signature de l’attribut vérifiable à renouveler par l’entité électronique émettrice de ce dernier, à l’aide de l’identité digitale publique (PI Ij) de cette dernière ; o l’étape (220) de renouvellement d’un attribut vérifiable d’ores et déjà émis et de transmission (VC_M) d’un nouvel attribut vérifiable :
■ n’est mise œuvre que si ladite étape (214) de vérification de la signature de l’attribut vérifiable (VCi) à renouveler confirme l’authenticité de cette dernière ;
■ l’étape (221 ) d’élaboration du nouvel attribut vérifiable (VCi+i) consistant à signer ledit nouvel attribut vérifiable (VCi+i) à l’aide de l’identité digitale privée (SKIj’) de l’entité émettrice (Ij’) dudit nouvel attribut vérifiable.
4. Procédé (300) selon la revendication 3, pour lequel :
- le premier sous-procédé (100) est agencé de sorte que l’étape (120) d’élaboration et de déclenchement de l’émission d’une requête en renouvellement (VC_RR) comporte une étape (125) de signature de ladite requête en renouvellement (VC_RR) à l’aide de l’identité digitale privée (SKWm) du portefeuille (Wm) d’attributs vérifiables ; - le deuxième procédé (200) est agencé de sorte que : o l’étape (210) de traitement d’une requête en renouvellement d’un attribut vérifiable d’ores et déjà émis comporte une étape (214) de vérification de la signature de ladite requête en renouvellement par le portefeuille (Wm) d’attributs vérifiables, à l’aide de l’identité digitale publique (PIWm) de ce dernier ; o l’étape (220) de renouvellement d’un attribut vérifiable d’ores et déjà émis et de transmission (VC_M) d’un nouvel attribut vérifiable n’est mise œuvre que si ladite étape (214) de la signature de la requête en renouvellement (VC_RR) confirme l’authenticité de ladite signature.
5. Procédé (300) selon l’une quelconque des revendications 1 à 4, pour lequel :
- l’étape (110) de détection d’un événement déclencheur d’un renouvellement automatique d’un attribut vérifiable (VCi) d’ores et déjà émis, consiste en : o une lecture (111 ), dans une mémoire de données (M, 12) accessible en lecture et écriture par le portefeuille (Wm) d’attributs vérifiables, de la valeur d’un compteur (nPV) de messages de présentation (PV_M) véhiculant l’attribut vérifiable (VCi) adressés à une entité électronique vérificatrice (Vn) du système de preuve en ligne (S) ; o une comparaison (112) de la valeur courante dudit compteur à un seuil maximal prédéterminé et une conclusion quant à la détection d’un événement déclencheur d’un renouvellement automatique si (112-y) ladite valeur dudit compteur (nPV) atteint ledit seuil prédéterminé ; - l’étape de gestion (130) d’un nouvel attribut vérifiable (VCi+i ) fruit d’une requête en renouvellement (VC_RR), consiste en outre en une initialisation (132) de la valeur d’un compteur (nPV) de messages de présentation (PV_M) véhiculant ledit nouvel attribut vérifiable (VCi+i) dans une mémoire de données (M) accessible en lecture et en écriture par le portefeuille (Wm) d’attributs vérifiables.
6. Procédé (300) selon l’une quelconque des revendications précédentes, pour lequel l'étape (120, 125) d’élaboration et de déclenchement de rémission d’une requête (VC_RR) en renouvellement d’un attribut vérifiable (VCi) d’ores et déjà émis du premier sous-procédé (100) comporte :
- une étape (121 ) de production d’une nouvelle identité digitale (IWm) du portefeuille d’attributs vérifiables (Wm) en remplacement de la précédente ;
- l’étape (125) d’élaboration de la requête (VC_RR) en renouvellement de l’attribut vérifiable (VCi) d’ores et déjà émis à destination de l’entité émettrice (lj’) est agencée de sorte que ladite requête en renouvellement (VC_RR) comporte l’attribut vérifiable (VCi) à renouveler et la nouvelle identité digitale publique (PIWm) du portefeuille (Wm) d’attributs vérifiables.
7. Procédé (300) selon les revendications 3 et 6, pour lequel :
- l'étape (120) d’élaboration et de déclenchement de l’émission d’une requête (VC_RR) en renouvellement d’un attribut vérifiable (VCi) d’ores et déjà émis du premier sous-procédé (100) comporte :
- une étape (123) d’élaboration d’une requête (PI_R) en consultation d’identités digitales publiques (Pllj’) d’entités émettrices (lj’) du système de preuve en ligne (S) et de déclenchement de l’émission de ladite requête à destination du registre de confiance (TR) ;
- une étape (124) de réception d’un message de transmission (PI_M) émanant dudit registre de confiance (TR) et de lecture au sein de celui-ci d’une identité digitale publique (Pllj’) d’entité émettrice (lj’) véhiculée par ledit message (PI_M) ;
- l’étape (125) d’élaboration de la requête (VC_RR) en renouvellement de l’attribut vérifiable (VCi) d’ores et déjà émis à destination de l’entité émettrice (lj’) est agencée de sorte que l’identité digitale publique (Pllj’) de ladite entité émettrice (lj’) est tirée du message de transmission (PI_M) émanant dudit registre de confiance (TR).
8. Procédé (300) selon l’une des revendications 6 et 7 lorsqu’elles dépendent de la revendication 2, pour lequel l’étape (121 ) de production d’une nouvelle identité digitale (IWm) du portefeuille d’attributs vérifiables (Wm) consiste en outre en une élaboration d’une requête (PI_U) en mise à jour d’identité digitale publique à destination du registre de confiance (TR), ladite requête véhiculant la nouvelle identité digitale publique (PIWm) issue de la nouvelle identité digitale (IWm) signée à l’aide de la précédente identité digitale privée (SKm) dudit portefeuille d’attributs vérifiables (Wm).
9. Procédé (300) selon l’une quelconque des revendication 3 à 9, pour lequel : le registre de confiance (TR) est agencé pour mémoriser (TRM) tout attribut vérifiable révoqué (VCi) ou une information caractéristique d’un tel attribut vérifiable révoqué (VCi) en réponse à la réception d’une requête en révocation (VC RKR) d’attribut vérifiable ;
- l’étape de gestion (130) d’un nouvel attribut vérifiable (VCi+i ) fruit d’une requête en renouvellement (VC_RR) comporte une étape (133) d’élaboration d’une telle requête en révocation (VC_RKR) d’attribut vérifiable véhiculant l’attribut vérifiable (VCi) ayant fait l’objet d’un renouvellement à destination du registre de confiance (TR).
10. Procédé (300) selon la revendication précédente, pour lequel l’étape (133) d’élaboration d’une requête en révocation (VC_RKR) consiste en outre en l’élaboration d’une signature de ladite requête (VC_RKR) à l’aide de l’identité digitale privée (SKWm) dudit portefeuille d’attributs vérifiables (Wm).
11. Procédé (300) selon l’une quelconque des revendications 3 à 10, pour lequel l’étape (214) de vérification de la signature de l’attribut vérifiable à renouveler du deuxième sous-procédé (200) est précédée :
- d'une étape (212) d’élaboration d’une requête (PI_R) en consultation d’identités digitales publiques (PIWm, Pllj, Pllj’) d’entités électroniques (Wm, llj, lj’) du système de preuve en ligne (S) et de déclenchement de l’émission de ladite requête à destination du registre de confiance (TR) ;
- d’une étape (213) de réception d’un message de transmission (PI_M) émanant dudit registre de confiance (TR) et de recherche, au sein de celui-ci, de l’identité digitale publique (Pllj) de l’entité électronique émettrice lj de l’attribut vérifiable à renouveler (VCi).
12. Procédé (300) selon la revendication 4, pour lequel l’étape (214) de vérification de la signature de la requête en renouvellement par le portefeuille (Wm) d’attributs vérifiables du deuxième sous-procédé (200) est précédée :
- d'une étape (212) d’élaboration d’une requête (PI_R) en consultation d’identités digitales publiques (PIWm, Pllj, Pllj’) d’entités électroniques (Wm, llj, lj’) du système de preuve en ligne (S) et de déclenchement de l’émission de ladite requête à destination du registre de confiance (TR) ;
- d’une étape (213) de réception d’un message de transmission (PI_M) émanant dudit registre de confiance (TR) et de recherche, au sein de celui-ci, de l’identité digitale publique (PIWm) du portefeuille d’attributs vérifiables (Wm).
13. Procédé (300) selon l’une quelconque des revendications précédentes, pour lequel l’attribut vérifiable (VC, VCi, VCi+i) caractérise la majorité de l’utilisateur de l’objet électronique (Om) hébergeant le portefeuille (Wm) d’attributs vérifiables.
14. Procédé (300) selon l’une quelconque des revendications précédentes, pour lequel et pour chaque entité électronique du système de preuve (S) :
- l’identité digitale publique (Pllj, Pllj’, PIVn, PIWm) consiste en une clé publique (PKIj, PKIj’, PKVn, PKWm) et un identifiant (ID lj , IDIj’, IDVn, IDWm) ;
- l’identité digitale privée consiste en une clé privée (SKIj, SKIj’, SKVn, SKWm) produite conjointement avec ladite clé publique, (PKIj, PKIj’, PKVn, PKWm) par la mise en œuvre d’un algorithme cryptographique asymétrique.
15. Procédé (300) selon la revendication précédente, pour lequel, et pour chaque entité électronique du système de preuve en ligne (S), l'identifiant (IDIj, IDIj’, IDVn, IDWm) est un identifiant décentralisé dérivé de ladite clé publique (PKIj, PKIj’, PKVn, PKWm) par la mise en œuvre d’un algorithme cryptographique réversible, ladite identité digitale publique (Pllj, Pllj’, PIVn, PIWm) se réduisant ainsi en ledit identifiant décentralisé (IDIj, IDIj’, IDVn, IDWm) ou en ladite clé publique (PKIj, PKIj’, PKVn, PKWm).
16. Produit programme d’ordinateur (P) comportant une ou plusieurs instructions de programme exécutables par une unité de traitement (11 ) d’un objet électronique hébergeant un portefeuille (Wm) d’attributs vérifiables d’un système de preuve en ligne (S), lesdites instructions de programme étant :
- chargeables dans une mémoire (M, 13) dudit objet électronique (Om) hébergeant un portefeuille (Wm) d’attributs vérifiables ;
- conçues de sorte que leur exécution par ladite unité de traitement (11 ) provoque la mise en œuvre par ledit portefeuille (Wm) d’attributs vérifiables d’un premier sous-procédé (100) d’un procédé (300) de renouvellement automatique d’un attribut vérifiable (VC, VCi, VCi+i) selon l’une quelconque des revendications 1 à 15.
17. Support de mémorisation lisible par un ordinateur comportant les instructions d’un produit programme d’ordinateur selon la revendication précédente.
18. Produit programme d’ordinateur (P) comportant une ou plusieurs instructions de programme exécutables par une unité de traitement (11 ) d’une entité électronique émettrice (Ij, lj’) d’attributs vérifiables d’un système de preuve en ligne (S), lesdites instructions de programme étant : - chargeables dans une mémoire (M, 13) de ladite entité électronique émettrice (Ij, lj’) ;
- conçues de sorte que leur exécution par ladite unité de traitement (11 ) provoque la mise en œuvre d’un deuxième sous- procédé (200) d’un procédé (300) de renouvellement automatique d’un attribut vérifiable (VC, VCi, VCi+i) selon l’une quelconque des revendications 1 à 15.
19. Support de mémorisation lisible par un ordinateur comportant les instructions d’un produit programme d’ordinateur selon la revendication précédente.
20. Objet électronique (Om) comportant une unité de traitement (11 ), des moyens de communication (14) avec le monde extérieur et une mémoire (M, 13) enregistrant les instructions de programme d’un produit programme d’ordinateur selon la revendication 15.
21 . Entité électronique émettrice (lj, lj’) d’attributs vérifiables comportant une unité de traitement (11 ), des moyens de communication (14) avec le monde extérieur et une mémoire (M, 13) enregistrant les instructions de programme d’un produit programme d’ordinateur selon la revendication 18.
22. Système de preuve en ligne (S) comportant une pluralité d’entités électroniques (Vn, Wm, lj, lj’) respectivement agencées pour communiquer les unes avec les autres au sein dudit système (S) dont :
- une entité électronique vérificatrice (Vn) d’attributs vérifiables ;
- un portefeuille (Wm) d’attributs vérifiables mis en œuvre par une unité de traitement (11 ) d’un objet électronique (Om) détenu par un utilisateur (Um), ledit objet électronique étant agencé selon la revendication 20. - une entité électronique émettrice (Ij, lj’) d’attributs vérifiables agencée selon la revendication 21.
EP24721707.8A 2023-04-11 2024-03-21 Procédé de renouvellement automatique d'un attribut vérifiable et système associé Pending EP4695933A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR2303600A FR3147921B1 (fr) 2023-04-11 2023-04-11 Procédé de renouvellement automatique d’un attribut vérifiable et système associé
PCT/FR2024/050357 WO2024213840A1 (fr) 2023-04-11 2024-03-21 Procédé de renouvellement automatique d'un attribut vérifiable et système associé

Publications (1)

Publication Number Publication Date
EP4695933A1 true EP4695933A1 (fr) 2026-02-18

Family

ID=87889560

Family Applications (1)

Application Number Title Priority Date Filing Date
EP24721707.8A Pending EP4695933A1 (fr) 2023-04-11 2024-03-21 Procédé de renouvellement automatique d'un attribut vérifiable et système associé

Country Status (3)

Country Link
EP (1) EP4695933A1 (fr)
FR (1) FR3147921B1 (fr)
WO (1) WO2024213840A1 (fr)

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3906512A1 (fr) * 2019-01-04 2021-11-10 Axuall, Inc. Systèmes et procédés de vérification et de gestion de justificatifs d'identité numériques
US11961079B2 (en) * 2020-07-02 2024-04-16 Mastercard Asia/Pacific Pte. Ltd. Proof-of-age verification in mobile payments
US11646897B2 (en) * 2021-06-01 2023-05-09 Springcoin, Inc. Method and apparatus for utilizing off-platform-resolved data as an input to code execution on a decentralized platform

Also Published As

Publication number Publication date
FR3147921A1 (fr) 2024-10-18
WO2024213840A1 (fr) 2024-10-17
FR3147921B1 (fr) 2025-08-22

Similar Documents

Publication Publication Date Title
EP1442557B1 (fr) Systeme et procede pour creer un reseau securise en utilisant des justificatifs d'identite de lots de dispositifs
EP3568794A2 (fr) Procédés et systèmes pour l'exécution de programmes dans des environnements sécurisés
EP3803670A1 (fr) Une application logicielle et un serveur informatique pour authentifier l'identité d'un créateur de contenu numérique et l'intégrité du contenu du créateur publié
CA3057398C (fr) Execution securisee d'operations cryptographiques
CA2969495C (fr) Procede mis en oeuvre dans un document d'identite et document d'identite associe
FR2868896A1 (fr) Procede et dispositif de controle d'acces a un document numerique partage dans un reseau de communication de type poste a poste
FR3048530B1 (fr) Systeme ouvert et securise de signature electronique et procede associe
EP4186187A1 (fr) Systèmes et procédés destinés à la propriété à distance et au contrôle de contenu de fichiers multimédia sur des systèmes non sécurisés
WO2022208016A1 (fr) Procédé et système informatique de stockage decentralisé et de partage de fichiers numériques certifiés
WO2019092327A1 (fr) Procédé d'obtention d'une identité numérique de niveau de sécurité élevé
WO2024213840A1 (fr) Procédé de renouvellement automatique d'un attribut vérifiable et système associé
WO2003034654A2 (fr) Procede et dispositif de protection de donnees
EP4359986B1 (fr) Procédé et dispositif de paiement par chaînes de blocs
EP1637989A1 (fr) Procédé et système de séparation de comptes de données personnelles
EP2285042A1 (fr) Module logiciel de sécurisation utilisant le chiffrement du haché d'un mot de passe concaténé avec une graine
EP4128700A1 (fr) Procede et dispositif d'authentification d'un utilisateur aupres d'une application
EP3903210A1 (fr) Reseau de communication securisee et tracee
FR2889388A1 (fr) Procede et systeme de gestion securise de donnees entre un serveur et un client
FR2973140A1 (fr) Procede de generation et d'utilisation d'un titre dematerialise dans un dispositif portable et systeme de gestion de titres correspondant
WO2025125562A1 (fr) Procédé d'authentification d'un individu pour la mise en œuvre d'une transaction sur un terminal marchand
WO2022254117A1 (fr) Procede de gestion d'un registre local d'un noeud appartenant a un ensemble de noeuds contribuant a un registre distribue
WO2021156664A1 (fr) Plateforme de gestion des preferences en matiere de donnees personnelles
FR3067488A1 (fr) Procede de gestion d'identifiants de fidelite, procede de traitement de donnees de fidelite, serveur, dispositif de transaction et programmes correspondants
FR2901386A1 (fr) Support personnel de memoire de masse portatif et systeme informatique d'acces securise a un reseau par des utilisateurs.
FR2888437A1 (fr) Procede et systeme de controle d'acces a un service d'un fournisseur d'acces implemente sur un serveur multimedia, module, serveur, terminal et programmes pour ce systeme

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20251008

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC ME MK MT NL NO PL PT RO RS SE SI SK SM TR