Method for automatic renewal of a verifiable attribute and associated system

Abstract

The invention relates to a method (300) for automatically renewing a verifiable attribute (VCi) implemented by an online proof system comprising a wallet (Wm) of verifiable attributes hosted by an electronic object (Om) and an entity issuing verifiable attributes. Such a method (300) prevents the traceability of the public digital identity of the wallet and comprises two sub-methods (100, 200). The first (100) is implemented by said wallet (Wm) to produce a new digital identity (PIWm) and issue a request (VC_RR) for renewal of a verifiable attribute (VCi). The second (200) is implemented by the issuing entity (Ij') to produce a new verifiable attribute (VCi+1) to replace the previous one (VCi). Figure to be published with the abstract: Fig 3

Description

Title of the invention: Method for automatic renewal of a verifiable attribute and associated system

[0001] 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.

[0002] 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 veracity 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.

[0003] We may indeed have to prove: - that one is of legal age without necessarily providing one's date and place of birth; - that one resides in a city or region without having to provide one's full address; - that we present a certain level of studies without specifying the diploma(s) and years in which they were obtained.

[0004] In France, the National Commission for Information Technology and Civil Liberties, also known by the acronym "CNIL", recommends the use of systems that are not easily circumvented without being too intrusive, so that they respect everyone's privacy. 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 customer's age prior to any supply. This is the case, for example, for sites selling alcohol, gambling, online betting, photos or videos for adults.The CNIL recommends the use of an independent trusted third party intended 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 issuance of proof of age by a system in the form of a computer entity, which we may subsequently call "issuer" or "issuer" using English terminology for the sake of simplification, said issuer being responsible for validating the information on the person's age and issuing proof of age (for example proof of majority) accompanied by a level of confidence; - the transmission of said certified proof of age to one or more suppliers of goods or services so that the latter can deliver or refuse to deliver said goods or services to the Internet user concerned by said certified proof.

[0005] To preserve the data and privacy of said Internet user, triple protection of privacy is required: - 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; - proof of majority is transmitted to said supplier of goods and services via said subject or Internet user then via an electronic entity called a proof “verifier” (“verify” according to an Anglo-Saxon expression), hereinafter sometimes called “verifier” for simplification; - 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.

[0006] The use of an independent verifier is clearly recommended by the CNIL to best protect individuals' data. In this way, 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 as Self-Sovereign Identity or SSI, popularized with the emergence of Web3 technologies, including blockchain.

[0007] [Fig. 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).

[0008] According to said [Fig.l], 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 multimedia content of a pornographic nature. Said electronic object Om can consist of a smart mobile phone ("smartphone" in English terminology), an electronic tablet, a personal computer or any other suitable electronic object. Such a provider SP being subject to verification of the majority of any client, it relies on a verifier Vn to attest or not to such a majority. Such a verifier, in the form of a computer server, transmits a confirmation or a rejection of the proof of majority to the provider SP by transmitting a verification message V_M.To do this, 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.

[0009] This data structure, which we will call “verifiable attribute” VC, comprises 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, a validity end date, EVD, etc. Such 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 English 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. For simplification purposes, such an electronic wallet Wm of verifiable attributes may be called “wallet” in the remainder of this document.Thus, said Wm wallet can decode a VC_PR presentation request and issue a PV_M presentation message in response.

[0010] 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. Such 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.

[0011] Upon receipt of such a VC_CR creation request, the sender Ij requests a third party or trusted authority TA which has precise knowledge of the user Um. Such 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. We can for example 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 trust TA could also consist of a computer server operated by an energy supplier with knowledge of its users. In response to a request to create a verifiable attribute, the issuer Ij requests a CUI investigation from such a third party or TA authority to determine, for example, whether said user Um is of legal age or whether he resides in a particular location, depending on the verifiable attribute concerned. In this case, in the example described in connection with [Fig.l], the TA authority in the form of a banking server, knowing the date of birth of its client Um, can send the issuer information confirming or refuting the majority of the user Um. If so, the issuer Ij develops the verifiable attribute VC. So that the TA authority can respond favorably or unfavorably to said issuer Ij, the CUI investigation may consist of a request conveying public information on the digital identity of the subject Um.To make a link between the pseudonym constituted by such public information and a customer or subscriber as such, the TA authority can submit to the Wm wallet, a request for knowledge of information characterizing the bank account or telephone subscription of the subject user of the electronic object Om with the TA authority as well as the consent of the user of said electronic object Om. In response to such a request, after soliciting the user Um to confirm his request for a verifiable attribute, said Wm wallet returns the signed bank account or subscription information to the TA authority 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.Alternatively, such a request for knowledge of information characterizing the bank account of the user Um may consist of a banking transaction of a zero debited amount or any other suitable solution.

[0012] For example, as indicated in [Fig.l], an emitted verifiable attribute VC comprises contextual information Ctx, for example describing the cryptographic scheme used to sign said attribute prior to its emitting to the wallet Wm. Such a verifiable attribute VC may also comprise public digital identity information (unique identifier, public cryptographic key, etc.) respectively of the user Um and the issuer Ij, a creation date of said verifiable attribute, or even a validity end 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.

[0013] The online proof system S may comprise a plurality of issuers, verifiers and portfolios of verifiable attributes. To distinguish the electronic entities- Ironic and computer-related, these 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 sent by a first entity to a second entity, an online proof system S generally relies on an asymmetric cryptographic signature / verification scheme. Thus, each entity has a set of keys, respectively public PK and private SK. The public keys are symbolized by white keys in [Fig.l] and the private keys are symbolized by black keys.

[0014] A pair of public keys PKx and private keys SKx of a first electronic entity X is such that a second entity Y can verify the signature of the entity X by knowing the public key PKx if said signature was developed by the first entity X using the private key SKx. Alternatively or additionally, a message sent by the entity X and addressed to the entity Y can also be encrypted so that only the entity Y can read said message. In this case, the entity Y also includes a pair of private keys SKy and public keys PKy. Knowing the public key PKy, the entity X can encrypt the message using said public key PKy. Only the entity knowing the private key SKy (in this case, the entity Y) will be able to decode said encrypted message by using said private key SKy and obtain the clear text of said encrypted message.

[0015] In connection with [Fig.l], 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. In [Fig.l], the digital identity Ilj 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.

[0016] Thus, each electronic entity of the online proof system S of which the wallet Wm is 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. Optionally, 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.

[0017] Thus, the digital identity IWm of the Wm wallet consists of: - a public digital identity PlWm, in this case a unique identifier IDWm and a public key PKWm; - a private digital identity, in this case a private key SKWm jointly developed with said public key PKWm to ensure an asymmetric signature cryptographic scheme.

[0018] The digital identity Ilj of the issuer Ij of the attribute VCi, subject to automatic renewal, consists of: - a public digital identity Pllj, in this case a unique identifier IDIj and a public key PKIj; - 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.

[0019] The same would apply to a second transmitter Ij' (not shown in [Fig.l]) distinct from the transmitter Ij. Thus, the digital identity Ilj' of such a transmitter Ij' would consist of: - a public digital identity Pllj', in this case a unique identifier IDIj' and a public key PKIj'; - 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.

[0020] According to the example of [Fig.l], so that the electronic entities of the online proof system S can know the public digital identities PI (i.e. the public keys PK, or even the identifiers ID of said entities), said system S comprises a trust 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 trust register TR comprises a data memory TRM comprising a directory of the public digital identities of the entities Ij, 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 (in particular the issuers, verifiers and wallets) can thus request said trust 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 determined 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. The register of . trust register TR is thus a repository, to date, of the legitimate electronic entities composing 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 trust 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 has an entry in its repository of legitimate electronic entities of the system S. The PI_M message conveying the result of a PI_R request can, in turn, be signed by the trust register TR using its own private digital identity (private key SKTR) before transmission.

[0021] Uncontrolled or uncontrolled exploitation of independent unique identifiers, as expressed above, generally included in clear text in metadata, can pose confidentiality and traceability problems. Such identifiers can sometimes even be monetized for advertising targeting, for example. Also, the cryptographic scheme chosen to produce the digital identities (identifiers and cryptographic keys) of said entities and ensure exchanges between them, can be advantageously chosen to use secure identifiers called “decentralized identifiers” or DIDs (an English acronym for “Decentralized Identifiers”) instead of unique identifiers independent of public and private keys.The digital identities of the electronic entities of the online proof system S can then be expressed in the form of decentralized and secure ID identifiers (DIDs), created by said entities to guarantee their authentications and signatures. Depending on the algorithms used to generate such secure identifiers, it is thus possible to reduce the public digital identity to such a decentralized identifier or to the sole public key of an electronic entity, a bijective relationship existing between said public key and such a decentralized identifier. In a way, a decentralized identifier is inherited or derived from the public key associated with it. Thus, knowing the identifier (in the form of a DID) of a first entity, a second entity can recover the public key PK of said first entity from the decentralized identifier or vice versa.The trusted 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. In the same way, 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 Wm wallet which is included in said verifiable attribute vc.

[0022] As indicated in [Fig.l], 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. Conventionally and as illustrated in a simplified manner in [Fig.2], 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 [Fig.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.

[0023] The term "memory" means any computer memory, whether volatile or not. A non-volatile memory is a 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 technology ("Electrically-Erasable Programmable Read-Only Memory"), flash, SSD ("Solid-State Drive"), etc. Non-volatile memories are distinguished from so-called "volatile" memories whose data is lost in the absence of an electrical power supply.The main volatile memories currently available use RAM (Random Access Memory), DRAM (dynamic RAM, requiring regular updating), SRAM (static RAM requiring such updating when there is a power shortage), DPRAM or VRAM (particularly suitable for video), etc.

[0024] According to [Fig. 2], an electronic entity of an online proof system further comprises means 14 for communication with the outside world in the form of an input unit and an output unit. Said communication means 14 cooperate with the processing unit 11 and provide wireless or wired proximity communication with any other electronic entity of said system S. To operate, such 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 for controlling an interface human-machine input and / or output 17. The term "human-machine output interface" means any device, used alone or in combination, for outputting or delivering a graphic, haptic, audio or, more generally, human-perceptible representation. Such an output human-machine interface may consist, but is not limited to, of one or more screens, speakers or other suitable alternative means. The term "human-machine input interface" means a computer keyboard, a pointing device, a touch screen, a microphone or, more generally, any interface designed to translate gestures or instructions issued by a human into control or configuration data. Advantageously, the input and output human-machine interfaces may constitute a single physical entity.

[0025] Such an online proof system S can be adapted by loading into the program memory 13 of each electronic entity a computer program P comprising instructions to cause, during their execution, the implementation of a suitable method. This program can 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.

[0026] The use of pseudonyms (identifiers / public keys) instead of identifying information of Internet users limits the traceability of the latter, in particular through the use of centralized identifiers (DIDs). However, the latter remain traceable according to presentation requests or creations of verifiable attributes.

[0027] The invention makes it possible to resolve the drawbacks previously expressed. Among the numerous advantages provided by the implementation of the invention, we can mention that: - 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 an 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 fits perfectly into an online proof system according to the state of the art ([Fig.l]) 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 verifying entities with a view to obtaining content or goods and services.

[0028] To this end, the invention provides a method for automatically renewing an attribute of a user verifiable by a verifying electronic 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 verifying electronic 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.To preserve anonymity and prevent the traceability of the user's public digital identity, such an automatic renewal process includes: . - a first sub-process, implemented by a portfolio of verifiable attributes, comprising: • a step of detecting an event triggering a renewal of a verifiable attribute already issued; • 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; • a step of managing a new verifiable attribute resulting from such a renewal request and transmitted by said issuing entity; - a second sub-process implemented by a processing unit of an issuing entity comprising: • a step of processing a request for renewal of a verifiable attribute already issued, transmitted by a portfolio of verifiable attributes; • a step of renewing such a verifiable attribute already issued and transmitting a new verifiable attribute to the portfolio of verifiable attributes requiring said renewal of the verifiable attribute already issued.

[0029] Such an online proof system may include numerous electronic entities- Ironically, each electronic entity of said online proof system can 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 to: - record, in a data memory, the respective public digital identities of the electronic entities of said online proof system; - receive a request for consultation of public digital identities from an electronic entity of said system; - prepare a transmission message conveying one or more public digital identities and send such a message to the electronic entity issuing said request for consultation of public digital identities.

[0030] 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 includes: • 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; • a step of recording the new verifiable attribute, in a data memory accessible in reading and writing by the portfolio of verifiable attributes, in replacement of the renewed verifiable attribute if and only if said step of verifying the signature of the new verifiable attribute confirms the authenticity of said signature;

[0031] The second sub-process can, for its part, be arranged so that: - the processing step of a request for renewal of a verifiable attribute already issued includes: • 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; • 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: • is only implemented if the said step of verifying the signature of the verifiable attribute to be renewed confirms the authenticity of the latter; • includes one step: • development of the new verifiable attribute consisting of copying all of the information contained in the verifiable attribute to be renewed, with the exception of information relating to the development of the latter as such; • signing said new verifiable attribute using the private digital identity of the entity issuing said new verifiable attribute; • includes a step to cause the new verifiable attribute to be issued to the portfolio of verifiable attributes requiring renewal.

[0032] Advantageously, the first sub-process of an automatic renewal method according to the invention can be arranged so that the step of developing and triggering the issue of a renewal request can include a step of signing said renewal request using the private digital identity of the portfolio of verifiable attributes. In this case, the second sub-process can be arranged so 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; - the 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.

[0033] To promptly and automatically an implementation of a method for automatic renewal of an attribute in accordance with the invention, 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: - a reading, in a data memory accessible in reading and writing by the portfolio of verifiable attributes, the value of a message counter of presentation conveying the verifiable attribute addressed to an electronic verification entity of the online proof system; - a comparison of the current value of said counter with a predetermined maximum threshold and a conclusion as to the detection of an event triggering automatic renewal if said value of said counter reaches said predetermined threshold.

[0034] In this case, said first sub-method can furthermore be arranged so that the step of managing a new verifiable attribute resulting from a renewal request can also consist of initializing 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.

[0035] According to an advantageous embodiment, when the online proof system comprises a trust register, 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 comprise: - a step of developing a request for consultation of public digital identities of entities issuing the online proof system and triggering the issue of said request to the trusted register; - a step of receiving a transmission message from said trusted register and reading within it a public digital identity of the issuing entity conveyed by said message; - a step of producing a new digital identity from the portfolio of verifiable attributes to replace the previous one; - a step of preparing the request for renewal of the verifiable attribute already issued to the issuing entity whose public digital identity was read in the transmission message from said trust register, said renewal request comprising the verifiable attribute to be renewed and the new public digital identity of the portfolio of verifiable attributes.

[0036] According to this advantageous embodiment, in order to make such a new public digital identity of the portfolio of verifiable attributes accessible to the other electronic entities of the online proof system, the step of producing a new digital identity of the portfolio of verifiable attributes may further consist of developing a request for updating the public digital identity to the trusted register, 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.

[0037] To prevent any constitution, by a malicious electronic issuing entity or one likely to be the target of a malicious attack on purpose, of a history of emissions of verifiable attributes of a portfolio of verifiable attributes, and therefore ultimately of the Internet user carrying the electronic object which hosts said portfolio, the step of receiving a transmission message emanating from the trusted register and reading within it a public digital identity of an issuing electronic entity conveyed by said message may consist of the selection of a public digital identity of an issuing entity distinct from that of the issuing electronic entity having emitted the verifiable attribute to be renewed.

[0038] The invention makes it possible to prevent any future exploitation of a prior instance of a verifiable attribute which has been renewed, said prior instance being able to be subject to public revocation within the online proof system. For 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 receiving 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 computer characteristic of the latter.

[0039] According to this latter advantageous embodiment, in order to prevent any illegitimate revocation, 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.

[0040] According to an advantageous embodiment, 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 preparing 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 trust register and searching, within it, for the public digital identity of the electronic entity issuing the verifiable attribute to be renewed.

[0041] In the same way, the 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: - a step of preparing 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 trust register and searching, within it, for the public digital identity of the portfolio of verifiable attributes.

[0042] According to a preferred mode of application, 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.

[0043] According to a preferred embodiment, for each electronic entity of an online proof system adapted according to the invention: - 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 the said public key, by the implementation of an asymmetric cryptographic algorithm.

[0044] For each electronic entity of such a system, 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.

[0045] To adapt a known online proof system so that it preserves the anonymity of users and preserves all traceability of the respective activities of the latter, the invention further relates to a first computer program product 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: - loadable into a memory of said electronic object hosting a portfolio of verifiable attributes; - designed so that their execution by said processing unit causes the implementation by said portfolio of verifiable attributes of a first sub-process of a method for automatic renewal of a verifiable attribute according to the invention.

[0046] The invention then also relates to: - a computer-readable storage medium comprising the instructions of such a first computer program product; - an electronic object comprising a processing unit, means of communication communication with the outside world and a memory recording the program instructions of such a first computer program product.

[0047] To adapt a known online proof system so that it preserves the anonymity of users and preserves all traceability of the respective activities of the latter, 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: loadable into a memory of said transmitting electronic entity; designed so that their execution by said processing unit causes the implementation of a second sub-process of a method for automatic renewal of a verifiable attribute according to the invention.

[0048] The invention then also relates to: a computer-readable storage medium comprising 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.

[0049] Finally, 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: an electronic entity verifying verifiable attributes; a portfolio of verifiable attributes implemented by a processing unit of an electronic object held by a user, said electronic object being arranged according to the invention and as expressed previously; an electronic entity emitting verifiable attributes arranged according to the invention and as expressed previously.

[0050] Other characteristics and advantages will appear more clearly on reading the following description and on examining the accompanying figures, among which:

[0051] [Fig. 1], already described, illustrates an example of an online proof system of verifiable attributes according to the state of the art;

[0052] [Fig.2], already described, illustrates an example of functional architecture of any electronic entity forming said online proof system according to [Fig.l];

[0053] [Fig.3] illustrates an example of an automatic attribute renewal method verifiable in accordance with the invention and implemented by an online proof system of verifiable attributes;

[0054] [Fig.4] illustrates a functional flowchart of a first sub-process of a method for automatic renewal of verifiable attributes in accordance with the invention and described by [Fig.3], said first sub-method being intended to be implemented by a portfolio of verifiable attributes of an online proof system such as that illustrated by [Fig.l];

[0055] [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 by [Fig.3], said second sub-method being intended to be implemented by an electronic entity issuing verifiable attributes of an online proof system illustrated by [Fig.l].

[0056] [Fig.3] thus illustrates a method 300 for automatically renewing an attribute verifiable attribute VCi, intended to be verified by a verifier Vn of an online proof system S according to [Fig.l]. Such a verifier Vn is not involved in the method 300 and therefore does not appear in [Fig.3]. Indeed, a verifiable attribute obtained after the implementation of a renewal method 300 according to the invention is similar to any other verifiable attribute obtained after the implementation of a known process by an issuer Ij in response to a creation request VC_CR according to the state of the art.

[0057] 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 Figures 4 and 5.

[0058] 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.

[0059] The second sub-method 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 Ij'.

[0060] For its implementation, the invention thus only requires the adaptation or design of wallets and issuers of an online proof system S. As indicated in [Fig. 3], said method 300 can furthermore use a trust register TR recording the public digital identities of the electronic entities of the system S, including in particular those of the wallet Wm and of the issuer Ij' as well adapted. Indeed, said trust register TR can be advantageously requested during the implementation of the method 300 by means of conventional and known requests PI_R for consultation of public digital identities emanating from any electronic entity of an online proof system S such as that described in connection with [Fig.l]. Thus, such 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 request PI_R for consultation of public digital identities.

[0061] To illustrate such a method 300 in accordance with the invention, let us assume that a verifiable attribute VC attests to the majority of the bearer Um of the electronic object Om. An instance of this attribute, referenced VCi in [Fig. 3], has been created and sent in response to a request for creation of a verifiable attribute, said creation request VC_CR being in accordance with the current state of the art and having been sent by the wallet Wm to a first issuer Ij such as that already described in connection with the online proof system S according to [Fig. 1]. Said issuer Ij is not shown in [Fig. 3] because said step of creating and transmitting said verifiable attribute VCi is not part of the invention. Let us also assume that 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 public digital identity PIWm (IDWm identifier and / or PKWm public key) of the user Um or, more precisely, that of the Wm wallet implemented by the Om object held by said user Um; - 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 single attribute; - the digital identity of the issuer Ij having developed and issued said verifiable attribute VCi; - a date of creation or issue of the said verifiable attribute VCi; - an EVD validity end date beyond which, any request for pre CV_PR statement of said verifiable attribute VCi would be rejected by any verifier Vn of said system S; - a signature of said verifiable attribute VCi by the issuer Ij carried out by the latter using his private digital identity (private key SKIj).

[0062] Such a verifiable attribute can be used by the Wm wallet to respond to any VC_PR presentation request from Vn verifiers. Although possibly using a pseudonym in the form of a decentralized identifier IDWm, the latter can be traced by said Vn verifiers. It is therefore possible to consist of a history of PV_M presentation messages, history which may be detrimental to the Internet user, certain verifiers or transmitters being able to cross-reference and share their information in connection with the exploitation of said verifiable attribute. There is currently no solution to prevent this risk.

[0063] The method 300 illustrated by [Fig. 3] resolves this difficulty in an elegant and transparent manner for the Internet user. Thus, mainly by implementing the sub-method 100, a wallet Wm can decide, according to different criteria, to cause a joint renewal of the digital identity of the wallet Wm and of verifiable attributes already legitimately issued, without requiring iteration of a procedure VC_CR for creating verifiable attributes. Said sub-method 100 is arranged to address an innovative request for renewal of a verifiable attribute already issued VC_RR to any issuer Ij' of the online proof system S which would have been adapted or arranged to implement the sub-method 200. Such a request VC_RR mainly conveys the attribute VCi already issued by the issuer Ij and the new public digital identity of the wallet Wm.In response to such a VC_RR renewal request, since such a verifiable attribute VCi has been placed by a legitimate issuer Ij within the system S, the issuer Ij' creates a copy of the verifiable attribute VCi in the form of a new verifiable attribute VCi+1 retaining all or part of the content of the attribute VCi, that is to say, in this case: . - 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 may be optional within the framework of an online proof of majority system dedicated to this single attribute; - the EVD validity end date beyond which any request for presentation of CV_PR of said new verifiable attribute VCi+1 would be rejected by any Vn verifier of said system S.

[0064] The new verifiable attribute VCi+1, a quasi-clone of the verifiable attribute VCi, differs only in its content in that: - the public digital identity PlWm (identifier IDWm and / or public key PKWm) of the user Um or more precisely that of the Wm wallet requiring renewal and implemented by the Om object held by said user Um; - a signature of said new verifiable attribute VCi+1 by the issuer Ij' carried out by the latter using his private digital identity (private key SKIj') replaces the signature of the issuer Ij of the verifiable attribute VCi; - the public digital identity of the issuer Ij' having developed and issued said new verifiable attribute VCi+1 replaces that of the issuer Ij of the attribute VCi; - a creation or issue date CD of said new verifiable attribute VCi+1 instead of the creation date of the verifiable attribute VCi.

[0065] It should be noted that when the verifiable attribute to be renewed VCi has a validity end date EVD beyond which any request for presentation CV_PR of said new verifiable attribute VCi would be rejected by any verifier Vn of said system S, the new verifiable attribute VCi+1 resulting from the renewal process reproduces the same validity end date EVD as the initial verifiable attribute VCi.

[0066] By implementing the sub-method 200 after having created said new verifiable attribute VCi+1, without triggering any CUI investigation with an entity or authority TA, the transmitter Ij' transmits said new verifiable attribute VCi+1, 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+1.

[0067] Such a method 300 can be iterated as much as necessary, so that said new verifiable attribute VCi+1 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. By implementing the invention, tracing for the purpose of building up 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 an issuer requested for a renewal of a verifiable attribute is systematically or randomly different from the one who was at the origin of the issue (creation or renewal) of the verifiable attribute which is the subject of the renewal.

[0068] [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 register TR 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 Ij' 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 previously to prevent a follow-up of the renewals velements by a malicious issuer or target of an attack. For its part, to give a favorable response to a renewal request sent by a Wm wallet, an issuer receiving said request can request said trusted register TR 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 renewal. Said issuer receiving the renewal request can thus verify, on the one hand, the signature of the Wm wallet if it 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.

[0069] Finally, [Fig. 3] illustrates a method 300 for automatic renewal of a verifiable attribute for which the sub-method 100 allows a revocation request VC_RKR to be prepared for 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+1. Such a revocation request is arranged to be interpreted by the trust 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, to record information characteristic of the latter, such as the result of a cryptographic hash function of such a verifiable attribute for example.According to this variant, an issuer Ij' receiving a request for renewal of a verifiable attribute can further verify, by requesting said register, that the verifiable attribute subject to renewal is not a revoked verifiable attribute. If not, the sub-process 200 does not carry out the renewal and can return an error message to the wallet requesting the renewal.

[0070] [Fig.4] illustrates in detail advantageous embodiments of a sub-method 100 of a method for automatic renewal of verifiable attributes according to the invention. As indicated previously, such 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 issuer Ij' is adapted to implement a sub-method 200 exploiting a request for renewal of a verifiable attribute.

[0071] Such a sub-process 100 consists of three distinct major steps referenced 110, 120, 130 in [Fig.4], said steps being dedicated respectively to: - the detection 110 of an event triggering a renewal of a verifiable attribute VCi, that is to say a verifiable attribute already legitimately issued (simply created or previously renewed) by the transmitter Ij (not shown in [Fig.4]); - the development and triggering 120 of the transmission of a VC_RR request for renewal of such a verifiable attribute VCi to an issuer Ij' of the online proof system S; - the management 130 of a new verifiable attribute VCi+1 resulting from such a renewal request VC_RR and transmitted by said transmitter Ij' by a transmission message VC_M.

[0072] According to [Fig.4], each electronic entity of the online proof system of which the Wm wallet is 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.Optionally, 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 other electronic entities.

[0073] Thus, the digital identity IWm of the Wm wallet consists of: - a public digital identity PIWm, in this case a unique identifier IDWm (possibly decentralized) and a public key PKWm; - a private digital identity, in this case a private key SKWm jointly developed with said public key PKWm to ensure a cryptographic signature and / or asymmetric encryption scheme.

[0074] The digital identity Ilj of the issuer Ij of the attribute VCi, subject to automatic renewal, consists of: - a public digital identity Pllj, in this case a unique identifier IDIj (possibly decentralized) and a public key PKIj; - a private digital identity, in this case a private key SKIj jointly developed with said public key PKIj to ensure a cryptographic signature and / or asymmetric encryption scheme.

[0075] The same applies to the sender Ij' receiving a request for renewal of the verifiable attribute VCi, possibly or advantageously distinct from the sender Ij. Thus, the digital identity Ilj' of the sender Ij' consists of: - a public digital identity Pllj', in this case a unique identifier IDIj' (possibly decentralized) and a public key PKIj'; - a private digital identity, in this case a private key SKIj' jointly developed with said public key PKIj' to ensure a cryptographic signature and / or asymmetric encryption scheme.

[0076] The online proof system S, from which the wallet Wm and the issuers Ij and Ij' form part, comprises a trusted register TR arranged 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.

[0077] The sub-process 100 therefore comprises a first step 110 of detecting an event triggering a renewal of a verifiable attribute, in this case the verifiable attribute VCi previously emitted by the transmitter Ij.

[0078] Such an event can be of different natures. The invention in fact provides 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.l]. Such 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 a renewal of a verifiable attribute could furthermore 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.

[0079] As an example, [Fig.4] describes an embodiment according to which the wallet Wm associates with each verifiable attribute VCi which it manages, an nPV counter for sending messages in presentation PV_M conveying said verifiable attribute VCi in response to requests in presentation VC_PR from verifiers. According to this exemplary embodiment, 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 an nPV counter of messages of pre PV_M transmission conveying the verifiable attribute VCi addressed to a verifier of the online proof system S. Said step 110 can then consist of the comparison 112 of the current value of said nPV counter 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. Finally, said step 110 concludes with the detection of an event triggering an automatic renewal if said value of said nPV counter reaches said predetermined threshold. Such a situation is represented by the link 112-y in [Fig.4]. As long as said nPV counter remains below said threshold, no renewal of the verifiable attribute is triggered (situation represented by the link 112-n in [Fig.4]).

[0080] Such a renewal of verifiable attribute VCi is now detailed in connection with step 120 of sub-process 100. 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. For this, beforehand, in order to prevent the traceability of the public digital identity of the wallet and, consequently, that of the Internet user Um carrying the object Om hosting said wallet Wm, the processing 120 may comprise a step 121 of producing a new digital identity IWm of the portfolio 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. In the same way, such 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. When the trusted register TR stores the public digital identity of said wallet Wm, the invention provides that said step 121 may further consist of developing a request PI_U for updating the public digital identity intended for the trusted register TR.Such a request PI_U 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. remains however advantageous but optional. The invention provides in fact that a Wm wallet can keep the same digital identity IWm to implement a plurality of VC_RR renewal requests. Alternatively, 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. An 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 VC_RR renewal requests 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.

[0081] In order for the Wm wallet to be able to prepare the renewal request VC_RR 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 renewal request VC_RR.

[0082] For this, the invention provides different embodiments for selecting the future sender recipient of the VC_RR renewal request.

[0083] According to a first embodiment, the processing 120 comprises a step 122 for reading, within the verifiable attribute VCi (subject to 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.

[0084] As a variant, 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. At each iteration of said processing 120, 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.

[0085] According to a preferred alternative, to carry out such a selection from a list of public digital identities of issuers, the processing 120 comprises a step 123 of developing a request PI_R in consultation of public digital identities of issuer entities of the online proof system S and of 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 of reading within the latter of one or more public digital identities of issuers conveyed by said message PI_M. Such a systematic solicitation of the trust 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 receiving the renewal request VC_RR can also be carried out randomly within said list obtained or in a directed manner to prohibit itself from sending said request CV_RR to the issuer Ij of the verifiable attribute VCi subject to renewal. In this case, the selection of the recipient is carried out by choosing a public digital identity distinct from that of the issuer Ij.

[0086] Step 125 of processing 120 then consists of preparing the request VC_RR for renewal of the verifiable attribute VCi, then causing it to be sent to the sending 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.

[0087] Finally, said step 125 may advantageously consist of signing said request VC_RR, prior to the latter's issue, using the private digital identity SKWm of the wallet Wm. In this way, the recipient sender Ij' will be able to verify its legitimacy, as will be explained in connection with [Fig. 5]. In the same way, 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 sender Ij' can be the only one to decrypt said renewal request.

[0088] 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 for the latter, comprises a processing or management step 130 of a new verifiable attribute VCi+1 resulting from such a renewal request VC_RR and transmitted by a transmission message VC_M prepared by the sender Ij' recipient of said renewal request VC_RR.

[0089] Such processing 130 comprises a step 131 of receiving and reading a transmission message of a new verifiable attribute VCi+1 emanating from the sender Ij' recipient of the renewal request VC_RR prepared in processing 120. Such a step 131 may further consist of verifying the signature of the new verifiable attribute VCi+1 by the sending entity Ij' of the latter, using the public digital identity Pllj' of said sending entity Ij', if said new attribute has been signed by the latter. The new verifiable attribute VCi+1 is rejected if the verification of the signature fails and a new iteration of processing 120 is implemented, advantageously by selecting a transmitter Ij' distinct from the previous iteration to send it a VC_RR renewal request.

[0090] When said new verifiable attribute appears legitimate, the processing 130 comprises a step 132 of recording the new verifiable attribute VCi+1, in the data memory 12, M, accessible in reading and writing by the wallet Wm. This recording of the new verifiable attribute VCi+1 is carried out by overwriting the verifiable attribute VCi thus renewed or followed by the erasure of the latter.

[0091] When the sub-method 100 provides for the use of a counter of presentations nPV, 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+1 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.

[0092] As mentioned previously in connection with [Fig. 3], the sub-method 100 may provide for the preparation 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, following the production of a new verifiable attribute VCi+1. According to this advantageous embodiment, the processing 130 comprises, upstream of the destruction (by overwriting or erasure) of a renewed verifiable attribute VCi, a step for preparing 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.Such a 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 confirmation of the verification of the signature of said Wm wallet using the public digital identity PIWm of the latter.

[0093] 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 issuer Ij' of an online proof system S such as that Ij illustrated by [Fig.l]. To adapt the operation of such an issuer Ij', 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, a new verifiable attribute VCi+1 to the portfolio Wm requesting said renewal of verifiable attribute.

[0094] 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.

[0095] Said processing 210 further comprises a verification step 214: - the signature of said VC_RR renewal request by the Wm wallet, using the latter's public digital identity PIWm; - the signature of the verifiable attribute to be renewed VCi by the electronic entity issuing the latter Ij, using the public digital identity Pllj of the latter.

[0096] 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-process 100. On the other hand, 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. Thus, 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]).

[0097] When the verification 214 of the signature of said VC_RR request by the Wm wallet is planned, then the implementation of the second step 220 consisting as such in the renewal of a verifiable attribute is also conditioned on the confirmation of the authenticity of said signature of said VC_RR request (situation illustrated by the link 214-y in [Fig.5]).

[0098] If step 214 concludes that the signature(s) are not authentic, a situation symbolized by the link 214-n in [Fig. 5], the invention provides that said step 214 can further consist of the preparation of a transmission message VC_M conveying a content characterizing an error (symbolized by the Anglo-Saxon term “error” in [Fig.5]) intended for the wallet Wm requiring an aborted renewal. Such a message VC_M can be signed using the private digital identity SKIj' of the sender Ij' implementing the present instance of the sub-process 200.

[0099] To be able to verify the said signature(s) of the verifiable attribute to be renewed VCi and / or of the renewal request VC_RR as such, like what the first sub-process 100 provides in the optional steps 123 and 124, the step 214 of verifying the processing 210 of the second sub-process 200, can advantageously be preceded: - a step 212 of developing a PI_R request for consultation of public digital identities of electronic entities of the online proof system S and triggering the sending of said request to the trusted register TR; - a step 213 of receiving a transmission message PI_M emanating from said trust register TR and searching, within it, for the public digital identity Pllj of the electronic entity issuing Ij the verifiable attribute VCi to be renewed, or even that PIWm of the wallet Wm issuing the renewal request VC_RR.

[0100] 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+1 to the portfolio Wm requesting said renewal of verifiable attribute, comprises a step 221 of developing the new verifiable attribute VCi+1 consisting of copying all of the information contained in the verifiable attribute VCi to be renewed except for the information related to the development as such of the latter, as mentioned previously in connection with [Fig.3].

[0101] Said step 221 further consists of developing a signature of the new verifiable attribute VCi+1 using the private digital identity SKIj' of the issuing entity Ij' of said new verifiable attribute so that it is legitimately issued, like the renewed verifiable attribute VCi. Such a signature is an integral part of the content of the new verifiable attribute VCi+1.

[0102] The second step 220 of the second sub-method 200 comprises a sub-step 222 to cause the emission of the new verifiable attribute VCi+1 to the portfolio Wm requesting the renewal of the verifiable attribute VCi.

[0103] 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 proof of majority or any other verifiable attribute from 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. It is sufficient for this, that said supplier SP can establish a connection with a verifier Vn of such an online proof system S.

Claims

Claims

1. Method (300) for automatic renewal of an attribute of a verifiable user (Um) (VC, VCi, VCi+1) by a verifying electronic entity (Vn) of an online proof system (S), - said system (S) comprising a plurality of electronic entities (Vn, Wm, Ij, Ij') respectively arranged to communicate with each other within said system (S) including, in addition to said verifying electronic entity (Vn), a portfolio (Wm) of verifiable attributes implemented by a processing unit (11) of an electronic object (Om) held by a user (Um), an emitting electronic entity (Ij, Ij') of verifiable attributes, - any verifiable attribute (VC, VCi, VCi+1) issued having been previously developed and transmitted by an issuing electronic entity (Ij, Ij') of said online proof system (S) in response to a request (VC_CR) for the creation of a verifiable attribute initiated by a portfolio (Wm) of verifiable attributes of said system (S), said automatic renewal method (300) being characterized in that it comprises: - a first sub-process (100), implemented by a portfolio (Wm) of verifiable attributes, comprising: • a step (110) of detecting an event triggering a renewal of a verifiable attribute (VCi) already issued by an issuing electronic entity (Ij, Ij') of said online proof system (S); • a step (120, 125) of developing and triggering the sending of a request (VC_RR) for renewal of such a verifiable attribute (VCi) already sent, to an electronic sending entity (Ij') of the online proof system (S) distinct from that which sent said verifiable attribute (VCi) which is the subject of the request (VC_RR) for renewal;

2. • a step of managing (130) a new verifiable attribute (VCi+1) resulting from such a renewal request (VC_RR) and transmitted (VC_M) by said issuing entity (Ij'); - a second sub-method (200) implemented by a processing unit (11) of an issuing entity (Ij') of the online proof system (S) comprising: • a step (210) of processing a renewal request (VC_RR) of a verifiable attribute transmitted by a portfolio (Wm) of verifiable attributes; • in response to such processing of a renewal request (VC_RR), since said verifiable attribute has been issued by one of the issuing entities of the online proof system (S), a step (220) of renewing such a verifiable attribute and transmitting (VC_M) a new verifiable attribute to the portfolio (Wm) of verifiable attributes requiring said renewal of a verifiable attribute already issued, comprising: • a step (221) of developing a new verifiable attribute (VCi+1) consisting of copying all of the information contained in the verifiable attribute (VCi) to be renewed, except for the information linked to the development as such of the latter; • a step (222) to cause the emission of the new verifiable attribute (VCi+1) to the portfolio (Wm) of verifiable attributes requiring renewal. Method (300) according to claim 1, for which the step (120) of developing and triggering the sending of a request (VC_RR) for renewal of a verifiable attribute (VCi) already sent comprises, prior to the development (125) as such of said request (VC_RR), a selection of an electronic sending entity (Ij') of the online proof system (S) from among those contained in a list of issuing entities available and capable of carrying out such a renewal of verifiable attributes, so that the issuing entity selected and recipient of said renewal request (VC_RR) is distinct from the one having issued said verifiable attribute (VCi) which is the subject of the renewal request (VC_RR).

3. Method (300) according to claim 1 or 2, wherein: - each electronic entity (Ij, Ij', Vn, Wm) of said online proof system (S) is associated with a digital identity (Ilj, Ilj', IVn, IWm) formed of a public part (Pllj, Pllj', PIVn, PIWm), called "public digital identity" and a private part (SKIj, SKIj', SKVn, SKWm), called "private digital identity", said digital identity being recorded in a data memory (M, 12) of said each electronic entity; - said online proof system (S) comprises a trust register (TR) arranged for: • record, in a data memory (TRM, 12), the respective public digital identities (Pllj, Pllj', PIVn, PIWm) of the electronic entities (Ij, Ij', Vn, Wm) of said online proof system (S); • receive a request (PI_R) for consultation of public digital identities from an electronic entity of said system (S); • prepare a transmission message (PI_M) conveying one or more public digital identities (Pllj, Pllj', PIVn, PIWm) and send such a message to the electronic entity (Ij, Ij', Vn, Wm) issuing said request (PI_R) for consultation of public digital identities; - the first sub-process (100) is arranged so that: • the management step (130) of a new verifiable attribute (VCi+1) resulting from such a renewal request (VC_RR) comprises: • a step (131) of verifying the signature of the new verifiable attribute (VCi+1) by the issuing entity (Ij') of the latter (VCi+1), using the identity public digital (Pllj ') of said issuing entity (Ij'); • a step (132) of recording the new verifiable attribute (VCi+1), in a data memory (M, 12) accessible in reading and writing by the portfolio (Wm) of verifiable attributes, in replacement of the renewed verifiable attribute (VCi) if, and only if, said step (131) of verifying the signature of the new verifiable attribute (VCi+1) confirms the authenticity of said signature; the second method (200) is arranged so that: • step (210) of processing a request for renewal of a verifiable attribute already issued comprises: • a step of receiving (211) such a renewal request (VC_RR) and reading the information conveyed by the latter, including the verifiable attribute (VCi) already issued and the public digital identity (PIWm) of the portfolio (Wm) of verifiable attributes, respectively the object and issuer of said renewal request (VC_RR); • a step (214) of verifying the signature of the verifiable attribute to be renewed by the electronic entity issuing the latter, using the public digital identity (Pllj) of the latter; • the step (220) of renewing a verifiable attribute already issued and transmitting (VC_M) a new verifiable attribute: • is only implemented if said step (214) of verifying the signature of the verifiable attribute (VCi) to be renewed confirms the authenticity of the latter; • step (221) of developing the new attribute verifiable (VCi+1) consists of signing said new verifiable attribute (VCi+1) using the private digital identity (SKIj') of the issuing entity (Ij') of said new verifiable attribute.

4. Method (300) according to claim 3, for which: - the first sub-method (100) is arranged so that the step (120) of developing and triggering the issue of a renewal request (VC_RR) comprises a step (125) of signing said renewal request (VC_RR) using the private digital identity (SKWm) of the portfolio (Wm) of verifiable attributes; - the second method (200) is arranged so that: • the step (210) of processing a request for renewal of a verifiable attribute already issued comprises a step (214) of verifying the signature of said renewal request by the portfolio (Wm) of verifiable attributes, using the public digital identity (PIWm) of the latter; • the step (220) of renewing a verifiable attribute already issued and transmitting (VC_M) a new verifiable attribute is only implemented if said step (214) of signing the renewal request (VC_RR) confirms the authenticity of said signature.

5. Method (300) according to any one of claims 1 to 4, for which: - the step (110) of detecting an event triggering an automatic renewal of a verifiable attribute (VCi) already issued, consists of: • a reading (111), in a data memory (M, 12) accessible in reading and writing by the portfolio (Wm) of verifiable attributes, of the value of a counter (nPV) of presentation messages (PV_M) conveying the verifiable attribute (VCi) addressed to an electronic verifying entity (Vn) of the online proof system (S); a comparison (112) of the current value of said counter with a predetermined maximum threshold and a conclusion as to the detection of an event triggering an automatic renewal if (112-y) said value of said counter (nPV) reaches said predetermined threshold; the step of managing (130) a new verifiable attribute (VCi+1) resulting from a renewal request (VC_RR), further consists of an initialization (132) of the value of a counter (nPV) of presentation messages (PV_M) conveying said new verifiable attribute (VCi+1) in a data memory (M) accessible in reading and writing by the portfolio (Wm) of verifiable attributes.

6.

7. Method (300) according to any one of the preceding claims, for which the step (120, 125) of developing and triggering the sending of a request (VC_RR) for renewal of an attribute vé verifiable (VCi) already issued from the first sub-process (100) comprises: a step (121) of producing a new digital identity (IWm) from the portfolio of verifiable attributes (Wm) to replace the previous one; the step (125) of preparing the request (VC_RR) for renewal of the verifiable attribute (VCi) already issued to the issuing entity (Ij') is arranged so that said renewal request (VC_RR) includes the verifiable attribute (VCi) to be renewed and the new public digital identity (PIWm) of the portfolio (Wm) of verifiable attributes. Method (300) according to claims 3 and 6, for which: the step (120) of developing and triggering the sending of a request (VC_RR) for renewal of a verifiable attribute (VCi) already sent from the first sub-process (100) includes: • a step (123) of developing a request (PI_R) for consultation of public digital identities (Pllj') of issuing entities (Ij') of the online proof system (S) and triggering the sending of said request to the trusted register (TR); • a step (124) of receiving a transmission message (PI_M) emanating from said trust register (TR) and reading within it a public digital identity (Pllj') of the issuing entity (Ij') conveyed by said message (PI_M); - the step (125) of preparing the request (VC_RR) for renewal of the verifiable attribute (VCi) already sent to the sending entity (Ij') is arranged so that the public digital identity (Pllj') of said sending entity (Ij') is taken from the transmission message (PI_M) emanating from said trust register (TR).

8. Method (300) according to one of claims 6 and 7 when they depend on claim 2, for which the step (121) of producing a new digital identity (IWm) of the portfolio of verifiable attributes (Wm) further consists of developing a request (PI_U) for updating the public digital identity to the trusted register (TR), said request conveying the new public digital identity (PIWm) resulting from the new digital identity (IWm) signed using the previous private digital identity (SKm) of said portfolio of verifiable attributes (Wm).

9. Method (300) according to any one of claims 3 to 9, for which: - the trust register (TR) is arranged to store (TRM) any revoked verifiable attribute (VCi) or information characteristic of such a revoked verifiable attribute (VCi) in response to the reception of a revocation request (VC_RKR) of a verifiable attribute; - the step of managing (130) a new verifiable attribute (VCi+1) resulting from a renewal request (VC_RR) comprises a step (133) of developing such a request in revocation (VC_RKR) of verifiable attribute carrying the verifiable attribute (VCi) which has been renewed to the trusted registry (TR).

10. Method (300) according to the preceding claim, for which the step (133) of developing a revocation request (VC_RKR) further consists of developing a signature of said request (VC_RKR) using the private digital identity (SKWm) of said portfolio of verifiable attributes (Wm).

11. Method (300) according to any one of claims 3 to 10, for which the step (214) of verifying the signature of the verifiable attribute to be renewed of the second sub-method (200) is preceded by: - ​​a step (212) of developing a request (PI_R) for consultation of public digital identities (PIWm, Pllj, Pllj') of electronic entities (Wm, Ilj, Ij') of the online proof system (S) and triggering the transmission of said request to the trusted register (TR); - a step (213) of receiving a transmission message (PI_M) from said trusted register (TR) and searching, within the latter, for the public digital identity (Pllj) of the electronic entity Ij issuing the verifiable attribute to be renewed (VCi).

12. Method (300) according to claim 4, for which the step (214) of verifying the signature of the renewal request by the portfolio (Wm) of verifiable attributes of the second sub-method (200) is preceded by: - ​​a step (212) of developing a request (PI_R) for consultation of public digital identities (PIWm, Pllj, Pllj') of electronic entities (Wm, Ilj, Ij') of the online proof system (S) and triggering the transmission of said request to the trusted register (TR); of a step (213) of receiving a transmission message (PI_M) emanating from said trusted register (TR) and searching, within it, for the public digital identity (PIWm) of the portfolio of verifiable attributes (Wm).

13. Method (300) according to any one of the preceding claims, for which the verifiable attribute (VC, VCi, VCi+1) characterizes the majority of the user of the electronic object (Om) hosting the portfolio (Wm) of verifiable attributes.

14. Method (300) according to any one of the preceding claims, for which and for each electronic entity of the proof system (S): - the public digital identity (Pllj, Pllj', PIVn, PIWm) consists of a public key (PKIj, PKIj', PKVn, PKWm) and an identifier (IDIj, IDIj', IDVn, IDWm); - the private digital identity consists of a private key (SKIj, SKIj', SKVn, SKWm) produced jointly with said public key, (PKIj, PKIj', PKVn, PKWm) by implementing an asymmetric cryptographic algorithm.

15. Method (300) according to the preceding claim, for which, and for each electronic entity of the online proof system (S), the identifier (IDIj, IDIj', IDVn, IDWm) is a decentralized identifier derived from said public key (PKIj, PKIj', PKVn, PKWm) by the implementation of a reversible cryptographic algorithm, said public digital identity (Pllj, Pllj', PIVn, PIWm) thus being reduced to said decentralized identifier (IDIj, IDIj', IDVn, IDWm) or to said public key (PKIj, PKIj', PKVn, PKWm).

16. Computer program product (P) comprising one or more program instructions executable by a processing unit (11) of an electronic object hosting a portfolio (Wm) of verifiable attributes of an online proof system (S), said program instructions being: - loadable into a memory (M, 13) of said electronic object (Om) hosting a portfolio (Wm) of verifiable attributes; - designed so that their execution by said processing unit processing (11) causes the implementation by said portfolio (Wm) of verifiable attributes of a first sub-process (100) of a method (300) of automatic renewal of a verifiable attribute (VC, VCi, VCi+1) according to any one of claims 1 to 15.

17. A computer-readable storage medium comprising the instructions of a computer program product according to the preceding claim.

18. Computer program product (P) comprising one or more program instructions executable by a processing unit (11) of an electronic entity (Ij, Ij') issuing verifiable attributes of an online proof system (S), said program instructions being: - loadable into a memory (M, 13) of said electronic entity (Ij, Ij'); - designed so that their execution by said processing unit (11) causes the implementation of a second sub-method (200) of a method (300) for automatic renewal of a verifiable attribute (VC, VCi, VCi+1) according to any one of claims 1 to 15.

19. A computer-readable storage medium comprising the instructions of a computer program product according to the preceding claim.

20. Electronic object (Om) comprising a processing unit (11), means of communication (14) with the outside world and a memory (M, 13) recording the program instructions of a computer program product according to claim 15.

21. Electronic entity (Ij, Ij') transmitting verifiable attributes comprising a processing unit (11), means of communication (14) with the outside world and a memory (M, 13) recording the program instructions of a computer program product according to claim 18.

22. Online proof system (S) comprising a plurality of electronic entities (Vn, Wm, Ij, Ij') respectively arranged to communicate with each other within said system (S) including: - an electronic verifying entity (Vn) of verifiable attributes; - a portfolio (Wm) of verifiable attributes implemented by a processing unit (11) of an electronic object (Om) held by a user (Um), said electronic object being arranged according to claim 20; - an electronic entity (Ij, Ij') emitting verifiable attributes arranged according to claim 21.

Images