Multilevel Subgranting by Power of Attorney and OAuth Authorization Server in Cyber–Physical Systems

Many cyber–physical systems (CPSs) are today semi-autonomous and powerful enough to perform advanced tasks on their own. This means they can also act as representatives of people or devices that have given them an order. However, traditional access control policies and delegation models do not meet industrial requirements such as support for letting autonomous CPS devices act on their own with certified credentials under the subauthorization by subcontractors, without the need for a separate account per device. In this article, we analyze and compare Power of Attorney (PoA), proxy signature by warrant, and OAuth to identify the strengths and challenges of each. Based on the comparison, we propose an OAuth grant type based on the PoA and inspired by the concept of proxy signature by warrant. PoA is a generic and self-contained document that a principal signs and directs to an agent, thereby providing it the power to execute actions on behalf of the principal for a predefined time, even if it is offline. One key advantage of the PoA is that it can support effective subgranting on several levels to support industrial scenarios where resource owners bring in authorized contractors that can in their turn authorize and bring in several devices without incurring management overhead to the resource owner. A proof-of-concept and performance evaluation of the proposed model is presented using an industrial use-case scenario with multilevel authorization.

Authorization is the process of providing permissions to access resources with access control policies [3]. The authorization can be implemented by defined policies in the access control, where access control is a set of rules or privileges used to determine whether the access is granted or denied to the user. Different access control models are used appropriately based on the use-case scenario, such as role-based access control (RBAC) to provide certain privileges to a role, attribute-based access control (ABAC) [4] that identifies users based on certain attributes, discretionary access control (DAC) based on user privileges, and mandatory access control (MAC) based on a centralized administrator [5].
Furthermore, there are different delegations and subgranting-based authorization techniques for authorizing third-party services to access the user's resources. An industry state-of-the-art model is a delegation by an authorization server (AS), typically through the OAuth standard [6]. OAuth is used by resource owners to authorize the third-party application (client) to access the protected resources using the AS. In OAuth-based systems, ASs generate an access token that represents the authorization granted to the client and are secured with encryption algorithms [7]. Typically the delegations using existing grant types are valid only as long as the resource owner is online.
There is a need for subgranting-based authorization in industrial scenarios to use CPS devices, which are typically semi-autonomous and not resource-constrained, to act on behalf of the owner. The need for industrial CPS goes beyond traditional access control policies and delegation models. Subgranting is required for trusted devices to enter as agents on behalf of an owner and operate autonomously in a local network with defined credentials for a set period of time without requiring the owner to be online. Moreover, such agents should be able to act on behalf of the owner without requiring a separate account.
For example, consider a scenario where a contractor (user) uses his/her autonomous truck to collect some mining-related data from a mining station (main operator) on behalf of the user (contractor). In this scenario, the user (contractor) needs to authorize his/her trusted device (autonomous truck in this case) using certain authorization techniques. Commonly, contractors get access to resources of the main operator in a workplace and they want to bring in many semi-autonomous devices in operation. To facilitate this without extensive account management it is convenient if the contractor can provide subgrants or delegations to his/her devices based on the main credentials obtained (e.g., without requiring a separate account per device). This delegation should be supported at an arbitrary number of levels where devices can grant access to other devices.
The scope of this article is to compare existing delegation models, specifically the Power of Attorney (PoA) [8], the proxy signature by warrant [9], and OAuth [6]. The objective is to analyze the tradeoffs and propose a solution based on industry standards to facilitate industry uptake.
Based on the analysis, we define the structure of the PoA with inspiration from the proxy signature by warrant, and propose a new grant type in OAuth using the PoA. The PoA grant-type extension of the OAuth 2.0 protocol makes it applicable in a scenarios where a principal (e.g., a user) who controls the OAuth client delegate their power to the client. This feature allows the client to access resources from the resource owner on behalf of the principal even when the principal is unavailable. Furthermore, we compare this solution with other approaches for delegation, such as user managed access (UMA) and grant negotiation and authorization protocol (GNAP). We also present an early proof-of-concept and a performance evaluation of PoA-OAuth grant type-based delegation.
The main contributions of this article are the following. 1) Analysis and comparison of PoA-based authorization, proxy signature, public key infrastructure (PKI), and OAuth. 2) Identification of challenges with different delegationbased authorization systems. 3) Introduction of a new OAuth grant type for the PoA, including protocol flows. 4) Proof-of-concept and the use-case implementation of the OAuth-PoA integration using real-world scenarios. 5) A comparison between the proposed model with other approaches of delegation, such as UMA extension and GNAP. 6) A performance evaluation of the proposed system based on evaluation metrics, such as memory and CPU utilization. We find that the proposed model of PoA-based OAuth grant type can enhance the existing OAuth standard in several ways. PoA-based authorization extends OAuth to include the principal entity, allowing devices to act on behalf of the principal without requiring the principal to be online. Authorization can be performed at multiple levels with this new grant type to meet industrial requirements. Overall, we find that integrating PoA and OAuth can address different limitations of both techniques.
The outline is as follows: we first describe in detail different subgranting-based authorization techniques in Sections II-A) PoA, Section II-B) proxy signature, Section II-C) comparison: proxy signature and PoA, Section II-D) OAuth, Section II-E) comparison: PoA and OAuth, and Section II-F) X.509 PKI. The structure of the PoA is explained in Section III. After finding the differences and similarities, we propose our PoA-based OAuth integration in Section IV. In Section V, we provide the performance evaluation based on the usecase scenario implementation. The comparison between our proposed PoA-based OAuth integration with other existing approaches such, as 1) GNAP and 2) UMA are defined in Section VI. Different security concerns and mitigation strategies are defined in Section VII. Later, Section VIII provides the discussion, and further future directions. Finally, we summarize our findings in Section IX.

II. AUTHORIZATION TECHNIQUES FOR SUBGRANTING
In this section, we compare different subgranting techniques: PoA-based authorization Section (II-A), Proxy signature Section (II-B), X.509 proxy certificate profile Section (II-C), and server-based authorization; OAuth Section (II-D) based on different metrics, such as protocol flow, warrant format, control of expiration, security features, advantages, and security vulnerabilities or challenges.

A. Power of Attorney-Based Authorization
PoA-based authorization [8] is an authorization technique used to authorize devices to access protected resources on behalf of the principal, without requiring the principal to be online. The PoA model in its base form is completely decentralized [like for example pretty good privacy (PGP)], where the user subgrants their power in the form of a self-contained PoA that contains public information, such as public keys and a specific set of permissions for a predefined time.
Some centralization can be added by optional signatory registers and/or traditional certificate authorities (CAs).
The entities involved in the PoA-based authorization system are listed as follows.
1) Principal: The entity that generates and sends the PoA to the agent. 2) Agent: The device which receives the PoA to sign on behalf of the principal with limited features for a predefined time. 3) Resource Server: The third party with a server that stores the information entitled to the principal. 4) Signatory Registry: A database system where PoAs and system-related metadata are stored. It can serve as a trusted third-party in certifying and verifying PoA. This component is optional. The architecture of PoA-based authorization with different entities and the communication flow is illustrated in Fig. 1.
The principal generates the PoA in advance to entitle an agent to autonomously execute tasks in the absence of the principal. The PoA is digitally signed by the principal and the agent uses the limited features of the principal's account to execute tasks allowed by the PoA.
The major advantages with PoA-based authorization are included in the following.
1) The agent can work on behalf of the principal, even if the principal is not online. 2) Agents such as CPS devices can act on behalf of the principal user without requiring a separate account.
3) The PoA signed by the principal is self-contained and it can be used by the agent to sign on behalf of the principal without a third-party AS and any need for contact with the principal when authorization of the client is performed. 4) Multilevel authorization. The main challenges are that every party and device would need to be able to process PoAs independently and the infrastructure for this is not yet in place. This could be provided by an open-source lib or a trustworthy downloadable image (similar to what is provided for PGP [10]). Another way is to combine PoA with a system that has some level of centralization by an AS, where some essential parts of PoA execution can be handled.

B. Proxy Signature
Proxy signature is an authorization technique that is used in application scenarios where a user requires to delegate another user for signing his/her messages using secure public key cryptography-based algorithms.
It allows a proxy signer to sign on behalf of the original signer. Here, the original signer delegates the proxy signer by providing certain credentials, using which the proxy signer generates a proxy signature to sign on behalf of the original signer. This can be useful when the original signer is not available at a particular moment and requires signing. The cryptographic treatment of the proxy signature is started after the publication by Mambo et al. [9].
Here, the original signer can provide the delegation in different ways are listed. 1) Full Delegation: Where the secret key is given by the original signer to the proxy signer. In this case, we cannot distinguish the original and proxy signers. 2) Partial Delegation: The original signer generates a proxy key from his/her secret key and passes it to the proxy. So that the proxy can use it for signing. 3) Delegation by Warrant: In both the above cases, the delegation is not expiring. In this case, there is a time limit for the delegation provided to the proxy signer. Along with the time period, the identity of the signer and the qualification of the message on which the proxy signs are also addressed as part of the warrant. The warrant defines what message the proxy signer can sign with the proxy key [11]. The main algorithms used for the implementation include DLP, RSA, ECDSA, pairing based, etc. In the beginning, it was mostly full delegation, and later on, delegation by warrant came into existence. The contents of the warrant also changed over time and depending upon the use case. The main contents include identities of the entities, expiration date and time, message, and other use-case-specific requirements.
Initially, there were a number of security issues, especially with the delegation capability generation, and the proxy signature generation. Therefore, throughout the history of proxy signature research, the primary focus has been on security issues. Continuous evaluation and patching of security flaws with better cryptographic algorithms are prioritized in the state-of-the-art. There are newer and secure algorithms for proxy signature generation for Industrial Internet of Things (IIoT) based on cryptographic algorithms [12], [13], [14], [15].
There is a lack of explanation on the usability or implementation of these complicated cryptographical algorithms in a real-world industrial scenario. In the 1990s, there has been done few relevant works [16] on the usability of proxy signature-based delegation systems in the industry such as Kerberos [17], using restricted proxies. An architecture for practical delegation in a distributed system is proposed by Gasser and McDermott [18] relying on secure channels, established by delegation, to send streams of commands to a resource server (RS) that keeps an ACL that shall contain all the entities in the delegation chain for the delegation to be valid. This is primarily intended for having chains of secure channels set up while the original user is logged in and alive. As soon as the original user logs out (or when one delegation times out) the channel must not be valid.
So, while the focus of proxy signature often is on message signing or online delegation, there are few implementations of using the proxy signature to autonomously perform other tasks on behalf of the user in an industrial semi-autonomous CPS context. This includes the usability, scalability, and flexibility of this technique. When it comes to the implementation of proxy signature in CPS, the format of the warrant is not defined using an industry standard which makes it difficult to use in real-world applications. In this article, we designed a PoA format (Section III) acceptable for industry use cases. A more detailed comparison between proxy signature and PoA-based authorization is defined in the following section.

C. Comparison: Proxy Signature and PoA
As mentioned in Section II-B, there are different types of proxy signatures; the proxy signature with a warrant is the one we compare. The main similarities between the PoA-based authorization and proxy signature with a warrant are: In both these techniques, the agent (proxy signer) is acting on behalf of the principal (original signer). Also, the principal delegates or grant the power so that the agent can sign or perform a task on behalf of the principal. The expiration of time and revocation, and the different parameters that are passed for the generation of the delegation, are similar in both of these approaches. In the absence of the principal, these techniques can be used to increase overall productivity.
The main differences are seen in the applicability of the technique and the design methodology used for implementation. In proxy signature, the agent or proxy signer is required to perform several cryptographic calculations to sign a message, as described in the warrant on behalf of the principal or original signer. This requires more resource consumption at the agent device. In the case of PoA, the agent is only required to verify and forward the PoA (received from the principal) to the resource owner (third-party server) and provide its strong identity, to obtain the resources on behalf of the principal. This decreases the resource consumption of the agent entity. Most of the literature study focuses on the use of proxy signature to sign on behalf of the principal (original signer). There are only limited implementations in use-case scenarios, where the agent obtains resources from a third-party resource owner to work/act on behalf of the principal for a defined period of time. However, in PoA-based authorization, the ability of the agent device to collect resources from a third-party server is clearly defined.
Unlike the proxy signature, PoA-based authorization uses a more flexible token format [JSON Web tokens (JWT)] for the generation of delegation capability or the warrant format. When compared to the use of cryptographic formats based on mathematical notations in proxy signature, the use of JWT tokens makes it more human-readable and easy to implement. Proxy signature uses a centralized verification server that is contacted by the agent to verify the principal. However, there are some technical difficulties in the implementation of the decentralized PoA-based authorization technique. This includes the execution and verification of PoA by different entities in the process, which necessitates the use of the same cryptographic algorithms and decoding processes. The proxy signature is a significant security cryptographic algorithm that strengthens its security by patching newer security loopholes, whereas PoA-based authorization is an industrial authorization technique for CPS devices to act/work on behalf of the user that is designed with different cryptographic algorithms, including proxy signature, as foundation.

D. Open Authorization
OAuth is an open industry-standard protocol that is commonly used for authorization processes for third-party services. It is a delegation-based authorization technique, which uses a trusted AS that issues access tokens to the client. This authorizes the client to access protected resources on behalf of the resource owner [19].
OAuth resolved many prominent challenges at the time of its invention, including presenting an alternative to the storage of owner credentials, such as username and password and providing wide access to the owner's resources which could not be limited by the owner. Also, the owner had to rely on thirdparty services and could not revoke access once it had been granted. The revocation could only be made by the owner by changing their password, which made it less flexible. And, also an attack on the third-party application would have resulted in the compromise of the owner's data including the password. OAuth was designed to resolve these problems.
The major tokens used in OAuth are the authorization grant token and the access token. The authorization grant represents the resource owner's authorization, it is generated by the resource owner and provided to the client. The client uses the authorization grant to obtain the access token from the AS. The access token is used by the client to communicate with the RS to obtain the required resources. It is a string of data and a signature that can be implemented in various formats, and structures. OAuth also uses refresh tokens to renew access tokens. This concept of refresh tokens facilitates the process of generating tokens for already authorized users.
The OAuth authorization protocol is defined mainly based on the following roles.
1) Resource Owner: The person who owns the data/resources (a.k.a user). 2) Resource Server: The server that hosts the resources on behalf of the resource owner, or provides a service to the resource owner. 3) Client: The application which requests from the RS the resources belonging to the resource owner. 4) Authorization Server: The server that provides authorization tokens called access tokens to the client upon authentication. Based on these roles, the general overview of possible OAuth protocol flow is defined in Fig. 2. This protocol defines four different grant types in the original specification, which are authorization code, implicit type, resource owner password credentials, and client credentials [19].
In the first type, authorization code, the resource owner and the client are not directly communicated in the beginning. In the first stage, the client uses AS to connect with the resource owner. Here, instead of directly receiving the authorization grant from the resource owner, the authorization grant is obtained through the AS. This type of grant increases the security of the resource owner because of the avoidance of direct communication with the resource owner.
The second type, implicit, is a simpler grant type, where the client receives the access token directly from the AS. It is called implicit because intermediate tokens such as authorization codes are not included in this grant type. Here, after obtaining the access token, the client requests data from the resource owner. This grant type is beneficial for clients that are in-browser applications. There are security issues with this grant type such as impersonation attack [19].
In the third type, resource owner password credentials, to obtain the access token from the AS, the client submits the username and password of the resource owner instead of the authorization grant. This is only implemented by highly privileged clients, in such a way that the client and resource owner know each other with a high degree of trust between them.
In the fourth type, client credentials, the client provides their credentials (client credentials) as an authorization grant to obtain the access token from the AS. This is possible only when the client accesses the resource under the client's control or to access resources that are previously arranged by the AS, typically when the client is also the resource owner.
There are several applications where OAuth is used for authorization purposes. Cirani et al. [20] used OAuth to implement authorization service architecture for secure services in IoT. Similarly Sciancalepore et al. [21] used OAuth for access control framework in IoT. Sucasas et al. [22] used OAuth to address privacy issues in smart city mobile applications. Solapurkar [23] used OAuth to secure healthcare services in IoT cloud. OAuth is commonly used for access control and authorization in several other IoT ecosystems [24], [25], [26], [27], [28], [29], [30]. It is also used in decentralized networks such as blockchain for authorization purpose [31], [32].
Several privacy evaluations have been performed on the OAuth protocol, and several privacy issues and vulnerabilities have been discovered, as well as the susceptibility to numerous malicious attacks. Benolli et al. [33] evaluated the OAuth cross-site request forgery (OCSRF) attacks on a large-scale analysis of different high-ranked sites. Morkonda et al. [34] defined the privacy implications in OAuth deployments using data from single sign-on (SSO) platforms of major identity providers, such as Google, Apple, Facebook, and LinkedIn. There are limitations with the capabilities of the AS, the registration process of the client, and issues with endpoint discovery [19]. Fig. 3 shows a comparison of the OAuth (authorization code grant type) and PoA-based authorization mechanisms and the main differences in the situations in which they are used. For comparison, we assume that:

E. Comparison: OAuth and PoA
1) the client in OAuth is similar to the agent in PoA. Because both these entities request data/resources using a token or PoA; 2) the principal in PoA is often not the same as the resource owner. However, there are certain situations where it can be considered the same as the resource owner. In PoA-based authorization, the AS is not defined, because of the self-contained nature of PoAs. The PoA can be used to act on behalf of the principal without any third-party AS, provided that the RS and concerned parties are capable of processing PoAs. In PoA-based authorization, the agent does In OAuth, a third-party AS is used to issue access tokens. The AS issues the access tokens on a request by the client in the OAuth system. The client (agent) requires an account with the AS for communication regarding the authorization tokens. The process of dynamic client registration is explained in the OAuth specification [35]. In addition, client authentication is defined. For a private or confidential client, the authentication is done by submitting a set of client credentials, such as a password and public/private key pair to the AS.
There are a few things defined as out of the scope of OAuth specification, which are deliberately left for future work to make the OAuth protocol more open for future extensions. They are the following.
1) The type, scope, and the means by which the initial access token (issued by the AS), that is used in dynamic client registration is out of the scope of OAuth specification. 2) Unregistered clients are out of the scope. The OAuth specification is open for extensions to resolve additional challenges, e.g., by defining additional grant types [36], [37]. It supports one step of delegation, not fully able to separate the resource owner (the main operator) from the contractors, and the devices in an arbitrary number of delegation levels. This means OAuth includes only the resource owner entity and does not include the principal (contractor) entity. This means, in OAuth the person who provides access privileges is the same as the resource owner (person who owns the resources), there is no separate entity called the principal (contractor) who uses the agent/client to request the resources owned by the resource owner. Table I shows the main differences between the above-discussed delegation-based authorization techniques.

F. X.509 Public Key Infrastructure Proxy Certificate Profile
Proxy certificates are used to delegate a proxy to do several tasks on behalf of the user as specified in the proxy certificate. A profile for the X.509 proxy certificate is developed using different policies [38]. An attack on the proxy machine, which holds the credentials of the user would cause several privacy Authorized licensed use limited to the terms of the applicable license agreement with IEEE. Restrictions apply. and security issues. To avoid these restricted proxies are used, that are implemented by providing policies on the proxy certificate that can restrict the use of credentials on behalf of the user.
This approach also provides a unique identity for the proxy to have its own rights. The proxy policy includes proxyPolicy and policyLanguage attributes to define the policy for authorization. The proxy certificate along with its appropriate public key is verified using the proxy certificate path validation algorithm. An industry network authentication protocol based on secret-key cryptography that is used for the authentication of client/server applications is Kerberos [17].
The main difference between Kerberos and the PoA-based authorization is that Kerberos is used to provide authentication or user identification and PoA-based authorization is an authorization technique based on delegation or subgranting mechanisms. Kerberos uses tickets to identify the client at the end server along with an authenticator that is encrypted with the session key. On the other hand, a proxy signature uses different keys, such as a secret key and a proxy key for delegating the proxy signer which enables the proxy signer to sign on behalf of the original signer. Kerberos requires a third-party key distribution center to create and delegate ticket granting tickets (TGTs), where the proxy signature trust mechanism is based on the security of the private, public, or secret keys involved in the process. There are approaches thats extends the authentication systems to support restricted proxies which helps to support flexible distributed authorization mechanisms [16]. However, it is used to delegate the identity of the principal to a service by passing the identity or identity credentials.

III. POA STRUCTURE
In this section, we discuss the design format of the PoA in the PoA-based authorization (as mentioned in Section II-C). Tokens are of different types with dedicated structures and semantics for specific needs. The OAuth 2.0 does not define a particular type of token, such as JWT [39], Proof-of-Possession (PoP) tokens, and bearer tokens [40]. Another alternative referred to as the token introspection [41] discusses a process of querying the AS about the token metadata using a network protocol.
The access tokens can be of different structures, mainly identifier type and self-contained type. With the identifier type token, which is the most commonly used, the access-related data is stored in a separate database. The token contains an identifier that points to the information stored in the database. This token itself cannot be used for authorization, it is used along with the database storage.
In self-contained tokens, the data required for authorization is embedded in the token. This will eliminate the use of an AS and provide the token full control of authorization. The PoAs are self-contained tokens that are structured in JWT format. The entire PoA in the JWT form is digitally signed by the principal using his/her private key. CBOR format can also be used especially in an IoT application scenario.
The various parameters included in a PoA are the following. Principal Public Key: REQUIRED. The public key uniquely identifies the principal who generates the PoA. We assume that the public key is generated using a secure public-key algorithm by the principal. With this parameter, the AS can identify the person who generated the PoA.
Principal Name: OPTIONAL. The human-readable name of the principal, which is additional information about the principal.
Resource Owner ID: REQUIRED. The unique identifier or the public key of the resource owner from where the protected resources are granted.
Agent Public Key: REQUIRED. The public key, which uniquely identifies the agent who receives the PoA from the principal. We assume that the agent public key is generated using a secure public-key algorithm by the owner. This parameter helps the trusted server to identify the agent and check whether it is genuine or not.
Agent Name: OPTIONAL. The human-readable name of the agent, which is additional information about the agent.
Signing Algorithm: OPTIONAL. The name of the signature algorithm used by the principal to digitally sign the PoA.
Transferable: REQUIRED. It is a positive integer defining how many steps the PoA can be transferred. The default is 0, which means that it is not transferable. A PoA can be transferred by including it in another PoA, i.e., it is signed in several delegation steps (where the number is decreased by one in each step).
iat (Issued at): REQUIRED. The time at which the PoA is issued by the principal to the agent.
eat (Expires at): REQUIRED. The time at which the PoA expires. This parameter is predefined by the principal in the PoA and the PoA will be invalid after eat.
Metadata: OPTIONAL. The metadata is associated with the specific application use-case. This parameter includes different subparameters that add application-specific information to the PoA.

IV. POA AND OAUTH INTEGRATION
For the reasons mentioned in Section II, especially the comparison of PoA and OAuth-based authorization techniques, we find it reasonable to combine PoA with OAuth to obtain the benefits of both approaches and at the same time close some gaps in both techniques. We here present the architecture and implementation details of the PoA-based OAuth grant type. The operational assumptions for using this authorization grant type are listed.
1) There is established mutual trust between the principal and the client (i.e., PoAs are only assigned to trusted parties). 2) The client is an autonomous or semi-autonomous device with sufficient resources to perform authorization.
3) The identity of the principal and client must be possible to verify. Whether this is based on a strong identity or only on public-private key challenges depends on the application.

A. Architecture
The PoA-based OAuth authorization requires entities from both PoA and OAuth-based authorizations. The integration of these two authorization techniques extends their capabilities and security. Fig. 4 shows the architecture overview of PoAbased OAuth authorization. The integration of OAuth security adds the AS entity, that generates the access token that is used to obtain resources from the RS. The RS that trusts the AS trusts the agent transitively. Thereby, increasing the overall performance and reliability of the authorization system.
The different entities involved in the PoA-based OAuth model are listed.
1) Principal: The person or entity that generates and sends the PoA to the agent. It may or may not be the same as the resource owner. In many PoA cases, it is considered to be a different entity. 2) Agent: An application making protected resource requests on behalf of the resource owner and with its authorization. The term "client" does not imply any particular implementation characteristics (e.g., whether the application executes on a server, a desktop, or other devices). It receives the PoA from the principal and requests the protected resources from the resource owner via the AS on behalf of the principal.
3) Authorization Server: An OAuth component, which receives the PoA and performs client registration and access token generation. 4) Resource Owner: An entity capable of granting access to a protected resource. When a resource owner is a person, it is referred to as an end-user. It is an OAuth component, that generates the authorization grant to provide access to its protected resources. 5) Resource Server: An OAuth component, that hosts the protected resources on behalf of the resource owner. It is capable of accepting and responding to protected resource requests using access tokens. This can be either on the resource owner machine itself or on a separate database server. In our approach, the principal (different from the resource owner) provides his/her PoA to the agent to access resources that are not owned by him/her. For example, consider that the principal is a CEO of an organization X and the agent is an employee in the same organization X. The CEO can issue the PoA to the employee (agent) to access the resources owned by organization Y (resource owner). In this scenario, we use the PoA to provide adequate information regarding the principal, the agent, and the request for the resource. Fig. 5 presents the protocol flow of PoA-based OAuth authorization. In step 1, the principal sends the PoA to the agent. In step 2, the agent registers with the AS using the PoA. The AS verifies the PoA and registers the agent/client so that it then can communicate with the resource owner. Here, the client registration is done by representing the principal by using the data embedded in the PoA. This is an added functionality that enables client registration. This can be performed by other means as well.
In step 3, the AS verifies the PoA and sends a client identifier (ID) to the agent, which must be used by the agent to communicate with the resource owner.
In step 4, the agent sends the client ID along with the PoA to request the authorization grant from the resource owner. The resource owner identifies the agent using the client ID, verifies the PoA, and in return sends the authorization grant (step 5). The authorization grant is used to obtain the access token from the AS in the next step (step 6).
After the acceptance of the access token (step 7), the agent can access the resources stored at the RS. For this, the agent Authorized licensed use limited to the terms of the applicable license agreement with IEEE. Restrictions apply. sends the access token to the RS (step 8). The RS receives and verifies the access token, upon successful verification, the requested data is sent to the agent (step 9).
In the final stage (step 10), the agent sends a report to the principal, which is an optional step that depends on the specific use case.
Algorithm 1 describes the entire OAuth integration with the PoA concept. Here, the principal p i generates PoA PA using PoA generation function f (p i , a i ). The AS as i receives the PoA and verifies it using the verification function f (a i , PA). Upon successful verification, the AS returns the client ID C ID , which is used to obtain Authorization Grant AG from the Resource Owner. The AG is used to obtain Access Token AT. The AT is used to access the actual data from the RS. In the final step, the agent receives d i from the RS.
The principal in our PoA-based OAuth integration can also be considered the same as the resource owner; that means the principal and the resource owner may or may not be the same. In the case of the principal and resource owner being the same, the agent will be accessing resources owned by the principal on behalf of the principal. This means the principal owns different resources or multiple instances of the resource. In this situation, the authorization grant (step 5 in Fig. 5) from the resource owner (principal) is not necessary. Because the authorization is already provided by the principal (resource owner) in the form of PoA.

B. Implementation
The proof-of-concept for PoA-based OAuth model is implemented from a technological standpoint, as a secure and reliable authorization system with extended features and functionalities. We use java spring boot security to build the system and Postman for the application interface and testing. The entire implementation is divided into three different parts.
1) Client: This part is dedicated to the client-side implementation, which includes principal and agent components. ts i ⇐ a i (PA) 6: f (a i , PA) 7: a i ⇐ ts i (C ID ) 8: else 9: if a i (PA) ∈ γ AND step 7 then 10: ro i ⇐ a i (PA, C ID ) 11: f (a i , PA) 12: a i ⇐ ro i (AG) 13: ts i ⇐ a i (AG) 14: a i ⇐ ts i (AT) 15: rs i ⇐ a i (AT) 16: a i ⇐ rs i (d i ) 17: end if 18: return d i 19: end if 2) Authorization Server: This part serves as the authorization server side, which generates access tokens and other authorization-related implementation. 3) Resource Server: This part implements the resource owner and RS which secures the protected resources. 1) Client: The client part includes the principal and the agent, where the principal creates the PoA based on the PoA structure defined in Section III. The required parameters are added by the principal according to the specific use case. The generated PoA is digitally signed using the RSASHA256 hash algorithm and sent to the agent over an HTTP(s) connection in JWT token format.
The agent receives the PoA in JWT format and decodes it into an appropriate readable format as shown in Fig. 6 and checks the validity and credibility of the PoA and performs the tasks mentioned in the PoA. Afterward, the agent will send the PoA to the AS to obtain the necessary tokens.
2) Authorization Server: The AS verifies and accepts the PoA from the agent and registers the agent as a client into the system. For this, the AS configuration based on OAuth primarily requires a pair of private and public keys. In our implementation, we used the RSA key generation algorithm [42] of the 2048-bit long modulus (two primes) to generate a public and private key pair. We use RSA because it is a secure asymmetric encryption standard with both private and public key pairs that are commonly used in different applications, such as OAuth and GNAP [43]. We use the OpenSSL [44] genrsa command to generate the RSA key pair by specifying the required key size of 2048 bits. This key pair is used by the AS to generate the tokens and to communicate with the RS. The other essential requirements of the AS are PoA and client secret, which are used to register the client (agent) into the AS.
The verified PoA is decoded and creates a client ID as shown in Fig. 7 from the details provided in the PoA along with other information added by the AS upon PoA validation.
The client ID payload includes parameters as shown in Fig. 7. In our implementation, the client ID payload is signed and protected using the RSASHA256 signing algorithm.
3) Resource Server: The resource part mainly includes the resource owner entity and the RS. In our demonstration, we assume that the RS is the same as the resource owner itself. Here, the resource owner receives the client ID and PoA from the agent. Upon verification, the resource owner generates and sends the authorization grant to the agent.
The agent uses the authorization grant to obtain the access token from the AS. The AS generates the access token in JWT format after the verification process. The access token is used by the agent to obtain the required protected resources from the RS. In the final step, the agent receives the resources from the RS successfully and sends a report to the principal.
The verification of PoA and all other tokens plays a crucial role in the entire authorization process. This can be done in different ways.
1) Storing verification source code on all entities in the authorization system. 2) Using third-party public-key digital signature-based verification methods using a separate trusted server.

A. Use-Case Scenario
Our use case is based on the scenario of mine-related data collection by a truck from a mining station. The main components involved in the use case are listed.  Here, we assume the RS is the same as the resource owner (i.e., under the same governance). The workflow of the use-case scenario is shown in Fig. 8. Here, we assume that there is trust between the contractor and the mining station. Possibly, that trust may have been detailed by a previous PoA from the mining station to the contractor. In our use case, the contractor requires the truck to perform tasks using the mining data from the mining station.
In step 1, the contractor generates a PoA and assigns it to the trusted device truck. In this use case, the parameters in the PoA structure are contractor public key, truck public key, mining station ID, transferable status, PoA iat, eat, and metadata, such as contractor name, truck name, and signature algorithm type. The PoA provides special features and capabilities to the truck to sign on behalf of the contractor. The PoA will be invalid at the time expires at (eat). The eat is set by the contractor to remove stale PoAs from the system.
In the next step after obtaining the PoA, the truck sends the PoA to the AS (step 3). In step 4, the AS issues a client ID to the truck by extracting information from the PoA and adding other authorization-specific data. The truck sends the client ID and PoA to the mining station (resource owner) (step 6). Later, the mining station verifies the client ID and PoA to generate the authorization grant (step 7) and send it to the truck (step 8). The truck receives the authorization grant and sends it to the AS in step 9. The AS verifies the authorization grant and provides the access token to the truck (step 10).
The truck validates the access token and sends the access token to the mining station to obtain mining-related data (step 11). The mining station verifies the access token and provides mining-related data to the truck (step 12). The truck can also submit an acknowledgment report to the contractor, which is an optional step in this use case. Table II and Fig. 9 show our implementation details with different functions, such as PoA generation, client ID generation, authorization grant generation, access token generation, and mine data access. The header and body of requests for each function and the appropriate http/s methods are defined in Table II. An advantage of adding the PoA system is to provide OAuth the ability to separate the resource owner from the contractor, and the devices in an arbitrary number of delegation levels. Another feature added to the usecase implementation is the use of PoA for client registration. Instead of sending the client credentials, the PoA is transferred to the AS to obtain the client ID. In further interactions with the mining station (resource owner), the truck uses this client ID along with the PoA to obtain the authorization grant. All other steps, such as access token and authorization grant generation are existing parts of the OAuth protocol.

B. Performance
The application is tested on a LENOVO 20N2000SMX model computer with the Intel Core i7-8565U processor, 23.2-GB memory size, and Ubuntu 18.04.5 LTS operating system. The source code of our PoC implementation is freely available under MIT license. 1 Fig. 9. Implementation details of the use-case scenario.  The performance of the proposed system is measured using four metrics: 1) memory utilization; 2) CPU utilization; 3) computation cost; and 4) communication cost. The measurement is taken using the spring boot actuator along with the HAL browser. We evaluated the performance of the PoA generation, client ID generation, and access token generation. We have considered ten samples of each parameter and calculated the average value and standard deviation. Table III shows the measurement details of different parameters based on the Resource Owner: https://github.com/sreelakshmivs/PoA implementationin-JavaResourceserver.
Client Part: https://github.com/sreelakshmivs/PoAimplementationinJava. metrics memory and CPU utilization, the symbol σ denotes the standard deviation. The standard error of the mean (SEM) is calculated using the equation SEM = σ ÷ √ n, where n = 10 (number of samples). Table IV shows the measurement details of different parameters based on the metrics computation and communication cost to analyze the effectiveness of the proposed system. Computation cost is calculated based on the time in milliseconds required for each task in the PoA-based authorization (PoA generation, client ID, and access token generation). Communication cost is calculated using the size of the message in MB for PoA generation, client ID, and access token generation.  As a result, we discovered that the PoA generation process consumes the most memory and the least CPU when compared to the client ID and access token generation processes.
The graph shown in Fig. 12 provides the average communication and computation cost of the proposed model. According to the graph, PoA generation requires an average of 95.8 ms of computation cost and 0.613965 kB of communication cost. The generation of client IDs uses an average of 1518.7 ms of computation cost and 3.25 kB of communication cost. Finally, the generation of access tokens consumes an average of 1449.9 ms of computation cost and 2.146 kB of communication cost. As a result, we discovered that the PoA generation process consumes the least computation and communication cost when compared to the client ID and access token generation processes.
The numbers presented in the graphs depend to some extent on the algorithm chosen [45]. In any case, we address devices that have enough resources to act on behalf of a principal and thereby are not generally resource constrained, and in this context, the processing resources needed are small. We conclude that the processing overhead is typically not an issue.

VI. RELATED FRAMEWORKS FOR DELEGATION
There are different works using delegation-based authorization systems. Schneider et al. [46] proposed DelegaTEE, a type of delegation-based authorization system. In this delegation method, the owners push all the necessary credentials, such as username and password to a shared system with the delegatee. The delegatee uses the credentials to access protected resources from the RS. Other main delegation or subgranting-based authorization techniques are the following.

A. Grant Negotiation and Authorization Protocol
GNAP [43] is an authorization protocol similar to OAuth that addresses some use-case problems of OAuth and is not an OAuth extension. The main application scenario of GNAP is when a piece of software, which is a client instance needs to request delegation to access the protected resources of a resource owner. It is mostly applicable if the application requires interoperability between different roles in the system. GNAP assumes that the end user entity, that operates the client instance is mostly the same as the resource owner. They also assume the end user is authenticated using existing identity protocols.
Also, functions, such as multiple access token requests by the client, use of client software and multiple client instances, JSON format of authorization request to the resource owner, and token management are introduced. GNAP is a work in progress in the IETF, and therefore we do not cover the current state in depth.

1) Comparison (GNAP and PoA-Based OAuth Integration):
GNAP is an IETF standard that allows a client instance or software to request delegated authorization to RSs. This delegation includes a set of APIs as well as information passed directly to the software resources. GNAP provides interoperability between different parties that perform different actions under different roles. The different roles in GNAP are AS, Client, RS, Resource Owner (RO), and the end-user. The PoAbased OAuth authorization includes entities that are similar to the GNAP, especially the end-user entity.
According to GNAP, the end-user is a human entity that operates the client instance, which is similar to the principal entity in our proposed model. However, the GNAP specification states that the end user may or may not be the same as the resource owner, and in practice, they are usually the same. In GNAP, the same party can perform in multiple roles, and GNAP allows you to switch between them. In addition, in the majority of the application scenarios described in the specification, the resource owner and the end-user are the same.
GNAP can be used in different ways to provide delegation which involves different roles of the protocol. The main delegation process involves all the roles in the protocol, which starts with the end-user who interacts with the client instance to get access to resources on behalf of the resource owner. However, the interaction between the end-user and resource owner is not based on self-contained tokens such as PoA as in our proposed model. GNAP uses access tokens in JWT format along with RS256 digital signature similar to our proposed model.

B. User-Managed Access
There is an existing OAuth extension, referred to as UMA [47], which adds the requesting party concept to OAuth. UMA is applicable in use-case scenarios where the use of OAuth needs to be enhanced. For example, it can be used where a user with a bank account requires services to share specific information about his/her bank account with other trusted users. The main assumptions of UMA include that the requesting party or end-user and the resource owner are natural persons or legal persons. They also assume that requesting party and the resource owner may or may not be the same. In this specification, the client requests the RS on behalf of the requesting party. The requesting party in the UMA specification is similar to the principal in the PoAbased OAuth extension system. However, they differ in some aspects.
In UMA, the client sends a request for resources without any access token or permission ticket. Upon request, the RS at the other end returns a permission ticket that can be used by the client in the next step, where the client sends a request permission token (RPT) request to the AS. This includes parameters, such as a type of grant, ticket (most recent permission ticket received), claim token, etc. Upon receipt of access token request, with a permission ticket, and claim token (push claims), the AS sends a 403 response with a new permission ticket, need info error, and redirect-user hint.
The client redirects the requesting party to AS for interactive claims gathering. At the endpoint of the AS's claims interaction, they request direct interactions with the requesting party, such as registration of an account and local authentication to the AS as an identity provider, filling out a questionnaire, or asking the user to approve the subsequent collection of claims through interaction, and continuous storage of such claims.
The UMA specification provides an AS redirect of requesting party back to the client after an interactive claims-gathering. However, the process of claims gathering is specified to be out of the scope of this specification. They also define that the information that will be gathered at this point is not shared with the client. It is used by the AS for its authorization assessment purposes. In later steps, these claims are represented by a token issued to the client.
UMA is used in several applications for authorization purposes. Rivera et al. [48] used UMA for access control in IoT devices and intelligent agents. It can also be used in a decentralized IoT ecosystem for access control [49] and is used also in Web resources and Web 2.0 applications [50], [51], [52].

1) Comparison (UMA and PoA-Based OAuth Integration):
In a PoA-based OAuth integration system, the principal (similar to requesting party in the UMA) generates and provides his/her PoA to the agent (client) which makes the agent sign or make requests on behalf of the principal. The informationgathering step, which is not specified in the UMA is provided in the form of PoAs in our PoA-based approach, where all the required information is included inside the PoA, which makes the authorization process more self-contained.
In UMA, the resource owner/requesting party needs to submit credentials by setting policy conditions to the AS to communicate with the client. However, in PoA-based authorization, the principal (similar to the requesting party in the UMA) does not necessarily have to communicate with the AS to interact with the client (agent).
The UMA protocol flow states that the specification can be used by one or two parties. Here, the requesting party and the resource owner could be the same, allowing the specification to be used in two different transfer levels. Similarly, in a PoA-based system there is a PoA parameter named "transferable" that indicates the number of transfers possible with a given PoA, as shown in Fig. 13. The values taken by this parameter are integer values of 0, 1, 2, etc., indicating the number of possible transfers. This parameter increases the transferability scope to a larger scale and, as in UMA, is not limited to two parties. The entire UMA specification requires a lot of communication flows between entities, which is eliminated in the PoA-based approach makes it more efficient.
Authorized licensed use limited to the terms of the applicable license agreement with IEEE. Restrictions apply.

C. Existing Identity Solutions and Relation With PoA-Based Authorization
PoA-based authorization assumes a strong authentication between different entities involved using a strong identity solution. The relation of PoA-based authorization with the existing identity standards and protocols based on SSO are detailed below. SSO is an authentication mechanism that is built on federated identity that allows the principal (user) to use different network services without providing the authentication credentials at each service. There are different types of SSO mechanisms, such as Secret Credential Store, Kerberos, NetWare Authentication, distributed computing environment (DCE) Security, X509 Authentication Framework, and pluggable authentication module (PAM). SSO can be implemented using SAML and OpenID protocols. OpenID is a common protocol that is used in the SSO authentication process for user identification. OpenID connect provides certified identity to user applications in JWT format [53] SSO can be used along with PoA-based authorization to identify the principal, agent, and the resource owner. Currently, the authentication between different entities in the PoA-based authorization is implemented using X.509 certificates.

VII. SECURITY ANALYSIS OF PROPOSED MODEL
There are several vulnerabilities found in the PoA-based authorization integrated with the OAuth protocol that might be exploited by the attackers. We have analyzed different attacks and provides the appropriate mitigration strategies.

A. Spoofing
Spoofing is not a threat in the proposed model. This is because the PoA is digitally signed using a standard public key approach and there are public keys inside the PoA to identify the principals and agents. Hence, even when the attacker sends a poa signed with his/her private key, the agent checks the public key and rejects the poa because it is not part of the agent's trusted public keys.

B. Sniffing/Eavesdropping the PoA and Man-in-the-Middle Attack
The PoA that is sent from principal to agent can be eavesdropped on. Even though the data inside the PoA may not be sensitive, it's recommended to use TLS for better security and to eliminate privacy attacks. This is the same for the man-in-the-middle (MITM) attack.

C. Denial of Service
An external agent interrupts the data flowing across the trust boundary in either direction. DoS is mitigated or can decrease the impact by making the attacker consume more of his resources than yours to launch the attack. Make the attacker reply using information from previous message exchanges, to prove they can receive data from you [54]. Individual targeted DoS attacks are difficult to prevent in this design.

D. Cross Site Scripting (XSS) or Code Injection
While downloading the public library to generate or validate the PoA, the entity might download a malicious one instead of the legitimate lib. This could be prevented with input sanitization or filtering techniques.
Tables V and VI show the comparison of functionality and security features of the proposed model with the existing schemes.

VIII. DISCUSSION AND FUTURE WORK
This article proposes multilevel subgranting using PoA and OAuth, which allows automated or semi-automated CPS devices to act on the user's behalf, even if the user is not online. We compare and analyze different subgranting-based authorization techniques, such as proxy signature, OAuth, X.509 PKI proxy certificate profile, and PoA. We integrate the PoA technique with the open industry authorization standard OAuth to overcome challenges and improve the usability and functionalities of both techniques.
We discuss the significance and value of proxy signature in the development of PoA-based authorization and identify the limitations of proxy signature, particularly in its applicability in an industrial setting. The potential benefits of PoA-based authorization, particularly its usability and adaptability in the industry when compared to proxy signatures, are defined throughout this article. We describe the use of PoA to act or work on behalf of the user, which is a more advanced feature than allowing the agent to sign on behalf of the user as in the proxy signature.
This article outlines the architecture, protocol flow, implementation details, and performance evaluation of the proposed OAuth integration with PoA. In addition, the structure of the core component of PoA-based authorization, ie the PoA itself, is defined using different parameters and its specific properties. The proof-of-concept is implemented using a use-case scenario that demonstrates the usefulness of the proposed system in an industrial context.
For future work, the challenge of PoA-based authorization in its decentralized deployment is that every party must be able to process PoA according to their role. The possible future directions are: first, the availability of open and compliant libs that can be downloaded and executed by anyone. This is similar to the challenges of decentralized public-private key solutions such as PGP. Those models have been proven very successful and, based on that approach, PoA could be provided similarly at least in principle.
Second, a complementary way to go is to rely on third-party trusted servers to certify and/or execute PoAs. This would be similar to adding CA and/or ASs as trust anchors in decentralized public-private key infrastructures. We have a notion of an optional PoA registry that could take this role by both storing PoAs, certifying them, and being able to execute parts of them as a trusted party. More research and definition are however needed on these concepts.
Third, as we propose in this article, is to build on wellestablished security techniques such as OAuth. This trail will be continued as it is favorable to build on established frameworks to make the PoA more generic, independently of whether we want to eliminate the use of third-party ASs or rely on third-party trust anchors.
The fourth is to provide the proof of correctness of the proposed system and the comparison of the computational and communication metrics of the proposed system with other related schemes.

IX. CONCLUSION
In this article, we present the PoA-based authorization technique by comparing it with other existing delegation techniques. We define the structure of the PoA, including both required and optional components, which can be added appropriately by the principal based on the specific use case. We analyze proxy signature by warrant, PoA-based, and OAuthbased authorization techniques, their uses and, limitations. We present the integration of PoA and OAuth-based authorization techniques as a new grant type, that enables a device/agent to sign or access resources on behalf of the principal based on OAuth security. The following advantages are obtained: separation of the principal and the resource owner, and the ability of the client to work on behalf of the principal even if the principal is offline. Authorization can be performed in an arbitrary number of levels to meet requirements in industrial scenarios where several levels of contractors and subcontractors are used to deliver services. The OAuth security part adds the AS entity, which ensures authorized access to the system. We found that PoA and OAuth in concert can solve many of the limitations held by both authorization techniques.
We define the use of PoA for client registration, which provides a client ID back to the client for unique identification. The suggested integration is also compared with GNAP and with the OAuth extension known as UMA.
The proof-of-concept that we present in this article is explained with an architecture, system design, and use-casebased implementation. The performance of the proposed system is evaluated based on the metrics of memory and CPU utilization.