Positioning of PoA

Other prominent delegation based authorization standards There are different delegation based authorization techniques that are important to discuss in relation to PoA based authorization. Most of them are centralized methods that rely on a trusted authorization server. Although PoA-based authorization does not rely on a centralized server, it also does not use distributed ledger technology. PoA based authorization uses the state of art techniques as a foundation and builds an authorization technique that will be useful in a subgranting situation in an industrial ecosystem. Different prominent delegation-based authorization models are as follows:

OAuth OAuth is a delegation-based authorization technique, which uses a centralized authorization server that issues access tokens to the client. This authorizes the client to access protected resources on behalf of the resource owner. 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 authorization server. The access token is used by the client to communicate with the resource server to obtain the required resources. 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. Different grant types in OAuth are authorization code type, where the resource owner issues an authorization grant/code for better security. In the implicit type, the access token is directly received from the AS without any intermediate tokens. The resource owner password credentials type is used for highly privileged clients, where the RO send their username and password to the client. The client credentials type is used for the client to access resources under its control, where the client uses its credentials as an authorization grant to obtain the access token from the AS. The main difference between different OAuth grant types and PoA based authorization is that PoA based authorization can be used in a scenario where a user (different from RO) has to access the resources owned by the RO through the client, even if the user is offline. This can be accomplished by transferring the PoA from the user to the client, allowing the client to access the resources user's behalf. By adding PoA based authorization as a new OAuth grant type, a new perspective of delegation can be added to OAuth. The main difference between PoA based authorization and OAuth are as follows: Principal can be offline: In OAuth, there is no entity similar to the principal. The resource owner is the one who delegates the client to access resources on behalf of the resource owner. In PoA based authorization, there is another entity called principal, which is different from the resource owner and PoA based authorization does not require the principal to be online during the process. Multi-level authorization: OAuth 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 . In PoA based authorization, the PoA received from the principal can be transferred by the agent to another trusted number of agents using the transfer parameter in PoA. Both of these authorization techniques can be used in different situations. The PoA based authorization is used in situations where the principal requires the agent to access data from the resource server on behalf of the principal. In PoA based authorization, the AS is not defined, because of the self-contained nature of PoAs and decentralized operation. The PoA itself can be used to sign on behalf of the principal without any third-party authorization server, provided that the resource server and concerned parties are capable of processing PoAs. In contrast, in OAuth, the resources are requested by the client for their purpose through a thrid-party authorization server that issues access tokens. In PoA, a challenge is to enable PoA execution in any system. This could be provided by an open-source lib or a trustworthy downloadable image (similar to what is provided for PGP). Another approach is to combine PoA with OAuth that has some level of centralization via the authorization server, where some essential parts of PoA execution can be handled.

GNAP GNAP is an in-progress authorization mechanism that performs delegation for a client instance to request delegation or direct information from the resource server. The main roles in GNAP are end-user, client instance, authorization server, resource owner, and resource server. The end user operates the client instance (software) and interacts with the authorization server to authenticate the request. The client instance requests the delegation from the resource server through an authorization server. The delegation can be considered as a grant, access token, or other information. GNAP focuses on the delegation process with the client instance and provides interoperability between different parties involved . GNAP is designed with a built-in identity, which is usually based on cryptographic keys. This is considered the main difference between GNAP and OAuth. In contrast, PoA based authorization, similar to OAuth is not connected with a built-in identity solution. Physical entity identity solutions such as biometric authentication are out of the scope of PoA based authorization. The PoA-based 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 addition, there is an information-gathering step in the different GNAP authorization modes where they mention the end user entity:

basic protocol flow
redirect-based interaction
user code interaction
requesting subject information only

Here the AS needs to obtain more information from the end user or the resource owner (if the end user and the resource owner are the same). This indicates that GNAP requires the end user presence even after the end user delegation to the client. To prevent future involvement of the end user in the authorization process, GNAP requires a stronger delegation or sub-granting process between the end user and the client. In the Cross User authentication mode, the end user and the RO are two different entities. Here, there is no information-gathering step between the AS and the end user because of the first couple of steps (steps 1 and 2) in the protocol flow. However, steps 1 and 2, where the end user identifies the RO (which is out of band from the protocol; through a phone call) and the end user communicates the identifier to the client instance is out of the scope of the protocol. Step 2 is the phase where GNAP and PoA match their features. Step 2, which is out of the scope of GNAP is well-defined or is the core part of the PoA-based authorization.

UMA UMA is an OAuth extension, that adds a requesting party entity to OAuth. In this specification, the client requests the resource server on behalf of the requesting party. The requesting party in the UMA specification is similar to the principal in PoA-based 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 resource server 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 the type of grant, ticket (most recent permission ticket received), claim token, etc. Upon receipt of the access token request, with a permission ticket, 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 authorization server’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 authorization server 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. In PoA-based authorization, the principal (similar to requesting party in the UMA) generates and provides his/her PoA to the agent (client) which makes the agent work or make requests on behalf of the principal. The information-gathering 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 authorization server 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 authorization server 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 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. 12. 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 that makes it more efficient.

ACE ACE is a standard build on top of the OAuth protocol for constrained environment. The use of protocols such as CBOR and CoAP make it suitable for constrained environment such as IoT. The different entities in the ACE framework is similar to OAuth standard. PoA based authorization can be used in the ACE framework to add the principal entity that provide a notion of delegation in the ACE framework. This may be useful to resolve the client registration and AS validation issues in the ACE framework.

Proxy signature It is a traditional cryptographic technique that 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. The original signer can provide the delegation in different ways such as full delegation, partial delegation, and delegation by warrant . The proxy signature is a security cryptographic algorithm. To our understanding, the original signer can be offline when the proxy signing is executing. However, proxy signature has not been adapted to industry-oriented technique, where the device acts/works on behalf of the principal (contractor) for some limited time. PoA-based authorization is an industrial authorization technique for CPS devices that are designed with different cryptographic algorithms, and is similar work as the proxy signature with warrant . The proxy signature is a significant security cryptographic algorithm that strengthens its security by patching newer security loopholes. The main differences are seen in the applicability of the technique and the design methodology. 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. PoA can be seen as a more industry-oriented technique, where the device acts/works on behalf of the principal as described in the PoA. Here, the agent is only required to verify and forward the PoA (received from the principal) to the resource owner and provide its strong identity, to obtain the resources on behalf of the principal.