[go: up one dir, main page]

WO2023154783A2 - Vérification d'identité préservant la confidentialité - Google Patents

Vérification d'identité préservant la confidentialité Download PDF

Info

Publication number
WO2023154783A2
WO2023154783A2 PCT/US2023/062264 US2023062264W WO2023154783A2 WO 2023154783 A2 WO2023154783 A2 WO 2023154783A2 US 2023062264 W US2023062264 W US 2023062264W WO 2023154783 A2 WO2023154783 A2 WO 2023154783A2
Authority
WO
WIPO (PCT)
Prior art keywords
identifier
user
community
identity
computing node
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/US2023/062264
Other languages
English (en)
Other versions
WO2023154783A3 (fr
Inventor
Patrick Meehan
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fall Guy dba Fall Guy Consulting LLC
Original Assignee
Fall Guy dba Fall Guy Consulting LLC
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fall Guy dba Fall Guy Consulting LLC filed Critical Fall Guy dba Fall Guy Consulting LLC
Publication of WO2023154783A2 publication Critical patent/WO2023154783A2/fr
Publication of WO2023154783A3 publication Critical patent/WO2023154783A3/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication

Definitions

  • a method for privacy-preserving identity verification includes, at a computing node, receiving, over a computer network, a unique user identifier for a user within an online community, and a community identifier for the online community.
  • An identity profile identifier is computer-generated based at least in part on the unique user identifier, the community identifier, and a nonce identification value.
  • a network-accessible identity profile for the user is computer-generated, the identity profile including one or more verified identity claims for the user, and the identity profile indexed by the identity profile identifier.
  • FIGS. 1A and IB schematically illustrate the use of a privacy-preserving identity verification service to verify identity details for an online community.
  • FIG. 2 illustrates an example method for privacy-preserving identity verification.
  • FIGS. 3A and 3B schematically illustrate a computing node maintaining an identity profile having verified identity claims for a user.
  • FIG. 4 illustrates an example method for privacy-preserving identity verification.
  • FIGS. 5A-5E schematically illustrate operation of three different computing nodes to generate an identity having verified identity claims for a user.
  • FIG. 6 schematically shows an example computing system.
  • an online community e.g., social network, online forum, digital marketplace
  • a user often requires a user to provide various personal identity details, such as their birthdate or nationality, to the online community in order to verify their eligibility for membership.
  • various personal identity details such as their birthdate or nationality
  • the user may not wish to be personally identifiable as a member of any particular community, and may be reluctant to share certain personal details with the community, such as their real name.
  • the present disclosure is directed to computerized techniques for implementing a privacy-preserving identity verification service, which enables generation of an identity profile that can be used to verify selected personal details for a user to an online community.
  • the identity profile is indexed by a unique identity profile identifier, which is derived at least in part from a user identifier for a user within the online community (e.g., a unique username), a community identifier for the online community (e.g., a website address), and a nonce identification value (e.g., cryptographically random value generated by the verification service).
  • the identity profile includes identity claims that have been verified by the verification service, and that a user has chosen to share with a particular online community.
  • the design of the verification service is such that no particular party within the service has enough information about the user to tie them back to any particular online community, as will be described in more detail below.
  • the techniques described herein beneficially enable the user to limit access to their identity profile by controlling who has access to the three components of the identity profile identifier - specifically, the user identifier, community identifier, and nonce identification value.
  • the user can choose to publish the nonce identification value on their user account page within the online community.
  • other members of the community can combine the user’s identifier, the community identifier, and the nonce identification value to recreate the identity profile identifier for the user’s identity profile, allowing them to find the profile and review the user’s verified identity claims.
  • FIG. 1A shows an example website corresponding to an online community 100, which in this non-limiting example is called “Festive Holiday Hats.”
  • an “online community” can refer to an online forum, social network, communication/messaging platform, digital marketplace, online gaming platform, online educational service, and/or any other suitable online platform or service that enables user(s) to create accounts, e.g., for the purpose of communication and/or collaboration.
  • a user e.g., “Alice”
  • the user account is associated with a user identifier 104 for Alice (e.g., “HappyHatter27”), and a verification number 106.
  • Alice e.g., “HappyHatter27”
  • Verification number 106 is an example of a nonce identification value as introduced above.
  • the nonce identification value is a cryptographically random value (e.g., a cryptographic salt generated by the identity verification service) having any suitable length, although in general the nonce identification value may take any suitable form.
  • the nonce identification value is randomly generated by the identity verification service (e.g., generated by a computing node as will be described in more detail below).
  • the nonce identification value is provided by the user.
  • the nonce identification value beneficially serves two purposes.
  • the nonce identification value in some cases introduces an element of randomness sufficient to make a brute force attack against the profile identifier infeasible - e.g., even if the user identifier and community identifier are known, the attacker would still have to guess the nonce identification value.
  • the identity profile is accessible via an identity profile identifier, which is derived from the user identifier (e.g., “HappyHatter27”), the online community identifier (e.g., www.festiveholidayhats. example), and a nonce identification value (e.g., verification number 106).
  • an identity profile identifier which is derived from the user identifier (e.g., “HappyHatter27”), the online community identifier (e.g., www.festiveholidayhats. example), and a nonce identification value (e.g., verification number 106).
  • the community identifier takes the form of a website address, although it will be understood that this is non-limiting.
  • the “community identifier” takes the form of any suitable sequence of characters that is used to uniquely identify an online community.
  • the community identifier is an informal name used by members of the community to refer to the community as a whole, rather than a website address.
  • FIG. IB shows a different example website for an identity verification service 108, having the non-limiting name “GamerCert.”
  • the verification service includes an identity profile 110 created for Alice, as will be described in more detail below.
  • the identity profile is indexed by an identity profile identifier 112, and includes a plurality of verified identity claims 114 for the user.
  • the verified identity claims specify that Alice was bom in July and is a United States citizen.
  • the identity profile can include any number and variety of verified identity details for a user, such as the user’s name, citizenship, address, current location, financial information, health information, etc.
  • FIGS. 1 A and IB beneficially requires no integration between the online community website and the identity verification service.
  • the user may post their nonce identification value on any website allowing them to add arbitrary text to a “profile” or “about me” section.
  • the online community website supports direct integration with the online verification service.
  • the online community website may include a specific option for the user to provide their nonce identification value, which in some cases is publicly visible on the user’s account page.
  • the online community website includes functionality for automatically deriving the user’s identity profile identifier, accessing the identity verification service (e.g., via an application programming interface of the verification service), parsing any verified identity claims included in the user’s identity profile, and adding such claims to the user’s profile in the online community. Additionally, or alternatively, either or both of the online community and identity profile may refrain from publishing the user’s identity claims themselves, but rather may include an indication that whatever information the user has provided has been verified as accurate and/or is compliant with respect to one or more criteria (e.g., user is verified as being above minimum age without listing the user’s age).
  • FIG. 2 illustrates an example method 200 for privacy-preserving identity verification.
  • Method 200 may be performed by any suitable computing system of one or more computing devices.
  • a computing device implementing steps of method 200 may have any suitable capabilities, form factor, and hardware configuration.
  • steps of method 200 are described herein as being performed by a “computing node.” In some examples, this takes the form of a discrete physical computing device, such as a server computer. In other examples, however, a “computing node” takes the form of a virtual machine or other suitable virtual instance, such that a single physical computing device can independently implement multiple different computing nodes.
  • method 200 is implemented by computing system 600 described below with respect to FIG. 6.
  • method 200 includes, at a computing node, receiving, over a computer network, a unique user identifier for a user within an online community, and a community identifier for the online community. This may be done substantially as described above with respect to FIGS. 1 A and IB - e.g., a user provides their unique user identifier (e.g., website username) and the community identifier (e.g., website address) for the online community. In some examples, these are provided by the user directly to the verification service over a computer network - e.g., by entering the user identifier and community identifier into a graphical interface provided by the verification service. This beneficially requires no integration between the verification service and the online community’s website.
  • a unique user identifier e.g., website username
  • the community identifier e.g., website address
  • method 200 includes computer-generating an identity profile identifier based at least in part on the unique user identifier, the community identifier, and a nonce identification value.
  • FIG. 3A shows an example computing node 300.
  • computing node 300 takes the form of any suitable physical computing device or virtualized software instance (e.g., virtual machine).
  • a “computing node” as described herein is implemented as computing system 600 described below with respect to FIG. 6.
  • the computing node has received a unique user identifier 302, a community identifier 304, and a nonce identification value 306.
  • a unique user identifier 302 may be received from any suitable source - e.g., received over a computer network (such as the Internet) from a user computing device.
  • the unique user identifier, community identifier, and nonce identification value are received via a computer network 301.
  • the nonce identification value is generated by the computing node (e.g., a randomly generated cryptographic string). In other examples, the nonce identification value is specified and provided by the user.
  • the computing node Based on the unique user identifier, the community identifier, and the nonce identification value, the computing node generates an identity profile identifier 308, which will be used to index an identity profile provisioned for the user.
  • the identity profile identifier is generated in any suitable way, provided that it is consistently replicable (e.g., to enable users of an online community to consistently recreate the identity profile identifier based on its three substituent components).
  • the identity profile identifier is generated by concatenating and hashing the unique user identifier, the community identifier, and the nonce identification value via a suitable hashing algorithm (e.g., MD5 hashing).
  • the identity profile identifier 308 may be saved in any suitable format compatible with its generation approach, e.g., an integer data structure.
  • the identity verification service after generating the identity profile identifier, deletes the unique user identifier, the community identifier, and the nonce identification value, while storing the identity profile identifier. This enables unique profile identifiers to be generated based on the user identifier and community identifier, while making it infeasible to recreate the user identifier or community identifier from the profile identifier.
  • the computing node After generating the identity profile identifier, the computing node in some cases checks for collisions against identifiers used for other identity profiles. In the unlikely event that a collision is detected, a different profile identifier can be generated based on a new nonce identification value.
  • method 200 includes computer-generating a network-accessible identity profile for the user, the identity profile including one or more verified identity claims for the user, and the identity profile indexed by the identity profile identifier.
  • identity profile including one or more verified identity claims for the user
  • identity profile indexed by the identity profile identifier This is schematically illustrated with respect to FIG. 3B, again showing computing node 300.
  • the computing node has generated an identity profile 310 for the user, which is indexed by the identity profile identifier 308 generated as described above.
  • the identity profile additionally includes a plurality of verified identity claims 312 for the user.
  • the verified identity claims are verified against a plurality of verified identity details stored in a secured user account for the user, where the secured user account is maintained by a second computing node.
  • a second computing node 314 maintains a secured user account 316, which in turn includes a number of verified identity details 318 for the user.
  • Separating information between different computing nodes in this manner can beneficially serve to preserve user privacy - e.g., no single computing node has enough information to associate a specific user identity with the online communities that they have joined. More specific details regarding how the identity profile is generated, as well as how the user’s identity claims are verified, will be described below with respect to FIGS. 4 and 5A-5E.
  • FIG. 4 illustrates another example method 400 for privacypreserving identity verification.
  • method 400 may be performed by any suitable computing system of one or more computing devices. Any computing device implementing steps of method 400 may have any suitable capabilities, form factor, and hardware configuration. In some examples, method 400 is implemented by computing system 600 described below with respect to FIG. 6.
  • steps of method 400 are described as being distributed between three different computing nodes controlled by three different parties. It will be understood that this is non-limiting, and that in other examples, the steps described herein are performed by another suitable number of computing nodes. In general, distributing steps of method 400 between different computing nodes controlled by different parties as described herein beneficially prevents any single party within the identity verification service from having enough unencrypted information to associate the true identity of a user (e.g., Alice), with a specific online community (e.g., Festive Holiday Hats).
  • a user e.g., Alice
  • a specific online community e.g., Festive Holiday Hats
  • the first computing node, the second computing node, and the third computing node are separate server computing devices. In other examples, however, any or all of the computing nodes are implemented as virtual machines. [0032] Furthermore, it will be understood that the various records, identifiers, receipts, and other types of data described herein may be combined or packaged in any suitable way. With particular respect to FIGS. 5 A-5E, the various types of data transmitted to and/or between the various computing nodes may be divided into any suitable number of different data packets, frames, and/or discrete data structures.
  • a computing node may be combined into a single data structure, and/or split into two or more different data structures.
  • each of the identifiers and/or other computer data/information described herein may be represented and/or saved using any suitable data structure(s).
  • method 400 includes, at a first computing node, maintaining a secured user account including a cryptographic salt and a plurality of verified identity details for a user.
  • a “secured” user account is distinct from an identity profile as discussed above, in that an identity profile is created for a specific online community and is intended to be accessible to members of that community - e.g., to verify the identity claims that the user has chosen to share.
  • a user may in some examples create a number of different identity profiles corresponding to different online communities.
  • the user is restricted from creating more than one secured user account with the identity verification service, and the secured user account is typically not intended for sharing with others.
  • FIG. 5A schematically shows an example computing node 500.
  • Computing node 500 is sometimes referred to herein as a “first computing node.”
  • computing node 500 includes a cryptographic salt 504 generated for the user.
  • the cryptographic salt is a random string generated by the first computing node.
  • the cryptographic salt serves as an indication to other computing nodes described herein that a particular user has a unique user account maintained by the first computing node.
  • the cryptographic salt is signed by the first computing node, and the signature is verified when the cryptographic salt is presented to other computing nodes.
  • the cryptographic salt is encrypted using a public encryption key associated with the user - e.g., the public key is one half of a key pair generated by the user on their client device using a password and a slow hashing function.
  • the secured user account additionally includes a plurality of verified identity details 506.
  • verified identity details 506 can include any details used by the verification service to verify the user’s identity - e.g., the user’s name, birthdate, government identification number - and/or any personal details that the user intends to share with an online community as described above (e.g., the user’s age or nationality). It will be understood that the specific identity details included in the secured user account will vary depending on the implementation.
  • identity details are verified by the identity verification service in any suitable way.
  • the plurality of identity details for the user are verified during a live review session via a Know Your Customer (KYC) service.
  • KYC Know Your Customer
  • this may involve manual review by one or more human reviewers at the identity verification service and/or KYC service to verify that the user’s submitted identity details are accurate (e.g., by reviewing government-issued documentation provided by the user).
  • this includes verifying during the live review session that the computing node is not maintaining a preexisting secured user account for the user - e.g., confirming that the user is not attempting to create multiple user accounts with the identity verification service.
  • any identity details verified by the first computing node are signed by the first computing node using a unique cryptographic signature, which can be used downstream by the first computing node and/or other computing nodes in the system to confirm that the identity details have been verified as accurate.
  • the verified identity details are encrypted by the first computing node, and only stored in an encrypted form - e.g., unencrypted versions of the identity details are deleted and not stored. This beneficially ensures that no personally identifying information for the user is stored by the first computing node over time.
  • the user saves the signed and/or encrypted identity details on their client device.
  • the identity verification service may first confirm that any provisional identity claims submitted by the user were signed by the first computing node, thereby verifying that the provisional identity claims are accurate.
  • the secured user account additionally includes a prior community membership record 508 for the user, which includes a prior unique session identifier 510.
  • a prior community membership record 508 for the user which includes a prior unique session identifier 510.
  • these can be used to prevent scenarios where a malicious user attempts to exploit the separation between the different computing nodes to make unauthorized changes to the record of communities that they maintain identity profiles for, and/or create multiple identity profiles for the same online community.
  • method 400 includes, at a second computing node, receiving the cryptographic salt, a unique user identifier for the user within an online community, and a community identifier for the online community.
  • This is schematically illustrated with respect to FIG. 5B, showing cryptographic salt 504, a user identifier 512, and a community identifier 514 being received by a second computing node 516.
  • the second computing node is independent from the first computing node, and therefore unable to associate the information it receives with a specific user identity - e.g., the second computing node cannot associate the user identifier or community identifier with the verified identity details stored in the user’s secured account on the first computing node.
  • the cryptographic salt is in some cases signed by the first computing node.
  • the second computing node can confirm the authenticity of the cryptographic salt, and its origination from the first computing node, by verifying the signature.
  • the information received at the second computing node is anonymously transmitted by the user (e.g., via their personal computing device), and is not transmitted by the online community and/or the first computing node.
  • the user may first decrypt their cryptographic salt prior to transmitting it to the second computing node - e.g., in cases where the cryptographic salt is encrypted via the user’s public key as described above.
  • method 400 includes, at the second computing node, generating an identity profile identifier and an obfuscated community identifier. This is schematically illustrated with respect to FIG. 5B, in which the second computing node generates an identity profile identifier 518 and an obfuscated community identifier 520.
  • the identity profile identifier is generated based at least in part on the unique user identifier, the community identifier, and a nonce identification value as described above with respect to FIGS. 3A and 3B.
  • the obfuscated community identifier is generated based at least in part on the community identifier and the cryptographic salt - e.g., by hashing the cryptographic salt with the community identifier.
  • the cryptographic salt is unique to the user and does not change, the same community identifier will always result in the same obfuscated community identifier being generated, while preventing the original community identifier from being recreated by any party that only knows the obfuscated community identifier.
  • the second computing node signs either or both of the identity profile identifier and the obfuscated community identifier. In this manner, other computing nodes of the identity verification service can verify the second computing node’s signature, and thereby verify that the identity profile identifier and/or obfuscated community identifier are genuine and originate from the second computing node. Furthermore, in some examples, the second computing node generates a symmetric encryption key, which is used to encrypt the identity profile identifier as an encrypted identity profile identifier. In some examples, after being used to encrypt the identity profile identifier, the symmetric encryption key is itself encrypted using the user’s public encryption key and provided to the user.
  • the second computing node generates the identity profile identifier and the obfuscated community identifier as part of a session record having a unique session identifier.
  • This is schematically illustrated in FIG. 5B, in which the identity profile identifier 518 and obfuscated community identifier 520 are included in a session record 522, which includes a unique session identifier 524.
  • this can be used to mitigate the risk that a malicious user attempts to create multiple identity profiles for the same online community.
  • the first computing node may store records of previous sessions for the user, and only produce a verification receipt useable to create or update an identity profile after verifying that a user-submitted community membership record references a most-recent prior session identifier.
  • method 400 includes, at a third computing node, generating a community membership record based at least in part on the obfuscated community identifier and the identity profile identifier.
  • a third computing node 526 receives the identity profile identifier 518 and obfuscated community identifier 520, and generates a community membership record 528.
  • the community membership record includes the identity profile identifier 518 and the obfuscated community identifier 520.
  • the community membership record generated by the third computing node serves as a non-identifying list of the online communities for which the user has created identity profiles. Use of obfuscated community identifiers ensures that neither the third computing node, nor any other parties that receive the community membership record, are able to derive the actual community identifiers for the communities that the user has joined.
  • the identity profile identifier and obfuscated community identifier are transmitted to the third computing node by a user computing device - e.g., rather than transmitted directly by the second computing node - which can serve to preserve user anonymity.
  • the identity profile identifier and obfuscated community identifier are transmitted to the third computing node in another suitable way - e.g., directly by the second computing node.
  • the identity profile identifier is received by the third computing node as an encrypted identity profile identifier - e.g., after encryption by the second computing node using a symmetric encryption key.
  • the community membership record is generated based on the encrypted identity profile identifier.
  • the third computing node receives the identity profile identifier and obfuscated community identifier as part of a session record - e.g., session record 522 as is shown in FIG. 5C.
  • the community membership record includes the unique session identifier - e.g., unique session identifier 524 as shown in FIG. 5C.
  • the community membership record created by the third computing node is the first community membership record created for the user.
  • the user already has an identity profile with the identity verification service, either for the same online community corresponding to the obfuscated community identifier, or a different online community altogether.
  • the third computing node also receives a prior community membership record 508 associated with a prior unique session identifier 510.
  • the prior community membership record is received from the first computing device, which previously received and stored the prior community membership record as is shown in FIG.
  • the first computing node receives the prior community membership record during earlier provisioning of an identity profile corresponding to a different online community.
  • the user may retrieve their prior community membership record from the first computing node, and submit the prior community membership record to the third computing node.
  • the community membership record 528 will be referred to as a “current” community membership record, and in this example, includes “current” unique session identifier 524.
  • the third computing node When a prior community membership record is submitted to the third computing node, the third computing node adds a prior unique session identifier associated with the prior community membership record to the current community membership record being generated. For instance, in FIG. 5C, the current community membership record includes prior unique session identifier 510, in addition to current unique session identifier 524. The third computing node additionally extracts any previous obfuscated community identifiers included in the prior community membership record, and adds them to the current community membership record.
  • the third computing node After generating the community membership record, the third computing node in some examples signs and/or encrypts the community membership record, prior to returning the community membership record to the user. This can help to mitigate the risk that a malicious user tampers with the community membership record to create falsified data.
  • method 400 includes, at the first computing node, receiving the community membership record and one or more provisional identity claims submitted by the user.
  • method 400 includes, at the first computing node, verifying the one or more provisional identity claims against the plurality of verified identity details as one or more verified identity claims. The first computing node then generates a verification receipt corresponding to the one or more verified identity claims.
  • first computing node 500 receives the community membership record 528 and a set of provisional identity claims 530.
  • the first computing node additionally receives the session record 522.
  • the provisional identity claims are verified against the set of verified identity details 506 maintained in the secured user account 502.
  • the provisional identity claims are a subset of the verified identity details, and were stored by the user when the identity details were previously verified by the first computing node.
  • verifying the provisional identity claims may include confirming that the provisional identity claims are signed with a cryptographic signature of the first computing node, thereby confirming that the provisional identity claims were previously verified by the first computing node.
  • the provisional identity claims additionally include an embedded user account identifier, which is verified by the first computing node. The user may beneficially choose to include any selected subset of the verified identity details in the identity profile generated for a particular online community.
  • the user computing device and/or the first computing node may convert the provisional identity claims to use a different format - e.g., when the verification service and/or an online community use a particular format that differs from the format of the provisional identity claims.
  • the first computing node prior to generating the verification receipt, the first computing node confirms that the prior unique session identifier included in the prior community membership record stored by the first computing node matches the prior session identifier included in the current community membership record. For example, in FIG. 5D, the first computing node receives community membership record 528, which includes the prior unique session identifier 510 submitted to the third computing node as is shown in FIG. 5C. First computing node 500 additionally stores prior community membership record 508, also including prior unique session identifier 510.
  • the first computing node confirms that the user submitted the most-recent version of their prior community membership record to the third computing node. This can beneficially mitigate the risk that a malicious user attempts to create a falsified community membership record, or create multiple identity profiles for the same online community.
  • the first computing node Upon receiving the current community membership record and verifying the user’s provisional identity claims, the first computing node generates a verification receipt 532. This is useable by the second computing node to generate an identity profile that includes the verified identity claims.
  • the verification receipt includes the identity profile identifier 518, the verified identity claims 534, and the current unique session identifier 524.
  • the first computing node stores the current community membership record, which will be provided as a prior community membership record the next time that the user attempts to create a new identity profile, or update an existing identity profile.
  • the first computing node stores the current community record provisionally, until receiving a confirmation that the verification receipt was indeed used to create or update an identity profile.
  • method 400 includes, at the second computing node, generating an identity profile based at least in part on the verification receipt.
  • the identity profile includes the one or more verified identity claims, and is indexed by the identity profile identifier.
  • FIG. 5E illustrates the identity profile 516 for the user, the identity profile including the identity profile identifier 518 and the verified identity claims 534. In some cases, this includes updating an earlier version of the identity profile previously generated for an online community, and then deleting the previous version.
  • the second computing node upon successfully provisioning the identity profile, the second computing node then generates and cryptographically signs a confirmation receipt, which is provided to the user.
  • the confirmation receipt By presenting the confirmation receipt to the first computing node, the user confirms that the current community membership record previously presented to the first computing node resulted in an identity profile being created or updated at the second computing node.
  • the first computing node overwrites the provisional status of the current community membership record, and stores it as the most-recent prior community membership record, to be provided to the third computing node whenever the user next attempts to create or update an identity profile.
  • the second computing node in some cases generates an interruption receipt for providing to the first computing node.
  • the first computing node Upon receiving the interruption receipt, the first computing node deletes the provisionally-stored community membership record, allowing the user to restart the identity profile provisioning process from the beginning.
  • the first computing node stores a cryptographic salt for the user, which is provided to the second computing node along with the user identifier and community identifier each time the user provisions an identity profile.
  • the cryptographic salt can be masked using a blinding factor applied with an associative composition function (e.g., XOR). This can beneficially mitigate the risk that a malicious actor that gains access to the second computing node is able to track use of the same cryptographic salt over time, and thereby associate the same salt with multiple different community identifiers.
  • the user makes use of a trusted obfuscation service (OBFS) in obfuscating the cryptographic salt prior to transmission to the second computing node.
  • OBFS trusted obfuscation service
  • the user presents the salt to OBFS, which verifies a cryptographic signature of the first computing node.
  • the OBFS generates a blind, which in some examples is a cryptographically random string having the same length as the cryptographic salt.
  • the OBFS composes the salt and the blind as COMP (salt, blind) and signs the result, also signing the blind independently, and returns the signed components to the user.
  • the user next sends the community identifier and COMP (salt, blind) to the second computing node, which verifies OBFS’s signature on COMP (salt, blind).
  • the second computing node then produces COMP (community identifier, COMP (salt, blind)) and hashes the result.
  • This hashed value is included in the session record generated for provisioning a new identity profile, which is provided to the third computing node as described above.
  • the user additionally provides the blind to the third computing node, along with COMP (community identifier, salt), which the user produces on their client device.
  • the third computing node verifies OBFS’s signature on the blind, and verifies the second computing node’s signature on the session record, and then produces a value COMP (COMP (community identifier, salt), blind), and verifies the result (or its hash) against the value found in the session record.
  • COMP community identifier, salt
  • the third computing node additionally hashes COMP (community identifier, salt), and uses the result as a key in the community membership record to store or update the identity profile identifier.
  • the above process beneficially enables the user to prove to the third computing node that they generated COMP (community, salt) without revealing the salt itself. Without knowing the salt, there is no way for the second or third computing nodes to derive information from the community identifier that could uniquely identify the user. Furthermore, OBFS is not provided with the community identifier, and therefore cannot link the user to any specific online community.
  • Any or all of the herein-described methods and processes may be implemented as an executable application, a network-accessible service, an application-programming interface (API), a library, and/or any other suitable computer resources or combinations of computer resources.
  • API application-programming interface
  • FIG. 6 schematically shows a simplified representation of a computing system 600 configured to perform any or all of the techniques described herein.
  • Computing system 600 may take the form of one or more personal computers, network-accessible server computers, mobile computing devices, mobile communication devices (e.g., smart phone), and/or other computing devices.
  • Computing system 600 includes a logic subsystem 602 and a storage subsystem 604.
  • Computing system 600 may optionally include a display subsystem 606, input subsystem 606, communication subsystem 610, and/or other subsystems not shown in FIG. 6.
  • Logic subsystem 602 includes one or more physical logic devices configured to execute computer instructions.
  • the logic subsystem may include hardware elements configured to execute instructions that are part of one or more software applications or other executable data constructs, and/ or the logic subsystem may include one or more hardware or firmware elements configured to execute hardware or firmware instructions.
  • Processors of the logic subsystem may have any suitable number of cores, and may execute instructions via sequential, parallel, and/or distributed processing.
  • Individual components of the logic subsystem optionally may be distributed among two or more separate devices, which may in some cases be remotely located.
  • aspects of the logic subsystem may be virtualized and executed by remotely-accessible, networked computing devices - e.g., configured in a cloud-computing configuration.
  • Storage subsystem 604 includes one or more physical storage devices configured to temporarily and/or permanently hold computer information - e.g., instructions executable by the logic subsystem, and/or other suitable data. When the storage subsystem includes two or more devices, the devices may be collocated and/or remotely located. Storage subsystem 604 may include volatile, nonvolatile, dynamic, static, read/write, read-only, random-access, sequential-access, location-addressable, file-addressable, and/or content- addressable devices. Storage subsystem 604 may include removable and/or built-in devices. In some cases, execution of instructions by the logic subsystem may change the data stored by the storage subsystem - e.g., to store new data.
  • any or all aspects of logic subsystem 602 and/or storage subsystem 604 may be integrated together into one or more hardware-logic components.
  • Such hardware-logic components may include program- and application-specific integrated circuits (PASIC / ASICs), program- and application-specific standard products (PSSP / ASSPs), system-on-a-chip (SOC), and complex programmable logic devices (CPLDs), for example.
  • PASIC / ASICs program- and application-specific integrated circuits
  • PSSP / ASSPs program- and application-specific standard products
  • SOC system-on-a-chip
  • CPLDs complex programmable logic devices
  • the logic subsystem and the storage subsystem may cooperatively implement one or more logic machines.
  • the term “machine” is used generally to refer to the combination of computer hardware, firmware, software, instructions, and/or any other components that together provide computer functionality. In other words, “machines” are never abstract ideas and always have a tangible form.
  • a machine may be instantiated by a single computing device, or a machine may be distributed between components of two or more different computing devices.
  • a machine may include a local component (e.g., software application executed by a local computer processor) cooperating with a remote component (e.g., a network-accessible service provided by one or more remote computing devices).
  • display subsystem 606 may be used to present a visual representation of any or all data held by storage subsystem 604.
  • the visual representation may take the form of a user interface that presents information to and optionally receives input from a human user.
  • Display subsystem 606 may include one or more display devices utilizing virtually any suitable type of display technology.
  • input subsystem 608 may comprise or interface with one or more input devices.
  • Input devices may include user input devices and/or sensor input devices.
  • Non-limiting examples of user input devices may include a keyboard, mouse, or touch screen.
  • Input devices of the input subsystem may include integrated devices and/or peripheral devices.
  • communication subsystem 610 may be configured to communicatively couple any or all components of computing system 600 with one or more other computer components - e.g., corresponding to other computing devices.
  • Communication subsystem 610 may include wired and/or wireless communication devices compatible with any suitable data communication protocols.
  • the communication subsystem may be configured for communication via personal-, local- and/or wide-area networks.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Storage Device Security (AREA)

Abstract

Un procédé de vérification d'identité préservant la confidentialité comprend, au niveau d'un nœud informatique, la réception, sur un réseau informatique, d'un identifiant utilisateur unique pour un utilisateur dans une communauté en ligne, et d'un identifiant de communauté pour la communauté en ligne. Un identifiant de profil d'identité est généré par ordinateur sur la base, au moins en partie, de l'identifiant utilisateur unique, de l'identifiant de communauté et d'une valeur d'identification de nonce. Un profil d'identité accessible par réseau pour l'utilisateur est généré par ordinateur, le profil d'identité comprenant une ou plusieurs revendications d'identité vérifiées pour l'utilisateur, et le profil d'identité indexé par l'identifiant de profil d'identité.
PCT/US2023/062264 2022-02-10 2023-02-09 Vérification d'identité préservant la confidentialité Ceased WO2023154783A2 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US202263267836P 2022-02-10 2022-02-10
US63/267,836 2022-02-10

Publications (2)

Publication Number Publication Date
WO2023154783A2 true WO2023154783A2 (fr) 2023-08-17
WO2023154783A3 WO2023154783A3 (fr) 2023-09-21

Family

ID=87565103

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2023/062264 Ceased WO2023154783A2 (fr) 2022-02-10 2023-02-09 Vérification d'identité préservant la confidentialité

Country Status (1)

Country Link
WO (1) WO2023154783A2 (fr)

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10291587B2 (en) * 2013-06-25 2019-05-14 Nokia Technologies Oy Method and apparatus for anonymous and trustworthy authentication in pervasive social networking
US9172697B1 (en) * 2013-09-16 2015-10-27 Kabam, Inc. Facilitating users to obfuscate user credentials in credential responses for user authentication
US9288217B2 (en) * 2013-12-02 2016-03-15 Airbnb, Inc. Identity and trustworthiness verification using online and offline components
US9672336B1 (en) * 2014-08-29 2017-06-06 ProfileCorrect LLC Security system for verification of user credentials
SG11201803010UA (en) * 2015-10-14 2018-05-30 Cambridge Blockchain Llc Systems and methods for managing digital identities
US10764051B2 (en) * 2017-10-25 2020-09-01 Google Llc Privacy-preserving identity verification

Also Published As

Publication number Publication date
WO2023154783A3 (fr) 2023-09-21

Similar Documents

Publication Publication Date Title
US12058115B2 (en) Systems and methods for Smartkey information management
US8897450B2 (en) System, processing device, computer program and method, to transparently encrypt and store data objects such that owners of the data object and permitted viewers are able to view decrypted data objects after entering user selected passwords
US9635000B1 (en) Blockchain identity management system based on public identities ledger
US20220014367A1 (en) Decentralized computing systems and methods for performing actions using stored private data
US20130305054A1 (en) Truly anonymous cloud key broker
US20250080322A1 (en) Key sharing system, method, program, server device, and terminal device
Soni et al. Blockchain-based user authentication and data-sharing framework for healthcare industries
EP3996328A1 (fr) Certification axée sur chaîne de blocs de communications électroniques itératives
Sharma et al. A two-tier security solution for storing data across public cloud
Agarwal et al. Guarded dual authentication based DRM with resurgence dynamic encryption techniques
US11750380B2 (en) Storing and retrieving user data using joint, non-correlative, irreversible and private indexical expressions
US12506738B2 (en) Privacy-preserving identity verification
US20230254316A1 (en) Privacy-preserving identity verification
WO2023154783A2 (fr) Vérification d'identité préservant la confidentialité
Kiefer et al. Blind password registration for two-server password authenticated key exchange and secret sharing protocols
Kara et al. File system for aircraft maintenance records based on blockchain and IPFS
US20250358104A1 (en) Password sharing system, method, and program, server device, and terminal device
Le et al. BL0K-ME Protocol: A Zero-Knowledge Proof Approach For Message Authentication In E2EE Conversations
Gagged et al. Improved secure dynamic bit standard technique for a private cloud platform to address security challenges
Pedersen et al. Crypton: Zero-knowledge application framework
Helmich et al. Securing End‐To‐End Encrypted File Sharing Services With the Messaging Layer Security Protocol
Schärli Security Assessment of the Sharekey Collaboration App
Akamri et al. Ensuring the Integrity of Cloud Computing Against Account Hijacking Using Blockchain Technology
Li et al. Bilinear‐map accumulator‐based verifiable intersection operations on encrypted data in cloud
Lizardo Secure share of information in web groups

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 23753647

Country of ref document: EP

Kind code of ref document: A2

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 23753647

Country of ref document: EP

Kind code of ref document: A2