| Internet-Draft | Abbreviated Title | October 2023 |
| Sudarsan, et al. | Expires 20 April 2024 | [Page] |
Power of Attorney (PoA) based authorization is a generic and decentralized subgranting based authorization technique. In this, a principal can grant limited credibilities for an agent to act on its behalf for some limited time and context. This can be used in both constrained and non-constrained environments. PoA is a self-contained document that a principal sign and directs to an agent, thereby providing it the power to execute user actions on behalf of the principal for a predefined time. In this document, we compare PoA based authorization with different existing internet protocols for authorization and the relation with existing identity solutions.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 20 April 2024.¶
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Power of Attorney (PoA) based authorization is a completely generic and decentralized delegation or subgranting based authorization technique. It can be used in situations where the user needs to use a trusted device to act/work on his/her behalf. This will enable the user to subgrant their power to the trusted device and enable it to work on-behalf of the user especially when he/she is not available. This authorization technique is based on the traditional legal PoA document, which is used by people to transfer control of assets to trusted users. We bring the idea of the legal PoA document into the age of Cyber Physical Systems (CPS) and Internet of Things (IoT), where humans can instruct their trusted smart devices to act on their behalf for a limited time.¶
There are existing prominent internet standards for authorization especially based on delegation based authorization such as OAuth, ACE, GNAP, and UMA. The objective of this document is to position PoA-based authorization by complementing other existing delegation based authorization standards and to avoid reinventing existing features. This allows us to understand the key differences between them and identify the potential scenarios where PoA-based authorization can be used.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
PoA-based authorization is a generic authorization technique used to authorize devices to access protected resources on behalf of the user (principal). Some critical properties of PoA based authorization are:¶
Here 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. Different entities involved can access and verify the PoA using a downloadable image or library similar to PGP. Some centralization can be added by optional signatory registers and/or traditional Certificate Authorities (CA). The entities (roles) involved in PoA based authorization system are:¶
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.¶
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 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 [OAuth]. 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 [OAuth] that has some level of centralization via the authorization server, where some essential parts of PoA execution can be handled.¶
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].¶
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:¶
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 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.¶
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 [proxy-signature]. 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 [proxy-signature]. 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.¶
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 Single Sign-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 [SSO].¶
SSO can be used along with PoA based authorization to identify the principal, agent, and resource owner. Currently, the authentication between different entities in the PoA based authorization is implemented using X.509 certificates.¶
In this draft, we compared the state of the art such as OAuth, GNAP, UMA, and proxy signatures that are relevant to discuss with respect to PoA based authorization. The main properties that make the PoA different are its offline property, decentralization, and multi-level authorization. Analyzing the existing delegation-based authorization standards and protocols, especially the OAuth, PoA based authorization can be extended as an additional grant type to OAuth. Another approach is a clean state implementation of PoA based authorization from the scratch, which provides complete decentralization, however, this appears to be a more complex and challenging approach.¶
Thanks to all of the contributors.¶