WO2023247998A1

WO2023247998A1 - Multi-blind authentication

Info

Publication number: WO2023247998A1
Application number: PCT/IB2022/055897
Authority: WO
Inventors: Nicholas Francis GATLAND; Mehdi SOLTANY; Michael John Simpson; Gregory John Dickason
Original assignee: Locii Innovation Pty Ltd
Priority date: 2022-06-24
Filing date: 2022-06-24
Publication date: 2023-12-28

Abstract

A method for securely verifying a user's identity for accessing a computer system includes a user device sending an access request from an application to the computer system. The user device requests authentication from an authentication server and receives a type of identity verification to be performed and an identity server to be contacted. The user device sends the identity type information encrypted with the application's encryption key to the identity server. The user device receives a token from the authentication server if the authentication server verifies the user's identity based on a number of identity verifications needed to verify the user's identity. The user device sends the token to the computer system and receives access to the computer system if the computer system verifies the token with the authentication server.

Description

MULTI-BLIND AUTHENTICATION

BACKGROUND

[001] Accurate authentication for each digital interaction of customers, businesses, and machines is an issue for corporations and governments and will become more important as artificial intelligence (Al) and bots permeate the digital world. Once a customer is identified and authorized by a computer system, there is an ongoing challenge to assist the customer to manage their credentials to ensure they can easily interact with service providers while maintaining high security.

[002] Existing online identity services provide an easy way for consumers to authenticate a range of services. The challenge with the existing online identity services is that they do not provide a secure and trusted profile of a consumer. In today’s online environment, the rudimentary username and password approach to security is easy prey for cybercriminals as well as an unsatisfactory user experience for consumers to continually manage passwords. Logins may be compromised in minutes, and private data such as personal and financial details is under increasing threat. While there have been some recent improvements in proof- of-identity, such as Multi-Factor Authentication (MFA), these improvements do not solve the fundamental challenges. The foundation for proof -of-identity is still flawed with an onerous customer experience for consumers.

[003] Smart phones now have a range of biometric capabilities that are underleveraged for proof-of-identity. For example, fingerprint readers, facial scans, iris scans, and “voice prints” may be commonly used for tasks such as unlocking a user’s device but are not extensively used to authenticate users on Web sites and applications. Part of the challenge is that consumers do not want their biometric information stored on dozens of different Web sites and are naturally wary of having one centralized organization that controls all their biometric information. [004] Customers also understand more about how they remain vulnerable to phishing, man-in-the-browser, and man-in-the-middle attacks. These types of attacks mean that biometric -based MFA alone does not provide a sufficient level of security. A solution is needed that can authenticate a user without letting anyone or anything “get in the middle.”

SUMMARY

[005] A method for securely verifying a user’s identity for accessing a computer system includes sending an access request from an application running on a user device to the computer system. The user device receives an indication from the computer system that the user device needs to be authenticated. The user device requests authentication from the authentication server. The user device receives a type of identity verification to be performed and an identity server to be contacted from the authentication server. The user device encrypts the identity type information to be verified with the application’s encryption key. The user device sends the encrypted identity type information to the identity server. The user device receives a token from the authentication server based on a verification of the user’s identity as determined by the identity server. The user device sends the token to the computer system. The user device receives access to the computer system after the computer system has verified the token with the authentication server.

[006] A system for securely verifying a user’s identity for accessing a computer system includes a plurality of identity servers, an authentication server, and a user device. The user device is configured to send an access request from an application running on the user device to the computer system; receive an indication from the computer system that the user device needs to be authenticated; request authentication from an authentication server; receive a type of identity verification to be performed and an identity server to be contacted from the authentication server; encrypt the identity type information to be verified with the application’s encryption key; send the encrypted identity type information to the identity server; receive a token from the authentication server based on a verification of the user’s identity as determined by the identity server; send the token to the computer system; and receive access to the computer system after the computer system has verified the token with the authentication server.

[007] A system for securely verifying a user’s identity for accessing a computer system includes a plurality of identity servers, a user device, an authentication server, and an accounting module in the authentication server. The user device is configured to send an access request from an application running on the user device to the computer system. The computer system is configured to send an indication to the user device that the user device needs to be authenticated. The user device is further configured to request authentication from the authentication server. The accounting module is configured to determine a risk level for the access request, including a number and types of identity verification needed to verify the user’s identity. The user device is further configured to receive a type of identity verification to be performed and an identity server to be contacted from the authentication server; encrypt the identity type information to be verified with the application’s encryption key; send the encrypted identity type information to the identity server; receive a token from the authentication server based on a verification of the user’s identity as determined by the identity server; send the token to the computer system; and receive access to the computer system after the computer system has verified the token with the authentication server.

[008] A method for securely verifying a user’s identity by an identity server includes receiving an encrypted identity type information, an encryption key of an application running on a user device, and a token from the user device. The encrypted identity type information is decrypted with the application’s encryption key. The decrypted identity type information and a corresponding identity type information stored on the identity server are compared. The token is signed on a condition that the decrypted identity type information matches the corresponding identity type information. The signed token is sent to the user device.

[009] A method for requesting a user’s private cryptography key on a user device includes verifying the user’s identity and requesting a vault component running on the user device to reconstruct the user’ s private cryptography key. Reconstructing the user’s private cryptography key includes requesting a shard of the user’ s private cryptography key from each of a plurality of secret store locations; receiving the shard from each of the plurality of secret store locations; and reconstructing the user’s private cryptography key with a threshold number of shards, wherein the threshold number of shards is fewer than a total number of shards.

[010] A system for requesting a user’s private cryptography key includes a plurality of identity servers, an authentication server including an accounting module, and a user device including a vault component. The user device is configured to verify the user’s identity and request the vault component to reconstruct the user’s private cryptography key. The vault component is configured to request a shard of the user’s private cryptography key from each of a plurality of secret store locations; receive the shard from each of the plurality of secret store locations; and reconstruct the user’s private cryptography key with a threshold number of shards, wherein the threshold number of shards is fewer than a total number of shards.

[OH] It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the disclosed embodiments, as claimed.

BRIEF DESCRIPTION OF THE DRAWINGS

[012] The accompanying drawings are not necessarily to scale or exhaustive. Instead, emphasis is generally placed upon illustrating the principles of the disclosure described herein. These drawings, which are incorporated in and constitute a part of this specification, illustrate several embodiments consistent with the disclosure and, together with the detailed description, serve to explain the principles of the disclosure. In the drawings:

[013] Fig. 1 is a flow diagram of a process for performing a multi-blind authentication.

[014] Fig. 2 is a flowchart of a method performed by a user device in the multi -blind authentication process shown in Fig. 1.

[015] Fig. 3 is a flow diagram of a process performed by an identity server to shard a piece of information.

[016] Figs. 4A-4B are a flowchart of a method performed by the identity server to authenticate a user’s identity using the processes of Fig. 1 and Fig. 3.

[017] Fig. 5 is a flow diagram of a process for retrieving a user’s private cryptography key.

[018] Figs. 6A-6B are a flowchart of a method performed by a user device in the process shown in Fig. 5.

DETAILED DESCRIPTION

[019] In the following detailed description, numerous specific details are set forth to provide a thorough understanding of the disclosed example embodiments. However, it will be understood by those skilled in the art that the principles of the example embodiments may be practiced without every specific detail. Well-known methods, procedures, and components have not been described in detail so as not to obscure the principles of the example embodiments. Unless explicitly stated, the example methods and processes described herein are neither constrained to a particular order or sequence, nor constrained to a particular system configuration. Additionally, some of the described embodiments or elements thereof can occur or be performed simultaneously, at the same point in time, or concurrently. Reference will now be made in detail to the disclosed embodiments, examples of which are illustrated in the accompanying drawings. Unless explicitly stated, sending and receiving as used herein are understood to have broad meanings, including sending or receiving in response to a specific request or without such a specific request. These terms thus cover both active forms and passive forms of sending and receiving.

[020] Multi-blind authentication (MBA) implements a form of Authentication, Authorization, and Accounting (AAA) that complies with OpenlD connect and/or OAuth2 protocols (for example) and extends them. Authentication is a process that authenticates that a user is who they say they are. This extends beyond the standard username and password combination or multi-factor authentication (MFA) approach to allow any set of identity claims to be combined to verify identity. Authentication may also be extended to allow for overrides if a user’s identity is hijacked. Authorization is a process to authorize a user to access a service, such as a Web site or an application. Accounting is a process to monitor a user’s accesses over time and may use rules or artificial intelligence (Al) algorithms to alert the user or block access to the service if the rule or algorithm indicates that the user’s credentials have been hijacked. MBA combines AAA to allow for ease of authentication and authorization while providing robust identity management.

[021] The authentication process manages the creation and management of the user’ s credentials and/or private cryptography key for both identity setup and for authentication of every digital interaction thereafter. The private cryptography key is created “virtually” though never stored in a single location so that it cannot be hacked. Rather, the private cryptography key is “sharded” (i.e., broken into separate pieces through an m of n protocol) across multiple trusted servers. In an m of n protocol (for example, Shamir’s Secret Sharing), the private cryptography key is split into multiple parts (shards) which may be used to reconstruct the private cryptography key. A minimum threshold number of shards are needed to reconstruct the private cryptography key, and the threshold number (m) may be fewer than the total number of shards (n). It is noted that the m of n protocol may be applied to any stored item of information, including but not limited to, individual items of the user’s identity that may be used for identity verification, such as a face scan biometric, an iris scan biometric, a fingerprint biometric, or a voice scan.

[022] The MBA authentication process as described herein may be “called” (i.e., built into any Web service process) in a similar manner as existing services, such as OpenlD Connect or OAuth2.0. MBA provides a rigorous process that checks multiple input biometric variables to prove that the user really is who they say they are. In some embodiments, the MBA authentication process may be “coordinated” by an application running on a user’s device (e.g., a mobile phone).

[023] In the MBA authentication process described herein, there is a set of independent and objective providers which together interact to allow the creation of an authentication and access token. As used herein, the term “token” may include a piece of software or code that is transmissible over a communications network. A token may include one or more distinct pieces of information, including other tokens. A token may be configured to be electronically signed by a sender such that the recipient may electronically verify that the token was sent by the sender and that the contents of the token were not tampered with or otherwise modified during transmission from the sender to the recipient.

[024] Each provider is set up to accept a different authentication from the user, for example: a face scan biometric, an iris scan biometric, a fingerprint biometric, a voice scan, a password, or a mobile device identifier. User biometrics or passwords are “over-the-top” of the device in an MBA authentication library with client applications such that the information is not stored on the user device where it can be compromised. The authentication process itself is encrypted over Secure Sockets Layer (SSL) or other Transport Layer Security protocol. An MBA library may be used across many forms of devices (for example, a smart phone, a laptop computer, a desktop computer, or voice-enabled Al device) allowing easy maintenance and use.

[025] In an example authentication use case flow, a user authenticates their identity on a user device (e.g., the user’s mobile phone) through being challenged for biometric and other inputs (e.g., by putting a finger on a sensor, looking at a screen and saying two personal keywords). The user attempts to access an identity -controlled Web site, for example their bank, via the user device. In some embodiments, an MBA library on the Web site sends an unverified session token (Tl) to the user device.

[026] In some embodiments, the user device sends the session token Tl to an authentication server of the MBA service to request an access token (T2). In some embodiments, the tokens Tl and T2 may not be used and may be replaced by a request/response exchange mechanism between the user device and the computer system. [027] The authentication server indicates to the user device the number and type(s) of authentication required for access to the Web site. The user device initiates a session with each of a number of identity servers indicated by the authentication server. The number of identity servers used may correspond to a level of risk associated with the access request. The number of identity servers used may be higher for a high level of risk than the number of identity servers used for a low level of risk. The level of risk may be determined by the authentication server. The level of risk may be determined by an accounting module in the authentication server that may monitor access requests to flag possibly suspicious access requests (for example, an access request from the user but from a new user device, an access request from the user coming from a geographic location not typically associated with the user, or at a time different from a time window when the user previously made access requests). [028] The user device sends a verification token (T3) and the necessary information to verify the user’s identity to each of the identity servers. In some embodiments, the necessary information (e.g., a user’s keyword) is signed with the MBA application’s encryption key. In some embodiments, the MBA application is an application running on the user device and the application’s encryption key is separate and distinct from the user’s public cryptography key. In some embodiments, the necessary information may not include the token T3 and may include a session identifier, a transaction identifier, or another unique identifier received from the authentication server.

[029] For example, a keyword identity server receives the user’s keyword signed with the MBA application’s encryption key and the verification token T3. The keyword identity server determines whether the user’ s keyword matches its internal store. If there is a match, the keyword identity server signs the verification token T3 and sends the signed verification token T3 back to the user device. In another example, a facial scan identity server determines whether the user’s facial scan matches (to a nearest likely match) its internal store and, if the match is within a confidence level, the facial scan identity server signs the verification token T3 and returns the signed verification token T3 to the user device. The user device then sends the signed verification token T3 to the authentication server. The authentication server verifies each of the received signed verification tokens T3 with the respective identity server. In some embodiments, this process is repeated until the authentication server receives the number of signed verification tokens T3 determined by the level of risk. In some embodiments, this process is repeated until the authentication server receives m of n signed verification tokens T3.

[030] The identifier may include any one or more of: a face scan biometric, an iris scan biometric, a fingerprint biometric, a voice scan, a password, an identifier of the user’s device, or other identifier that may be used to uniquely identify the user. The identity server verifies the user’ s identity on a condition that the decrypted identity type information matches a corresponding identity type information stored by the identity server. The corresponding identity type information may be a same identifier associated with the user that was previously captured and stored by the identity server. On the condition that the decrypted identity type information matches the corresponding identity type information, the identity server may sign the verification token T3 and send the signed verification token T3 to the user device.

[031] To provide an additional layer of security, the corresponding identity type information stored by the identity server may be sharded and each shard may be stored in a separate location. The identity server may implement an m of n protocol to shard the corresponding identity type information. The identity server may then reconstruct the corresponding identity type information with a threshold number of shards, wherein the threshold number of shards is fewer than a total number of shards.

[032] The authentication server may use an m of n protocol and require only m of the n identity servers to send signed verification tokens T3 to be able to verify the user’ s identity to allow access to the Web site. If the authentication server has not yet received the threshold number (m) of verifications, the authentication server instructs the user device with the details of the next identity verification step to be performed, including the identity type to be verified (e.g., face scan, iris scan, etc.) and the identity server to be accessed. Once the authentication server receives the threshold number (m) of verifications, it sends a signed access token (T4) to the user device. The access token T4 may be any type of indicator that conveys a small amount of information from the authentication server to the user’s device. The access token T4 may include one or more fields to verify that the authentication server is the source of the access token T4. [033] The user device then sends the signed access token T4 to the computer system. The computer system verifies the signed access token T4 with the authentication server, and if the access token T4 is verified, the computer system sends an access grant to the user device. The access grant may be any type of indicator that conveys a small amount of information from the computer system to the user device. The access grant may include one or more fields to verify that the computer system is the source of the access grant. The user is then able to interact with the service they have requested access to (e.g., their bank) in the same way as if they had authenticated with a standard OpenlD Connect service, with the MBA authentication server acting as an OpenlD Connect authorization server. The MBA authentication process may be a subset of the OpenlD Connect authentication flow.

[034] By using an m of n protocol, the MBA authentication process can provide a series of progressively more secure authentication levels by varying the threshold number of identity servers needed to authenticate the user. This ensures an appropriate and optimal authentication process that may be configured for each customer experience interaction. For example, some customer interactions may not require high levels of security, in which case service providers may choose a single biometric as the requirement for access. In other cases, such as where higher levels of security are imperative, the service provider may define multiple biometrics for proof-of-identity. The MBA authentication process described herein enables the service provider to define the level of authentication required for any type of interaction.

[035] For business continuity, if one or more of the trusted servers are offline, the design of the MBA authentication process enables the user to continue working. A nested security hierarchy potentially enables the user to perform a range of functions that require a lower level of security and hence infrastructure availability. Multiple trusted identity servers may be used to authenticate each of the identity shard types, thereby delivering greater redundancy without introducing additional security risk. Using an m of n protocol, not every shard is required from a trusted identity server if the threshold number of shards can be provided. [036] Fig. 1 is a flow diagram of a process 100 for performing a multi-blind authentication. The process 100 is performed between a user device 102, a computer system 104 that a user wishes to access, a plurality of identity servers 106a, 106b, . . ., 106n, and an authentication server 108 including an accounting module 110. The number of identity servers N may be any integer number of servers, and the process 100 will perform in a similar manner regardless of the number of identity servers 106. For ease of explanation, only three identity servers 106 are shown in Fig. 1.

[037] In some embodiments, the process 100 may be performed by one or more software applications running on the user device 102, the computer system 104, the identity servers 106, the authentication server 108, and the accounting module 110. In some embodiments, the accounting module 110 may be a hardware component, a software component, or a combination of hardware and software. In some embodiments, the accounting module 110 may be a hardware component, for example, a central processing unit (CPU), a graphics processing unit (GPU), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), or other programmable circuitry.

[038] The user sends an access request via the user device 102 to the computer system 104 (flow 1; operation 120). The computer system 104 may be any computer system or service to be accessed by the user, for example, a bank Web site where the user has an account. The computer system 104 sends an indication to the user device 102 that the user device 102 needs to be authenticated (flow 2; operation 122).

[039] The user device 102 requests access to the computer system 104 from the authentication server 108 (flow 3; operation 124). In some embodiments, the communications between the user device 102 and the authentication server 108 are structured as a request/response mechanism. The accounting module 110 determines a risk level for the access request. The risk level determines how many and which types of authentication that the user will need to provide to be able to access the computer system 104.

[040] The authentication server 108 sends a response to the user device 102 that specifies which type of authentication is required to access the computer system 104 (flow 4; operation 126). The user device 102 sends the necessary information to the identity server 106 associated with the authentication type specified by the authentication server 108 (flow 5; operation 128). In some embodiments, each identity server 106 is configured to verify the user’s identity based on a specific authentication type. For example, there may be a separate password verification server, face scan verification server, etc. The user device 102 may be configured to run an application that assembles the information into a “package” to be sent to the identity server 106. In some embodiments, the package includes the identity type information to be verified (for example, a face scan of the user) that is signed with the application’s encryption key and a session identifier, a transaction identifier, or another unique identifier received from the authentication server 108. In some embodiments, the package may be formatted as a signed lavaScript Object Notation (JSON) Web Token (IWT).

[041] Each of the identity servers 106a-106n performs a similar method to verify the user’s identity based on the received package of information. The identity server 106 verifies the authenticity of the signed identity type information, to ensure that the identity type information was sent by the user device 102 and has not been tampered with during transit. The received identity type information is compared with a corresponding identity type information securely stored by the identity server 106. For example, if the identity server 106 is to verify a face scan biometric, the received identity type information is a current face scan biometric captured by the user device 102 and the corresponding identity type information is a previously captured face scan biometric stored by the identity server 106. If the received identity type information matches the corresponding identity type information, this means that the item of the user’s identity has been verified by the identity server 106. The identity server 106 generates and signs a first token (e.g., an identity verification token). The first token includes information about the user (and/or the user device 102), the identity server 106 that generated the token, and whether the verification was successful or not. In some embodiments, the first token may include additional information, such as a timestamp of when the verification was completed or other information to help prove whether the verification was successful. The identity server 106 sends the signed first token back to the user device 102 (flow 6; operation 130). If the received identity type information does not match the corresponding identity type information, this means that the item of the user’ s identity has not been verified by the identity server 106. The identity server 106 still generates and signs the first token, but the first token includes an indication that the verification was not successful.

[042] The user device 102 sends the signed first token to the authentication server 108 as proof of whether the authentication was successful or not (flow 7; operation 132). In some embodiments, if the authentication server 108 does not receive the signed first token from the user device 102 after a set period of time after the first token is generated by the identity server 106, it may be implied that the item of the user’s identity has not been verified by the particular identity server 106. In such circumstances, the user device 102 may receive a session timeout error from the authentication server 108.

[043] The authentication server 108 verifies the authenticity of the signed first token with the identity server 106 that signed the first token (flow 8; operation 134). If the signed first token is verified, the accounting module 110 instructs the user device 102 with the details of the next challenge including identity server details (repeating flow 4; operation 126) if an additional identity item verification is required based on the determined risk level. Flows 4 through 8 (operations 128, 130, 132, and 134) are repeated for each additional identity item verification.

[044] Once the accounting module 110 in the authentication server 108 determines that it has received a sufficient number of identity verifications to verify the user based on the risk level associated with the access request, the authentication server 108 sends a signed second token (e.g., a signed access token) to the user device 102 (flow 9; operation 136). In some embodiments, the authentication server 108 uses an m of n protocol to verify the user’s identity. By using the m of n protocol, the authentication server 108 may verify the user’s identity once it has received the m number of verifications. In the event that the authentication server 108 is unable to verify the signed first token received from the user device 102 (i.e., flow 8 (operation 134) fails), then that identity item does not count toward the m number of identity items to be verified. If the signed first token indicates that the verification with an identity server 106 has failed, this identity item also would not count toward the m number of identity items to be verified. The accounting module 110 then selects the next identity item to be verified (repeating flows 4 through 8 (operations 126-134) as needed until the m number of identity items have been verified).

[045] The user device 102 sends the signed second token to the computer system 104 (flow 10; operation 138). The computer system 104 verifies the signed second token with the authentication server 108 (flow 11; operation 140). If the signed second token is verified by the authentication server 108, then the computer system 104 grants access to the user device 102 (flow 12; operation 142). In some embodiments, the computer system 104 creates a session for the user and provides access to the resources initially requested by the user.

[046] Fig. 2 is a flowchart of a method 200 performed by the user device 102 in the multiblind authentication process shown in Fig. 1. The user device 102 sends an access request to the computer system 104 (operation 202). The user device 102 receives an indication from the computer system 104 that the user device 102 needs to be authenticated (operation 204). The user device 102 contacts the authentication server 108 to request authentication (operation 206). The second token may include the first token.

[047] The user device 102 receives an indication of a type of authentication required to verify the user’s identity and the identity server 106 to be accessed from the accounting module 110 (operation 208). The type of authentication required may be based on the risk level associated with the access request, as determined by the accounting module 110. For example, the type of authentication may include a face scan biometric, an iris scan biometric, a fingerprint biometric, a voice scan, a password, an identifier of the user device 102, or another identifier that may be used to uniquely identify the user. The user device 102 sends the identity type information to be verified to the identity server 106 to be accessed (operation 210).

[048] If the identity type information sent by the user device 102 is verified by the identity server 106, then the user device receives a signed first token from the identity server 106 (operation 212). The user device 102 sends the signed first token to the authentication server 108 as proof of authentication (operation 214).

[049] A determination is made whether the user device 102 has received a signed second token from the authentication server 108 (operation 216). When the authentication server 108 has verified the user’s identity based on the risk level associated with the access request (in some embodiments, by using an m of n protocol), the user device 102 receives the signed second token from the authentication server 108. If the user device 102 has not received the signed second token, this is an indication that additional items need to be verified to fully verify the user’s identity (operation 216, “no” branch). In such circumstances, the user device 102 receives an indication of the next type of authentication that is required from the accounting module 110 (operation 208). Operations 208-214 are repeated until the user device 102 has received the signed second token from the authentication server 108 (operation 216, “yes” branch).

[050] Once the user device 102 receives the signed second token, the user device 102 sends the signed second token to the computer system 104 (operation 218). If the computer system 104 verifies the signed second token, then the user device 102 receives access to the computer system 104 (operation 220).

[051] Fig. 3 is a flow diagram of a process 300 performed by an identity server to shard a piece of information. The piece of information may include an identity type information, a private cryptography key, or other type of information to be securely stored. To provide additional security, an identity server may shard a piece of information across several different storage locations. It is noted that the process 300 may be performed by one or more of the identity servers 106a-106n shown in Fig. 1. The process 300 is performed by an identity server 302, a secret store registry 304, and a plurality of secret store locations 306a, 306b, ..., 306m. The number of secret store locations M may be any integer number of locations, and the process 300 will perform in a similar manner regardless of the number of secret store locations 306. For ease of explanation, only three secret store locations 306 are shown in Fig. 3. In some embodiments, the process 300 may be performed by one or more software applications running on the identity server 302, the secret store registry 304, and the secret store locations 306.

[052] The identity server 302 sends a request to the secret store registry 304 for a list of secret store locations associated with a particular piece of information (operation 320). The identity server 302 may use a different set of secret store locations for different pieces of information. The set of secret store locations may be randomly determined at a time when the piece of information is initially stored by the identity server 302. [053] The secret store registry 304 returns the list of secret store locations to the identity server 302 (operation 322). The list of secret store locations indicates all the secret store locations 306a-306m used by the identity server 302 to store the piece of information. The identity server 302 requests a secret shard from each secret store 306 on the list of secret store locations (operation 324). Requesting the secret shard from each of the secret store locations 306a-306m may be performed in any order or in parallel if the identity server 302 is configured to send multiple parallel communications. Each secret store location 306 sends its secret shard to the identity server 302 (operation 326). An m of n protocol as has been described herein may be implemented by the identity server 302 to reconstruct the piece of information from the secret shards without needing all the shards (i.e., by needing m of the n shards to reconstruct the piece of information).

[054] Figs. 4A-4B are a flowchart of a method 400 performed by the identity server to authenticate a user’s identity using the processes of Fig. 1 and Fig. 3. To provide additional security, the identity server may shard a stored secret across several different storage locations. It is noted that the method 400 may be performed by one or more of the identity servers 106a-106n shown in Fig. 1 or by the identity server 302 shown in Fig. 3.

[055] The identity server receives an encrypted piece of information (e.g., the identity type information), the application’s public key, and a token (e.g., the third token as described above) from the user device (operation 402). In some embodiments, the application is run on the user device and the application’s encryption key is used to encrypt the piece of information. In some embodiments, the received piece of information is not encrypted but is signed by the application’s encryption key to verify that the piece of information is sent by the application (and the user device).

[056] The identity server requests a list of secret store locations from the secret store registry (operation 404) and receives the list of secret store locations (operation 406). The identity server requests a secret shard from each of the secret store locations (operation 408). The identity server receives a secret shard from at least one of the secret store locations (operation 410).

[057] The identity server can reconstruct the stored secret based on a threshold number of secret shards (operation 412). An m of n protocol as has been described herein may be implemented by the identity server. To reconstruct the stored secret, the identity server also needs to know the threshold number of shards.

[058] The identity server decrypts the received encrypted piece of information with the application’s encryption key (operation 414). The decrypted piece of information is compared with the reconstructed stored secret (operation 416). A determination is made whether the decrypted piece of information matches the reconstructed stored secret (operation 418). If there is not a match (operation 418, “no” branch), then the identity server includes a failure indication in the token (operation 420). By including the failure notification in the token, the identity server indicates that it has failed to verify the user’s identity based on the received piece of information.

[059] If the decrypted piece of information matches the reconstructed stored secret (operation 418, “yes” branch; meaning that the user’ s identity type information has been verified by the identity server) or if the failure indication has been included in the token (operation 420), then the identity server signs the token (operation 422) and sends the signed token to the user device (operation 424).

[060] It is noted that operations 404-412 are performed if the identity server shards the stored information. In an embodiment where the identity server does not shard the stored information, operations 404-412 may be skipped and the remaining operations of method 400 (i.e., operations 402 and 414-424) would be performed in a similar manner. [061] The MBA authentication process as described above may be modified to recreate a user’s private cryptography key. This process may be used where the user does not interact directly with a centralized service (such as their bank), but rather where a client device (e.g., the user’s device, such as a smart phone) interacts with a blockchain (for example) and needs to digitally sign transactions or instructions and perform other interactions with the blockchain or other protocol where the user’s private cryptography key may be used to digitally sign a document or authorize a transaction. In this scenario, the user’s private cryptography key has previously been sharded, with each shard stored in a separate location. The user’s private cryptography key is temporarily created on the user device to sign the transaction through an m of n protocol, similar to the process described above. The user’ s private cryptography key is not stored in any single location, mitigating most attacks that may compromise a user’s private cryptography keys. For example, if any single server in the MBA authentication process is compromised, the attacker cannot gain access to the user’s credentials.

[062] In an example use case flow, the user’s device (e.g., a smart phone, laptop computer, or desktop computer) software client asks for authentication from each identity server (e.g., password, biometric face scan, etc.) in a similar manner as described above in connection with Fig. 1. If the user’s identity is verified, a vault component running on the user device reconstructs the user’ s private cryptography key by contacting each of a number of secret store locations to retrieve the individual shards of the user’s private cryptography key.

[063] Fig. 5 is a flow diagram of a process 500 for retrieving a user’s private cryptography key to access a cryptographic wallet, for example. It is noted that the process 500 may be performed in any situation where the user wants to use their private cryptography key to sign a transaction. The process 500 is performed by a user device 502, a cryptographic wallet 504, a plurality of identity servers 506a, 506b, .. . , 506n, an authentication server 508 including an accounting module 510, a vault component 512 on the user device 502, a secret store registry 514, and a plurality of secret store locations 516a-516m. The number of identity servers N may be any integer number of servers, and the process 500 will perform in a similar manner regardless of the number of identity servers 506. For ease of explanation, only three identity servers 506 are shown in Fig. 5. The number of secret store locations M may be any integer number of secret store locations, and the process 500 will perform in a similar manner regardless of the number of secret store locations 516. For ease of explanation, only three secret store locations 516 are shown in Fig. 5.

[064] In some embodiments, the process 500 may be performed by one or more software applications running on the user device 502, the cryptographic wallet 504, the identity servers 506, the authentication server 508, the accounting module 510, the vault component 512, the secret store registry 514, and the secret store locations 516. In some embodiments, the accounting module 510 and/or the vault component 512 may be a hardware component, a software component, or a combination of hardware and software. In some embodiments, the accounting module 510 and/or the vault component 512 may be a hardware component, for example, a CPU, a GPU, an ASIC, an FPGA, or other programmable circuitry.

[065] A user, via the user device 502, wants to access their cryptographic wallet 504. The user device 502 sends an access request to the cryptographic wallet 504 (flow 1; operation 520). Flow 2 through 9 (operations 522-536) to verify the user’ s identity are the same as flows 2 through 9 (operations 122-136) as described above in connection with Fig. 1 and are not repeated herein.

[066] When the user device 502 has received the signed second token from the authentication server (flow 9; operation 536), the user device 502 sends a request to the vault component 512 to retrieve the user’s private cryptographic key. The vault component 512 sends a request to the secret store registry 514 for a list of secret store locations associated with the user’s private cryptography key (flow 13; operation 550). The set of secret store locations may be randomly determined at a time when the user’ s private cryptography key is initially stored by the vault component 512.

[067] The secret store registry 514 returns the list of secret store locations to the vault component 512 (flow 14; operation 552). The list of secret store locations indicates all the secret store locations 516a-516m used by the vault component 512 to store the user’s private cryptography key. The vault component 512 requests a secret shard from each secret store 516 on the list of secret store locations (flow 15; operation 554). Requesting the secret shard from each of the secret store locations 516a-516m may be performed in any order or in parallel if the vault component 512 (and the user device 502) is configured to send multiple parallel communications. Each secret store location 516 sends its secret shard to the vault component 512 (flow 16; operation 556). An m of n protocol as has been described herein may be implemented by the vault component 512 to reconstruct the user’s private cryptography key from the secret shards without needing all the shards (i.e., by needing m of the n shards to reconstruct the user’s private cryptography key).

[068] Once the vault component 512 has reconstructed the user’s private cryptography key, the user device 502 may use the user’s private cryptography key to sign a transaction on the cryptographic wallet 504 (flow 17; operation 558). When the user device 502 has received confirmation from the cryptographic wallet 504 that the transaction has been successfully signed, the user device 502 indicates to the vault component 512 to delete the reconstructed version of the user’s private cryptography key. In this manner, the user’s private cryptography key is not stored on the user device 502 for any longer than is needed to sign a transaction.

[069] Figs. 6A-6B are a flowchart of a method 600 performed by the user device 502 in the process shown in Fig. 5. The user device 502 sends an access request to the cryptographic wallet 504 (operation 602). The user device 102 receives an indication from the cryptographic wallet 504 that the user device 502 needs to be authenticated (operation 604). Operations 606-616 to verify the user’s identity are the same as operations 206-216 as described above in connection with Fig. 2 and are not repeated herein.

[070] When the user device 502 receives the signed second token from the authentication server 508 (operation 616, “yes” branch), the user device 502 sends a request to the vault component 512 to reconstruct the user’s private cryptography key (operation 630). The vault component 512 requests a list of secret store locations from the secret store registry 514 (operation 632) and receives the list of secret store locations from the secret store registry 514 (operation 634). The vault component 512 requests a secret shard of the user’s private cryptography key from each of the secret store locations 516 (operation 636). The vault component 512 receives the secret shards of the user’s private cryptography key from the secret store locations (operation 638). The vault component 512 reconstructs the user’s private cryptography key based on a threshold number of received secret shards (operation 640). In some embodiments, the vault component 512 uses an m of n algorithm as described above to reconstruct the user’s private cryptography key from the received shards. Once the user’s private cryptography key has been reconstructed by the vault component 12, the user device 502 can use the user’s private cryptography key to sign a transaction on the cryptographic wallet 504 (operation 642).

[071] An MBA authorization process may be a use case extension of the MBA authentication process. The signed token created by the authentication server (e.g., the second token as described above) may be coded with authorization details for the service. This enables a service provider to limit the access of a user. It also limits what identity verification credentials that a user will supply to the services they interact with. Authorization works for both blockchain based and non-blockchain based flows by inserting a token in the flow that controls access. It works with on-chain authentication services such as UPort through the smart contracts that execute UPort authentication.

[072] In some embodiments, the accounting module may act separately from the authentication server to monitor a user’s accesses and determine the level of authorization required for a given transaction. For example, when the customer starts an authentication process, the accounting module may log information regarding characteristics of the user’s access, such as time, location, etc. The current parameters may be compared to parameters captured from previous interactions with the user. If any parameters of the user’s current access are uncharacteristic (e.g., outside a range, over a threshold, or under a threshold), the current interaction may be flagged as suspicious, and the user alerted. If the interaction does not appear suspicious, the interaction may proceed.

[073] The accounting module may use Al to look for fraudulent activity that triggers a further authentication check at the appropriate level. The accounting module may then initiate an interaction with the user to recover their credentials. The accounting module may also determine which identity servers are needed for the level of interaction. For example, a low- level payment might only require a password and possession of a device.

[074] The MBA authentication process also addresses the challenge of password retrieval. In some current security processes, when a user forgets their password, the password may be reset in a relatively insecure reset process from an email account. In the MBA authentication process, a user has a private key that is created virtually behind the scenes whenever sufficient supporting identity verification data is provided. If a user is not able to successfully authenticate, a backup process is possible in which the user can reset their credentials or their primary private key through a secondary private key, providing peace of mind to the user.

[075] The accounting module may also initiate a private cryptography key override if a user’s private cryptography key is stolen or the user’s credentials are compromised. This override requires a secondary private cryptography key to be setup for the sole purpose of a reset. When the user’s primary cryptography key is compromised, the user may initiate a reset or the Al in the accounting module may alert the user to suspicious behavior and the likelihood of a compromise. The primary cryptography key may then be reset through first authenticating the user’s identity using the secondary private cryptography key. The user may be required to provide new credentials as part of the key resetting process. For example, the user may need to provide a new face scan biometric, a new iris scan biometric, a new fingerprint biometric, a new voice scan, and/or a new password.

[076] User experience is a part of the MBA authentication process, allowing for ease of user interaction in normal processing, and even when a highly sensitive recreation of the user’s private keys is required. In some current solutions, typically an additional authentication request such as password regeneration for a bank is achieved by a timeconsuming phone call to the impacted customer (or a text message requesting a call back through a call queue). In the described MBA authentication process, additional authentication requests will trigger the user to provide one or more items of biometric information and/or personal information keywords (pieces of unforgettable personal information only known to the user, such as the currently known security questions) in just seconds on their device.

[077] The MBA authentication process permits establishing “distributed trust,” with each party acting as an authentication node on an MBA network. No authentication would be possible without multiple trusted parties involved. In some implementations, these “trusted parties” may earn a small transaction management fee (for example, under Ethereum, a smart contract fee) for each authentication process (where the trusted party runs their part of the overall authentication process). The MBA authentication process may partner with biometric partners that run either external trusted services and/or are established as internal MBA trusted network nodes. An operator of the MBA authentication process may be able to utilize the best solutions for its customers’ needs at all times, with seamless transition to new partners as technology evolution takes place.

[078] The disclosed embodiments may be implemented in a system, a method, and/or a computer program product. The computer program product may include a computer readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out aspects of the described embodiments.

[079] The computer readable storage medium may be a tangible device that can retain and store instructions for use by an instruction execution device. The computer readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of the computer readable storage medium includes the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD- ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanically encoded device such as punch-cards or raised structures in a groove having instructions recorded thereon, and any suitable combination of the foregoing. A computer readable storage medium, as used herein, is not to be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission media (e.g., light pulses passing through a fiberoptic cable), or electrical signals transmitted through a wire.

[080] Computer readable program instructions described herein can be downloaded to respective computing/processing devices from a computer readable storage medium or to an external computer or external storage device via a network, for example, the Internet, a local area network, a wide area network, and/or a wireless network. The network may include copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers, and/or edge servers. A network adapter card or network interface in each computing/processing device receives computer readable program instructions from the network and forwards the computer readable program instructions for storage in a computer readable storage medium within the respective computing/processing device.

[081] Computer readable program instructions for carrying out operations of the described embodiments may be assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state-setting data, or either source code or object code written in any combination of one or more programming languages, including an object oriented programming language such as Smalltalk, C++, or the like, and conventional procedural programming languages, such as the “C” programming language or similar programming languages. The computer readable program instructions may execute entirely on the user’s computer, partly on the user’ s computer, as a stand-alone software package, partly on the user’s computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user’ s computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGA), or programmable logic arrays (PLA) may execute the computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry, to perform aspects of the described embodiments. [082] Aspects of the disclosure are described herein with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to the described embodiments. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, may be implemented by computer readable program instructions.

[083] These computer readable program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks. These computer readable program instructions may also be stored in a computer readable storage medium that can direct a computer, a programmable data processing apparatus, and/or other devices to function in a particular manner, such that the computer readable storage medium having instructions stored therein includes an article of manufacture including instructions which implement aspects of the function/act specified in the flowchart and/or block diagram block or blocks.

[084] The computer readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other device to produce a computer implemented process, such that the instructions which execute on the computer, other programmable apparatus, or other device to implement the functions/acts specified in the flowchart and/or block diagram block or blocks.

[085] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments. In this regard, each block in the flowcharts or block diagrams may represent a software program, segment, or portion of code, which includes one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, may be implemented by special purpose hardware -based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

[086] The descriptions of the various embodiments have been presented for purposes of illustration but are not intended to be exhaustive or limited to the embodiments disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope of the described embodiments. The terminology used herein was chosen to best explain the principles of the embodiments, the practical application or technical improvement over technologies found in the marketplace, or to enable others of ordinary skill in the art to understand the embodiments disclosed herein.

[087] It is appreciated that certain features of the disclosure, which are, for clarity, described in the context of separate embodiments, may also be provided in combination in a single embodiment. Conversely, various features of the disclosure, which are, for brevity, described in the context of a single embodiment, may also be provided separately or in any suitable subcombination or as suitable in any other described embodiment. Certain features described in the context of various embodiments are not to be considered essential features of those embodiments unless the embodiment is inoperative without those elements. [088] Although the disclosure has been described in conjunction with specific embodiments thereof, it is evident that many alternatives, modifications, and variations will be apparent to those skilled in the art. Accordingly, it is intended to embrace all such alternatives, modifications, and variations that fall within the scope of the appended claims.

Claims

WHAT IS CLAIMED IS:

1. A method for securely verifying a user’ s identity for accessing a computer system, the method comprising: sending an access request from an application running on a user device to the computer system; receiving an indication by the user device from the computer system that the user device needs to be authenticated; requesting authentication by the user device from an authentication server; receiving a type of identity verification to be performed and an identity server to be contacted by the user device from the authentication server; encrypting the identity type information to be verified by the user device with the application’s encryption key; sending the encrypted identity type information from the user device to the identity server; receiving a token by the user device from the authentication server based on a verification of the user’ s identity as determined by the identity server; sending the token from the user device to the computer system; and receiving access to the computer system by the user device after the computer system has verified the token with the authentication server.

2. The method of claim 1, wherein the type of identity verification includes any one or more of: a face scan biometric, an iris scan biometric, a fingerprint biometric, a voice scan, a password, or an identifier of the user device.

3. The method of claim 1, wherein a number of identity verifications to be performed corresponds to a level of risk associated with the access request.

4. The method of claim 3, wherein the number of identity verifications to be performed is higher for a high level of risk than the number of identity verifications to be performed for a low level of risk.

5. The method of claim 1, wherein the level of risk is determined by an accounting module in the authentication server.

6. The method of claim 1, wherein the verification of the user’s identity includes: decrypting the encrypted identity type information by the identity server with the application’s public key; and verifying the identity type information on a condition that the decrypted identity type information matches a corresponding identity type information stored by the identity server.

7. The method of claim 6, wherein: the encrypted identity type information is an identifier associated with the user; and the corresponding identity type information is a same identifier associated with the user that was previously captured and stored by the identity server.

8. The method of claim 6, wherein: the corresponding identity type information stored by the identity server is sharded; and each shard is stored in a separate location.

9. The method of claim 8, wherein the identity server is configured to reconstruct the corresponding identity type information with a threshold number of shards, wherein the threshold number of shards is fewer than a total number of shards.

10. The method of claim 6, wherein the verifying includes: generating and signing a second token by the identity server, wherein the second token includes an indication whether the identity server verified the identity type information; and sending the signed second token by the identity server to the user device.

11. The method of claim 10, further comprising: sending the signed second token from the user device to the authentication server as proof of authentication by the identity server.

12. The method of claim 11, further comprising: sending the signed token from the authentication server to the user device on a condition that the authentication server has received a number of signed second tokens from the user device including positive verifications that equals the number of identity verifications to be performed as determined by the risk level for the access request.

13. The method of claim 12, wherein the number of signed second tokens is based on an m of n protocol.

14. A system for securely verifying a user’s identity for accessing a computer system, comprising: a plurality of identity servers; an authentication server; and a user device, configured to: send an access request from an application running on the user device to the computer system; receive an indication from the computer system, that the user device needs to be authenticated; request authentication from an authentication server; receive a type of identity verification to be performed and an identity server to be contacted from the authentication server; encrypt the identity type information to be verified with the application’s encryption key; send the encrypted identity type information to the identity server; receive a token by the user device from the authentication server based on a verification of the user’s identity as determined by the identity server; send the token to the computer system; and receive access to the computer system after the computer system has verified the token with the authentication server.

15. The system of claim 14, wherein the type of identity verification includes any one or more of: a face scan biometric, an iris scan biometric, a fingerprint biometric, a voice scan, a password, or an identifier of the user’s device.

16. The system of claim 14, wherein a number of identity verifications to be performed corresponds to a level of risk associated with the access request.

17. The system of claim 16, wherein the number of identity verifications to be performed is higher for a high level of risk than the number of identity verifications to be performed for a low level of risk.

18. The system of claim 14, wherein the level of risk is determined by an accounting module in the authentication server.

19. The system of claim 18, wherein the accounting module is configured to: evaluate the access request to determine whether the user device is permitted to access the computer system, the permission being separate from verifying the user’s identity.

20. The system of claim 19, wherein the accounting module is further configured to evaluate the access request by permitting the access request on a condition that parameters of the access request are within a threshold of parameters of prior access requests.

21. The system of claim 19, wherein the accounting module is further configured to evaluate the access request by denying the access request on a condition that the parameters of the access request are not within a threshold of parameters of prior access requests.

22. The system of claim 14, wherein each of the plurality of identity servers is configured to: decrypt the encrypted identity type information with the application’s public key; and verify the identity type information on a condition that the decrypted identity type information matches a corresponding identity type information stored by the identity server.

23. The system of claim 22, wherein: the encrypted identity type information is an identifier associated with the user; and the corresponding identity type information is a same identifier associated with the user that was previously captured and stored by the identity server.

24. The system of claim 22, wherein: the corresponding identity type information stored by the identity server is sharded; and each shard is stored in a separate location.

25. The system of claim 24, wherein each identity server is further configured to reconstruct the corresponding identity type information with a threshold number of shards, wherein the threshold number of shards is fewer than a total number of shards.

26. The system of claim 22, wherein each identity server is further configured to: generate and sign a second token, wherein the second token includes an indication whether the identity server has verified the identity type information; and send the signed second token to the user device.

27. The system of claim 26, wherein the authentication server is further configured to: receive the signed second token from the user device as proof of authentication by the identity server.

28. The system of claim 27, wherein the authentication server is further configured to: send the signed token to the user device on a condition that the authentication server has received a number of signed second tokens from the user device including positive verifications that equals the number of identity verifications to be performed as determined by the risk level for the access request.

29. The system of claim 28, wherein the number of signed second tokens is based on an m of n protocol.

30. A system for securely verifying a user’s identity for accessing a computer system, comprising: a plurality of identity servers; a user device, configured to send an access request from an application running on the user device to the computer system; the computer system is configured to send an indication to the user device that the user device needs to be authenticated; the user device is further configured to request authentication from an authentication server; an accounting module in the authentication server is configured to determine a risk level for the access request, including a number and types of identity verification needed to verify the user’s identity; the user device is further configured to: receive a type of identity verification to be performed and an identity server to be contacted from the authentication server; encrypt the identity type information to be verified with the application’s encryption key; send the encrypted identity type information to the identity server; receive a token by the user device from the authentication server based on a verification of the user’s identity as determined by the identity server; send the token to the computer system; and receive access to the computer system after the computer system has verified the token with the authentication server.

31. The system of claim 30, wherein the type of identity verification includes any one or more of: a face scan biometric, an iris scan biometric, a fingerprint biometric, a voice scan, a password, or an identifier of the user device.

32. The system of claim 30, wherein a number of identity verifications to be performed corresponds to a level of risk associated with the access request.

33. The system of claim 32, wherein the number of identity verifications to be performed is higher for a high level of risk than the number of identity verifications to be performed for a low level of risk.

34. The system of claim 30, wherein each of the plurality of identity servers is configured to: decrypt the encrypted identity type information with the application’s public key; and verify the identity type information on a condition that the decrypted identity type information matches a corresponding identity type information stored by the identity server.

35. The system of claim 34, wherein: the encrypted identity type information is an identifier associated with the user; and the corresponding identity type information is a same identifier associated with the user that was previously captured and stored by the identity server.

36. The system of claim 34, wherein: the corresponding identity type information stored by the identity server is sharded; and each shard is stored in a separate location.

37. The system of claim 36, wherein each identity server is further configured to reconstruct the corresponding identity type information with a threshold number of shards, wherein the threshold number of shards is fewer than a total number of shards.

38. The system of claim 34, wherein each identity server is further configured to: generate and sign a second token, wherein the second token includes an indication whether the identity server has verified the identity type information; and send the signed second token to the user device.

39. The system of claim 37, wherein the user device is further configured to: send the signed second token to the authentication server as proof of authentication by the identity server.

40. The system of claim 39, wherein the authentication server is further configured to: send the signed token to the user device on a condition that the authentication server has received a number of signed second tokens from the user device including positive verifications that equals the number of identity verifications to be performed as determined by the risk level for the access request.

41. The system of claim 40, wherein the number of signed second tokens is based on an m of n protocol.

42. The system of claim 30, wherein the accounting module is further configured to: evaluate the access request to determine whether the user device is permitted to access the computer system, the permission being separate from verifying the user’s identity.

43. The system of claim 42, wherein the accounting module is further configured to evaluate the access request by permitting the access request on a condition that parameters of the access request are within a threshold of parameters of prior access requests.

44. The system of claim 42, wherein the accounting module is further configured to evaluate the access request by denying the access request on a condition that parameters of the access request are not within a threshold of parameters of prior access requests.

45. A method for securely verifying a user’s identity by an identity server, the method comprising: receiving an encrypted identity type information and a public key of an application running on a user device from the user device; decrypting the encrypted identity type information with the application’s public key; comparing the decrypted identity type information and a corresponding identity type information stored on the identity server; generating and signing a token, wherein the token includes an indication whether the identity server has verified the identity type information; and sending the signed token to the user device.

46. The method of claim 45, wherein: the encrypted identity type information is an identifier associated with the user; and the corresponding identity type information is a same identifier associated with the user that was previously captured and stored by the identity server.

47. The method of claim 46, wherein the identifier includes any one or more of: a face scan biometric, an iris scan biometric, a fingerprint biometric, a voice scan, a password, or an identifier of the user device.

48. The method of claim 45, wherein: the corresponding identity type information stored by the identity server is sharded; and each shard is stored in a separate location.

49. The method of claim 48, further comprising reconstructing the corresponding identity type information with a threshold number of shards, wherein the threshold number of shards is fewer than a total number of shards.

50. The method of claim 49, wherein the reconstructing is performed using an m of n protocol.

51. The method of claim 49, wherein the reconstructing includes: requesting a list of secret store locations from a secret store registry; receiving the list of secret store locations from the secret store registry; requesting a shard from each of the secret store locations on the list; receiving the shard from each of the secret store locations on the list; and reconstructing the identity type information with the threshold number of shards.

52. The method of claim 49, wherein the reconstructing includes: requesting a shard from each of a plurality of secret store locations; receiving the shard from each of the plurality of secret store locations; and reconstructing the identity type information with the threshold number of shards.

53. A method for requesting a user’s private cryptography key on a user device, the method comprising: verifying the user’s identity; requesting a vault component running on the user device to reconstruct the user’s private cryptography key, comprising: requesting a shard of the user’s private cryptography key from each of a plurality of secret store locations; receiving the shard from each of the plurality of secret store locations; and reconstructing the user’s private cryptography key with a threshold number of shards, wherein the threshold number of shards is fewer than a total number of shards.

54. The method of claim 53, wherein the reconstructing is performed using an m of n protocol.

55. The method of claim 53, wherein the vault component is further configured to: request a list of secret store locations from a secret store registry; receive the list of secret store locations from the secret store registry; and request a shard from each of the secret store locations on the list.

56. The method of claim 53, wherein the verifying includes: sending an access request from an application running on the user device to a cryptographic wallet; receiving an indication by the user device from the cryptographic wallet that the user device needs to be authenticated; requesting authentication by the user device from the authentication server; receiving a type of identity verification to be performed and an identity server to be contacted by the user device from the authentication server; encrypting the identity type information to be verified by the user device with the application’s encryption key; sending the encrypted identity type information from the user device to the identity server; receiving a token by the user device from the authentication server based on a verification of the user’s identity as determined by the identity server.

57. The method of claim 56, wherein the type of identity verification includes any one or more of: a face scan biometric, an iris scan biometric, a fingerprint biometric, a voice scan, a password, or an identifier of the user device.

58. The method of claim 56, wherein a number of identity verifications to be performed corresponds to a level of risk associated with the access request.

59. The method of claim 58, wherein the number of identity verifications to be performed is higher for a high level of risk than the number of identity verifications to be performed for a low level of risk.

60. The method of claim 56, wherein the level of risk is determined by an accounting module in the authentication server.

61. The method of claim 56, wherein verifying the user’s identity further includes: decrypting the encrypted identity type information by the identity server with the application’s public key; and verifying the identity type information on a condition that the decrypted identity type information matches a corresponding identity type information stored by the identity server.

62. The method of claim 61, wherein: the encrypted identity type information is an identifier associated with the user; and the corresponding identity type information is a same identifier associated with the user that was previously captured and stored by the identity server.

63. The method of claim 61, wherein: the corresponding identity type information stored by the identity server is sharded; and each shard is stored in a separate location.

64. The method of claim 63, wherein the identity server is configured to reconstruct the corresponding identity type information with a threshold number of shards, wherein the threshold number of shards is fewer than a total number of shards.

65. The method of claim 61, wherein the verifying further includes: generating and signing a second token by the identity server, wherein the second token includes an indication whether the identity server has verified the identity type information; and sending the signed second token by the identity server to the user device.

66. The method of claim 65, further comprising: sending the signed second token from the user device to the authentication server as proof of authentication by the identity server.

67. The method of claim 66, further comprising: sending the signed token from the authentication server to the user device on a condition that the authentication server has received a number of signed second tokens from the user device including positive verifications that equals the number of identity verifications to be performed as determined by the risk level for the access request.

68. The method of claim 67, wherein the number of signed second tokens is based on an m of n protocol.

69. The method of claim 53, further comprising: digitally signing a transaction on the cryptographic wallet with the user’s reconstructed private cryptography key.

70. The method of claim 69, further comprising: deleting the user’s reconstructed private cryptography key after receiving an acknowledgement that the transaction was successfully signed.

71. A system for requesting a user’s private cryptography key, comprising: a plurality of identity servers; an authentication server including an accounting module; and a user device including a vault component, configured to: verify the user’s identity; request the vault component to reconstruct the user’s private cryptography key, wherein the vault component is configured to: request a shard of the user’ s private cryptography key from each of a plurality of secret store locations; receive the shard from each of the plurality of secret store locations; and reconstruct the user’s private cryptography key with a threshold number of shards, wherein the threshold number of shards is fewer than a total number of shards.

72. The system of claim 71, wherein the reconstructing is performed using an m of n protocol.

73. The system of claim 71, wherein the vault component is further configured to: request a list of secret store locations from a secret store registry; receive the list of secret store locations from the secret store registry; and request a shard from each of the secret store locations on the list.

74. The system of claim 71, wherein verifying the user’s identity includes: a user device is further configured to: send an access request from an application running on the user device to a cryptographic wallet; receive an indication from the cryptographic wallet that the user device needs to be authenticated; request authentication from the authentication server; the accounting module is configured to determine a risk level for the access request, including a number and types of identity verification needed to verify the user’s identity; the user device is further configured to: receive a type of identity verification to be performed and an identity server to be contacted from the authentication server; encrypt the identity type information to be verified with the application’s encryption key; send the encrypted identity type information to the identity server; and receive a token by the user device from the authentication server based on a verification of the user’s identity as determined by the identity server.

75. The system of claim 74, wherein the type of identity verification includes any one or more of: a face scan biometric, an iris scan biometric, a fingerprint biometric, a voice scan, a password, or an identifier of the user’s device.

76. The system of claim 74, wherein a number of identity verifications to be performed corresponds to a level of risk associated with the access request.

77. The system of claim 76, wherein the number of identity verifications to be performed is higher for a high level of risk than the number of identity verifications to be performed for a low level of risk.

78. The system of claim 74, wherein each of the plurality of identity servers is configured to: decrypt the encrypted identity type information with the application’s public key; and verify the identity type information on a condition that the decrypted identity type information matches a corresponding identity type information stored by the identity server.

79. The system of claim 78, wherein: the encrypted identity type information is an identifier associated with the user; and the corresponding identity type information is a same identifier associated with the user that was previously captured and stored by the identity server.

80. The system of claim 78, wherein: the corresponding identity type information stored by the identity server is sharded; and each shard is stored in a separate location.

81. The system of claim 80, wherein each identity server is further configured to reconstruct the corresponding identity type information with a threshold number of shards, wherein the threshold number of shards is fewer than a total number of shards.

82. The system of claim 74, wherein each identity server is further configured to: generate and sign a second token, wherein the second token includes an indication whether the identity server verified the identity type information; and send the signed second token to the user device.

83. The system of claim 82, wherein the user device is further configured to: send the signed second token to the authentication server as proof of authentication by the identity server.

84. The system of claim 83, wherein the authentication server is further configured to: send the signed token to the user device on a condition that the authentication server has received a number of signed second tokens from the user device including positive indications that equals the number of identity verifications to be performed as determined by the risk level for the access request.