Claims:1. A system for authenticating a subject to access an object, the system comprising:
a software agent (406) running at a client device (402) associates with the subject (414) to generate an access token using a private key associated with a public-private key pair stored in a wallet (404) of the client device;
an authentication server (606) configured to
receives through the software agent (406) an access request to access the object (610), wherein the access request comprises a decentralized ID (DID) associated with the wallet (404) and the access token;
validate with a client ID registry whether the subject has the right to request the object (610); and
in response to affirmative validation:
request to a distributed ledger (608) for a DID document;
receive from the distributed ledger (608), the DID document, a blockchain address associated with the DID document, and a public key associated with the DID document;
recover a public key from the access token using a cryptographic key recovery engine;
recover a blockchain address from the public key;
determine whether the blockchain address associated with the DID document matches the recovered blockchain address, and the public key associated with the DID document matches the recovered public key; and
in response to an affirmative determination, approve the access request initiated for the object.

2. The system of claim 1, wherein the software agent is a client-side Software Development Kit (SDK) (406).

3. The system of claim 1, wherein the access request is a Hypertext Transfer Protocol Secure (HTTPS) access request, and the authentication server decodes the HTTPS access request to extract access token, and the DID from a payload of the HTTPS access request.

4. The system of claim 1, wherein the cryptographic key recovery algorithm is complimentary to a cryptographic algorithm used for generating the public-private key pair

5. The system of claim 1, wherein the public, private key pair is generated using any of an ES256k, ES256k-R and Ed25519 cryptographic generator.

6. A method for authenticating a subject to access an object, the method comprising:
generating, at a client device (402) associates with the subject, by a software agent (406) an access token using a private key associated with a public-private key pair stored in a wallet (404) of the client device (402);
receiving, at an authentication server (606) through the software agent (402), an access request to access the object (610), wherein the access request comprises a decentralized ID (DID) associated with the wallet and the access token;
validating, by the authentication server (606) with a client ID registry, whether the subject has the right to request the object (610);
in response to affirmative validation:
requesting, by the authentication server (606) to a distributed ledger, for a DID document;
receiving, at the authentication server (606) from the distributed ledger, the DID document, a blockchain address associated with the DID document, and a public key associated with the DID document;
recovering, at the authentication server (606), a public key from the access token using a cryptographic key recovery engine;
recovering, at the authentication server (606), a blockchain address from the public key;
determining, at the authentication server (606), whether the blockchain address associated with the DID document matches the recovered blockchain address, and the public key associated with the DID document matches the recovered public key; and
in response to an affirmative determination:
approving, by the authentication server, access to the object (610).

7. The method of claim 1, wherein the software agent is a client-side Software Development Kit (SDK).

8. The method of claim 1, wherein the access request is a Hypertext Transfer Protocol Secure (HTTPS) access request, and the authentication server decodes the HTTPS access request to extract access token and the DID from a payload of the HTTPS access request.

9. The method of claim 1, wherein the cryptographic key recovery algorithm is complimentary to a cryptographic algorithm used for generating the public-private key pair.

10. The method of claim 1, wherein the public, private key pair is generated using any of an ES256k, ES256k-R and Ed25519 cryptographic generator.
, Description:COPYRIGHT NOTICE
[0001] Contained herein is material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction of the patent disclosure by any person as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all rights to the copyright whatsoever. Copyright © 2020, Vlinder Labs Private Limited.

FIELD OF INVENTION
[0002] Embodiments of the present disclosure generally relate to blockchain-based authentication and authorization. In particular, embodiments of the present disclosure relate to systems and methods for enabling decentralized identity (DID) based authentication and authorization of a subject to access an object.

BACKGROUND OF THE INVENTION
[0003] Authentication and authorization of an object to perform a certain activity or to access a network resource have been an active field of research for a long. The evolving landscape of different types of subjects (e.g., user, device, service, API, a function call, etc.) and objects that are subject access control requires a more efficient, secure, and convenient way of authenticating and authorizing. Access control is required for all computer systems, not only in a client/server system or a client/browser system but also in a cloud system. There are many existing solutions for authenticating and authorizing a subject to access an object. For example, a subject (user or device, etc.) can be authenticated using a combination of user name/password. Another widely used mechanism for authenticating is subject to a short message verification code or a hardware-based USB Key (Ukey) mechanism. Likewise, there are several other ways by which a subject can be authenticating. However, each of these existing mechanisms has its own limitations.
[0004] Most of the present access control systems that manage authentication and authorization require a server to maintains a secret key (e.g., password, encrypted values, etc.) For secret key management, for example, password management, existing systems store the password in their server in some form of encryption or hashing. Whenever access is required, the subject needs to provide a secret key (e.g., password) that goes through the same encryption or hashing and compares with the key stored on the server. The server authenticates the subjects of the secret key provided by the subject matches the secret key maintained by the server. If the centralized server is hacked by any third party or person and they come to know what encryption or hashing algorithm is used for secret key management, hackers can read or get access to all client's data.
OBJECT OF THE INVENTION
[0005] An object of the present disclosure is to provide an access control system and method for authenticating and authorizing a subject to access an object without storing a secret key on the authentication server.
[0006] Another object of the present disclosure is to provide a system and method for authenticating and authorizing a subject to access an object in an efficient and secure manner.
[0007] Another object of the present disclosure is to provide a system and method for passwordless less authentication and authorization.
SUMMARY
[0008] System and method for authenticating and authorizing a subject to access an object using a decentralized ID are provided. According to an embodiment, a client device associated with a subject stores the public, private key pair in a digital wallet, and when access to an object is required, a software agent (client SDK) running on the client device generates an access request using the private key. The access request includes a decentralized ID associated with the wallet and an access token generated using the private key. On receiving the access request to access the object, an authentication server validates with a client ID registry whether the subject has the right to request the object. The authentication server requests a distributed ledger for a DID document in response to an affirmative validation. The authentication server receives from the distributed ledger the DID document, a blockchain address associated with the DID document, and a public key associated with the DID document. The authentication server recovers a public key from the access token using a cryptographic key recovery engine and a blockchain address from the public key and determines whether the blockchain address associated with the DID document matches the recovered blockchain address, and the public key associated with the DID document matches the recovered public key. The authentication server approves the access request, and grants access to the object in response to an affirmative determination.
[0009] In an embodiment, the access request is sent as a Hypertext Transfer Protocol Secure (HTTPS) access request, and the authentication server decodes the HTTPS access request to extract the access token and the DID from a payload of the HTTPS access request.
[00010] In some embodiment, the cryptographic key recovery algorithm is complimentary to a cryptographic algorithm used for generating the public, private key pair. The cryptographic algorithm used to generate public-private key pair includes an ES256k, ES256k-R………………..
[00011] Other features of embodiments of the present disclosure will be apparent from accompanying drawings and detailed description that follows. 
BRIEF DESCRIPTION OF THE DRAWINGS
[00012] In the figures, similar components and/or features may have the same reference label. Further, various components of the same type may be distinguished by following the reference label with a second label that distinguishes among the similar components. If only the first reference label is used in the specification, the description applies to any one of the similar components having the same first reference label irrespective of the second reference label.
[00013] FIG. 1 illustrates an example network environment in which a decentralized ID (DID) based access control system is deployed in accordance with an embodiment of the present disclosure.
[00014] FIG. 2 illustrates the functionals blocks of a DID-based access control system in accordance with an embodiment of the present disclosure.
[00015] FIG. 3 illustrates the functional modules of a DID-based access control system in accordance with an embodiment of the present disclosure.
[00016] FIG. 4 illustrates example access request processing in accordance with an embodiment of the present disclosure.
[00017] FIG. 5 illustrates an example sequence diagram for creating DID, keys pair, and generating access token in accordance with an embodiment of the present disclosure.
[00018] FIG. 6 illustrates an example sequence diagram for access request processing in accordance with an embodiment of the present disclosure.
[00019] FIG. 7A shows a generalized embodiment of an exemplary client device used to initiate access requests in accordance with an embodiment of the present disclosure.
[00020] FIG. 7B a block diagram illustrating the component of a mobile device used to initiate access requests in accordance with an embodiment of the present disclosure.
[00021] FIG. 8 is an example flow diagram illustrating access request processing in accordance with an embodiment of the present disclosure.
DETAILED DESCRIPTION
[00022] Systems and methods are described for Decentralized ID (DID) based authentication and authorization of a subject to access an object. A DID-based system enables the registration of a subject (also referred to as a client) with an ID hub, which generates a DID for the subject and a public-private key pair. The DID hub shares the DID of the subject to a client ID registry associated with an authentication server, and shares DID along with associated public-private key pair to the client. A digital wallet associated with the client may link the DID with the client and store the public-private key pair. The client ID registry maintains only the DID and a list of allowed resources that the client can access. The system doesn’t require the authentication server or the client-side registry to store public-private key pair for authenticating the subject. When a client needs access to an object, a client-side SDK may generate an access token using the private for accessing the object and send an access request to the authentication server. The authentication server on receiving the access request, which contains DID and access token, may check if the DID is a valid ID generated by the client ID registry. The authentication server may extract the DID and validate the client using DID resolver. The DID resolver reads the distributed leader, which maintains all the activity and access rights of the client in a distributed ledger, to authenticate the access request and grant permission to access the object.
[00023] The system may facilitate easy onboarding of different organizations and help them protect their network resources. The system uses blockchain resources for registering a subject (client) and processing the access request. As one will appreciate, the system completely eliminates secret key management, which normally requires the server to store secret keys in a centralized server for a big set of clients.
[00024] Embodiments of the present disclosure include various steps, which will be described below. The steps may be performed by hardware components or may be embodied in machine-executable instructions, which may be used to cause a general-purpose or special-purpose processor programmed with the instructions to perform the steps. Alternatively, steps may be performed by a combination of hardware, software, firmware, and/or by human operators.
[00025] Embodiments of the present disclosure may be provided as a computer program product, which may include a machine-readable storage medium tangibly embodying thereon instructions, which may be used to program the computer (or other electronic devices) to perform a process. The machine-readable medium may include, but is not limited to, fixed (hard) drives, magnetic tape, floppy diskettes, optical disks, compact disc read-only memories (CD-ROMs), and magneto-optical disks, semiconductor memories, such as ROMs, PROMs, random access memories (RAMs), programmable read-only memories (PROMs), erasable PROMs (EPROMs), electrically erasable PROMs (EEPROMs), flash memory, magnetic or optical cards, or other types of media/machine-readable medium suitable for storing electronic instructions (e.g., computer programming code, such as software or firmware).
[00026] Various methods described herein may be practiced by combining one or more machine-readable storage media containing the code according to the present disclosure with appropriate standard computer hardware to execute the code contained therein. An apparatus for practicing various embodiments of the present disclosure may involve one or more computers (or one or more processors within the single computer) and storage systems containing or having network access to a computer program(s) coded in accordance with various methods described herein, and the method steps of the disclosure could be accomplished by modules, routines, subroutines, or subparts of a computer program product.
Terminology
[00027] Brief definitions of terms used throughout this application are given below.
[00028] The terms "connected" or "coupled" and related terms are used in an operational sense and are not necessarily limited to a direct connection or coupling. Thus, for example, two devices may be coupled directly or via one or more intermediary media or devices. As another example, devices may be coupled in such a way that information can be passed therebetween, while not sharing any physical connection with one another. Based on the disclosure provided herein, one of ordinary skill in the art will appreciate a variety of ways in which connection or coupling exists in accordance with the aforementioned definition.
[00029] If the specification states a component or feature "may," can," could," or "might" be included or have a characteristic, that particular component or feature is not required to be included or have the characteristic.
[00030] As used in the description herein and throughout the claims that follow, the meaning of "a," an," and "the" includes plural reference unless the context clearly dictates otherwise. Also, as used in the description herein, the meaning of "in" includes "in" and "on" unless the context clearly dictates otherwise.
[00031] The phrases "in an embodiment," "according to one embodiment," and the like generally mean the particular feature, structure, or characteristic following the phrase is included in at least one embodiment of the present disclosure and may be included in more than one embodiment of the present disclosure. Importantly, such phrases do not necessarily refer to the same embodiment.
[00032] As used herein, an identity management system generally refers to a system for identifying, authenticating, and authorizing individuals or groups of people or any subject to have access to protected objects (e.g., applications, Application Programming Interfaces (APIs), data, functions, systems or networks) by associating user/subject rights and restrictions with established identities.
[00033] While embodiments of the present disclosure have been illustrated and described, it will be clear that the disclosure is not limited to these embodiments only. Numerous modifications, changes, variations, substitutions, and equivalents, will be apparent to those skilled in the art without departing from the spirit and scope of the disclosure, as described in the claims.
[00034] Thus, it will be appreciated by those of ordinary skill in the art that the diagrams, schematics, illustrations, and the like represent conceptual views or processes illustrating systems and methods embodying this disclosure. The functions of the various elements shown in the figures may be provided through the use of dedicated hardware as well as hardware capable of executing associated software. Similarly, any switches shown in the figures are conceptual only. Their function may be carried out through the operation of program logic, through dedicated logic, through the interaction of program control and dedicated logic, or even manually, the particular technique being selectable by the entity implementing this disclosure. Those of ordinary skill in the art further understand that the exemplary hardware, software, processes, methods, and/or operating systems described herein are for illustrative purposes and, thus, are not intended to be limited to any particular name.
[00035] As used herein, and unless the context dictates otherwise, the term "coupled to" is intended to include both direct coupling (in which two elements that are coupled to each other contact each other) and indirect coupling (in which at least one additional element is located between the two elements). Therefore, the terms "coupled to" and "coupled with" are used synonymously. Within the context of this document, terms "coupled to" and "coupled with" are also used euphemistically to mean "communicatively coupled with" over a network, where two or more devices are able to exchange data with each other over the network, possibly via one or more intermediary device.
[00036] As used herein, an access control system refers to a system for identifying, authenticating, and authorizing individuals or groups of people or any subject to have access to protected objects (e.g., applications, Application Programming Interfaces (APIs), data, functions, systems or networks) by associating user/subject rights and restrictions with established identities.
[00037] The phrase “software agent” generally refers to a set of tools, libraries, relevant documents, code samples, processes, and or guides that allow a client to interact with a different system and sub-components. The software agent may be a client-side software development kit (SDK) running of a client device. The software agent is deployed on the client device in the form of a lightweight application that may utilize less than one percent of CPU and less than 200 MB of RAM and may leverage, among other things, various APIs to generate access requests.
[00038] FIG. 1 illustrates an example network environment in which a decentralized ID (DID) based access control system is deployed in accordance with an embodiment of the present disclosure. A DID, a unique identifier enabling verifiable decentralized digital identity, is used to identify any subject (e.g., a user, end-user device, an organization, a thing, a data model, an abstract entity, etc.). The DID contains URI scheme identified, DID method identifier, and DID method-specific identifier. An example, DID is “123456789abcdefghi”. In contrast to typically centralized identifiers, DIDs have been designed to decouple authentication from centralized registries, identity providers, and certificate authorities, which were vulnerable to different types of attacks. DID document may contain information associated with the DID, such as a way to cryptographically authenticate the DID controller as well as services that can be used to interest with the DID and the services that the DID can access. When access to an object needs to be granted, the DID document can be updated to reflect that permission. A DID controller can make changes to the DID documents and include DID of objects that a subject can access. A DID resolver is software and/or hardware that receives a DID and associated input metadata as input and produces a conforming DID document and associated metadata as output. A distributed ledger is used for recording DIDs and retrieving datapoint necessary to produce DID documents. Specifically, while other parties might be used to help enable the discovery of information related to a DID, the DID based authentication enables a controller of a DID to prove control over it without requiring permission from any other party. DIDs are URIs that associate a DID subject with a DID document allowing trustable interactions associated with that subject.
[00039] Each subject, for example, client 108a-n, needs to get a DID for a selected blockchain environment. A subject that needs to access objects that are controlled by access control mechanisms using different blockchains (Ethereum, bitcoin, etc.) needs to get DID for each blockchain separately. For the purpose of simplicity, we are considering access to all the resources ( also referred to as objects) are controlled using one blockchain environment (e.g., Ethereum). Each client may have a digital wallet (e.g., wallets 112a-n) configured to store public-private key pair for a DID assign to the client, and a software agent (e.g., SDK 110a-n) to invoke the right set of APIs, pull the key from the wallet and initiate access request. Each client may have as many DIDs as it needs to respect the desired separation of identities, personas, and contexts. Wallet 112a may store multiple DIDs, and the software agent 110a uses appropriate DID depending on context (e.g., object being requested). The software agent scopes the use of DIDs to the most appropriate contexts.
[00040] An authentication server 102 receives an access request from client 108a-n, which may be a user, an end-user device, an application, or a service, referred interchangeably as a subject for access of an object. The object, for example, may include an application 114, APIs 116, data 118, and a function 120 or any network resources. An authentication server 102 connected to the network 106 implements access control for protected objects. The authenticated server 102 receives access requests, which include DID and access token generated by a software agent (e.g., SDK 110a). The software agent (e.g., SDK 110a) generates the access token using a private key of a public-private key pair stored in a digital wallet (e.g., wallet 112a). On receiving the access request, the authentication server 102 verifies the DID using a registry validation server running on a client ID registry. The authentication server 102 further decodes the access request if the access request is a Hypertext Transfer Protocol Secure (HTTPS) access request and extracts the access token and DID from the access request. The server 102 requests DID document from distributed ledger through DID resolver 102. The DID resolver 104 may read the distributed ledger and obtain a DID document and share the DID document along with the discovered blockchain address and discovered public key with the server. Server 102 recovers public key from access token using a cryptographic recovery engine implementing a cryptographic algorithm(e.g., ES256K). Server 102 may further recover a blockchain address from the recovered public key. Server 102 will compare the discovered public key and discovered blockchain address with the recovered public key and the recovered blockchain address. If the said comparison is affirmative, server 102 may allow the client to access the requested object. Before making the access request, the client 108a-n needs to get DID from a client ID hub.
[00041] FIG. 2 illustrates the functionals blocks of DID based access control system in accordance with an embodiment of the present disclosure. An ID hub 204, generally referred to as a DID controller in a blockchain environment, generates DID, which is a uniquely binding cryptographic proof with the identifier, typically using a public-private key-pair. Suitable cryptographic algorithms, such as ES256K, ES256K-R and Ed25519 , can be used for creating the DID. The DID is recorded in a DID registry 206 in such a manner as to be able to resolve to a DID Document. The DID Document may be dynamically and deterministically generated through resolution, or it may be explicitly constructed as a stand-alone resource and either stored or referenced in the registry. The controller publishes the DID with public proof material that can be accessed by a DID resolver 212 (connection is not shown). The DID and public-private key pair are shared with the client 202 that stores the DID and public-private key pair in a secure digital wallet. DID is generated for each client (subject) and resource (object) that are part of protected enterprise resources. As one will appreciate, a client may change its role to act as a resource which access of the client needs to be controlled, and similarly, the resource may act as the client when it needs to get verified to access other resources.
[00042] When access to resource 210 is needed, client 202 generates an access token using a private key of the public-private key pair stored in the wallet. An access request that includes DID and the access token is sent from the client 202 to an authentication server 208. The client 202 may use a software agent (e.g., a client SDK) to generate the access token and communicate with the authentication server 208. Appropriate Application Program Interfaces (APIs) can be used by the software agent for inter-device communication and for communicating with the authentication server 208. Although authentication server 208 is shown as the device processing the access request, one skilled in the art will appreciate that the access request is processed in a distributed manner using the blockchain resources. The authentication server, on receiving the access request, which may in the form of an HTTPS access request, decode the HTTPS access request and extract the DID and the access token.
[00043] The wallet in some implementation can act as a controller and can be used to prove that the client presenting a DID is, in fact, its DID Controller or specified as a Controller for a particular service endpoint. The authentication process uses the cryptographic material in the DID Document to test if the claimed controller can, in fact, prove control, typically through some sort of challenge-response. The wallet (controller) may use cryptographic key pair associated with that found in a DID Document to sign access token. The access token can later be verified to demonstrate the authenticity of the client. The access token signed by DID the authentication server may use the cryptographic material (public key) in the DID Document to verify the access token (signature). The authentication server 208 refers to a DID resolver 212 that can read distributed ledger 214 (DLT 214) to verify the access token and, once the access token is verified, authorize access of resource 210.
[00044] FIG. 3 illustrates the functional modules of a DID based access control system in accordance with an embodiment of the present disclosure. A DID-based access control system 302 includes an access token generation module 304, also referred to as a software agent, running at a client device associates with a subject to generate an access token to access an object. Module 304 uses a private key associated with a public-private key pair stored in a wallet of the client device to sign access token. The subject needs to verify its identity to access the object. The client device may send an access request, which includes a pre-generated DID for the client and a DID-signed access token. The DID-signed access token is signed using a private key.
[00045] The system 302 includes an access request receiving module 306 configured to receive access requests at an authentication server, which may be a blockchain resource and not necessarily a centralized server. The access request receiving module 306 receives from the software agent an access request to access the object. A validation module 308 of the system 302 may validate with a client ID registry whether the subject has the right to request the object and if the DID is a recognized DID, and a DID-based authentication module 310 may authenticate the subject based on the DID. In response to affirmative validation, the DID-based authentication module 310 requests to a distributed ledger for a DID document and receives from the distributed ledger the DID document, a blockchain address associated with the DID document, and a public key associated with the DID document. Module 310 recover a public key from the access token using a cryptographic key recovery engine and recover a blockchain address from the public key. Module 310 determines whether the blockchain address associated with the DID document matches the recovered blockchain address, and the public key associated with the DID document matches the recovered public key, and in response to an affirmative determination, approve the access request initiated for the object.
[00046] The system checks the decentralized ID and access token (digital signature) in a blockchain to validate that the client is actually the owner of DID. The system may allow the software agent (client SDK) to set an expiry time as well. Once the system authenticates the access request, the client may not need to be verified again if the subsequent access request is sent before the expiry time. The same access token (digital signature) can be used for subsequent requests until that digital signature expires. The system 302 can be used for full resource allocation management. The DID document associated with the DID can be updated to reflect which resource the client has access to, and the access to the resource after DID validation can be granted when the DID document associated with the DID indicates so. The DID registry maintains the list of allowed resources. Once DID is resolved, the system gets the DID and then check the DID in our client ID registry and matched it, and then allow only those entitled resources that the client is entitled to.
[00047] As shown in FIG. 2, for performing client-server (resource) authentication and authorization, the ID Hub 204 creates blockchain decentralized ID (DID) and also the corresponding key pair, and the client ID registry provides cryptographic keys (public-private key pair) and maintains in a distributed ledger the DID document. “Key Pair” is basically a cryptographic key pair that has both public and private keys.
[00048] Whenever the client logs in, the system validates its identity access to protected resources. As one will appreciate, the system validates on the client on the fly from the DID and does not need to store the private key on any central device. The system only stores decentralized client ID (DID) in client ID registry 206. The system 302, in other words, performs client profile management using decentralized ID.
[00049] System 302 enables multiple integrators and efficient onboarding for an organization in DID based access control environment. The system may allow onboarding multiple integrators and subscribe to DID based access control mechanism so that an organization can use our blockchain resources and need not maintain authentication server infrastructure of its own. The system 302 completely eliminates secret key management, which typically requires one to store keys in our centralized server.
[00050] FIG. 4 illustrates example access request processing in accordance with an embodiment of the present disclosure. When a user 414 needs to access a protected resource through client device 402, the user may request access to the protected resource through an interactive user interface or a mobile application. The client device 402 may store the DID of the user 414 and its associated public-private key pair 410 in wallet app 404. To access a protected resource 408, a client SDK 406 may pull the private key, generate an access token and send the access request, which includes the DID and access token to a blockchain resource to validate its identity. As one will appreciate, for resources tagged with different DID methods, such as bitcoin, Hyperledger Fabric, Corda, sovrin, Ethereum, etc., different DIDs may be stored in the Wallet app 404. The SDK 406 may pull the right DID and use the corresponding private key to sign/generate an access token depending on the resource being requested. On receiving the access request, the corresponding DID method is used to receive the public key and resolve the DID. The resolved DID verify against the ID registry before granting access to the protected resource.
[00051] FIG. 5 illustrates an example sequence diagram for creating DID, keys pair, and generating access token in accordance with an embodiment of the present disclosure. A client 502, for example, a user who needs to register with the DID-based access control system needs to register. The user may provide registration information (e.g., name, nationality, mobile number, email address, SSN, AADHAR, biometric credentials, etc.) through an interactive user interface. Part of the registration information, for example, biometric credentials, can be retrieved using one or more sensor and/or I/O interface attacked with the client device. A client ID hub 506 using the registration information generates DID and corresponding public-private ley pair using a cryptographic algorithm. The client ID hub 506 may use an ES256k cryptographic generator or ES256k-R algorithm to generate public-private key pairs. Once the DID is generated, the client ID hub 506 shared the DID with the client ID registry 508, which maintains rights associated with the DID. The client ID hub 506 share the DID (client ID) and the public-private key pair with the client 502. Its the responsibility of client 502 to keep the private key secure. In an embodiment, the client may use a digital wallet to store the public-private key pair.
[00052] After registration, when client 502 needs to access a protected resource, the client SDK 504 may pull the DID and private key from the client's wallet and create an access token by signing the DID using a private key. In an embodiment, the client SDK 504 may sign the access token using the ES256K-R algorithm. The client sends the access request, which includes DID and access token.
[00053] FIG. 6 illustrates an example sequence diagram for access request processing in accordance with an embodiment of the present disclosure. As shown in FIG. 6, a client SDK 602 (same as client SDK 504) sends the access request, which may be an HTTPS access request, to an authentication server 606. The authentication server decodes the access token and extract DID from the payload. The authentication server requests for DID document associated with the DID from distributed ledger DLT 608. The DLT 608 provides a DID document with a blockchain address (Ethereum address) and a public key associated with the DID document. The authentication server 606 recovers the public key from the access token using the cryptographic key recovery algorithm, for example, ES256K-R. The authentication server 606 further recovers the blockchain address using the recovered public key and compares the public key associated with the DID document with the public key recovered from the access token, and the blockchain address associated with the DID document with the recovered blockchain address, and both the comparison indicates a match, the authentification server 606 may allow access of resource 610. The comparison authenticates the client as a valid client. The authentication server 610 may further use role bases access control to determine if resource 610 is listed as the authorized resource for the client. When the role-based access control indicates that the client holding the DID is allowed to access the resource, the system allows grant access to the resource 610.
[00054] FIG. 7A shows a generalized embodiment of an exemplary client device used to initiate access requests in accordance with an embodiment of the present disclosure. As depicted, the client device 700, also referred interchangeably as computing device 700, maybe a smartphone or a tablet. The computing device 700 may receive content and data via an input/output (hereinafter "I/O") path 702. The I/O path 702 may provide biometric data, metadata, voice profiles, and/or voice clips to control circuitry 704, which includes processing circuitry 706 and storage 708. The control circuitry 704 may send and receive commands, requests, and other suitable data using the I/O path 702. The I/O path 702 may connect the control circuitry 704 (and specifically the processing circuitry 706) to one or more communications paths (described below). I/O functions may be provided by one or more of these communications paths but are shown as a single path in FIG.7A to avoid overcomplicating the drawing.
[00055] The control circuitry 704 may be based on any suitable processing circuitry, such as the processing circuitry 706. As referred to herein, processing circuitry should be understood to mean circuitry based on one or more microprocessors, microcontrollers, digital signal processors, programmable logic devices, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), etc., and may include a multi-core processor (e.g., dual-core, quadcore, Hexa-core, or any suitable number of cores) or supercomputer. In some embodiments, the processing circuitry is distributed across multiple separate processors or processing units of different types, for example, multiple of the same type of processing units (e.g., two Intel Core i7 processors) or multiple different processors (e.g., an Intel Core i5 processor and an Intel Core i7 processor).
[00056] In some embodiments, the control circuitry 704 executes instructions for initiating access requests stored in memory (i.e., storage 708). Specifically, the control circuitry 704 may be instructed to retrieve biometric data, retrieve data and/or voice profiles or voice clips, and/or perform the other functions discussed above and below.
[00057] In client/server-based embodiments, the control circuitry 704 includes communications circuitry suitable for communicating with an authentication server or other networks or servers. The instructions for carrying out the above-mentioned functionality may be stored on a server or a cloud database. Communications circuitry may include a cable modem, integrated services digital network (ISDN) modem, a digital subscriber line (DSL) modem, a telephone modem, an Ethernet card, or a wireless modem for communications with other equipment, or any other suitable communications circuitry. Such communications may involve the Internet or any other suitable communications networks or paths. In addition, communications circuitry may include circuitry that enables peer-to-peer communication of client devices or communication of media devices in locations remote from each other.
[00058] The memory may be an electronic storage device provided as the storage 708 that is part of the control circuitry 704. As referred to herein, the phrase "electronic storage device" or "storage device" should be understood to mean any device for storing electronic data, computer software, or firmware, such as random-access memory, hard drives, optical drives, solid-state devices, quantum storage devices, or any other suitable fixed or removable storage devices, and/or any combination of the same. Nonvolatile memory may also be used (e.g., to launch a boot-up routine and other instructions). Cloud-based storage may be used to supplement the storage 708 or instead of the storage 708.
[00059] The control circuitry 704 may include audio processing circuitry and/or audio generation circuitry, other digital encoding or decoding circuitry, or any other suitable audio circuits or combinations of such circuits. Encoding circuitry (e.g., for converting received audio input or digital signals to audio signals for analysis or storage) may also be provided. The audio circuitry may be used by the computing device 700 to receive, process, and generate audio input or output. The circuitry described herein, including, for example, audio generating, encoding, decoding, encrypting, decrypting, and analog/digital circuitry, may be implemented using software running on one or more general-purpose or specialized processors. Multiple circuits may be provided to handle simultaneous processing functions. If storage 708 is provided as a separate device from the media device 700, the circuitry may be associated with storage 708.
[00060] A user may send instructions to the control circuitry 704 using a user input interface 710 of the computing device 700. The user input interface 710 may be any suitable user interface, such as a remote control, mouse, trackball, keypad, keyboard, touch screen, touchpad, stylus input, joystick, or other user input interfaces. Display 712 may be a touchscreen or touch-sensitive display. In such circumstances, user input interface 710 may be integrated with or combined with the display 712. A camera, microphone 716, or other visual or voice recognition interface may also be used to receive user input (e.g., voice prompts). Speakers 714 may be provided as integrated with other elements of the computing device 700.
[00061] The interactive application and/or any instructions for performing any of the embodiments discussed herein may be encoded on computer-readable media. Computer-readable media includes any media capable of storing data. In some embodiments, the software agent and SDK is a client application running on the computing device 700. Data for use by a thick or thin client implemented on the computing device 700 is retrieved on-demand by issuing requests to a server remote to the computing device 700, as described above. For example, the computing device 700 may receive inputs from the user via the input interface 710 or the microphone 716 and transmit those inputs to the remote server (e.g., cloud database 208) for processing and generating the corresponding outputs. The generated output is then transmitted to the computing device 700 to be output to the user.
[00062] FIG. 7B a block diagram illustrating the component of a mobile device used to initiate access requests in accordance with an embodiment of the present disclosure. The mobile device 750 may receive the intent of a user to initiate an access request via an input/output path 752. The I/O path 752 may provide data related to the user and other required services to control circuitry 754. The control 754 includes a processing circuitry 756 configured to process the data and execute instructions to perform function s of the system 400 described below. The control circuitry 754 includes a storage 758 that stored programmable instructions and other data related to DID based access control. The control circuitry 754 may send and receive commands, requests, and other suitable data using the I/O path 752. The I/O path 752 may connect the control circuitry 754 to one or more communications paths.
[00063] FIG. 8 is an example flow diagram illustrating access request processing in accordance with an embodiment of the present disclosure. One or more computing resources performs the access request processing in a distributed manner using blockchain infrastructure. The access request processing includes a step of generating, at a client device associates with the subject, by a software agent an access token using a private key associated with a public-private key pair stored in a wallet of the client device, as shown at block 802. The process 800 includes steps of receiving, at an authentication server through the software agent, an access request to access the object, wherein the access request comprises a decentralized ID (DID) associated with the wallet and the access token, as shown at block 804, and validating, by the authentication server with a client ID registry, whether the subject has the right to request the object as shown at block 806. In response to affirmative validation, the authentication server further performs steps of requesting, by the authentication server to a distributed ledger, for a DID document as shown at block 808, receiving the DID document, a blockchain address associated with the DID document, and a public key associated with the DID document as shown at block 810, recovering a public key from the access token using a cryptographic key recovery engine as shown at block 812, recovering a blockchain address from the public key as shown at block 814, determining whether the blockchain address associated with the DID document matches the recovered blockchain address, and the public key associated with the DID document matches the recovered public key as shown at block 816, and approving the access request to grant access of the object, in response to an affirmative determination, as shown at block 818.
[00064] It should be apparent to those skilled in the art that many more modifications besides those already described are possible without departing from the inventive concepts herein. The inventive subject matter, therefore, is not to be restricted except in the spirit of the appended claims. Moreover, in interpreting both the specification and the claims, all terms should be interpreted in the broadest possible manner consistent with the context. In particular, the terms "comprises" and "comprising" should be interpreted as referring to elements, components, or steps in a non-exclusive manner, indicating that the referenced elements, components, or steps may be present, or utilized, or combined with other elements, components, or steps that are not expressly referenced. Where the specification claims refer to at least one of something selected from the group consisting of A, B, C …. and N, the text should be interpreted as requiring only one element from the group, not A plus N, or B plus N, etc.
[00065] While the foregoing describes, various embodiments of the disclosure, other and further embodiments of the disclosure may be devised without departing from the basic scope thereof. The scope of the disclosure is determined by the claims that follow. The disclosure is not limited to the described embodiments, versions, or examples, which are included to enable a person having ordinary skill in the art to make and use the disclosure when combined with information and knowledge available to the person having ordinary skill in the art.
ADVANTAGES OF THE INVENTION
[00066] The present disclosure provides an access control system and a method for authenticating and authorizing a subject to access an object without storing a secret key on an authentication server.
[00067] The present disclosure provides a system and method for authenticating and authorizing a subject to access an object inefficient and secure manner.
[00068] The present disclosure provides a system and method for passwordless authentication and authorization.
[00069] The present disclosure provides a DID based access control system and method.