| US20180096551A1 | 2018-04-05 | |||
| US20180122006A1 | 2018-05-03 | |||
| US20200007331A1 | 2020-01-02 | |||
| US20200162268A1 | 2020-05-21 | |||
| US10673617B1 | 2020-06-02 | |||
| US20220116218A1 | 2022-04-14 | |||
| US20200133955A1 | 2020-04-30 |
| CLAIMS 1. Systems and methods for the zero-knowledge validation and verification of private Personally-Identifiable Information (PII) for a PII Prover, with the PII being maintained and hosted by a PII Host, without the necessity for either of the PII Host or the PII Prover to disclose such PII with any 3rd parties; the systems and methods comprising a. The concept of a “PII Certificate” per each PII Owner, comprising a set of data items, PII Owner ID Token Hash, public cryptographic keys or material, custom extras and digital signatures without including any derivations of PII in any forms or shapes. b. A PII Host, hosting the PII and acting as a PII Certificate Authority c. A PII Prover with the intention to veify it has access to PII values that are fuzzily-identical to the PII hosted by the PII Host as used by the PII Host at the time of creating the PII Certificate d. A PII Verifier which can be an intermediary to expose certain services to the PII Host and the PII Prover to make the PII verification process possible and to act as a “Root PII Certificate Authority” e. A PII Prover Onboarding process whereby certain acceptance criteria are applied to a PII Prover by the PII Verifier and a PII Host to make this PII verification and validation process only available to approved PII Provers f. A PII Certificate Repository, hosted by the PII Verifier optionally using an immutable ledger like a blockchain g. The concept of PII Certificate Seeds that are generated and rotated by PII Hosts per each PII Certificate (or optionally per some PII Certificates) and are treated as secrets and remain unknown to the PII Verifier and are made provided to approved PII Provers privately either via the PII Verifier or alternatively by an optional Root PII Certificate Seeds Authority h. An optional “Root PII Certificate Seeds Authority” to act as the repository or provider of PII Certificate Seeds to PII Provers. i. A PII Host Onboarding process whereby certain checks and balances are applied to a PII Host organization to be accredited as a PII Host by the PII Verifier j. A PII Certificate Generation step that is executed once for each PII Owner per each PII Certificate refresh cycle by the PII Host without the necessity to acquire the consent or awareness of the PII Owner k. A PII Verification step, performed by a PII Prover, comprising steps to retrieve certain cryptographic parameters belonging to a PII Owner’s PII Certificates from the PII Verifier without the necessity to disclose PII to the PII Verifier nor to the PII Host, which may involve retrieving or reconstructing relevant PII Certificate Seeds from the PII Verifier (or from an optional Root PII Certificate Seeds Authority), facilitating a true/false answer to whether or not the PII-to-Prove owned by the PII Prover is identical to the PII that the PII Host used to generate PII Certificates l. The possibility for a PII Host to privately share data or metadata with a PII Prover without sharing such data with the PII Verifier or any other parties 2. The systems and methods of claim 1 wherein the PII Prover remains able to verify that the PII related to a PII Owner identified by a PII Owner Identifier owned by or provided to the PII Prover are fuzzily-identical to the PII hosted by the PII Host without the PII Verifier maintaining knowledge of any of the PII. 3. The systems and methods of claim 1 wherein the PII Verifier - and/or any party except the PII Prover with the same level of access to the data that the PII Verifier maintains - remains unable to brute force such data by trying all combinations and permutations of all PII values against such data to discover the true original values of the PII hosted by the PII Host. 4. The systems and methods of claim 1 wherein the PII Prover - and/or any party except the PII Verifier with access to the data that the PII Prover is provided with throughout all stages of the proposed systems and methods - remains unable to brute force such data by trying all combinations and permutations of all PII values against such data to discover the true original values of the PII hosted by the PII Host. 5. The systems and methods of claim 1 wherein the PII Host does not have to expose any live/real-time Application Programming Interfaces (APIs) or services to any parties. 6. The systems and methods of claim 1 wherein the PII Prover does not have to expose any live/real-time Application Programming Interfaces (APIs) or services to any parties. 7. The systems and methods of claim 1 wherein the PII Host is empowered to share data related to a PII Owner with a PII Prover without the PII Verifier maintaining knowledge of such data. 8. The systems and methods of claim 1 wherein the PII Prover and PII Host do not need to change their backend back-of-house systems and protocols despite becoming able to validate PII between each other, facilitated by application-level integration of the proposed invention as opposed to a backend-affecting integration. 9. The systems and methods of claim 1 wherein the PII Host and PII Prover do not have to disclose any PII belonging to a PII Owner to any 3rd parties, including but not limited to the PII Verifier. 10. The systems and methods of claim 1 wherein the verification of PII can be established by a PII Host without the necessity to seek consent and permission from PII Owners to share such PII hence facilitating a global comprehensive and inclusive PII validation/verification mechanism for all types of PII irrespective of regulative requirements around privacy and private information sharing. 11. The systems and methods of claim 1 wherein if the PII Host was a payee’s bank and PII Prover was a payer’s bank, it would become possible for the payer’s bank to implement extra payment authorization schemes like Confirmation of Payee or verification of Payees’ name, address and other details, which in return can help prevent payment redirection fraud or wrong-payee errors or anonymous payments in money laundering operations, helping improve compliance for such banks and protection for payers and payees respectively. 12. The systems and methods of claim 1 wherein if the PII Host was a payee’s bank and PII Prover was a payer’s bank, it would become possible for the payer’s bank to enforce Know Your Customer (KYC) requirements to their payees hence making it possible to effectively apply preventive mechanisms for payments made to sanctioned account holders, helping prevent payments to blacklisted payees. 13. The systems and methods of claim 1 wherein if the PII Host was a payee’s bank and PII Prover was a payer’s bank, it would become possible for the payer’s bank to apply Confirmation of Payee or enforce Payee KYC for all types of account identifiers, comprising but not limited to the combination of account numbers or aliases (e.g. PayID (common in Australia)) plus jurisdictional bank branch identifiers like Routing Transit Number (common in the US), Bank State Branch (common in Australia), Sort Code (Common in the UK) or International Bank Account Identifiers (IBAN) or account or bank identification systems like Swift or cryptocurrency wallet identifiers. 14. The systems and methods of claim 1 wherein the PII Host is empowered to privately share any desired private data or metadata, not belonging to an individual to require consent for sharing, directly to a PII Prover without any other parties, inclusive of PII Prover, maintaining knowledge over such data and without the PII Host requiring to expose any real-time/live Application Programming Interface (API) or other applicable services to the PII Verifier nor to the PII Prover to achieve this purpose. 15. The systems and methods of claim 1 wherein if the PII Host was a payee’s bank and PII Prover was a payer’s bank, it would become possible for the payer’s bank to gain access to a private metric belonging to a bank account that can help prevent specific types of payment fraud with examples comprising but not limited to an ‘Account Trust Index’ which is calculated by the payer’s bank from a set of criteria like how frequently the payee’s account is used, how long the payee’s account has been open, how active it has been and how the payee’s credit history scores, as a result of which, providing a method of determining how trustable a payee’s account is to a payer’s bank and to a payer. 16. The systems and methods of claim 1 wherein only a legitimate PII Host remains capable of participating in the process of creating PII Certificates. 17. The systems and methods of claim 1 wherein PII validation is performed with case insensitivity to ensure flexibility in such validations. 18. The systems and methods of claim 1 wherein the validation of first name, middle name, surname or phrases that can be abbreviated is performed with multiple permutations and combinations of such phrases to enable a fuzzy and flexible validation of such values. 19. The systems and methods of claim 1 wherein PII Certificate signing keys can be rotated to improve security. 20. The systems and methods of claim 1 wherein PII Certificate Seeds can be rotated to improve security. 21. The systems and methods of claim 1 wherein the PII Verifier is empowered to apply granular controls on which PII items they can make verifiable for PII Provers. 22. The systems and methods of claim 1 wherein the PII Host is empowered to apply granular controls on which PII items they make verifiable for which PII Provers. 23. The systems and methods of claim 1 wherein the PII Verifier can use any other alternate Zero-Knowledge Password Proof or Password-Authenticated Key Exchange algorithms to facilitate the verification of PII items between PII Hosts and PII Provers without the typical issue of PII Verifier’s ability to brute force PII values using the data that it has access to. 24. The systems and methods of claim 1 wherein through any applicable Application Programming Interfaces (APIs) like Open Banking, PII Owners can initiate the process to generate PII Certificates on their own terms without the in-take and adoption of the proposed systems and methods by their respective PII Hosts. 25. The systems and methods of claim 1 wherein the PII Prover can be a client-side application to facilitate the verification of PII hosted by a known PII Host. |
| AMENDED CLAIMS received by the International Bureau on 06 September 2023 (06.09.2023) CLAIMS 1. Systems and methods for the zero-knowledge validation and verification of private Personally-ldentifiable Information ( PII) for PII Prover with the Pll being maintained and hosted by a Pll Host, without the necessity for either of the Pll Host or the Pll Prover to disclose such Pll with any 3rd parties; the systems and methods comprising a. The concept of a “Pll Certificate” per each Pll Owner, comprising a set of data items, Pll Owner ID Token Hash, public cryptographic keys or material, custom extras and digital signatures without including any derivations of Pll in any forms or shapes. b. A Pll Host, hosting the Pll and acting as a Pll Certificate Authority c. A Pll Prover with the intention to veify it has access to Pll values that are fuzzily-identical to the Pll hosted by the Pll Host as used by the Pll Host at the time of creating the Pll Certificate d. A Pll Verifier which can be an intermediary to expose certain services to the Pll Host and the Pll Prover to make the Pll verification process possible and to act as a “Root Pll Certificate Authority” e. A Pll Prover Onboarding process whereby certain acceptance criteria are applied to a Pll Prover by the Pll Verifier and a Pll Host to make this Pll verification and validation process only available to approved Pll Provers f. A Pll Certificate Repository, hosted by the Pll Verifier optionally using an immutable ledger like a blockchain g. The concept of Pll Certificate Seeds that are generated and rotated by Pll Hosts per each Pll Certificate (or optionally per some Pll Certificates) and are treated as secrets and remain unknown to the Pll Verifier and are made provided to approved Pll Provers privately either via the Pll Verifier or alternatively by an optional Root Pll Certificate Seeds Authority h. An optional “Root Pll Certificate Seeds Authority” to act as the repository or provider of Pll Certificate Seeds to Pll Provers. i. A Pll Host Onboarding process whereby certain checks and balances are applied to a Pll Host organization to be accredited as a Pll Host by the Pll Verifier j. A Pll Certificate Generation step that is executed once for each Pll Owner per each Pll Certificate refresh cycle by the Pll Host without the necessity to acquire the consent or awareness of the Pll Owner k. A Pll Verification step, performed by a Pll Prover, comprising steps to retrieve certain cryptographic parameters belonging to a Pll Owner’s Pll Certificates from the Pll Verifier without the necessity to disclose Pll to the Pll Verifier nor to the Pll Host, which may involve retrieving or reconstructing relevant Pll Certificate Seeds from the Pll Verifier (or from an optional Root Pll Certificate Seeds Authority), facilitating a true/false answer to whether or not the Pll-to-Prove owned by the Pll Prover is identical to the Pll that the Pll Host used to generate Pll Certificates I. The possibility for a Pll Host to privately share data or metadata with a Pll Prover without sharing such data with the Pll Verifier or any other parties 2. The systems and methods of claim 1 wherein the Pll Prover remains able to verify that the Pll related to a Pll Owner identified by a Pll Owner Identifier owned by or provided to the Pll Prover are fuzzily-identical to the Pll hosted by the Pll Host without the Pll Verifier maintaining knowledge of any of the Pll. 3. The systems and methods of claim 1 wherein the Pll Verifier - and/or any party with the same level of access to the data that the Pll Verifier maintains (in certain embodiments, any such parties except the Pll Prover) - remains unable to brute force such data by trying all combinations and permutations of all Pll values against such data to discover the true original values of the Pll hosted by the Pll Host. 4. The systems and methods of claim 1 wherein the Pll Prover - and/or any party with access to the data that the P ll Prover is provided with throughout all stages of the proposed systems and methods (in certain embodiments, any such parties except the Pll Verifier) - remains unable to brute force such data by trying all combinations and permutations of all Pll values against such data to discover the true original values of the Pll hosted by the Pll Host. 5. The systems and methods of claim 1 wherein the Pll Host does not have to expose any live/real-time Application Programming Interfaces (APIs) or services to any parties. 6. The systems and methods of claim 1 wherein the Pll Prover does not have to expose any live/real-time Application Programming Interfaces (APIs) or services to any parties. 7. The systems and methods of claim 1 wherein the Pll Host is empowered to share data related to a Pll Owner with a Pll Prover without the Pll Verifier maintaining knowledge of such data. 8. The systems and methods of claim 1 wherein the Pll Prover and Pll Host do not need to change their backend back-of-house systems and protocols despite becoming able to validate Pll between each other, facilitated by application-level integration of the proposed invention as opposed to a backend-affecting integration. 9. The systems and methods of claim 1 wherein the Pll Host and Pll Prover do not have to disclose any Pll belonging to a Pll Owner to any 3rd parties, including but not limited to the Pll Verifier. 10. The systems and methods of claim 1 wherein the verification of Pll can be established by a Pll Host without the necessity to seek consent and permission from Pll Owners to share such Pll hence facilitating a global comprehensive and inclusive Pll validation/verification mechanism for all types of Pll irrespective of regulative requirements around privacy and private information sharing. 11. The systems and methods of claim 1 wherein if the Pll Host was a payee’s bank and Pll Prover was a payer’s bank, it would become possible for the payer’s bank to implement extra payment authorization schemes like Confirmation of Payee or verification of Payees’ name, address and other details, which in return can help prevent payment redirection fraud or wrong-payee errors or anonymous payments in money laundering operations, helping improve compliance for such banks and protection for payers and payees respectively. 12. The systems and methods of claim 1 wherein if the Pll Host was a payee’s bank and Pll Prover was a payer’s bank, it would become possible for the payer’s bank to enforce Know Your Customer (KYC) requirements to their payees hence making it possible to effectively apply preventive mechanisms for payments made to sanctioned account holders, helping prevent payments to blacklisted payees. 13. The systems and methods of claim 1 wherein if the Pll Host was a payee’s bank and Pll Prover was a payer’s bank, it would become possible for the payer’s bank to apply Confirmation of Payee or enforce Payee KYC for all types of account identifiers, comprising but not limited to the combination of account numbers or aliases (e.g. PaylD (common in Australia)) plus jurisdictional bank branch identifiers like Routing Transit Number (common in the US), Bank State Branch (common in Australia), Sort Code (Common in the UK) or International Bank Account Identifiers (IBAN) or account or bank identification systems like Swift or cryptocurrency wallet identifiers. 14. The systems and methods of claim 1 wherein the Pll Host is empowered to privately share any desired private data or metadata, not belonging to an individual to require consent for sharing, directly to a Pll Prover without any other parties, inclusive of Pll Prover, maintaining knowledge over such data and without the Pll Host requiring to expose any real-time/live Application Programming Interface (API) or other applicable services to the Pll Verifier nor to the Pll Prover to achieve this purpose. 15. The systems and methods of claim 1 wherein if the Pll Host was a payee’s bank and Pll Prover was a payer’s bank, it would become possible for the payer’s bank to gain access to a private metric belonging to a bank account that can help prevent specific types of payment fraud with examples comprising but not limited to an ‘Account Trust Index’ which is calculated by the payer’s bank from a set of criteria like how frequently the payee’s account is used, how long the payee’s account has been open, how active it has been and how the payee’s credit history scores, as a result of which, providing a method of determining how trustable a payee’s account is to a payer’s bank and to a payer. 16. The systems and methods of claim 1 wherein only a legitimate Pll Host remains capable of participating in the process of creating Pll Certificates. 17. The systems and methods of claim 1 wherein Pll validation is performed with case insensitivity to ensure flexibility in such validations. 18. The systems and methods of claim 1 wherein the validation of first name, middle name, surname or phrases that can be abbreviated is performed with multiple permutations and combinations of such phrases to enable a fuzzy and flexible validation of such values. 19. The systems and methods of claim 1 wherein Pll Certificate signing keys can be rotated to improve security. 20. The systems and methods of claim 1 wherein Pll Certificate Seeds can be rotated to improve security. 21. The systems and methods of claim 1 wherein the Pll Verifier is empowered to apply granular controls on which Pll items they can make verifiable for Pll Provers. 22. The systems and methods of claim 1 wherein the Pll Host is empowered to apply granular controls on which Pll items they make verifiable for which Pll Provers. 23. The systems and methods of claim 1 wherein the Pll Verifier can use any other alternate Zero-Knowledge Password Proof or Password-Authenticated Key Exchange algorithms to facilitate the verification of Pll items between Pll Hosts and Pll Provers without the typical issue of Pll Verifier’s ability to brute force Pll values using the data that it has access to. 24. The systems and methods of claim 1 wherein through any applicable Application Programming Interfaces (APIs) like Open Banking, Pll Owners can initiate the process to generate Pll Certificates on their own terms without the in-take and adoption of the proposed systems and methods by their respective Pll Hosts. 25. The systems and methods of claim 1 wherein the Pll Prover can be a client-side application to facilitate the verification of Pll hosted by a known Pll Host. |
DESCRIPTION OF THE DRAWINGS Figure 1 demonstrates a high-level view of the steps taken in the proposed systems and methods of zero-knowledge PII verification between a PII Host and a PII Prover through a PII Verifier. Figure 2-1 demonstrates the onboarding of a PII Host on the PII verification program proposed by this invention. Figure 2-2 demonstrates the onboarding of a PII Prover on the PII verification program proposed by this invention. Figure 3 demonstrates the high-level steps to create a PII Host Certificate, which acts as a PII Certificate Authority Certificate. Figure 4-1 demonstrates the high-level building block steps to create a PII Certificate. Figure 4-2 demonstrates the steps to create PII Certificate Seeds per each certificate & encrypt-broadcasting them via the PII Verifier. Figure 4-3 demonstrates the steps to create PII Certificate Seeds per some certificates & encrypt-broadcasting them via the PII Verifier Figure 4-4 demonstrates the steps to create PII Certificate Seeds and distributing them to PII Provers via a Root PII Certificate Seeds Authority. Figure 4-5 demonstrates one embodiment of the steps to create PII Certificates by PII Hosts. Figure 5-1 demonstrates the steps to generate a PII Verification Initiation Request by referring to a PII Verifier to look up PII Certificate Seeds Figure 5-2 demonstrates the steps to generate a PII Verification Initiation Request by referring to a Root PII Certificate Seeds Authority to look up PII Certificate Seeds Figure 5-3 demonstrates the steps to verify PII items after generating a PII Verification Initiation Request Figure 6-1 demonstrates the steps to turn any Zero-Knowledge Password Proof or Password Authenticated Key Exchange into a Zero-Knowledge Inter-Organizational PII Verification Algorithm to generate PII Certificates without offline brute forcing vulnerabilities. Figure 6-2 demonstrates the steps to turn any Zero-Knowledge Password Proof or Password Authenticated Key Exchange into a Zero-Knowledge Inter-Organizational PII Verification Algorithm to verify PII without offline brute forcing vulnerability via reliance on a Root PII Certificate Seeds Authority.
DETAILED DESCRIPTION OF INVENTION The inventor hereby proposes novel systems and methods for the validation and verification of personally-identifiable information (PII) between a party hosting such PII, PII Host, and a party trying to verify a set of PII they have access to, PII Prover, via just interacting with a PII Verifier without any of the PII being disclosed to any party, not even with the PII Verifier, and without the PII Verifier and PII Prover remaining capable of brute forcing the information they have access to in order to discover such PII. Referring to Figure 1, a high-level view of the steps taken in the proposed systems and methods can be viewed. The foundations of the proposed systems and methods that facilitate the critical claims of this invention are that a) instead of sharing PII values, a PII Host is given an option to generate a range of easily-and-freely-sharable cryptographic constructs, PII Certificates, and share them with a PII Verifier, b) verifying the PII for the PII Verifier remains dependent upon a range of PII Certificate Seeds that the PII Verifier maintains no knowledge of hence preventing the PII Verifier from a possibility of brute forcing the PII Certificates, c) when trying to verify PII values, the information passed to a PII Verifier maintains no derivations of the PII in any form or shape hence the PII Verifier remains unable to brute force the data it maintains or receives throughout the process, and d) the verification of PII by the PII Prover remains dependent upon the PII Certificates that are only available to the PII Verifier hence preventing the PII Prover from being able to brute force the data available to them and to derive back the original valid PII values such data. These four foundations facilitate critical attributes that make all the unique claims of this invention possible. PII Certificates are cryptographic constructs which are predominantly a range of digitally-signed public keys or public cryptographic material generated based upon the PII values that a PII Host has access to in its records, as a source of truth. These certificates do not include any derivations of the PII in any form or shape which makes sharing them a possibility since by owning such certificates, as per their detailed design, no party remains capable of deriving bac or generating the original PII values, nor remains capable of brute forcing them to re-build the original PII from the certificates. In other words, with the proposed design of the PII Certificates, they can be easily shared with a PII Verifier without fears of breaching privacy and information security and information sharing regulations or requiring the consent of PII owners hence facilitating claims 2, 9 and 10. The public key infrastructure (PKI) formed around the PII Verifier, as the root PII Certificate Authority, and the PII Hosts as Certificate Authorities enables a strong authentication mechanism around the creation of PII Certificates in which only authorized and governed PII Hosts remain capable of creating and submitting PII Certificates which facilitates claim 16. Depending on configuration and embodiment, the steps to initialize PII Certificate Seeds at the time of creating PII Certificates or verifying PII can be handled by a Root PII Certificate Seeds Authority instead of the PII Verifier that can bring a range of attributes and benefits as will be discussed in the next chapters. Referring to Figure 1, at the beginning, a PII Verifier 101 goes through an initialization phase where it generates a range of asymmetric PII Verifier Signature Keypairs, the private PVSKpr and the public PVSKpu, and persists both while publicising the public key PVSKpu. At a later point, a PII Host 100 then initiates onboarding with a PII Verifier 101 which after approving the onboarding request 104, allows the PII Host to initiate the creation of a PII Host Certificate which will act as a certificate authority certificate to be used to digitally sign the PII Certificates that the PII Host will be issuing in future. As a response to a signing request, the PII Verifier digitally signs the requested signing request with its own private cryptographic key, PVSK pr , and supplies the signed PII Host Certificate which the PII Host will persist for future use. At a later point, periodically whenever PII items are created or modified or deleted, the PII Host creates or revokes PII Certificates. This involves initializing 109 PII Certificate Seeds either via the PII Verifier or depending on the embodiment, via a Root PII Certificate Seeds Authority, and then using 121 such PII Certificate Seeds and PII item values to generate PII Certificates, with the purpose of such seeds being to make the creation of PII Certificates dependent upon secrets that remain unknown to the PII Verifier. Depending on embodiment, the PII Verifier may persist the initialized seeds or alternatively, when using Root PII Certificate Seeds Authority, may generate and maintain relevant secrets to build seeds upon such secrets 121. Later on, the PII Host publishes PII Certificates 110 through the PII Verifier in a global PII Certificate repository that depending on embodiment can be a private or public repository with or without the use of a private ledger like a blockchain. A PII Prover 103 also onboards 111 to the PII verification program via the PII Verifier which after providing approval, forwards the PII Prover onboarding request 112 to the applicable PII Hosts which may then approve or reject such onboarding request 113. In steps 112 and 113, the PII Verifier and the PII Host may use persisted state to apply access rules on the approval request coming from a PII Prover, which can include what information items a PII Prover will be requesting to verify in future, therefore, the PII Verifier is then empowered to apply granular access control on which PII items PII Provers can verify which helps fulfill claim 21. Depending on which embodiment of the proposed systems and methods are being used, at this point, it may be necessary for the PII Host to publish some PII Certificate Seeds for the newly-approved PII Prover without which PII verification may not become possible for the newly-joined PII Prover which also supports claim 22 in terms or giving control to PII Hosts over which PII Provers they are willing to enable to verify PII items. Later on and following approvals by both PII Verifier and applicable PII Hosts, a PII Prover will then initiate 115 a PII verification process by compiling a PII Verification Initiation Request. Depending on embodiment, such requests can be sent to either the PII Verifier or an optional PII Certificate Seeds Authority, which then in return, calculates and/or supplies 116 a PII Verification Response which will include a set of PII Certificate Seeds. Upon receiving the PII Verification Response, a PII Prover will then calculate and build 117 a PII Verification Request which depending on the embodiment, either includes the hash of the mixture of PII Certificate Seeds and PII-to-Prove item values, or, when using a PII Certificate Seeds Authority, includes the blinded PII-to-Prove item values based on the PII Certificate Seeds, and submits it to the PII Verifier which then calculates 118 a PII Verification Response inclusive of whether or not the PII Prover has access to the same fuzzily-identical PII item values as the PII Host did use when creating the PII Certificates at the time of creating the relevant PII Certificate. Referring to Figure 1, in all the interactions that a PII Host and a PII Prover have with a PII Verifier, they are the initiator of the interaction with a message they send and a response they receive. Hence, while the proposed invention makes it possible for a PII Host to allow others to verify the PII item values that it maintains, it manages to facilitate this goal without any of the PII Host or PII Prover having to play the role of a ‘respondent to incoming requests’. This is equivalent to both PII Host and PII Prover not having to expose any real-time live Application Programming Interfaces (APIs) or any other applicable exposed services to facilitate the goal of the invention, hence fulfilling claim 5 and 6. Referring to Figure 1, in different embodiments, a multi-PII-value-inclusive Certificate can either be created per each PII Owner who can be identified using a PII Owner ID or alternatively, multiple single-PII-value-inclusive Certificates can be created against a single PII Owner. In all communications with the PII Verifier, and in order to refrain from sending any identifying information to 3 rd parties, PII Hosts and PII Provers may use a range of different tokenization schemes against the PII Owner ID and then feed the tokenized PII Owner ID to a cryptographic hash function to generate a PII Owner ID Token Hash, which can, in an irreversible fashion, without revealing any identifiable information to the PII Verifier, identity a PII Owner. These tokenization schemes comprise but are not limited to two-way tokenization techniques like deterministic encryption (DE), format-preserving encryption with FFX (FPE-FFX), one-way tokenization (e.g. using cryptographic hashing), masking, bucketing or replacement. Referring to Figure 1, in different embodiments of the proposed invention, at the time of creating PII Certificates and at the time of verifying PII item values, all PII item values are first turned into lowercase or uppercase versions before being used to generate PII Certificates or being used to verify PII item values to ensure case insensitivity is achieved when verifying PII, facilitating claim 17. Referring to Figure 1, in different embodiments of the proposed invention, PII Hosts are empowered to include multiple PII items, PIIn, and possible combinations and permutations of values for each PII item, PIIn,k, in PII Certificates where n∈ {1,2,…, PII items count} and k ∈ {1,2,…, Count of possible permutations of PII item values for PIIn }. There is an implied reliance on using consistent indexes for PII items in the proposed invention. For example, 1 for ‘full name’, 2 for ‘first name’, 3 for ‘middle name’, 4 for ‘last name’, 6 for ‘full name’, 7 for ‘date of birth’, 8 for ‘Line 1 of Postal Address’, 9 for ‘full account name’ and so forth with this list being open ended to include as many PII items as desired. For example, for a PII item like ‘full account name’ with n=9, depending on the discretion of the PII Host on what values they intend to make verifiable for PII Provers, combinations comprising but not limited to the likes of "First Name || ' ' || Surname”, "First Name || ' ' || Middle Name || ' ' || Surname”or "First Name || ' ' || First Character of Middle Name || '.' || ' ' || Surname” or "First character of First Name || '.' || ' ' || First Character of Middle Name || '.' || ' ' || Surname" or "First Joint Account Holder’s Full Name || ' AND ' || Second Joint Account Holder’s Full Name" or "First Joint Account Holder’s Full Name || ' & ' || Second Joint Account Holder’s Full Name", all in uppercase or lowercase versions, are used to generate PII Certificates where || denotes the string concatenation operator, which leads to the formation of PII 9,1 , PII 9,2 , PII 9,3 , … PII 9,6 . At the time of verifying a given PII item value, if a match is found for any of the combinations and permutations of values for the PII item, a ‘positive match’ is reported back to a PII Prover for that PII item. Either way, in the proposed invention, what the PII Host includes in the generation of PII Certificates must come from validated information that the PII Host intends to make verifiable for PII Provers and the whole proposal focuses on facilitating PII item value checking against what the PII Host has decided to include in the PII Certificates as a source of truth. In other words, the proposed scheme does not focus on authenticity checking of PII item values and it leaves the trust on PII Hosts to include validated PII item values while generating PII Certificates. The inclusion of different combinations and permutations of PII item values facilitates a “controlled level of fuzziness” despite enforcing “character by character identicality” in the PII item values at the time of verification, helping fulfill claims 17 and 18. Referring to Figure 2-1, in one embodiment, the onboarding of a PII Host 200 starts with initiation an onboarding request, or alternatively, with the PII Host responding to an initial request of onboarding created from a PII Verifier. The PII Verifier 201 will then perform a manual or automated or mixed-automated-and-manual qualification process against the PII Host which would then lead to the authorization of the PII Host to embark on the process to complete their onboarding process which includes generating and securely persisting 204 a range of PII Host Account Details, received from the PII Verifier, and generating a PII Host Identity Keypairs Set, used for encryption in some embodiments as {PrPHIDK m , PuPHIDK m } where m ∈ {1,2,…, selected count of PII Host Identity Keypairs} and PrPHIDK m denoting a private key and PuPHIDK m denoting a public key and PRPIDKS host , denoting the public keyset as PRPIDKS host ={ PuPHIDK m } and PrIDKShost denoting the private keyset as PrIDKS host ={ PrPHIDK m }. The type of controls and checks and balances that the PII Verifier may employ when processing an onboarding request from a PII Host comprise but is not limited to domain name verification, business name validation, organizational email validation, business details verification, manual engagement and onboarding of organizations at the right levels and using the relevant organizational units within a PII Host organization. Then the PII Host submits 205 its non- secret account details to the PII Verifier which in return will verify and persist 206 the details in the PII Host’s account. In the next step, the PII Host should approve 207 already- onboarded PII Provers to be allowed to verify the PII hosted by the PII Host which may or may not involve engaging such PII Provers and/or the PII Verifier to get the right information required for the PII Host to allow such PII Provers to join the approved PII Provers that can verify the PII hosted by the PII Host. In different embodiments, depending on which asymmetric encryption algorithms are used different number of keypairs may be generated to support a range of possibilities. For example, to employ the Extended Triple Diffie-Hellman scheme (Moxie Marlinspike, 2016) for key exchange and end-to-end encryption of PII Certificate Seeds between PII Hosts and PII Provers, these keysets can include an identity key, a signed pre-key, and one-time pre-keys. Referring to Figure 2-2, in one embodiment, the process to onboard and approve a PII Prover 220 starts wit the PII Prover initiating 222 their onboarding request and submitting it to the PII Verifier 201. It is obvious that, in certain embodiments like banking, banks can be onboarded as both PII Hosts (for their own customers) and PII Provers (for their payees) hence the same entity may have to go through both onboarding processes as PII Hosts and PII Provers. Once the PII Verifier performs 223 its onboarding qualification checks and balances in a pre-screening and/or vouching step, it then forwards the PII Prover’s onboarding request to all the PII Hosts already onboarded on the PII verification program. Methods for this forwarding comprise but are not limited to sending notifications, emails, or even making such incoming requests available in a software system like a PII Host dashboard. The PII Host then approves 224 the PII Prover’s onboarding request following the relevant steps, checks and balances which may involve communicating back and forth and requesting different documents in an automated or manual process or mixed process. The PII Host then informs 225 the PII Verifier of the approval of the PII Prover which then leads to the PII Verifier updating state and requesting the PII Prover 226 to complete its onboarding which can be done via any application notification mechanisms or methods. Next, the PII Prover generates a PII Prover Identity Keypairs Set, used for encryption in some embodiments, as {PrPHIDKm, PuPHIDKm} where m ∈ {1,2,…, selected count of PII Prover Identity Keypairs} and PrPHIDKm denoting a private key and PuPHIDKm denoting a public key and PRPIDKS PIIProver , denoting the public keyset asPRPIDKS PIIProver ={PuPHIDK m } and PrIDKS PIIProver denoting the private keyset as PrIDKS PIIProver ={PrPHIDK m } and then submits 228 all non-secret necessary account details as well as PRPIDKSP IIProver to the PII Verifier which will then verify and complete the creation of 229 a PII Prover Account for the PII Prover. At a later point, as part of a period operation, which may include PII lifecycle management (e.g. account operations in a bank) which can be triggered whenever PII items are created, modified or deleted, the PII Host, if necessary depending on embodiment, then publishes the relevant PII Certificate Seeds for the newly-approved PII Prover, as will be discussed in next chapters. Referring to Figure 3, in one embodiment, the process to create a PII Host Certificate, which acts as a PII Certificate Authority Certificate, facilitating a mechanism of authenticating PII Certificates’ validity and their issuance by the right party as part of a Public Key Infrastructure (PKI), starts with the PII Host 300 (which acts as a PII Certificate Authority) generating and securely persisting 302 a PII Host Signature Keypair, inclusive of an InternalKeyID, private PHSK pr and public PHSK pu and then generating 303 a Certificate Signing Request (CSR) as {InternalKeyID, PHSK pu , KeyType, KeyLength, Extensions} and then submitting 304 the compiled request to the PII Verifier 301 which also acts as the Root PII Certificate Authority, which will then look up 305 the details of the PII Host from the context of the Certificate Signing Request and then generates 306 a PII Certificate Authority Body, PCACB, as {ID: PII Host ID || InternalKeyID, PublicKey=PHSK pu , ExpiryDate=A date in future} where ‘||’ denotes the string concatenation operator. The PII Verifier then looks up and loads 307 its own private Root PII Verifier Signature Key, PVSK pr and selects a signing algorithm SigningAlgorithm and generates the PII Certificate Authority Certificate Signature, PCACS, as DigitalSignature (Key=PVSK pr ,Data= PCACB) where DigitalSignature is a digital signature function capable of generating digital signatures using asymmetric keypairs. The PII Verifier then generates 308 a PII Host Certificate as {Body=PCACB, Signature=PCACS, Signature Algorithm=SigningAlgorithm} and persists the certificate in the global certificate repository that it makes available to the authorized PII Provers and sends back 309 the PII Host Certificate to the PII Host which it will then persist 310 for future use, especially, when generating PII Certificates and singing such certificates. Referring to Figure 4-1, the building block steps to create PII Certificates start with the PII Host 400 initializing 402 a set of PII Certificate Seeds, S n , where n∈ {1,2,…, PII items count}. In different embodiments, this initialization step can be carried in different ways, as will be described, which may include either generating securely-random values, or alternatively, using a Root PII Certificate Seeds Authority, that will use a Secure 2-party Computation (S2PC) method like an Oblivious Pseudorandom Function (OPRF) to mix- blind the value of PII items with some private secrets at the time of creating PII Certificates and verifying PII item values, helping keep PII values protected from the Root PII Certificate Seeds Authority as well as the PII Verifier. Next steps include the use of such seeds as well as PII values to generate 403 PII Certificates, PCert, submitting 403 PCerts to the PII Verifier 301 which after verifying 405 the signature of such certificates, persists and publishes 406 PCerts in the global PII Certificates repository, which could be privately or publicly operated by any party, including but not limited to the PII Verifier using mechanisms that comprise but are not limited to a private database or private immutable ledgers like a blockchain. The purpose of these PII Certificate Seeds is to make the generation of PII certificates and the verification of PII in the proposed invention dependent upon parameters that the PII Verifier maintains no knowledge of hence preventing the PII Verifier from the possibility to brute force the data it maintains to gain knowledge over the PII, facilitating claim 3. Referring to Figure 4-2, in one embodiment, the process to generate PII Certificate Seeds starts with a PII Host 400 using a secure random generator to generate 420 a random seed Sn with reasonably long length per each PII item, PII n , as S n =SecureRandom() where n∈ {1,2,…, PII items count} and SecureRandom being a secure random number generation function, capable of generating outputs of at least 512 bytes long, hence leaving a huge computationally-infeasible brute-forcing space of 2 512x8 for a possible attacker or adversary when trying to brute force PII Certificates for each PII item value. Then with the goal to ensure that no other party except an approved PII Prover can access Sn, the PII Host then looks up 421 the public PII Prover’s Identity Keypairs Set PRPIDKS i , inclusive of a range of public keys for each approved PII Prover, PIIP roveri . The PII Host then uses 422 PII Host’s own Private Identity Keypairs Set, PrIDKS host , to broadcast each privately encrypted PII Certificate Seed to each PIIProversi by calculating EncryptedS n,i =AsymmetricEncrypt(private keys=PrIDKS host , public keys= PRPIDKS i , data=S n ) and then submitting EncryptedS n,i alongside the PII Owner ID Token Hash to the PII Verifier which it will then persist per each PII Cert per each PII Prover and make available to approved PII Provers, where AsymmetricEncrypt can be any encryption function that operates based on asymmetric keys, comprising but not limited to SymmetricEncrypt(data=S n , symmetric key= KeyDerivation(private keys=PrIDKS host , public keys= PRPIDKS i )) where KeyDerivation comprise but is not limited to any asymmetric key derivation function like the Diffie-Hellman key exchange function whose output is fed to a hash-based key derivation function (HKDF) accordingly as KeyDerivation(private keys=PrIDKS host , public keys= PRPIDKS i )= HKDF(DHKE(private keys=PrIDKS host , public keys= PRPIDKS i )) with DHKE denoting the Diffie-Hellman key exchange. In this step, if there is a need to privately share any data item, D m , related to a PII Owner with a PII Prover where m ∈ {1,2, … , Count of approved data items intended to be privately shared with PII Provers by PII Hosts without being shared with any other parties}, then the PII Host can calculate a privately-encrypted version of such data items as EncryptedD m,i =AsymmetricEncrypt(private keys=PrIDKS host ,public keys= PRPIDKS i , data=D m ) and include {EncryptedD m,i } with its submission to the PII Verifier. As can be obvious, this embodiment involves broadcast-encrypting PII Certificate Seeds for each certificate to each PII Prover and involves a very communication-heavy process and re- encryption of each seed per each PII Prover, resulting in potentially high data storage needs by the PII Prover despite making granular control possible over which PII Provers can be sent the seeds, hence fulfilling claim 22, reflecting the fact that if a PII Host does not submit the encrypted seed to a specific PII Prover, such a PII Prover will not be able to verify any PII. In this embodiment, since the private identity keys belonging to each PII Prover are necessary to be able to decrypt each seed and since such keys are only owned by the approved PII Provers, not the PII Verifier, hence PII Verifier can never maintain knowledge of such seeds, facilitating claims 3. Since a PII Host can, at any time, re- generate all or some of its previously-created PII Certificate Seeds and re-publish them, Claim 20 is also achieved. On the other hand, since extra encrypted data {EncryptedD m,i } can only be decrypted by authorized PII Provers with access to private PrPIDKS i items, the PII Verifier or any other party remain unable to decrypt and access such data, hence facilitating claim 7. Referring to Figure 4-3, in one embodiment and with the goal to reduce the complexity of broadcast-encrypting individual-per-certificate PII Certificate Seeds, alternatively, a PII Host, can choose a configuration parameter, PII Certificate Seeds Count, and then generate 430 a range of secure random PII Certificate Seeds S m =SecureRandom() where m∈ {1,2,…, PII Certificate Seeds Count for the PII Host}. Then for each approved PII Prover PIIProveri, the PII Host will look up 431 the public PII Prover’s Identity Keypairs Set, PRPIDKSi, inclusive of a range of public keys and it will use 432 PII Host’s own Private Identity Keypairs Set, PrIDKS host , to broadcast privately encrypted PII Certificate Seed, S m to each PIIProvers i by calculating EncryptedS m,i =AsymmetricEncrypt(private keys=PrIDKS host , public keys= PRPIDKS i , data=S m ) and then submitting {EncryptedS m,i } alongside the PII Owner ID Token Hash to the PII Verifier, which it will then make available to the approved PII Provers. As a result, in the embodiment, for a lower level of complexity and PII Verifier’s data storage needs, a PII Host chooses a smaller number of seeds, smaller than the number of its total issued PII Certificates, and encrypts and broadcasts them for all its approved PII Provers. Given that still private identity keys owned by PII Provers are required to decrypt the encrypted seeds and with such private keys unknown to the PII Verifier and anyone other than PII Provers, and that the PII Host still remains able to change such seeds and re-broadcast them to all PII Provers after re-generating its PII Certificates using such rotated seeds, claims 3 and 20 are met. Referring to Figure 4-4, in one embodiment and with the goal to reduce the complexity of encrypting and broadcasting PII Certificate Seeds to all PII Provers, a PII Host initiates the process of creating PII Certificate Seeds per each PII Certificate by starting 441 a Secure 2 Party Computation (S2PC) process with a Root PII Certificate Seeds Authority 440, which must be a party other than the PII Verifier. In this embodiment, and given the inherited attributes of S2PC, the Root PII Certificate Seeds Authority and the PII Verifier remain unaware of the initial PII n,k as owned by the PII Host whilst the PII Host maintains no knowledge of the parameters and secrets the Root PII Certificate Seeds Authority uses during the S2PC handshake. To ensure that the PII Verifier remains unable to brute force the data it maintains, it is imperative for the Root PII Certificate Seeds Authority to be a different party than the PII Verifier without having access to the secrets required for the S2PC process to work, helping facilitate claims 2, 3, 4, 9. In one embodiment, as an S2PC scheme, an Oblivious Pseudorandom Function handshake (OPRF) like DH-OPRF (also called 2HashDH) (Jarecki et al., 2014) for each kth value of the n th PII item, PII n,k , is used by calculating Blind(H(PII n,k )) and submitting it to the Root PII Certificate Seeds Authority, which then generates and persists 442 a set of parameters or keys that it requires to run a secure 2-party computation operation, {OK n,p }, where H is a cryptographic hash function of choice, n∈ {1,2,…, PII items count}, k ∈ {1,2,…, Count of possible permutations of PII values}, p ∈ {1,2,…, Count of parameters required by the Root PII Certificate Seed Authority for S2PC handshake for each S n }, Blind is a cryptographic blinding function like the Diffie-Hellman blinding function, DH(x)= x q mod p, where q is a random secret key that needs to be maintained by the PII Host for the next steps of seed generation and p is a very large prime number. As per the characteristics of the discrete log problem, the Root PII Certificate Seeds Authority will remain unaware of the inputs of the blinding function (i.e. of H(PII n,k )). At the next step, the Root PII Certificate Seeds Authority and the PII Host engage 443 in an DH-OPRF handshake, per each PII n,k , and use {OK n,p } and the OPRF function to calculate and return OPRF(Blind(H(PII n,k )),{OK n,p }) where OPRF is a Diffie-Hellman blinding function DH(x)=x y mod p, where y being the secret the Root PII Certificate Seeds Authority has to generate and maintain as part of its S2PC parameters {OK n,p }. In the next step, the PII Host calculates 444 Unblind (OPRF(Blind(H(PII n,k )),{OK n,p })) where Unblind(x) = x 1/q mod p where p is a large prime number and q is a value already selected by and known to the PII Host in step 441. The PII Host then assumes the result of Unblind() as S n,k to generate its PII Certificates using them in next steps. The use of a DH-OPRF function in this embodiment facilitates the mixing of a secret owned by the Root PII Certificate Seeds Authority and the PII items owned by the PII Host to generate a combined seed that can’t be unblinded by the PII Verifier without having access to the secrets Root PII Certificate Seeds Authority maintains, assuring the zero knowledge of PII Verifier against any PII values both at the time of creating PII certificates and at the time of verifying PIIs by PII Provers, helping claims 2 and 9. Referring to Figure 4-5, in one embodiment, the process to generate PII Certificates starts with the PII Host 400 using their private computing zone on their private infrastructure, without sending out any PII item values, generating 450 a Private PII Verification Key for the kth possible combination of values for the n th PII item, PII n,k , as PrPVK n,k . When not using a Root PII Certificate Seeds Authority, PrPVK n,k = H(PII n,k || S n ) where n∈ {1,2, … , PII items count} and k ∈ {1,2, … , Count of possible permutations of each PII n values} and H is a cryptographic hash function of choice and S n is the PII Certificate Seed of PII n , as described in multiple embodiments in previous chapters. When using a Root PII Certificate Seeds Authority, however, the calculated Sn,k as returned by the Root PII Certificate Seeds Authority are used as PrPVK n,k =S n,k since such values are already blinded PII values using the secrets maintained by the Root PII Certificate Seeds Authority. The PII Host then uses 451 PrPVK n,k to generate a Public PII Verification Key PuPVK n,k and then includes the resulting public key to generate 452 the PII Certificate Body PCB={PII Owner ID Token Hash, {PuPVK n,k }, H, Expiry Date, Serial Number, Version, {Optional Extensions}}. Depending on the asymmetric key generation schemes used, the process to generate a public key from the private key may comprise a range of options. For example, when using Diffie–Hellman, PuPVK n,k = g PrPV K n , k m o d p where g is a generator and p is a large prime number. Next, the PII Host will look up 453 the private PII Host Signature Key, PHSK pr , and generates the PII Certificate Signature PIICertSig =DigitalSignature (key=PHSK pr ,data= PCB) where DigitalSignature is an asymmetric digital signature function. The PII Host then generates 454 the PII Certificate as PCert={PCB, PIICertSig, PII Host ID, PII Host Certificate ID}, which is then submitted 455 to the PII Verifier, which after the right verifications, especially around the digital signature of the certificate to authenticate the issuer of the certificate, is published and made available in the global PII Certificates repository by the PII Verifier. It is clear that a PII Certificate is a cryptographic construct inclusive of a range of digitally-signed public keys and metadata that do not include any derivations of the original PII. It is also obvious that due to the obvious characteristics of asymmetric cryptography and the extremely high computational cost of computing a private key from a public key, PII Certificates cannot be used to drill back to the private keys that the PII Host has used to generate such PIIs without paying an extremely high computation cost. Not only that, even if it was possible to brute force a public key against all alternate private keys, since the generation of PrPVK n,k depends upon S n,k which is only known to PII Hosts and PII Provers (not PII Verifier or any attacker that has managed to gain access to the same data that PII Verifier maintains), it remains computationally-infeasible to brute force all possible combinations and permutations of PII item values against the reconstructed private PrPVK n,k for the PII Verifier (or an attacker with its same level of access to data). As a result, critical claims 2,3 and 9 are all met with the proposed design. The fact that PII Certificates are digitally signed by the PII Host and that their digital signature gets checked by the PII Verifier, as part the proposed Public Key Infrastructure, it becomes impossible for an adversary to publish certificates on behalf of an approved PII Host without having access to the private signing key that only an approved PII Host has access to, which facilitates claim 16. Since no PII or any derivations of any PII are exposed to any 3 rd parties as part of creating a PII Certificate, no PII Owner consent is necessary to be acquired by a PII Host to make such PII verifiable for PII Provers, which facilitates claim 10. Referring to Figure 5-1, in one embodiment, the process to initiate the verification of PII by a PII Prover 500 starts by compiling a PII Verification Initiation Request as {PII Host ID, PII Owner ID Token Hash, {n}} where n∈ {indexes of PII-to-Prove items}. The PII Prover then passes the compiled PII Verification Initiation Request to the PII Verifier which hosts the end-to-end encrypted PII Certificate Seeds. For each n, the PII Verifier then looks up 503 the Encrypted PII Certificate Seed relevant to the PII Provider, EncryptedSn,PIIProover , and compiles a PII Verification Initialization Response as {EncryptedSn,PIIProover}. The PII Prover then looks up 504 the Public Identity Keys Set belonging to the PII Host, PPIDKSPIIHost, as well as PII Prover’s own Private Identity Keys Set, PrPIDKSPIIProver, and calculates Sn=AsymmetricDecrypt(private keys=PrPIDKSPIIProver, public keys= PPIDKSPIIHost, data=EncryptedSn,PIIProver). The PII Prover then uses Sn 505 to compile a PII Verification Request as {PII Owner ID Token Hash, {PIIVerificationReqn}} where PIIVerificationReqn = H(Sn || PII-to-Proven) where H denotes the same cryptographic hash function as used by the PII Host at the time of creating the PII Certificate and PII-to-Proven denotes the uppercase or lowercase version of the value of the PIIn item that the PII Prover is trying to verify aligned with which version of PII values have been used by the scheme at the time of generating PII Certificates by PII Hosts. Referring to Figure 5-2, in one embodiment, the process to initiate the verification of PII by a PII Prover 500 starts by initiating a Secure 2 Party Computation (S2PC) Session with a Root PII Certificate Seeds Authority 520 by compiling a PII Verification Initiation Request as {PII Host ID, PII Owner ID Token Hash, {n}, {Blind(H(PII-To-Proven))}} where Blind denotes a cryptographic blinding function of choice as used by the PII Host at the time of creating the certificate, which is included within the certificate as extra metadata and PII-To-Proven is the uppercase or lowercase version of the PII item value to be verified, aligned with which version has been used by the scheme when generating the PII Certificate. Depending on embodiment, a range of S2PC options can be employed comprising but not limited to the use of an Oblivious Pseudorandom Function (OPRF) like the DH-OPRF (Jarecki et al., 2014). The Root PII Certificate Seeds Authority then looks up 522 all previously-generated necessary server-side parameters and keys related to PII n as created by the PII Host for the S2PC handshake, {OK n,p } where p ∈ {1,2,…, Count of parameters required by the Root PII Certificate Seeds Authority for S2PC handshake for each S n }. It then engages 523 in an S2PC handshake per each PIIn, uses {OK n,p } and the OPRF function and returns OPRF(Blind(H(PII-to-Prove n )),{OK n,p }) to the PII Prover which then uses 524 an Unblind function on the returned value to calculate Unblind( OPRF(Blind(H(PII-to-Prove n )),{OK n,p })) and assumes the result as S n . Next, it uses 525 {S n } to compile a PII Verification Request as {PII Owner ID Token Hash, {PIIVerificationReq n }} where PIIVerificationReq n = S n . It is obvious that in this embodiment, the calculated S n value is calculated with a mixture of PII-to-Prove item values as well as secrets maintained by the Root PII Certificate Authority to assure the zero-knowledge of the PII Verifier and the Root PII Certificate Authority from PII-to-Prove item values, as per the specifications of S2PC and OPRF schemes. Referring to Figure 5-3, in one embodiment, following the reception of a PII Verification Initiation Response by a PII Prover 500, the process of verifying PII item values starts with submitting 530 the PII Verification Request compiled in previous steps to the PII Verifier 501 as {PII Owner ID Token Hash, {PIIVerificationReq n }} which then looks up 531 the PII Certificate relevant to the PII Owner ID Token Hash, verify expiry and extract the Public PII Verification Keys, {PuPVK n,k }, from the certificate. Next, the PII Verifier deems 532 each PIIVerificationReqn as a Private PII Verification Key, PrPVK n . Then it generates 533 a Verifier’s Ephemeral Name Verification Keypair VENVK pr , VENVK pu and calculates 534 CHK1 n =DeriveCommonSecret(public key=VENVK pu , private key= PrPVK n ) and CHK2 n,k =DeriveCommonSecret(public key=PuPVK n,k , private key= VENVK pr ) where DeriveCommonSecret is a common secret derivation function using a private and a public key that comprise but is not limited to the Diffie-Hellman key exchange algorithm or any other applicable asymmetric common secret derivation function. For all n and k values, it will then calculate 535 KeyEqualityResultsn = true if CHK2 n,k equals CHK1 n for at least one k, and uses the results to generate 536 a PII Verification Response as {KeyEqualityResults n }. It is obvious that this will be a set of Boolean values indicating if the value of PIIn used to compile the original PII Verification Initiation Request is case- insensitively identical to at least one of the combinations or permutations of possible values that the PII Host assumed for PII n . The PII Prover can then apply results 537 for decision making while deeming PII-to-Prove n is fuzzily-identical to PII n as hosted by the PII Host if V n is true. The principle used in this scheme is that if the passed PIIVerificationReq n is equal to the same PrPVK n that the PII Host created at the time of issuing the PII Certificate, then using any random ephemeral keypair and deriving common secrets using PrPVK n and the public ephemeral key must lead to the derivation of the same secret as using the private ephemeral key and at least one of the PuPVK n ,k items that relate to the right combination or permutation of the PII value hence providing a mechanism of checking identicality of values without actually having a knowledge of the values, facilitating claims 1, 2 and 9. In all embodiments described herein, It is obvious that since S n remains unknown to the PII Verifier and provided that S n is generated with a high-enough length and entropy of at least 512 bytes, by being passed H(S n || PII-to-Prove n ), the PII Verifier remains unable to generate or guess PII-to-Prove n hence supporting claims 2 and 9. The fact that PII Prover is not revealing the value of the PII-at-hand-to-prove and passing a high-entropy hashed version of the PII values using an unknown seed makes it possible for the verification process not to include the disclosure of PII to any 3 rd parties, removing the needs of consent collection from PII Owners, supporting claim 10. The fact that all what a PII Prover receives from the PII Verifier is a random inherently-useless seed, there remains no possibility for the PII Prover to check all possible values of the PII items locally against what they have access to, without having to ask the PII Verifier, which applies applicable use policies against its services, hence preventing a possibility for brute forcing true PII item values using the data that is provided to PII Provers, hence facilitating claim 4. Referring to Figures 4-5 and 5-3, in one embodiment, instead using PrPVK n,k items as a private keys to then generate public keys PuPVK n,k based upon asymmetric keypairs and then including the public keys in the PII Certificate, one can include H(PrPVK n,k ) instead of the public PuPVK n,k items for inclusion in the certificates. At the time of verifying the PII items, instead of using asymmetric key derivation schemes upon an ephemeral keypair, a PII Prover can pass H(PIIVerificationReq n ) instead of PIIVerificationReq n which then should get simply compared with the H(PrPVK n,k ) originally included in the PII Certificate. In principle, all claims stand valid due to the fact that S n items used to generate PrPVK n,k still remain unknown to the PII Verifier, except for the fact that a different checking mechanism is used without using keypairs and secret derivation when verifying PII items. Referring to Figure 6-1, the proposed invention can be embodied in a range of possible configurations and alternatives where instead of using the detailed PII Certificate creation algorithm using asymmetric keypairs or hash functions, as described in previous chapters, one could turn any Zero-Knowledge Password Proof (ZKPP) or Password Authenticated Key Exchange (PAKE) algorithms with some extra layers to achieve the same goals of facilitating a zero-knowledge inter-organizational PII verification mechanism based on PII Certificates. These algorithms can comprise but are not limited to Secure Remote Password (SRP) (Wu, 1998), J-PAKE (Hao and Ryan, 2010), PAK and PPK (Boyko et al., 2000), AuCPace (Haase and Labrique, 2018), OPAQUE (Jarecki et al., 2018) and the like which make it possible for multiple parties to agree upon a common secret by having no knowledge of the common phrase without exchanging the phrase or any derivations of the phrase despite having a vulnerability to offline brute forcing performed by any party that can have access to the data maintained or persisted server- side by such algorithms. To achieve this goal, just like any other embodiment, the process to create PII Certificates starts with initializing PII Certificate Seeds either via the PII Verifier 601 or via the Root PII Certificate Seeds Authority and once such seeds become available to the PII Host 600, then they can be used 602 to blind or mask {PII n }. This can be achieved by calculating either H (S n || PII n ) when receiving {S n } from the PII Verifier, or alternatively, when using a Root PII Certificate Seeds Authority, using {Sn} themselves as ‘passwords’ within these AKPP or PAKE algorithms. In the case of relying upon a Root PII Certificate Seeds Authority, since {S n } are already the results of an S2PC process involving {PII n } and secret keys known to the Root PII Certificate Seeds Authority, {S n } are already blinded versions of the {PII n }. Then the PII Host selects a Zero Knowledge Password Proof (ZKPP) or Password Authenticated Key Exchange (PAKE) algorithm, A, and their parameters {P} and submits a PII Certificate Creation Request as {PII Owner ID Token Hash, A, {P}, {Blinded or Masked PIIn}} to the PII Verifier. Then the PII Verifier creates 603 a PII Certificate entry under PII Owner ID Token Hash in its repository and initializes 604 a ‘sign-up/registration’ handshake using A and {P} and assumes { Blinded or Masked PII n } as secrets (or passwords) to be persisted, and it then generates client-side parameters {CV} and server-side verification parameters {SV}, then persists {SV} and sends back {CV} to complete a sign-up handshake by submitting back {CV} to the PII Host, which will then executes A 605 using {CV} and {Blinded or Masked PII n }, generate interim client-side parameters {CP} and send {CP} to the PII Verifier which it will then use to complete 605 the sign-up/registration handshake and report back the results that the PII Host uses to inform outcomes 606. Irrespective of what algorithm is used to generate the PII Certificates, the type of algorithm and its public parameters can be included in the PII Certificate maintained by the PII Verifier. Since the input PII are blinded or masked by seeds unknown to the PII Verifier and the blinded or masked PII are used as the material that are treated as secrets by the ZKPP or PAKE algorithms, there remains no possibility for the PII Verifier, or any adversary with similar level of access, to brute force the data maintained by the PII Verifier to derive back any of the original PII items values, helping fulfill claims 1,2 and 3 despite using any of such algorithms alternatively. Given that it is one of the attributes of such algorithms to maintain or persist no derivations of secrets (i.e. PII) claim 9 is also fulfilled when using any of such algorithms in the described way. Referring to Figure 6-2, the proposed invention can be embodied in a range of possible configurations and alternatives where instead of using the detailed verification algorithm using asymmetric keypairs, as described in previous chapters, one could turn any Zero-Knowledge Password Proof (ZKPP) or Password Authenticated Key Exchange (PAKE) algorithms with some extra layers into a mechanism of verifying PII between organizations using the concept of PII Certificates on a zero-knowledge basis without the vulnerability of offline brute forcing of the data maintained by the PII Verifier. This process involves the compilation of a PII Verification Initiation Request to create blinded or masked {PII-to-Prove n } as {PIIVerificationReq n } using PII Certificate Seeds that are unknown to the PII Verifier by the PII Prover 620, as described in Figure 5-1 or 5-2, and then submitting 622 the request to the PII Verifier 621. The PII Verifier then Looks up 623 the PII Certificate, verifies its signature, expiry and other relevant details and then starts a PII verification session by extracting A and {P} 624 from the PII certificate, initializing and executing A, assuming {PIIVerificationReq n } is the set of secrets to verify, generating client-side verification parameters {CV} and server-side verification parameters {SV} and sending {CV} through alongside a session id for the verification session to the PII Prover. The PII Verifier then uses 626 the session id to look up {SV} to then verify {IV} using {SV} and to generate the next set of verification parameters {Vv2} which are sent back to the PII Prover. Next, the PII Prover verifies {Vv2} which leads to the verification of whether or not the PII-to-Proven is identical to at least one of the permutations and combinations of PIIn as used by the relevant PII Host at the time of generating the PII Certificates. Referring to Figure 6-1 and Figure 6-2, when treating PII item values like passwords and using any Zero-Knowledge Password Proof (ZKPP) or Password Authenticated Key Exchange (PAKE) algorithms to protect them while verifying them between a PII Host and a PII Prover via a PII Verifier, which acts in the role of the server in such algorithms, whilst all the attributes of such algorithms in protecting PII item values without sharing them are inherited from such algorithms, but also most importantly, a significant shortcoming of such algorithm in this specific space is resolved. All such algorithms leave the possibility open for any party with access to the data that the ‘server’ in such algorithms maintains to brute force such secrets and for low-entropy values like names, addresses, phone numbers and email addresses. Such brute forcing possibility leads to the PII Verifier or anyone with the same level of access as the PII Verifier being able to test each permutation and combination of characters against its own data and determine what the true values of the PII the PII Certificates have been built upon. The proposed invention adds the concept of securely-random PII Certificate Seeds, Sn, which remain unknown to the PII Verifier and by blinding or mixing the value of PII items with such seeds before using the resulting blinded or masked values as ‘passwords’ with such algorithms, the proposed invention, even when utilizing such algorithms, fulfills all claims, especially claims 23, 2, 4 and 9. Referring to Figure 1, in one embodiment, a mobile or web application or any other applicable systems may act on behalf of the PII Host to generate PII Certificates by first receiving PIIs from a true PII Host after receiving consent from PII Owners. This process can normally start by the PII Owner starting to use such mobile or web applications which would then redirect the user to some kind of authentication and authorization and consent collection section of PII Host’s systems where the user can authenticate themselves and following the providing of consent, then such mobile or web apps will then make application programming interface (API) calls to PII Host’s owned exposed services to receive the PII from the PII Host and then start the process of issuing PII Certificates as per the invention. In this embodiment, still, the PII Host will not need to expose APIs to PII Verifiers or PII Provers but will empower an intermediary or 3 rd party to act on its behalf to issue PII Certificates. In this embodiment, the process to digitally sign the generated PII Certificates can be also delegated to the mobile or web application or software system following the onboarding and approval of such applications and systems as approved PII Hosts or PII Certificate Issuers. One example of this embodiment can be incarnated via Open Banking APIs exposed by banks (i.e. PII Hosts) whereby a developer of an open banking enabled system, who can be an authorized 3rd party other than banks, can get access to a PII Owner’s PII and on behalf of the PII Host, they can start issuing PII Certificates for the PII owned by such PII Owners hence fulfilling claim 24. Referring to Figure 1, in one embodiment, a mobile or web application or any other applicable systems may act on behalf of the PII Prover to verify the PII item values by making application programming interface (API) calls to a backend owned and operated by a PII Prover that has been successfully onboarded and approved by the PII Verifier and PII Hosts hence fulfilling claim 25. Referring to Figure 1, in one embodiment where the PII Host is a payee’s bank and the PII Prover is a payer’s bank, the payer’s bank is empowered to request extra fields and values from a payer, as part of a payment process, to then receive PII values from the payer that the payer has received from a payee, to be then checked against the PII values that the payee has provided to their bank where they have an account. As a result, the payer’s bank is empowered to confirm and verify the PII values belonging to the payee as a mechanism for ‘Confirmation of Payee’, whereby a payer is empowered to verify if the account holder’s name and the account identifier they are about to make a payment to match the records held by the payee’s bank, preventing them from errors when entering account identifiers (which can lead to wrong-payee errors without account holder’s details being verifiable to the payer), as well as making payers aware if the account belongs to a different actual owner, hence help prevent payment redirection fraud which is based upon the lack of ability to match account identifiers and account holder’s name at the time of payment, fulfilling claim 11. In the same embodiment, the payer’s bank may also apply custom logic to seek different levels and numbers of payee’s PII values from payers and apply different acceptance or rejection logic depending on the success or failure of PII verification. For example, a payer’s bank can implement a controlling logic as part of their payment systems to enforce the correct entry of a payee’s full name, full address or phone number from the payer for payments that meet certain criteria, like being more than a certain threshold or being targeted towards payees of certain locations, hence empowering a payer’s bank to implement custom payment authorization schemes, fulfilling claim 11, and in doing so, neither of payer’s or payee’s bank will require to modify anything in their existing payment processing backend systems as this extra authorization step is implemented as a control logic prior to payment even hitting such backends hence fulfilling claim 8. Referring to Figure 4-2, in one embodiment where the PII Host is a payee’s bank and the PII Prover is a payer’s bank, any custom attribute related to a bank account can be privately shared with the payer’s bank by the payee’s bank, as a {Dm} item, that can help inform the payer of possible risks involved in making payments to a bank account. This can comprise but is not limited to the concept of ‘Account Trust Index’ which can be a numeric value from 1 to 10, representing low to high trust index of an account. This value can be calculated from a range of parameters like the age of a bank account, how active the account has been, how much funds have been transferred into and out of the account recently, and finally, how high-credit the owner of the account is. While the PII Verifier maintains no knowledge of such data, the data can help a payer’s bank inform a payer that an account may have been just opened without much activity and that the payer may need to apply discretion before making a payment. In cases of identity theft where a fraudster opens a legitimate bank account on behalf of the owner of a stolen identity and starts fraudulent activities to receive funds with such an account, the concept of an ‘Account Trust Index’ and making it known to payers can help minimize chances of payers making payments to such fraudsters, hence chances of fraudsters succeeding being minimized in their fraudulent activities, facilitating claims 7 and 15. Given that in the proposed invention, PII Hosts and PII Provers always are the initiators of requests they send to the PII Verifier (or the root PII Certificate Seed Authority) and they do not need to expose application programming interfaces (APIs) to respond to other’s interactions, the purpose of sharing private data between PII Hosts and PII Provers is facilitated via the invention without them having to expose APIs, fulfilling claim 14. In such an embodiment, if the PII items include account holders’ full name, then the proposed scheme can empower a payer’s bank to perform Confirmation of Payee (COP) hence making it possible for a payer to verify that the combination of account identifiers (i.e. PII Owner ID) and account names (i.e. PII value) are legitimate and are case-insensitively and fuzzily identical to the details maintained by a payee’s bank hance facilitating claim 11. In this embodiment, by enforcing the supply of the correct verifiable name, addresses and other applicable details of a payee, and given that the identity of payees has been already verified by the payee’s bank at the time of opening an account, as per KYC requirements, the proposed invention makes it possible for a payer’s bank to then enforce KYC requirements even to payees that may not be the customers of the payer’s bank. As a result, the payer’s bank is empowered with the possibility to validate the true KYC-verified details of a payee and use the validated details to query or compare against a blacklisted list of payees who may have been blacklisted due to a various set of reasons comprising but not limited to sanctions, hence empowering a payer’s bank to prevent payments from being made to blacklisted or sanctioned payees automatically fulfilling claim 12. In this embodiment, a payer’s bank is also empowered to get a payer to provide different private details of a payee like address, full name, or phone numbers as part of the payment initiation process and then try to verify such details via the proposed systems and methods before processing the payment, hence simulate a similar payment authorization style that is common for credit card payments which include a primary account number, expiry and billing address entry. The proposed invention provides this facility to a payer’s bank to have the freedom to apply different levels of rigour to this style of authorization based on different criteria like the physical location of the payee or the amount of payment to then improve money laundering monitoring controls, as well as the ability to apply novel dynamic payment authorization schemes for account-to-account payments without adopting a different payment processing backend, hence fulfilling claim 11 and 12. In all embodiments of the proposed invention, one or more PII Certificates can be created for a PII Owner who can be identified with any PII Owner ID which can be any string value. In all interactions between PII Hosts, PII Provers and the PII Verifier, the PII Owner ID and its hashed tokenized version, PII Owner ID Token Hash, is used which is generated by feeding the tokenized version of PII Owner ID, as described in previous chapters, to a cryptographic hash function, generating an irreversible unique identifier for a PII Certificate. Since PII Owner ID can be any string value, in different embodiments, different alternatives can be used as a PII Owner ID which comprise but are not limited to “bank branch identifier || account number”, where ‘||’ denotes the string concatenation operator, “person identifier”, “patient identifier”, “student identifier” etc... Depending on jurisdiction, a range of alternatives may be used for bank branch identifier which comprise but is not limited to Routing Transit Number (RTN) in the US, Bank State Branch (BSB) in Australia, Sort Code in the UK. Unique account identifiers like PayID (common in Australia) or International Bank Account Number (IBAN) or Swift code or unique cryptocurrency wallet identifiers can all be used as PII Owner ID in the proposed invention. In the case of cryptocurrency wallets that do not inherently belong to or provided by banks as PII Hosts, such PII Hosts need to first verify the ownership of such wallet Identifiers as presented by their respective owners and then use such wallet identifiers as a PII Owner ID when generating PII Certificates for their respective account holders as a PII Owner. As a direct result of dynamicity and openness of PII Owner ID in the proposed invention and that the invention operates independently from any payment processing protocols and schemes, in a banking setup where the PII Host is a payee’s bank and the PII Prover is a payer’s bank, claim 13 is met when the invention is used as a mechanism of Confirmation of Payee or Payee KYC enforcement, as described in previous chapters. REFERENCES BOYKO, V., MACKENZIE, P. & PATEL, S. Provably secure password-authenticated key exchange using Diffie-Hellman. International Conference on the Theory and Applications of Cryptographic Techniques, 2000. Springer, 156-171. GRIEVE, C.2021. Home buyer caught in $100,000 bank scam hits out at ‘dismissive’ NAB [Online]. Available: https://www.smh.com.au/business/banking-and-finance/home- buyer-caught-in-100-000-bank-scam-hits-out-at-dismissive-nab -20210919- p58szy.html [Accessed]. GRIEVE, C.2022a. ACCC calls for banks to name-check transactions to stop ‘rapidly rising’ scams [Online]. Available: https://www.smh.com.au/business/banking-and- finance/accc-calls-for-banks-to-name-check-transactions-to-s top-rapidly-rising- scams-20211007- p58y2f.html#:~:text=Australian%20banks%20do%20not%20block,wh ich%20is%20 %E2%80%9Crapidly%20rising%E2%80%9D. [Accessed]. GRIEVE, C.2022b. Big banks fight push for billions of dollars in scam refunds [Online]. Available: https://amp-smh-com- au.cdn.ampproject.org/c/s/amp.smh.com.au/business/banking-an d-finance/big- banks-fight-push-for-billions-of-dollars-in-scam-refunds-202 20131-p59sp3.html [Accessed]. HAASE, B. & LABRIQUE, B.2018. AuCPace: Efficient verifier-based PAKE protocol tailored for the IIoT. Cryptology ePrint Archive. HAO, F. & RYAN, P.2010. J-PAKE: authenticated key exchange without PKI. Transactions on computational science XI. Springer. JARECKI, S., KIAYIAS, A. & KRAWCZYK, H. Round-optimal password-protected secret sharing and T-PAKE in the password-only model. International Conference on the Theory and Application of Cryptology and Information Security, 2014. Springer, 233-253. JARECKI, S., KRAWCZYK, H. & XU, J. OPAQUE: an asymmetric PAKE protocol secure against pre-computation attacks. Annual International Conference on the Theory and Applications of Cryptographic Techniques, 2018. Springer, 456-486. MOXIE MARLINSPIKE, T. P.2016. The X3DH Key Agreement Protocol [Online]. Available: https://signal.org/docs/specifications/x3dh/ [Accessed]. SADLER, H.2019a. Digital Invoice Wallet: Methods, Applications, Systems and Processes for Transferring Invoices to Buyers Seamlessly in Digital Format without the Need for Buyers to Share Their Personal Details [Online]. Available: https://patentscope.wipo.int/search/en/detail.jsf?docId=AU23 9180280 [Accessed]. SADLER, H.2019b. Secure Receipt Transfer Protocol: Cryptosystem, Communication Protocol, Systems, Methods and Smartphone Applications for End-To-End Encrypted Transfer of Tamper-Resistant Receipts as an Enabler for Anonymously- Individualized Marketing and Loyalty Management with Preservation of Buyers’ Anonymity and Privacy [Online]. Available: https://patentscope.wipo.int/search/en/detail.jsf?docId=AU24 9885057 [Accessed]. SCAMWATCH.GOV.AU. 2021a. Payment redirection scams cost Australian businesses $14 million [Online]. Available: https://www.scamwatch.gov.au/news- alerts/payment-redirection-scams-cost-australian-businesses- 14-million [Accessed]. SCAMWATCH.GOV.AU. 2021b. Payment redirection scams cost Australian businesses $128 million in 2020 [Online]. Available: https://www.scamwatch.gov.au/news- alerts/payment-redirection-scams-cost-australian-businesses- 128-million-in-2020 [Accessed]. WU, T. D. The Secure Remote Password Protocol. NDSS, 1998. Citeseer, 97-111.
Next Patent: RETAINER SYSTEMS