Method and apparatus for generating authenticated user data

Abstract

This document discloses a computer-implemented method for providing a verified certificate that will be modified during the generation of authenticated user data. It also discloses a computer-implemented method for enabling the representation of an unknown user from authenticated user data, and a method for representing the unknown user from the authenticated user data. The generation of the authenticated user data avoids the risk of personal information being leaked into the digital domain, except where it is necessary to represent or identify an unknown user with the assistance of a trusted system.

Description

Technical Field

[0001] This invention generally belongs to the field of information security technology. In particular, this invention relates to a method for generating authenticated user data, which cannot be associated with a specific user without the cooperation of a trusted system. Background Technology

[0002] Many people have one or more digital identities in addition to their official / legal identities, and many digital platforms require only a digital identity for those operating on the platform, which can be unique to that platform. In many cases, a digital identity is a customer account or "login" used to enable interaction with the digital platform.

[0003] In some scenarios, such as obtaining a license to drive a motor vehicle or interacting with tax authorities, it is necessary to ensure that a person's official identity, or at least their personal information, is verified before a digital identity is assigned. For example, a digital ID used to access a government platform is only provided after the ID has been verified. In other scenarios, interactions with a second entity may rely on prior verification already performed by the first entity; for example, when someone presents a passport to prove their ID when opening an account, the bank implicitly relies on prior verification of that person's official identity. In these scenarios, the first entity (e.g., a government agency) may collude with the second entity (e.g., a bank) to track user activity on the second entity's digital platform.

[0004] Using digital identities without verifying underlying official identities and personal information can lead to socially or legally unacceptable pseudonyms. For example, malicious provocation, deliberate misleading, and abusive comments on online media may go unpunished because the responsible individual cannot be identified. Alternatively, without verification, identities can be "impersonated," leading to potential fraudulent activities.

[0005] In many scenarios, such as obtaining a driver's license or interacting with tax authorities, people have long agreed on the need to ensure that an individual's official identity is verified before being assigned a digital identity. A growing number of digital platforms recognize that the need to verify identity, or at least some personal information, also applies to their services to maintain regulatory compliance or improve user experience.

[0006] However, verifying an individual's official identity and / or personal information can have significant privacy consequences. If the process of verifying, authenticating, and storing official identities or personal information exposes or stores links between pseudonyms and official identities or personal information, then such a pseudonymous privacy veil is compromised or easily abused, because the verifying / authenticating entity is aware of the link between the digital identity and the official identity / personal information. Furthermore, such a library of links is a natural target for malicious entities (such as hackers), and if compromised, the links between pseudonyms and their corresponding official identities / personal information could be obtained.

[0007] Therefore, a secure method is needed to provide the benefits of authentication while protecting the privacy features of pseudonyms in a way that avoids the increased risk of underlying personal and identification information being leaked into the digital domain. Summary of the Invention

[0008] According to a first aspect of the present invention, a computer-implemented method is provided for providing a verified certificate that will be modified during the generation of authenticated user data, the method comprising the steps of:

[0009] Verify user data, which includes the user's personal information;

[0010] Associate the verified user data with the first set of data;

[0011] Create a verified certificate that will be modified during the generation of authenticated user data, wherein the verified certificate includes a modifiable portion containing an indication of a first set of data;

[0012] Provide verified certificates for the generation of authenticated user data.

[0013] The modifiable part is so that when it is modified, the verified certificate is no longer associated with the verified user data.

[0014] In some embodiments, the first set of data includes one or more of a token, a database reference, or a serial number.

[0015] In some embodiments, the method further includes the step of encrypting a first set of data to form an encrypted first set of data, and the encrypted first set of data forming an indication of the first set of data.

[0016] In some embodiments, the modifiable portion of the created verified certificate includes an identifier of the entity that created the verified certificate, and optionally, the identifier includes a signature signed using the entity's private key.

[0017] In some embodiments, the modifiable portion includes a rerandomizable portion.

[0018] In some embodiments, the method further includes the step of storing an association between the first set of data and the verified user data.

[0019] In some embodiments, the encryption step occurs using the public key of the trustee system.

[0020] In some embodiments, the method further includes the step of modifying a modifiable portion of a verified certificate to generate authenticated user data.

[0021] In some embodiments, the method further includes a step of storing auxiliary data, wherein the auxiliary data includes an association between verified user data and an encrypted version of an indication of the authenticated user data, and optionally, wherein the encryption used to create the encrypted version of the indication of the authenticated user data occurs using a public key of a trustee system.

[0022] In some embodiments, personal information includes identification information.

[0023] In some embodiments, the authenticated user data includes the user's encryption key.

[0024] According to a second aspect of the present invention, a computer-implemented method is provided that enables the representation of an unknown user from authenticated user data, wherein the authenticated user data includes a modified portion of a verified certificate, the modified portion including a first set of data that has been encrypted, the verified certificate also including an identifier of an associated entity, the first set of data having been associated with the verified user data by the associated entity before the modification of the modified portion, the verified user data including personal information of the unknown user, the method comprising the following steps:

[0025] Receive a request from a requester, the request including an indication of authenticated user data;

[0026] Decrypt the encrypted first set of data, including the modified portion of the authenticated user data, to provide the first set of data; and

[0027] Provide the requester with a first set of data associated with verified user data to enable the characterization of unknown users.

[0028] In some embodiments, the identifier of the associated entity includes one or more of the following: (i) a signature signed using the associated entity's private key, and optionally, the signature is included in a modified portion; and (ii) the associated entity's public key included in a verified certificate, and optionally, the public key is included in an unmodified portion of the verified certificate.

[0029] In some embodiments, the first set of data includes one or more of a token, a database reference, or a serial number. In the same or other embodiments, the method is performed by a trustee system, and the first set of data has been encrypted using the trustee system's public key.

[0030] In some embodiments, the modified portion is a re-randomized portion, and the modification is re-randomization.

[0031] In some embodiments, the method further includes the step of authorizing a request from a requester to enable the representation of an unknown user. In some such embodiments, the method is performed by a plurality of trustee systems, and the step of decrypting an encrypted first set of data, including a modified portion of the authenticated user data, occurs only if the number of trustee systems among the plurality of trustee systems authorizing the request meets a threshold number.

[0032] In some embodiments, the method further includes a step of checking the validity of the identifier of the associated entity.

[0033] In some embodiments, the association of the first set of data with the verified user data occurs before the encryption of the first set of data.

[0034] In some embodiments, personal information is identification information, and the method is a method that enables the identification of unknown users from authenticated user data.

[0035] According to a third aspect of the present invention, a computer-implemented method for characterizing an unknown user from authenticated user data is provided, wherein the authenticated user data includes a modified portion of a verified certificate, the modified portion including a first set of data that has been encrypted, the verified certificate also including an identifier of an associated entity, the first set of data having been associated with the verified user data by the associated entity before the modification of the modified portion, the verified user data including personal information of the unknown user, the method comprising the following steps:

[0036] Instructions to provide authenticated user data to one or more trustee systems;

[0037] Receive a first set of data from the one or more trustee systems;

[0038] Provide the first set of data to the associated entities; and

[0039] Receive verified user data from the associated entity, the verified user data including the personal information of the unknown user.

[0040] In some embodiments, the identifier of the associated entity includes one or more of the following: a signature signed using the associated entity's private key, and optionally, the signature is included in a modified portion; and the associated entity's public key included in a verified certificate, and optionally, the public key is included in an unmodified portion of the verified certificate.

[0041] In some embodiments, the first set of data includes one or more of a token, a database reference, or a serial number.

[0042] In some embodiments, the modified portion is a re-randomized portion, and the modification is re-randomization.

[0043] In some embodiments, the method further includes at least one of the following: publishing the personal information of an unknown user; storing the personal information of an unknown user; punishing the user or subjecting the user to prosecution; selecting second certified user data, wherein the selection of the second certified user data is based on the personal information of the first certified user data; and adding the user's personal information to a blacklist.

[0044] In some embodiments, the association of the first set of data with the verified user data occurs before the encryption of the first set of data.

[0045] In some embodiments, the personal information is identification information, and the method is a method for identifying unknown users from authenticated user data.

[0046] According to a fourth aspect of the present invention, a method is provided, the method comprising the steps of the first aspect or one of its embodiments and the steps of the second aspect or one of its embodiments. Alternatively, a method is provided, comprising the steps of the first aspect or one of its embodiments and the steps of the third aspect or one of its embodiments. Further alternatively, a method is provided, comprising the steps of the second aspect or one of its embodiments and the steps of the third aspect or one of its embodiments. Still further alternatively, a method is provided, comprising the steps of the first aspect or one of its embodiments, the steps of the second aspect or one of its embodiments, and the steps of the third aspect or one of its embodiments.

[0047] According to a fifth aspect of the invention, a computer program product including instructions is provided, which, when executed, cause one or more processors to perform the method described in one of the preceding aspects.

[0048] According to a sixth aspect of the invention, a computer-readable medium including instructions that, when executed, cause one or more processors to perform the method described in one of the preceding aspects.

[0049] According to a seventh aspect of the invention, one or more processors are provided, which are configured to perform the method described in one of the preceding aspects. Attached Figure Description

[0050] Figure 1 It is a block diagram of the architecture of a system capable of executing a method for providing a verified certificate that will be modified in the generation of authenticated user data.

[0051] Figure 2 It can be made by Figure 1 A diagram of the authenticated user data generated by the system.

[0052] Figure 3 This is a flowchart of a method that provides a verified certificate to be modified in the generation of authenticated user data, and the modification of the verified certificate.

[0053] Figure 4 This is a block diagram of the system architecture for representing unknown users from authenticated user data and enabling the representation of those unknown users. Detailed Implementation

[0054] The features of specific embodiments of the invention are outlined in detail below. Additionally, some (but not all) variations of certain embodiments that can be implemented while still falling within the scope of the invention are described. Although the following description is subdivided into sections to aid those skilled in the art in understanding the subject matter, the particular substructures of the specific embodiments should not be considered as limiting the various embodiments of the invention. Rather, the features of the various sections can be appropriately combined.

[0055] To understand the principles of the invention outlined below, reference should be made to... Figures 1 to 4 The features shown in each figure are as follows. However, the invention is defined only by the appended claims.

[0056] As used herein, the term "personal information" refers to information that allows an individual to be represented. For example, personal information could be an individual's place of residence or nationality. Alternatively, personal information could be account details, such as social media accounts (e.g., Facebook or Twitter), or public identifiers, such as an author's pseudonym. Alternatively, personal information could be an IP address associated with an individual's device. In some instances, personal information could be identifying information that can identify the official identity of a natural or legal person. For natural persons, examples of identifying information include passports, driver's licenses, or birth certificates. For legal persons (e.g., corporations or trusts), identifying information could be the original articles of association or the original trust deed. Identifying information can be in physical or digital form (e.g., scans or photographs of the original document), but in each case, it can identify the official identity of the natural / legal person.

[0057] As used herein, the term "representation" refers to the identification of previously unknown personal information when a user is represented, but this does not necessarily reveal the user's official / legal identity. For example, a user's nationality or place of residence (when such information was previously unknown) is information that represents the user. However, knowing a user's nationality does not allow for the determination of the user's official identity, but it is still personal information about the user. Similarly, a user can be represented as an employee of a company or organization, which is personal and potentially private information about the user, but does not determine the individual's official identity.

[0058] As used herein, the term "privacy information" refers to information that is encompassed within personal information and may be encompassed within identifying information. For example, if personal information includes identifying information, and the identifying information contains a photograph of a natural person, then privacy information can be any biometric information that can be extracted from that photograph. Alternatively, if the identifying information includes an address, then such an address can also be privacy information. However, privacy information can also be captured in personal information that is not identifying information (such as an individual's place of residence or domicile for tax purposes). This type of information is privacy because it should not be disseminated beyond what is necessary to know, but such information does not necessarily establish an individual's legal / official identity.

[0059] As used herein, the term “associate” two or more entities / objects means establishing a link between two or more previously unrelated entities / objects such that, as a result of the association, the first of the entities / objects can be identified as having a connection or relationship with the second of the entities / objects.

[0060] As used herein, a “verified certificate” refers to data generated by a digital identity provider that indicates a user’s personal information has been successfully verified and that verified user data has been created. A verified certificate is data that has been certified by a competent authority and contains modifiable portions, and in some instances, immutable portions. A verified certificate, or a portion thereof, is linked to the user’s personal information via verified user data, and the existence of the verified certificate indicates successful verification. The digital identity provider responsible for creating the verified certificate is able to associate the certificate, or a portion thereof, with the verified user data.

[0061] As used herein, the term "authenticated user data" refers to user data that indicates the competent authority has successfully completed the verification process and created a verified certificate. However, authenticated user data contrasts with a verified certificate because the digital identity provider responsible for creating the verified certificate cannot associate authenticated user data, or a portion thereof, with verified user data without the cooperation of a trustee system.

[0062] The methods and system architectures described herein can be executed on any device equipped with a processor, such as a computer, mobile phone, tablet computer, PDA, local network, cloud network, etc. The processor is capable of executing instructions stored in associated memory to perform the described steps. The processor may include more than one core and / or may run on a virtual machine. In some instances, the processor may be a series of processors in a distributed computing system, such as a computer on a network. If distributed, some or all of the methods may be executed on different processors, cores, or networks.

[0063] Provide digital identity

[0064] Figure 1 A high-level block diagram of a system architecture capable of executing a computer-implemented method according to the present invention is shown. In the first step of the method, user 100 sends personal information 150 to digital identity provider 200. The personal information may be, for example, the user's driver's license. Since the personal information included in the driver's license enables the determination of the user's place of residence based on their address, the privacy information included in the license should only be shared on a necessary basis. Furthermore, since the driver's license also enables the identification of user 100 via their name, date of birth, and address (i.e., enables the determination of their official identity), the driver's license also includes identification information containing privacy information that should only be shared on a necessary basis.

[0065] The personal information 150 may take the form of an original copy of the user's driver's license or a previously authenticated copy of the user's driver's license (e.g., sent to the digital identity provider 200 by registered mail or post). Alternatively, the personal information 150 sent to the digital identity provider 200 may itself be a digital copy of the driver's license, such as a scanned copy or photograph of the original document or other data containing information embedded therein on the driver's license (such as the user's name and address).

[0066] Similarly, Figure 1As shown, digital identity provider 200 is an entity that functions to verify the authenticity of personal information 150 provided to it by user 100 and issue a verified certificate 400 to user 100, which confirms that the user has undergone the verification process. Issuing a certificate to a user (although not necessarily the content of the verified certificate 400) is an instruction to a third party indicating that user 100's personal information has been verified by digital identity provider 200. An example of such a process is when a user verifies his / her identity with a tax authority, or when a customer verifies his / her identity with a bank and does so using his / her driver's license.

[0067] Figure 3 The steps taken by digital identity provider 200 are illustrated. Upon receiving personal information 150 from user 100, digital identity provider 200 verifies (S1) the authenticity of personal information 150, and a digital copy of the information is securely stored (S2) in database 210 accessible by digital identity provider 200. If personal information 150 itself is non-digital (e.g., an original driver's license sent by registered mail), a digital copy of personal information 150 can be created and stored in database 210. Verification of personal information 150 can, for example, be performed by checking the hologram, official seal, or other verification features of the driver's license to verify its authenticity. In a digital environment, verification of the digital copy of personal information 150 can be performed by checking the digital signature of the digital copy, such as a signature made by user 100's private key or by another entity (e.g., an official agency). Alternative means for verifying personal information 150 can also be implemented, as will be apparent to those skilled in the art. In each case, the digital identity provider verifies the personal information 150 of user 100. If the personal information 150 contains identification information, the digital identity provider 200 verifies the identity of the user 100.

[0068] Once a user's personal information 150 has been verified, the data containing that personal information forms verified user data 220 that can be stored. Verified user data 220 has the quality based on the personal information 150 originating from user 100, and therefore provides a link back to the user 100 who provided it, from which user 100's personal information 150 can be retrieved. Furthermore, any privacy information captured within user 100's personal information 150 is easily accessible to any entity that reviews the user's verification data 220. In the example of a driver's license, the user's address is privacy information contained within personal information 150, and correspondingly, is included in verified user data 220.

[0069] like Figure 3As further illustrated, once the verified user data 220 is stored, the digital identity provider 200 associates a first set of data with the verified user data 220 (S3). The first set of data may be a database reference so that a specific entry within database 210 can be retrieved. The first set of data may be any token that has been created (at that time or previously) to serve as a database reference. Alternatively, the first set of data may be a modified form of the verified user data 220, such as an encryption function or hash of the verified user data 220 itself, and this hash or encryption function itself may be used as a database reference. In this example, the verified user data 220 is associated with a serial number 300. The association between the verified user data 220 and the serial number 300 may be stored in database 210, as well as... Figure 1 As shown in the diagram. If the digital identity provider 200 is responsible for verifying the identities of multiple users, the verified user data 220A, 220B, 220C for each user can be stored in association with serial numbers 300A, 300B, 300C (not shown). This associated storage allows the digital identity provider 200, which possesses serial number 300 or verified user data 220, to use the association to retrieve the other of serial number 300 or verified user data 220. In this example, knowing serial number 300 enables the retrieval of personal information 150 contained in the user's driver's license via verified user data 220. More generally, knowing the first set of data enables the retrieval of personal information.

[0070] Although in the example shown, the digital identity provider 200 establishes an association between the first set of data (serial number 300) and the verified user data 220, it should be emphasized that the use of such serial numbers is exemplary and alternative database references or tokens may be used instead.

[0071] In the example shown, digital identity provider 200 is aware of the association between serial number 300 and verified user data 220. Therefore, based on the fact that digital identity provider 200 is the entity responsible for establishing this association, digital identity provider 200 also, in principle, knows about personal information 150. However, digital identity provider 200 should only be provided with sufficient information to verify user 100's personal information and to indicate to any interested party that it has done so by generating a verified certificate 400. Therefore, it is desirable to eliminate for user 100 the requirement that digital identity provider 200 "trust" not to reveal the association between verified user data 220 and serial number 300. This is achieved by modifying at least a portion of the verified certificate 400 in a manner further detailed below, such that when modified, the verified certificate 400 can no longer be associated with verified user data 220 via serial number 300.

[0072] If the first set of data (serial number 300) is directly included in the verified certificate 400, the entity reviewing the verified certificate 400 would obviously be able to retrieve the associated verified user data 220 with the assistance of the digital identity provider 200. To prevent such insecurity, the verified certificate 400 contains an indication of the first set of data. For example, this indication could be an address at which the first set of data can be retrieved / reviewed by an entity authorized to retrieve / review the first set of data, or security could be achieved, for example, by using an encrypted or hashed form of the first set of data. In this example, the first set of data (serial number 300) Figure 1 The serial number 300 is directly encryptable, for example, using an asymmetric scheme (such as ElGamal). The serial number 300 is encrypted to provide an encrypted serial number 300E as ciphertext. This encryption can be performed using the public key of the trustee system 600. The public key of the trustee system is used so that the trustee system 600 can decrypt the encrypted serial number 300E in certain cases described later to reveal the original serial number 300.

[0073] To provide user 100 or a third party with evidence that user 100 has successfully completed the verification process, upon successful completion, digital identity provider 200 provides user 100 with (S4) a verified certificate 400. The creation and provision of the verified certificate 400 confirms that user 100 has successfully undergone the verification process.

[0074] It should be noted that although the storage of verified user data 220, the association of verified user data 220 with the first set of data (such as a serial number), the creation of the certificate, and the encryption of the first set of data have been described as being performed in a specific order, this order of steps is merely exemplary. As those skilled in the art will recognize, other orders of steps are also possible.

[0075] like Figure 1 As shown, the verified certificate 400 to be issued to user 100 includes a modifiable portion 410, which will be modified by user 100, as explained below. The modifiable portion 410 contains an indication of a first set of data, and in the example shown, this indication is encrypted first set of data. The encrypted first set of data is a decryptable portion of the modifiable portion 410 of the verified certificate 400, and in an exemplary embodiment, includes ciphertext representing the encrypted sequence number 300E encrypted with the public key of the trustee system 600. In this example, the modifiable portion 410 also contains a digital signature 420 of the digital identity provider 200 signed using the private key of the digital identity provider.

[0076] In some instances, the verified certificate 400 may include multiple modifiable parts, each of which may include one or more decryptable parts (e.g., multiple encrypted tokens / database references), or a single modifiable part may include multiple decryptable parts. Although in this example, the token / database reference (serial number 300) is encrypted with the public key of the trustee system 600, generally, in cases with multiple decryptable parts, the decryptable parts can be decrypted by different entities (such as different trustee systems). For example, one trustee system may only be able to decrypt a subset of the decryptable parts in the verified certificate 400, requiring another trustee system to decrypt the remaining parts. In some instances, each decryptable part requires a different trustee system.

[0077] In some instances, the verified certificate 400 also includes an immutable portion 415. This portion may include metadata, public information, or other data unrelated to the serial number 300, and does not permit the verified certificate 400 (or a portion thereof) to be associated with the verified user data 220. In some instances, a copy of the digital identity provider's public key 430 is also provided within the immutable portion 415. The public key 430 enables third parties to verify the signature of the digital identity provider 200 responsible for creating the verified certificate 400.

[0078] Although some or all of the modifiable portion 410 may not be accessible to third-party observers due to its encryption, hashing, or other reasons, one or both of (i) or (ii): (i) providing the public key 430 of the digital identity provider in the immutable portion 415, and / or (ii) providing a digital signature 420 in the modifiable portion 410 as a modifiable digital signature, indicate to third-party observers that user 100 has undergone the verification process and that the user's personal information has been verified accordingly. (i) or (ii) may also provide indications that the user's personal information (which may include identifying information) may be disclosed in certain circumstances, and may indicate which digital identity provider 200 is responsible for the verification process.

[0079] The verified certificate 400 is provided to the user (S4). While the verified certificate 400 can be provided to the user via email, text message, etc., such a process has its own security risks due to the possibility of interception. As a more secure alternative to avoid such risks, the digital identity provider 200 can provide the verified certificate 400 to user 100 by informing user 100 where to find the verified certificate 400. For example, the verified certificate 400 can be published to a private blockchain, encrypted using user 100's public key, and a message can be sent to user 100 notifying them that the verified certificate 400 is available. Therefore, user 100 can freely access the verified certificate 400 using his or her private key. Other forms of disseminating the verified certificate 400 to user 100 will be readily understood by those skilled in the art.

[0080] Continue to refer to Figure 1 , Figure 2 and Figure 3 When the verified certificate 400 is created, the ciphertext of serial number 300E has already been signed by digital identity provider 200. Therefore, review of the verified certificate 400 will reveal the encrypted serial number 300E contained therein, and the encryption of the serial number means that it is generally inaccessible to third parties. However, when serial number 300 is provided, digital identity provider 200 can retrieve the associated verified user data 220, and correspondingly, can obtain personal information 150 and any privacy information contained therein. Since this association is stored in database 210, user 100 relies on the honest conduct of digital identity provider 200 to prevent digital identity provider 200 itself from revealing user 100's personal information. Digital identity provider 200, which has the encrypted serial number 300 to generate the ciphertext of encrypted serial number 300E, can "remember" (e.g., store in memory or cache) which verified user data 220 is associated with the ciphertext, especially if digital identity provider 200 is designed to be used only by a single user 100. If such a correspondence between the ciphertext and the verified user data 220 is "remembered," the digital identity provider 200 can effectively associate the encrypted serial number 300E with the verified user data 220. Both (i) the reliance on the honest conduct of the digital identity provider 200; and (ii) the ability of the identity provider 200 to associate the encrypted serial number 300E with the verified user data 220 in certain limited scenarios represent privacy risks beyond the user's control, as the user's verified user data 220, and therefore their personal information 150 and any privacy information therein, may be obtained through the actions of the digital identity provider 200 without the user's knowledge.

[0081] To avoid reliance on digital identity provider 200, the indication of the first set of data (serial number 300) includes a portion of the modifiable portion 410 of a verified certificate 400, which is provided to or received by user 100, and then the modifiable portion 410 of the verified certificate 400 is modified by user 100 (S5). Once the modifiable portion 410 is modified, the verified certificate 400 has been generated (i.e., become) authenticated user data 500, as... Figure 2 As shown in the diagram, the modification to the verified certificate 400 is such that the verified certificate 400 (specifically, the modifiable portion 410) can no longer be associated with the verified user data 220 by anyone (including the digital identity provider 200) without the assistance of the trustee system 600. Therefore, the modification to the verified certificate 400 prevents anyone from linking the authenticated user data 500 back to the verified user data 220 via instructions on the first set of data contained therein or via any other portion of the verified certificate.

[0082] In this example, serial number 300 has previously been associated with verified user data 220, and it indicates that the ciphertext of the encrypted serial number 300E includes a portion of the modifiable portion 410 of the verified certificate 400, which is re-randomized, and both the digital signature 420 and the encrypted serial number 300E (ciphertext) are re-randomized using a re-randomization scheme.

[0083] In a specific example, the applied rerandomization scheme is used for digital signatures on ciphertext. This scheme rerandomizes the ciphertext, which has the effect of creating a new ciphertext with the same underlying plaintext (serial number 300 in this example). The scheme then allows the digital signature to be adjusted so that it becomes a valid signature on the new ciphertext. A security property of this scheme is that the signature can only be adjusted for another ciphertext with the same associated plaintext. Unless the ciphertext is decrypted, it is impossible to determine whether two signed ciphertexts are associated with the same plaintext. An exemplary rerandomization scheme for signing on ciphertext is the scheme of Bauer and Fuchsbauer (https: / / eprint.iacr.org / 2020 / 524).

[0084] When a randomization scheme such as that described above is applied to the verified certificate 400, each of the ciphertext 300E and the signature 420 is modified by user 100 (more specifically, re-randomized). The public key 430, representing the identity of the original signer (possibly digital identity provider 200), remains unchanged because it is included within the immutable portion 415. The modified signature 420M is still a valid signature relative to the same public key 430.

[0085] Continue to refer to Figure 2 User 100 re-randomizes the modifiable portion 410 of the verified certificate 400 to generate authenticated user data 500. Authenticated user data 500 includes modified ciphertext of the modifiable portion 410 of the verified certificate 400. The modified ciphertext contains a modified encrypted sequence number 300M, which represents a re-randomized version of the ciphertext of the encrypted sequence number 300E. This modification means that if digital identity provider 200 presents the modified ciphertext 300M contained in authenticated user data 500, it will not be able to associate the ciphertext 300M with the verified user data 220 for a specific entry, even if digital identity provider 200 has stored a record of the creation of the ciphertext 300E. The modification of generating authenticated user data 500 containing ciphertext 300M has the following effect: user 100 no longer needs to rely on the behavior of digital identity provider 200 to ensure the security of authenticated user data 220, because the correspondence between ciphertext 300M and authenticated user data 220 is unknown to digital identity provider 200.

[0086] However, by examining the authenticated user data 500, and specifically the modified portion 410M, a third party can see that user 100 has undergone the verification process with digital identity provider 200, because re-randomization has adjusted the digital identity provider's signature 420M to make it valid for the new ciphertext 300M. Validity can be proven by examining signature 420M (where the signature form is as expected) or by using public key 430. In this example, the unmodified portion 415 (specifically public key 430) within the authenticated user data 500 indicates which digital identity provider 200 is responsible for the verification process and for creating the verified certificate 400 from which the authenticated user data 500 originates. Therefore, the third party can determine that user 100 has undergone the verification process, but neither the third party nor digital identity provider 200 can link the authenticated user data 500 back to the verified user data 220, and thus back to user 100's personal information 150. In this respect, the authenticated user data 500 (i.e., the verified certificate 400 once modified) can no longer be associated with the verified user data 220 via any indication of the first set of data contained therein.

[0087] Since neither the third party examining the authenticated user data 500 nor the digital identity provider 200 can link the authenticated user data 500 or any part thereof back to user 100, the authenticated user data 500 provides evidence of verification and a means of determining the user's personal information via a trustee system, but is otherwise entirely pseudonymous. User 100 can then use the authenticated user data 500 or some of its functions as a digital identity, securely knowing that his or her personal information 150 or the privacy information contained therein cannot be linked to the authenticated user data 500, and therefore there is generally no chance that personal information 150 (especially the privacy information contained in the user's driver's license and details of the user's identifying information) will be leaked into the digital domain.

[0088] In proportion to the aforementioned reduction in the risk to user personal information, a third party (such as a digital platform host 700 (e.g., a host for a forum or website)) may allow users of the forum or website to use authenticated user data 500 or some of its functions as a digital identity for the platform, securely knowing that the user's identity has been verified by the digital identity provider 200, but unable to use the authenticated user data 500 to recover personal information 150 to determine the user 100's personal information or any privacy information contained therein.

[0089] User 100 can generate more than one set of authenticated user data 500 from the verified certificate 400 by modifying (e.g., re-randomizing) the modifiable portion 410 of the verified certificate 400 in various different ways. Therefore, if each set of authenticated user data 500 corresponds to a different "login" for a different digital platform, user 100 can generate logins for multiple platforms from a single verification process at the digital identity provider 200.

[0090] In some examples, the authenticated user data 500 forms the public part of the user's cryptographic signing key. One advantage of this is that the user can then prove ownership of their authenticated user data 500 at any time. This capability is useful if the owner wishes to further associate the authenticated user data 500 with another form of identity (such as an account, profile, or digital wallet) (in a cryptographically bound manner).

[0091] In some examples, after user 100 has created authenticated user data 500, he or she can further encrypt the authenticated user data 500 or a portion thereof using a public key (such as the public key of the trustee system 600). In one example, user 100 further encrypts a modified serial number 300M to create a further encrypted modified serial number 300ME (not shown). User 100 then submits this further encrypted form of authenticated user data 500 (serial number 300ME in this example) back to digital identity provider 200 as supplementary data to be associated with one or more of the serial number 300, the verified certificate 400, the verified user data 220, etc. Therefore, the digital identity provider 200 accumulates records for each piece of authenticated user data 500 created by user 100, but cannot access records in the auxiliary data because the authenticated user data 500 has been further encrypted (in the absence of the further encrypted authenticated user data 500, the association between the authenticated user data 500 and the serial number 300 would be accessible to the digital identity provider 200). Again, although this example involves further encryption of the modified serial number, in general, this further encryption does not have to be the (modified) serial number, but could instead be a modified database reference, or generally, a modified first set of data.

[0092] In such examples, the accumulation of records allows the host 700 or regulatory body / supervisor 800 to subsequently request the trustee system 600 to expose some (or all) of the digital identities generated by a given person by requesting further encryption of the authenticated user data 500 already stored by the digital identity provider 200, decrypted using the trustee system's private key. This enables the removal of people from the digital platform, not just individual digital identities within their digital identities, and provides a mechanism by which each piece of authenticated user data associated with a specific user 100 can be identified. To perform such decryption, the host or regulator provides the trustee system 600 with instructions on auxiliary data for the trustee system 600 to decrypt.

[0093] Characterizing unknown users

[0094] The generation of authenticated user data 500 provides user 100 with a mechanism to prove that his or her personal information 150 has been verified, and provides a digital identity for use on digital platform 1000, but does not enable digital identity provider 200 to reveal user 100's personal information from the authenticated user data 500. Furthermore, the host 700 of the digital platform is also unable to identify user 100's personal information from the authenticated user data 500.

[0095] A certified user data 500, or some of its functions, can be used as a user's login to a digital platform; this can be referred to as a "certonym" (meaning a certified pseudonym). For example, if the digital platform is a website, a user's browsing, posting messages, or commenting can be logged directly or indirectly using instructions regarding certified user data 500. If the platform is a digital wallet, a user's transactions can be logged directly or indirectly using instructions regarding certified user data 500. In either case, and in some other examples, logging is for the purpose of tracing actions back to certified user data 500 responsible for each action. In some cases, if certified user data 500 forms the encryption key for user 100, user 100 can also cryptographically prove his or her ownership of certified user data 500.

[0096] In most uses, the verified pseudonyms behind such arrangements are generally acceptable. However, there are scenarios where other unknown users behind the digital identity using digital platform 1000 must be characterized from verified user data 500 and identified in some instances. One example is in emergency situations. Another example is where the behavior of the unknown user associated with verified user data 500 is unacceptable. For example, in the case where platform 1000 is a website, verified user data 500 constitutes part of the login of (unknown) user 100, and this login is found to be "malicious provocation" comments or content made by other users or hosts. Another example of unacceptable use is where the platform is a digital wallet, and verified user data 500 represents a login to said digital wallet, and an unknown user is found to be engaging in fraudulent or otherwise illegal transactions. In such scenarios, it may be necessary to identify the unknown user behind the digital identity including verified user data 500. In these scenarios, a mechanism is needed to reverse the process of generating authenticated user data 500, otherwise user 100 will be able to act unpunished in an unacceptable manner, just as it can be done with a purely pseudonymous system with the current level of technology.

[0097] Figure 4 A system architecture in which user 100 is characterized, said user 100 having previously been based on Figures 1 to 3 The present invention, illustrated in the scheme, generates authenticated user data 500 and has used the authenticated user data 500 to interact with a digital platform. Although this example relates to a scenario where a user 100 behind the authenticated user data 500 posts abusive comments on a website, this example should not be construed as limiting.

[0098] If a user's behavior is unacceptable, for example, because user 100 consistently violates comment rules or policies, the initial step of host 700 is to identify the verified user data 500 responsible for the comment. At this point, host 700 is unaware of the official identity or any personal information of user 100 behind the verified user data 500, and cannot access any personal information 150 or verified user data 220 about user 100. Therefore, user 100 remains an unknown user at this time.

[0099] Although user 100 cannot be identified, host 700 can determine the certified user data 500 responsible for the unacceptable behavior by, for example, querying the comments or logs of activity on the website.

[0100] Once the relevant authenticated user data (500) is identified, host (700) reviews the authenticated user data (500). For example... Figure 2As shown, included within the authenticated user data 500 are: an identifier of the digital identity provider 200 (as opposed to one or more public keys 430 residing in the unmodified portion 415 of the authenticated user data 500), and / or a modified digital signature 420M residing in the modified portion 410M of the authenticated user data 500. Accompanying each of these elements is ciphertext, in this example ciphertext 300M, which is a modified encrypted sequence number 300. Although the host 700 cannot decrypt ciphertext 300M, the host 700 can recognize the form of one or more of these elements to determine that the authenticated user data 500 being examined by the host is the authenticated user data previously generated from the verified certificate 400. In this sense, the fact that the authenticated user data 500 has the correct form is an indication that the host is querying the authenticated user data 500 (as opposed to any other data).

[0101] In some instances, host 700 can verify that the modified signature 420M is a valid signature relative to the public key 430 of digital identity provider 200.

[0102] Furthermore, the presence of the identifier (though not the content) makes the existence of the verified user data 220 and the associated serial number 300 readily understandable, even though neither is contained within the authenticated user data 500. Rather, the authenticated user data 500 itself provides an indication that an authentication process has previously been conducted with the digital identity provider 200, and that, in principle, the digital identity provider 200 knows or has stored a correspondence between the verified user data 220 and another piece of data (e.g., the (decrypted) ciphertext of the first set of data (serial number 300 in the example shown)).

[0103] In some examples, instead of host 700 verifying whether the authenticated user data 500 has the correct form and / or verifying the identity of digital identity provider 200, host 700 enables the authenticated user data 500 to be verified by a third party. The third party could be a regulatory body 800, a trustee system 600, or another entity. To check the form of the authenticated user data 500, it can be sent to the third party, or it can be provided to the third party, for example, via publication. The third party can then query the authenticated user data 500 and confirm that it has the correct form in a manner similar to that outlined above for host 700. The third party (such as regulator 800) then provides confirmation to host 700. In this alternative, upon receiving confirmation, host 700 is provided with instructions regarding the verification process previously performed by digital identity provider 200.

[0104] Subsequently, as Figure 4 As shown, host 700 sends a (U1) request 710 to trusted system 600. This request may include a copy of the authenticated user data 500 itself, or may include an indication of the location of the authenticated user data 500 (such as the server address of the authenticated user data 500) and means authorizing trusted system 600 to retrieve or query the authenticated user data 500. Host 700 may send request 710 itself, or may request a third party (such as regulatory body 800) to send request 710 to trusted system 600 on behalf of host 700. As a further alternative, host 700 may report unacceptable behavior and authenticated user data 500 to a third party or regulatory body 800, and the third party or regulatory body 800 may initiate request 710 to trusted system 600.

[0105] Upon receiving request 710, the trustee system 600 examines the authorized user data 500 of ciphertext 300M. Since ciphertext 300M was originally encrypted with the trustee system's public key before modification, the trustee system 600 can use its private key to decrypt ciphertext 300M and reveal serial number 300. In this example, the ciphertext of the modified encrypted serial number 300M is formed by re-randomizing the encrypted serial number 300E, and both are valid ciphertexts relative to the same plaintext (serial number 300) encrypted with the trustee system 600's private key. Because re-randomization preserves the underlying plaintext of the ciphertext, the trustee system's private key can be directly used to decrypt the modified encrypted serial number 300M to obtain serial number 300.

[0106] If multiple decryptable parts / encryption tokens / database references / serial numbers exist in the authenticated user data 500 (because the original verified certificate 400 contains a modifiable part 410 with multiple decryptable parts, or contains multiple modifiable parts, each with its own decryptable parts, as previously described), the trustee system 600 can choose which decryptable parts to decrypt while keeping the remaining parts encrypted. This choice can be made by the trustee system 600 itself or can be instructed to the trustee system 600 by the requester. Furthermore, in some cases, the trustee system 600 will only be able to decrypt a subset of the decryptable parts, and one or more other trustee systems will be required to decrypt the remaining parts.

[0107] While in principle only a single trustee system 600 with the correct private key is required, in some embodiments of the invention, multiple trustee systems 600 can decrypt the ciphertext (modified encrypted sequence number 300M) contained in the authenticated user data 500. For example, the trustee system 600 can be a distributed trustee system 600, in which multiple nodes are responsible for decrypting the ciphertext 300M, for example, each node decrypts a portion of the ciphertext using a threshold encryption / decryption scheme, or multiple nodes decrypt the text, with some nodes providing redundancy or verification functions.

[0108] Furthermore, the trustee system 600 (whether distributed or not) can verify the request 710 to decrypt the authenticated user data 500, for example, by verifying the authorization of the host 700 or the supervisor 800 to decrypt the ciphertext 300M. For example, the request 710 may include the requester's digital signature and public key to verify the requester's authorization to decrypt. If multiple trustee systems 600 are used, decryption of the ciphertext 300M will only occur if a threshold number of trustee systems (e.g., more than 50% of the trustee systems 600) agree that authorization exists.

[0109] Once the trustee system 600 decrypts the ciphertext of the modified encrypted serial number 300M, it provides the requester with (U2) the unencrypted serial number 300. In some instances, the serial number 300 may be transmitted to the requester, but similar to other instances outlined previously, such transmission may be vulnerable to interception. Therefore, in some examples, the serial number 300 is stored in a location accessible to the requester. For example, the trustee system 600 may re-encrypt the serial number 300 with the requester's public key and notify the requester of the location (e.g., a private blockchain), allowing the requester to access the serial number 300 using his or her private key. Although the serial number 300 is used as the first set of data in this example, the requester may be provided with an alternative token, alternative database reference, or other form of first set of data that is consistent with a data fragment previously associated by the digital identity provider 200 with the verified user data 220.

[0110] Although not shown, request 710 can be publicly logged, thus deterring the host 700 or regulator 800 from abusing their ability to make request 710, as any such request 710 could be seen by a third party and potentially by user 100. The public nature of this log prevents the host 700 or regulator 800 from attempting to reveal user 100's personal information behind authenticated user data 500 without the knowledge of user 100 or another third party. In some cases, the log can be an unavoidable, public, and persistent record of request 710, such as its publication on a public blockchain.

[0111] Once the unencrypted serial number 300 has been provided to the host 700 (or, where appropriate, to the regulator 800), the host provides (U3) serial number 300 to the digital identity provider 200. The instruction regarding which digital identity provider 200 the host 700 should contact is determined by the authenticated user data 500, which contains one or both of a digital signature 420M and a public key 430, each of which serves as an indicator for the digital identity provider 200. The host 700 may transmit serial number 300 (the first set of data) to the digital identity provider 200 in a manner similar to that used to provide authenticated user data 500 to the trustee system 600, or alternatively, may transmit a message to the digital identity provider 200 that readily indicates where serial number 300 can be found.

[0112] Upon receiving an instruction for serial number 300, digital identity provider 200 may respond by providing an instruction for verified user data 220, which contains personal information 150 associated with user 100. To this end, digital identity provider 200 queries database 210 to locate the verified user data 220 associated with serial number 300. In some examples, digital identity provider 200 may authenticate the permissions of host 700 or regulator 800, or other entity providing serial number 300. For example, serial number 300 may be accompanied by the digital signature of the requester (i.e., host 700 or regulator 800) and the requester's public key to authorize the requester's request for digital identity provider 200 to reveal the associated permissions.

[0113] Once verified user data 220, including personal information 150, is provided to host 700 or regulator 800, host 700 or regulator 800 can take action against that information. For example, and based on the personal information, host 700 can publish information related to now-known user 100, thereby revealing the personal information of the user responsible for unacceptable behavior; if the information is identifying information, the publication will reveal user 100's identity to others in a "name-and-stigma manner." Alternatively, host 700 can store the personal information of now-known user 100 for future reference, or if the information includes identifying information, store the identifying information of now-known user 100 for future reference. Host 700 can punish user 100, such as by banning access to websites or any digital platforms managed by host 700, or by restricting the user's ability to comment. The user's personal information may be added to a blacklist and / or reported to legal authorities for prosecution. In another example, host 700 may select a second piece of authenticated user data and request the trustee system 600 to decrypt the modified encrypted first set of data (in some examples, a modified encrypted sequence number) contained in the second piece of authenticated data. In one scenario, the host may want to check whether the two pieces of authenticated user data (authenticated user data 500 and the second piece of authenticated user data) have the same underlying user 100. In each case, as a result of an action taken on authenticated user data 500, host 700 (or supervisor 800, which may alternatively perform any of the above actions) may revoke the previously authenticated pseudonym held by user 100, thereby revealing the personal information of the user in question. In the example where the user has stored supplementary data with digital identity provider 200, the accumulated records at digital identity provider 200 may be provided to host 700 or supervisor 800. If these records have been encrypted with the public key of trustee system 600, the host or supervisor may request trustee system 600 to decrypt these records. The decryption request is similar to... Figure 4 The original request is processed and can be logged and authorized in a similar manner as described above. Once decryption by the trustee system 600 is complete, each piece of authenticated user data associated with user 100 will be revealed, and actions can be taken on each of these digital identities, such as removing them from the digital platforms associated with them.

[0114] As mentioned above, having Figure 4The system architecture shown indicates how authenticated user data 500 can be reconnected to verified user data 220, and ultimately to user 100's personal information 150, so that the user does not act unpunished on the digital platform. Therefore, in this sense, when the modifiable portion 410 of certificate 400 is modified to generate authenticated user data 500, the break in the link between the first set of data contained in the verified certificate 400 and the verified user data 220 is reversible, and this link can be re-established.

[0115] This invention provides users with a system for generating authenticated user data that can be used as a digital identity. It offers users the benefits of pseudonymity, data privacy, and minimized risk of information leakage, while also providing hosts or regulators with indications that the user's personal information has been previously authenticated by a digital identity provider. Furthermore, pseudonymity can be removed from the user's authenticated data should misconduct or other circumstances necessitate it.

[0116] Although the actions of the various entities in the system have been described in the examples explained above, those skilled in the art will recognize that combinations of various entities can also collectively provide the benefits of the system. As just a few examples, from the perspective of digital identity provider 200, once the user's personal information 150 has been authenticated, digital identity provider 200 and user 100 work together to create a verified certificate 400, thereby verifying user 100's information. From the perspective of user 100, in exchange for providing personal information 150 to digital identity provider 200, receiving or providing the verified certificate 400, he or she can modify the verified certificate 400 to generate authenticated user data 500. Host 700 (possibly under the supervision of regulatory body 800) can recognize that user 100 has gone through the authentication process with digital identity provider 200 and can optionally accept the authenticated user data 500 generated by digital identity provider 200 as part of login to access the host's digital platform, securely knowing that the user can be characterized or even identified if necessary. Although the host 700 / regulator 800 can work together to request and ultimately reveal user 100's personal information 150, each can only do so if it would require assistance from the trustee system 600. When such a situation arises, the trustee system 600 works with the host 700 / regulator 800 to prevent (unknown) user 100 from acting with impunity on the digital platform. However, user 100 can monitor requests to the trustee system 600 throughout, thereby deterring either the host 700 or the regulator 800 from abusing their capabilities to reveal users behind the authenticated user data 500. Similarly, the trustee system 600 works with the host 700 / regulator 800 to request and ultimately reveal the user's personal information 150 from the already created authenticated user data 500, where appropriate. Thus, each entity within the system is able to cooperate to realize the advantages offered by the system.

[0117] It should be understood that the foregoing disclosure provides specific examples of certain embodiments of the invention and modifications can be made within the scope of the appended claims. Such modifications will similarly capture the privacy and data security advantages of the methods and systems outlined herein, which will be readily apparent to those skilled in the art, and the various scenarios outlined herein should not be considered limiting.

[0118] Various aspects of the present invention:

[0119] 1. A computer-implemented method for providing a verified certificate that will be modified during the generation of authenticated user data, the method comprising the steps of:

[0120] Verify user data, which includes the user's personal information;

[0121] Associate the verified user data with the first set of data;

[0122] Create a verified certificate that will be modified during the generation of authenticated user data, wherein the verified certificate includes a modifiable portion containing instructions regarding the first set of data; and provide the verified certificate for the generation of authenticated user data.

[0123] The modifiable portion is such that when modified, the verified certificate is no longer associated with the verified user data.

[0124] 2. The method according to aspect 1, wherein the first set of data includes one or more of a token, a database reference, or a serial number.

[0125] 3. The method according to aspect 1 or aspect 2, wherein the method further includes the step of encrypting the first set of data to form an encrypted first set of data, and wherein the encrypted first set of data forms an indication of the first set of data.

[0126] 4. The method according to any one of aspects 1 to 3, wherein the modifiable portion of the created verified certificate includes an identifier of the entity that created the verified certificate, and optionally, wherein the identifier includes a signature signed using the entity's private key.

[0127] 5. The method according to any of the foregoing aspects, wherein the modifiable portion includes a re-randomizable portion.

[0128] 6. The method according to any of the foregoing aspects further includes the step of storing an association between the first set of data and the verified user data.

[0129] 7. The method described according to aspect 3 or any aspect subordinate to aspect 3, wherein the encryption step occurs using the public key of the trustee system.

[0130] 8. The method according to any of the foregoing aspects further includes the step of modifying a modifiable portion of the verified certificate to generate authenticated user data.

[0131] 9. The method according to any of the foregoing aspects further includes the step of storing auxiliary data, wherein the auxiliary data includes an association between the verified user data and an encrypted version of the indication of the authenticated user data, and optionally, wherein the encryption for creating the encrypted version of the indication of the authenticated user data occurs using the public key of the trustee system.

[0132] 10. The method according to any of the foregoing aspects, wherein personal information includes identification information.

[0133] 11. The method according to any of the foregoing aspects, wherein the authenticated user data includes the user's encryption key.

[0134] 12. A computer-implemented method enabling the representation of an unknown user from authenticated user data, wherein the authenticated user data includes a modified portion of a verified certificate, the modified portion including a first set of data that has been encrypted, the verified certificate also including an identifier of an associated entity, the first set of data having been associated with the verified user data by the associated entity prior to the modification of the modified portion, the verified user data including personal information of the unknown user, the method comprising the steps of:

[0135] Receive a request from the requester that includes instructions regarding the data of the authenticated user;

[0136] Decrypting the encrypted first set of data, including the modified portion of the authenticated user data, to provide the first set of data; and

[0137] Provide the requester with a first set of data associated with verified user data to enable the characterization of unknown users.

[0138] 13. The method according to aspect 12, wherein the identifier of the associated entity includes one or more of the following:

[0139] A signature signed using the private key of the associated entity, and optionally, wherein the signature is included in the modified portion; and

[0140] Includes the public key of the associated entity in the verified certificate, and optionally, where

[0141] The public key is included in the unmodified portion of the verified certificate.

[0142] 14. The method according to aspect 12 or aspect 13, wherein the first set of data includes one or more of a token, a database reference, or a serial number.

[0143] 15. The method according to one of aspects 12 to 14, wherein the method is performed by a trustee system, and wherein the first set of data has been encrypted using the public key of the trustee system.

[0144] 16. The method according to any one of aspects 12 to 15, wherein the modified portion is a re-randomized portion, and wherein the modification is re-randomization.

[0145] 17. The method according to any one of aspects 12 to 16, wherein the method further comprises the step of authorizing a request from a requester to enable the representation of an unknown user.

[0146] 18. The method according to aspect 17 or any aspect thereof, wherein the method is performed by a plurality of trustee systems, and the step of decrypting the encrypted first set of data, including the modified portion of the authenticated user data, occurs only when the number of trustee systems among the plurality of trustee systems authorizing the request meets a threshold number.

[0147] 19. The method according to any one of aspects 12 to 18 further includes the step of checking the validity of the identifier of the associated entity.

[0148] 20. The method according to any one of aspects 12 to 19, wherein the association of the first set of data with the verified user data occurs before the encryption of the first set of data.

[0149] 21. The method according to one of aspects 12 to 20, wherein the personal information includes identification information, and the method is a method for enabling the identification of unknown users from authenticated user data.

[0150] 22. A computer-implemented method for characterizing an unknown user from authenticated user data, wherein the authenticated user data includes a modified portion of a verified certificate, the modified portion including a first set of encrypted data, the verified certificate also including an identifier of an associated entity, the first set of data having been associated with the authenticated user data by the associated entity prior to the modification of the modified portion, the authenticated user data including personal information of the unknown user, the method comprising the steps of:

[0151] Provide instructions to one or more trustee systems regarding authenticated user data;

[0152] Receive the first set of data from one or more trustee systems;

[0153] Provide the first set of data to the associated entities; and

[0154] Receive verified user data, including personal information of unknown users, from associated entities.

[0155] 23. The method according to aspect 22, wherein the identifier of the associated entity includes one or more of the following:

[0156] A signature signed using the private key of the associated entity, and optionally, wherein the signature is included in the modified portion; and

[0157] Includes the public key of the associated entity in the verified certificate, and optionally, the public key is included in the unmodified portion of the verified certificate.

[0158] 24. The method according to aspect 22 or aspect 23, wherein the first set of data includes one or more of a token, a database reference, or a serial number.

[0159] 25. The method according to any one of aspects 22 to 24, wherein the modified portion is a re-randomized portion, and wherein the modification is re-randomization.

[0160] 26. The method according to any one of aspects 22 to 25, further comprising at least one of the following steps:

[0161] (i) Publishing personal information of unknown users;

[0162] (ii) Storing personal information of unknown users;

[0163] (iii) Punish the user or bring the user to trial;

[0164] (iv) Select second authenticated user data, which is based on the first authenticated user.

[0165] The data allows for the selection of a second, authenticated user data based on personal information.

[0166] (v) Add the user's personal information to a blacklist;

[0167] 27. The method according to any one of aspects 22 to 26, wherein the association of the first set of data with the verified user data occurs before the encryption of the first set of data.

[0168] 28. The method according to any one of aspects 22 to 27, wherein personal information includes identification information, and the method is a method for identifying an unknown user from authenticated user data.

[0169] 29. A method comprising the following steps:

[0170] The method described in one or more of aspects 1 to 11 and the method described in one or more of aspects 12 to 21; or

[0171] The method described in one or more of aspects 1 to 11 and the method described in one or more of aspects 22 to 28; or

[0172] The methods described in one or more of aspects 12 to 21 and the methods described in one or more of aspects 22 to 28; or

[0173] One or more of the methods in aspects 1 to 11, one or more of the methods in aspects 12 to 21, and one or more of the methods in aspects 22 to 28.

[0174] 30. A computer program product comprising instructions that, when executed, cause one or more processors to perform the method according to any one of aspects 1 to 29.

[0175] 31. A computer-readable medium comprising instructions that, when executed, cause one or more processors to perform the method according to any one of aspects 1 to 29.

[0176] 32. A processor configured to perform the method according to one of aspects 1 to 29.

Claims

1. A computer-implemented method (200) of providing an attested credential to be modified by a user in the generation of authenticated user data, the method comprising the steps of: verifying (SI) user data by an associated entity, wherein the user data comprises personal information of the user; associating (S2) the verified user data with a first set of data by the associated entity, wherein the first set of data comprises one or more of a token, a database reference, a serial number, or a hash of the verified user data; storing, by the associated entity, the association between the first set of data and the verified user data; creating (S3) the attested credential to be modified in the generation of the authenticated user data by the associated entity, wherein the attested credential comprises a modifiable portion containing an indication of the first set of data; and providing (S4) the attested credential for the generation of the authenticated user data by the associated entity, wherein the modifiable portion is re-randomizable such that when re-randomized, the attested credential is no longer associated with the verified user data, wherein the method further comprises the step of encrypting the first set of data using a public key of a trustee system to form an encrypted first set of data, and wherein the encrypted first set of data forms the indication of the first set of data.

2. The method of claim 1, wherein the re-randomizable portion of the created attested credential comprises an identifier of an entity creating the attested credential, and wherein the identifier comprises a signature signed using a private key of the entity.

3. The method of claim 1, further comprising the step of re-randomizing the re- randomizable portion of the attested credential to generate the authenticated user data.

4. The method of claim 1, further comprising the step of storing auxiliary data, wherein the auxiliary data comprises an association between the verified user data and an encrypted version of an indication of the authenticated user data, and wherein the encryption of the encrypted version of the indication of the authenticated user data occurs by using a public key of a trustee system.

5. A computer-implemented method of characterizing an unknown user from authenticated user data, wherein the authenticated user data has been generated by re-randomizing a re-randomizable portion of a validated credential, wherein the authenticated user data includes the re-randomizable portion of the validated credential, the re-randomizable portion including a first set of data that has been encrypted by using a public key of one or more fiduciary systems, wherein the first set of data includes one or more of a token, a database reference, a serial number, or a hash of verified user data, the validated credential and the authenticated user data further including an identifier of an associated entity, the first set of data having been associated with the verified user data by the associated entity prior to re-randomizing the re-randomizable portion, the verified user data including personal information of the unknown user, the method comprising the steps of: providing an indication of the authenticated user data to one or more fiduciary systems; decrypting, by the one or more fiduciary systems, the re-randomized portion using a private key of the one or more fiduciary systems to obtain the first set of data; receiving the first set of data from the one or more fiduciary systems; providing the first set of data to the associated entity; and receiving verified user data from the associated entity, the verified user data including personal information of the unknown user.

6. The method of claim 5, wherein the identifier of the associated entity includes one or more of: a signature signed using a private key of the associated entity, and wherein the signature is included within the re-randomized portion; and a public key of the associated entity included within the validated credential, and wherein the public key is included within an unmodified portion of the validated credential.

7. The method of claim 5, wherein the personal information includes identifying information, and the method is a method of identifying an unknown user from authenticated user data.

8. A computer-readable medium comprising instructions that, when executed, cause one or more processors to perform the method of any one of claims 1-4.

9. A computer-readable medium comprising instructions that, when executed, cause one or more processors to perform the method of any one of claims 5-7.

10. A processor configured to perform the method of any one of claims 1-4.

11. A processor configured to perform the method of any one of claims 5-7. ​

Images