Invented by Jonathan WEIMER, Ryan Fox, Capital One Services LLC

The market for blockchain systems for user authentication has been rapidly growing in recent years, as businesses and organizations seek more secure and efficient ways to verify the identities of their users. Blockchain technology, originally developed for cryptocurrencies like Bitcoin, has proven to be a game-changer in various industries, and user authentication is no exception. Traditional user authentication methods, such as passwords and two-factor authentication, have long been plagued by security vulnerabilities. Passwords can be easily hacked or stolen, and two-factor authentication methods like SMS codes can be intercepted by hackers. These weaknesses have led to an increase in identity theft and unauthorized access to sensitive information. Blockchain technology offers a decentralized and tamper-proof solution to these authentication challenges. By leveraging the immutability and transparency of blockchain, user authentication systems can provide a higher level of security and trust. Blockchain-based authentication systems store user credentials on a distributed ledger, eliminating the need for centralized databases that are vulnerable to hacking. One of the key advantages of blockchain-based authentication systems is the elimination of single points of failure. With traditional authentication methods, if a central server is compromised, all user credentials are at risk. In contrast, blockchain systems distribute user data across multiple nodes, making it virtually impossible for hackers to tamper with or steal the information. Moreover, blockchain authentication systems can enhance user privacy. Instead of relying on third-party identity providers, users can have more control over their personal information. They can choose which attributes to disclose and to whom, reducing the risk of data breaches and unauthorized access. The implementation of blockchain-based authentication systems varies across industries. In the financial sector, blockchain can be used to secure online banking and payment systems. By replacing passwords with blockchain-based authentication, banks can significantly reduce the risk of fraud and identity theft. In the healthcare industry, blockchain authentication systems can ensure the privacy and integrity of patient records. Medical data stored on a blockchain can be securely accessed by authorized healthcare providers, while patients retain control over their personal information. Blockchain authentication is also gaining traction in the e-commerce sector. By implementing blockchain-based user authentication, online retailers can protect customer data and prevent unauthorized access to accounts. This can lead to increased customer trust and loyalty, as consumers become more aware of the importance of data security. However, despite the numerous benefits, there are still challenges to overcome in the widespread adoption of blockchain-based authentication systems. One of the main obstacles is the scalability of blockchain technology. As more users join the network, the transaction processing time can increase, potentially leading to delays in user authentication. Additionally, the complexity of blockchain technology may pose a barrier to implementation for some organizations. Developing and maintaining a blockchain-based authentication system requires specialized knowledge and resources. Therefore, partnerships with blockchain solution providers or the use of pre-built platforms may be necessary for organizations looking to adopt this technology. In conclusion, the market for blockchain systems for user authentication is expanding rapidly as businesses and organizations recognize the need for more secure and efficient authentication methods. Blockchain technology offers a decentralized, tamper-proof, and privacy-enhancing solution to traditional authentication challenges. While there are still challenges to overcome, the benefits of blockchain authentication systems make them a promising solution for industries seeking to enhance data security and user trust.

The Capital One Services LLC invention works as follows

Computer-implemented methods and systems are provided for blockchain-mediated user authentication. In accordance with the disclosed embodiments of authentication, it may include operations such as receiving an authentication request from a system user for a particular user. These operations can also include determining the root system of the user by using a Blockchain, and redirecting to the root system. After redirection, the operations can include receiving a message that indicates the root has successfully authenticated the users. The message may also contain an authorization code to receive a secret from the root. Receiving identification data from a database using the root secret may be part of the operations. Determining the system root may include identifying a block in the blockchain that stores root system information using authentication requests and index information. Receiving the identity data can include retrieving the data from the database.

Background for Blockchain systems for user authentication and their implementation

Users may interact with computers associated with more than one institution. These institutions can configure their computer systems so that users who attempt to access them must be authenticated. The implementation of such authentication requirements may be a time-consuming and resource-intensive process for institutions. Users may also resent being asked to confirm their identity repeatedly as they move between computers associated with different institutions. Users and institutions may benefit from an authentication system that manages authentication interactions across multiple institutions.

But such collaboration is not possible without overcoming some technical issues.” The preferred authentication system would be one that tracks authentication interactions of users trying to access computer systems at participating institutions. This authentication system is not reputable and prevents users or institutions from challenging authentication records later as inaccurate or false. A preferred authentication system would also limit the sharing of personal data between users and institutions. The authentication system should also be designed in a manner that encourages participating institutions to have confidence in the authenticity of authentication records. There is a need for an authentication architecture that can address these technical issues. These embodiments are a concrete example of an authentication system architecture.

The disclosed embodiments relate to an authentication system which maintains a distributed and non-reputable record of authentication interaction, while restricting the sharing of personal data between institutions. This authentication system can be used by several participating member systems. This system, which is described below in more detail, solves these technical problems.

In some embodiments, the root system can establish an identity for every user of the authentication systems. The root system can store information on a blockchain. These information could be used by other members of an authentication system to locate a root system. The root system can also store user identification data in a database. The root system may be used by member systems to authenticate users and retrieve stored identification data. The blockchain could provide a non-reliable, distributed record of interactions between a user, member systems and the root system.

The disclosed embodiments can include, for instance, an authentication system consisting of at least one processor and at least a non-transitory storage. The non-transitory storage may contain instructions which, when executed by at least one processor cause the authentication system perform operations. Operation may include receiving an authentication request from a system user for a particular user. The operations can also include determining the root system of the user by using a Blockchain, and redirecting to the root system. “The operations may also include receiving a root secret from the root and receiving identification data from a database using the secret.

The disclosed embodiments can also include an authentication system that includes at least one processor and at least non-transitory storage. The non-transitory storage may contain instructions which, when executed by at least one processor cause the authentication system perform operations. Operation may include receiving personal information about a user. The operations can also include generating index and identification information for the user based on the personal information received. “The operations may also include writing the index and root system information to a Blockchain, encrypting identification data with a root key and storing it in a database.

It is understood that the general description above and the detailed description below are only exemplary and explanatory and do not restrict the disclosed embodiments as claimed.

The accompanying drawings illustrate the examples of the disclosed embodiments. The same reference numbers are used to refer to similar or identical parts wherever possible.

FIG. The figure 1 shows a schematic for an authentication system (authentication 100) that is consistent with the disclosed embodiments. The authentication system 100 can include systems that have access to database 109 and blockchain 105 over network 111. The authentication system 100 allows systems to share information about user authentication and the responsibility of authenticating users. As described below, systems may authenticate users for each user. This system is the root system of this user (e.g. root system 107). This system can create a message on blockchain 105 that corresponds to the user. This entry can indicate the user and give root system information to contact root system 107. The root system 107 can also be configured so that it creates an entry in the database 109 which stores identification data of user. The member systems (e.g. member system 103) may be configured so that authentication requests for the user are sent to root system 107 by a user system. After root system 107 authenticates the user, the member system can be configured to retrieve the identification data from database 109. The member system can be configured to record this authentication transaction on blockchain 105.

The disclosed system can use the root to store securely personal information.” The disclosed authentication system may also create a non-reputable record of authentication interactions by using a Blockchain, which provides information that allows the participating systems contact the root system. This blockchain can also be distributed to encourage trust in the authenticity of authentication interaction records. The disclosed authentication systems offer a technical solution that is innovative to the technical problems of collaborative authentication systems.

As anyone skilled in the art would recognize, the description of the authentication system 100 shown in FIG. The purpose of FIG. 1 is not to limit the scope. In certain embodiments, other elements can be added and/or the elements depicted in authentication system 100 can be combined, divided or modified. As an example, envisioned embodiments could implement a subset or superset of the elements depicted in authentication system 100. In some embodiments, for example, one or both of the blockchains 105 and databases 109 can be implemented by an element of authentication system (e.g. member system 103, root system 107)”.

User System 101″ may be configured to send an authentication request in accordance with disclosed embodiments. The user system 101 can be a computing device such as a desktop, server, laptop, phablet or smartphone. The following description will be made with reference to FIG. 7 User system 101 can be configured with input/output and display interfaces. The display and input/output user interfaces can be used to interact with an unknown user. Based on the interaction, user system 101 can be configured to contact a member system 103. User system 101 can be configured to act as an “end-user”. OpenID authentication 2.0 Final describes how to configure a user system 101 as an ‘end-user. OpenID is referred to as “OpenID” herein. “OpenID” is referred to herein as?OpenID?

Member system” 103 can be configured in accordance with the disclosed embodiments to authenticate users. The member system 103 can include one or multiple computing devices such as workstations or desktop computers. Members systems (e.g. member system 103) can act as “relying parties”. OpenID is a framework for OpenID, described in OpenID. This document incorporates this description by reference. The member system 103 can be a standalone system or a part of another system. Member system 103, for example, may be linked to a commercial institution. The member system 103 can include distributed servers located remotely that communicate with the other systems in the financial institution via a public or private network.

Member system” 103 can be configured to accept a request for authentication of a user. In some embodiments the member system 103 can be configured to accept a request from another element in authentication system 100 such as user system 101 or another system. To process the authentication requests, member system 103 can be configured to communicate with blockchain 105 and root system 107. In some embodiments processing the authentication may include receiving identification data from database 110. The member system 103 can be configured to utilize this identification data in order to complete a business procedure. The business process, for example, may require the identification of customers in accordance with statutory or regulatory guidelines. These guidelines may be satisfied by the receipt of identification data. “As an example, the data received may be used to fill out forms, accelerating the business process, and improving customer experience.

In accordance with the disclosed embodiments, “Member system” 103 could be configured to store messages on blockchain 105. In certain aspects, member system may be configured so that it adds blocks containing messages to blockchain 105. Member system 103 can be configured in various ways to send the messages to an approved system. The authorized system can be configured to add the blocks containing messages to blockchain 105. The following description is based on FIG. “According to FIG. 3A, messages can include index information 303 or authentication records 307.

Blockchain 105″ may consist of a distributed datastructure, in accordance with the disclosed embodiments. Blockchain 105 can be a private chain. As an example, authorized systems can store copies of the blockchain 105. These authorized systems can be configured to publish blocks to other systems and add new blocks to the blockchain 105. These authorized systems can be configured to receive messages for publication on blockchain 105 from other systems. These other systems could only have a read-only view of blockchain 105. In certain embodiments, root system 107 and at least one member system 103 are authorized systems. In some embodiments, root system 107 and member system 103 may not be authorized. FIG. 3A is described in more detail. “According to FIG. 3A, the blockchain 105 can be configured to store messages sent by member systems, including authentication records 307 and messages from root systems, including root system information.

According to the disclosed embodiments, “Root system” 107 can be configured to authenticate user. Root system 107 can include one or multiple computing devices such as workstations or desktop computers. In certain embodiments, the root system 107 can be linked to an OpenID connect point. The OpenID connect endpoint, as would be understood by a person of expertise in the field, may allow the root system to act as an identity provider. The root system 107 can be a standalone system or it can be a part of subsystems that are part of larger systems. Root system 107, for example, may be linked to a commercial institution. Root system 107 can include distributed servers located remotely that communicate with other financial institutions over a public or private network. Root system 107 can be configured to accept a request for authentication of a user. In some embodiments root system 107 can be configured to receive a request from an element of authentication system, such as the user system 101 or another system.

Database 109 can be configured to store user identification data, in accordance with the disclosed embodiments. Database 109 can be a distributed database in some aspects. Database 109, for example, may be a federated data base. Database 109 can also include a distributed hashtable. Nodes of the distributed hashtable may, in some aspects, be associated with members (e.g. member system 103 or root system 107) of authentication system 100.

Network 111″ may be configured in a way that it provides communications between the components shown in FIG. 1. “For example, network 11 may be any network (including infrastructures) which provides communications, exchanges data, and/or facilitates exchange of data, such as Internet, Local Area Networks, or any other suitable connections that enable authentication system 100 send and receives information between components of authentication system.

FIG. The 2 shows a logical representation of an example blockchain in accordance with the disclosed embodiments. Blockchain 105 can include many blockchains that are maintained by different systems, such as member system 103 or root system 107. These exemplary blockchains can be composed of blocks (e.g., blocks 201a-201d), messages (e.g., message 207b and message 27d), or a header (e.g., header 202b). The header can include at least one hash from the previous block (e.g. hash 203b), hash of messages within the block (e.g. a Merkle Root) and timestamp. In accordance with the disclosed embodiments of authentication system 100, blocks added to blockchain 10 may be required to satisfy at least one condition. This condition can be either a digital signing condition or a proof-of work condition. The header, for example, may include a random number chosen to ensure that the header meets the proof-of work condition. The proof-of work condition could, for example, require that the hash value of the header falls within a range of predetermined values. The header can also be digitally-signed with a cryptographic system key and the digital signature included. This digital signature can be verified by using a key that is available to members of authentication system.

FIG. 3A shows a logical representation of a message (207 b) stored in a chain (e.g. an element of the blockchain 105), which is consistent with embodiments disclosed. In certain embodiments, the message 207b may include index information 303. Index information 303 can include information that identifies a user in certain aspects. Index information 303 can include, for example, a user’s full name, an email address, a phone number or any other non-sensitive information. Index information 303 can include references to previous blocks on the private blockchain. Index information 303, for example, may include references to earlier blocks that are associated with the user. As an example of a reference, it may be a hash from a previous block in the chain associated with the user. Index information 303 can be encrypted or obfuscated in some aspects using methods that are known to those of ordinary skill. Index information 303, for example, may be encrypted using a cryptographic code. Index information 303 can also be a hash containing at least one full name, an email address, a phone number or any other non-sensitive information about the user.

Click here to view the patent on Google Patents.