Invention for Blockchain platform – Identity system to be used with

Invented by Shawn Jafari TABRIZI, Microsoft Technology Licensing LLC

Blockchain technology has revolutionized various industries, and one area where it has immense potential is in the development of identity systems. With the increasing need for secure and reliable digital identities, blockchain platforms are emerging as a promising solution.

The market for blockchain platforms that offer identity systems is growing rapidly. These platforms provide a decentralized and tamper-proof way of managing identities, ensuring privacy, security, and control over personal information. They eliminate the need for intermediaries and central authorities, reducing the risk of data breaches and identity theft.

One key advantage of blockchain-based identity systems is the ability to establish trust without relying on a single entity. Traditional identity systems often require individuals to share their personal information with multiple organizations, increasing the risk of data leaks. Blockchain platforms, on the other hand, enable users to have full control over their identity information and decide who can access it.

Moreover, blockchain platforms offer enhanced privacy by allowing users to share only the necessary information required for a particular transaction or interaction. This selective disclosure of information ensures that personal data is not unnecessarily exposed, reducing the risk of identity fraud.

The market for blockchain platforms offering identity systems is not limited to a specific industry. It has applications in various sectors, including finance, healthcare, supply chain, and government services. In the financial sector, blockchain-based identity systems can streamline customer onboarding processes, reduce fraud, and enhance regulatory compliance.

In healthcare, blockchain platforms can securely store and share patient records, ensuring interoperability and data integrity. This can lead to improved healthcare outcomes, reduced administrative costs, and better patient experiences.

Supply chain management can also benefit from blockchain-based identity systems. By providing a transparent and immutable record of each participant’s identity and transaction history, these platforms can enhance traceability, reduce counterfeiting, and improve supply chain efficiency.

Government services can leverage blockchain-based identity systems to provide secure and efficient citizen services. From issuing digital identities to managing voting systems, blockchain platforms can enhance transparency, reduce corruption, and increase trust in government processes.

As the market for blockchain platforms offering identity systems continues to grow, several key players have emerged. Companies like IBM, Microsoft, and Oracle are investing heavily in developing blockchain solutions for identity management. Startups such as Civic, uPort, and Sovrin are also making significant contributions to this market.

However, challenges still exist in the widespread adoption of blockchain-based identity systems. Interoperability between different blockchain platforms and legacy systems remains a hurdle. Moreover, regulatory frameworks and standards need to be established to ensure compliance and protect user rights.

In conclusion, the market for blockchain platforms offering identity systems is witnessing significant growth and holds immense potential. The benefits of enhanced security, privacy, and control over personal information make these platforms attractive to various industries. As technology advances and regulatory frameworks evolve, blockchain-based identity systems are likely to become a mainstream solution for secure and reliable digital identities.

The Microsoft Technology Licensing LLC invention works as follows

An Identity System is Provided that can include an Attestation Service that is configured for communication with a user computing device and a Blockchain Platform, and creates a Blockchain Account on the Blockchain Platform, the account has an associated backend identity blockchain application. The attestation system may be further configured to verify that the user of the computing device has a blockchain account for the user by obtaining signed messages from the user. The signed message can include a user’s access token generated by an identity provider service and a blockchain account of the owner to be associated with the token. The attestation service can be configured to identify and store one or more claims of identity associated with the token.

Background for Blockchain platform – Identity system to be used with

Blockchain identity is anonymous and costs little or nothing for users to create.” Sybil attacks are a threat to decentralized apps built with blockchain technology. These attacks are when a malicious actor creates a large amount of accounts and uses them to subvert the decentralized application.

On the contrary, web-based apps of today use trusted identity providers that allow information about the owner of the ID to be easily transferred and persistent between different web applications. This allows both the user as well as the application provider to add social value to the identity of the user by using it across different web-based apps. Blockchain technologies currently do not allow for such cross-platform use of trusted identities.

An Identity System is Provided that can include an Attestation Service executed on a First Server having a Processor and Non-Volatile Memory associated with it. The attestation server may be configured to communicate over a computer network via a user device and a Blockchain platform that is executed on at the very least a second computer. The attestation server may execute instructions in the non-volatile storage via the processor, to create a Blockchain account on the blockchain platform for the attestation services. This account will have an associated backend identity blockchain application. The attestation server may be configured to obtain a message signed using a private key belonging to the user and determine whether the user owns a blockchain account. The signed message can include a user’s access token from the user computing device, and a blockchain account of the owner to be associated with the token. The attestation service can be configured to identify and store one or more claims of identity associated with the token.

This Summary is intended to present a number of concepts that will be further explained in the detailed description. This Summary does not aim to identify the key features or essential elements of the subject matter claimed, nor to limit its scope. The claimed subject matter does not limit itself to solutions that address all or some of the disadvantages mentioned in this disclosure.

The development and use of Ethereum and other Blockchain platforms provide application developers with the platform they need to create open applications that are distributed, decentralized and censorship-free. These applications are usually limited to the user accounts and applications available on these blockchain platforms. User accounts are usually easy to create and free for users on blockchain platforms. To create a new account, for example, the blockchain platform or a computer device of the user may be configured to automatically generate a random 256-bit number to serve as a private key. The probability of generating a private key that is unique is 1/N where N is the total number of private keys. {In this example, the number of possible private keys is 2In this example, there are 2circumflexes over (? )256 (approximately 10In this example, the number of possible private keys is 2circumflex (????????????????????????????????????????????????????????????????????????????????????????????)256 (approximately tencircumflex (???????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????)????????????????????????????????????????????)?)?)?)?????????????????????????????????????????????????????????????????????????????????????)77) and the chance?) a certain exactly?)? )77) and the chance of getting a certain exact private key is 10circumflex over (?)?77.|The chance of getting an exact private key for a given account is 10circumflex above (?)}?77.} Having access to the private key that can be used to sign transactions in the blockchain platform strongly indicates the account owner.

However due to their easy and free nature, a user can create and control a huge number of accounts anonymously. Sybil attacks are therefore possible on blockchain platforms. A single user can use a large number accounts to exert a disproportionately high influence on an application running on the blockchain. A voting application is an example of a blockchain application that allows a user to use a large number accounts to influence a vote in a certain direction. If blockchain technology was used to create a platform for social networks, then the platform would be susceptible to Sybil attacks and other types.

To address these issues FIG. The example computing system 100 is configured to allow a user to link their identity data, stored by a trusted provider of identity 102, with an anonymous account previously on a Blockchain platform 104 through an attestation services 106. The attestation server 106 can be run at least partially on a first computer, such as a middle-tier computer system (114) of the computing system 100. The middle tier computing system 114 can include a processor and associated non-volatile storage, as well as other computer components. Middle tier computer systems 114 can be configured to communicate via a computer networking, such as a wide-area network (WAN), with the blockchain platform and a user device computer 108. A user computer device 108 may be used to interact with the trusted identification provider 102 and the blockchain platform. According to the description above, a user can create a user account 110 on the blockchain platform by using the software running in the browser of the user computer device. It should be noted that the private keys 112 can be generated by other software and computer devices. For example, the middle-tier computer system of the attestation services 106 will be described below.

Due to security concerns, it is common for users to store the private key 112 of the user’s blockchain account 110 on a separate user storage device, such as an external hard drive or thumb drive. It should be noted that the private key for the user account 110 can be stored at other locations. For example, on the computer device 108 of the user, the middle-tier computer system (114), or any other computer service that is configured to manage the users’ private keys 112.

The trusted identifier 102 can take the form of a system that provides trusted identities, like, for instance, MICROSOFT AZURE ACTIVE DIRECTORY. It is important to note that the trusted provider 102 can take on other forms, such as social networks like LINKEDIN or FACEBOOK, banks, government agencies, and other platforms that store identity data 118. User computer devices 108 can be used to interact with trusted identity providers 102 in order to manage user accounts 120 and stored user data 118. The type of trusted provider 102 can affect the types of user data 118 that are collected. Azure Active Directory, for example, may manage user identity data that includes the employer of the user (e.g. An employer identification, security group data, the first and/or the last name of the user, their home or workplace location, their language preferences, and the subscriptions they have to different applications (e.g. OFFICE, POWERPOINT, etc. (OFFICE, POWERPOINT, etc. ), user’s demographic data, etc. As an example, user identity data 118 that is managed by the social network’s trusted identity provider may include the name of the user, his or her demographic data, their schooling, connections, and friends. Another example is the user identity data managed by an entity such as the government. This data may include the citizen status of the user, their birthplace, and licensing information, like a driver?s license. The examples of user data 118 described in the above paragraphs are only exemplary. Any other types of suitable user data 118 can be collected and managed.

As shown in FIG. The attestation service is configured to perform these actions.

(1) Verify that the user can access the account 120 of a trusted identity provider selected 102.

(2) Provide proof that the user is the owner of the blockchain platform 104 user account 110.

(3) Attest user identity claims using the user data 118 that is received from the trusted provider 102 and make these user identity claims accessible to third-party applications 122 on blockchain platform 104.

The above steps 1-3 can be performed by an attestation system 106 middle-tier computer system (e.g., a computer running the blockchain platform 104) that interacts with the trusted identification provider 102, user computer device 108 and the backend blockchain app 124, which runs on the blockchain service platform 104. In one example the middle tier system 114 is configured to create a blockchain account 150 for the attestation service 106 on the blockchain platform 104. First server is configured to create the blockchain account 150 on the blockchain platform for the attestation services 106. The blockchain account 150 for the attestation services 106, as shown in the illustration, is linked to the backend blockchain applications 124 that run on the platform 104. The backend application 124 of the attestation service 106 is a backend identity application configured to receive a query for identity from a 122 third-party application associated with a executing third-party application on a server. The backend blockchain application identity may be configured, after receiving the identity request, to transmit a reply to the identity question, as discussed below in greater detail with reference to FIG. 2.

As used in this document, the term “blockchain application” is used. “A’smart contract’ is a ‘blockchain application. The blockchain platform 104 can run computer code that is immutably stored in the blockchain 126. In one example, a distributed virtual computer is included in the platform to run the computer code for smart contracts by using the hardware resources from client computing devices that are participating in the platform. These distributed client computing systems may each store a copy the blockchain of the Blockchain platform 104. They can also verify the contents, execute smart contract computer codes in the blockchain, and confirm the execution with other client computers on the Blockchain platform 104. A second server may execute at least part of the processes and functions of the Blockchain Platform 104 in conjunction with client computing devices that are participating in the Blockchain Platform 104. ETHEREUM is one example of a blockchain platform 104 that includes these features. It should be noted that the processes described in this document are applicable to any other blockchain platform 104 with these features.

The backend blockchain application includes functions and methods which may be used by different third-party applications 122 in order to confirm one of more claims made by a user for their blockchain account 110, as attested by the attestation services 106.

Steps 1-3 can be done in a variety of ways. FIG. Figure 2 shows an example of a specific process to perform the steps 1 – 3 shown in FIG. 1. The attestation service 106 can be configured using OAuth 2.0 to prove that the user is able to access the user account data 118 on the selected trusted identity providers 102. OAuth 2.0 can be used by the trusted provider 102 in order to give the attestation services 106 data from the user account without giving them access to the passwords for the user accounts 120.

As shown in FIG. The user can interact with the GUI 128 on a web front-end 130 that is run by one or several web servers. The web frontend 130 may include a script package from the attestation services for verifying that the user is in control of the user account 120 at the trusted identity provider. This verification can then be passed to the middle-tier computer system 114, which runs the attestation server 106.

At (1A), the web front-end 130 may be configured in a way that it communicates with the trusted Identity Provider 102, according to processes specified by OAuth 2.0. This allows the user access to their data on the user account 120 at the trusted Identity Provider 102 without having to share credentials with the attestation services 106. The OAuth 2.0 protocol allows the trusted identity provider 102 to receive credentials from the user (e.g. Login/Password for the user account and audience value of the middle-tier computer system. The trusted identity provider 102 can generate a signed token 152 according to OAuth 2.0 protocol for the user at (1B), and then send that signed token 152 to the computer device 108 of the user. The signed access key 152 can be checked to ensure that it is signed correctly for the trusted provider 102. This will prove that the person who holds the signed access key 152 has the right to access the user account 120 of the trusted provider 102. The signed access token 152 has an audience value which includes the middle-tier computer system (114) of the attestation services 106. This proves that the signed token 152 was intended to be used for verifying the user’s account 120 on the trusted provider 120. The attestation service may also use the signed access token to gain access to protected resources hosted by trusted identity provider 102, including, for example the user identity data on the account 120, with the consent of the user. In one example the attestation services 106 could retrieve the user data 118 directly from the servers of trusted identity provider 102. In another example the signed token 152 may contain the user data 118. The attestation service may be configured parse this signed token 152 in order to retrieve the data. The attestation server 106 can be configured to use the user identity data to identify and store one or multiple identity claims that are associated with the access token of the user. The one or more claims of identity may, for example, be stored in the blockchain 126 on the Blockchain platform 104.

However, you should understand that other processes can be used to verify whether the user has access the the user account 120 at the trusted identity provider 102. The trusted identity provider may, for example, provide an email address to the user in order to verify their account 120. The attestation service may use email verification processes in this example to verify the user’s access to their user account 120. The attestation service may, for instance, send an email containing a secure code or link to the email associated with the account 120. This allows the user verify their control over the account 120 and email address.

In a second example of a verification process, shown in FIG. The user can post a unique message in a field 132 that is public and accessible to the attestation services 106. If the trusted identity service 102 is, for instance, a social networking platform such as Twitter or Facebook, the user can post a message predetermined by the attestation services 106 to the social network via their account 120. The user can modify the specified public property of the public field 132, which is accessible or viewable by the attestation services 106. The attestation service can confirm the control of the user over the account 120 by detecting any changes to a specified public property such as a user avatar or address field. These methods of verification provide the benefit of asynchronous verification and registration of the user 120 account on the trusted provider 120. The user can modify or post the information at any time and the attestation services 106 will detect it asynchronously at a later time. This allows the user to control the account 120 of the trusted identity provider.

Click here to view the patent on Google Patents.


Comments

Leave a Reply

Your email address will not be published. Required fields are marked *