Internet DRAFT - draft-vattaparambil-positioning-of-poa
draft-vattaparambil-positioning-of-poa
Internet Engineering Task Force S. V. Sudarsan
Internet-Draft O. Schelen
Intended status: Informational U. Bodin
Expires: 20 April 2024 Lulea University of Technology
18 October 2023
Positioning of PoA
draft-vattaparambil-positioning-of-poa-01
Abstract
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.
Status of This Memo
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 Notice
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.
Sudarsan, et al. Expires 20 April 2024 [Page 1]
Internet-Draft Abbreviated Title October 2023
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Power of Attorney based authorization . . . . . . . . . . . . 3
3. Other prominent delegation based authorization standards . . 4
3.1. OAuth . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. GNAP . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3. UMA . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.4. ACE . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.5. Proxy signature . . . . . . . . . . . . . . . . . . . . . 9
4. Existing identity solutions and relation with PoA based
authorization . . . . . . . . . . . . . . . . . . . . . . 9
5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Normative References . . . . . . . . . . . . . . . . . . 10
6.2. Informative References . . . . . . . . . . . . . . . . . 10
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
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.
Sudarsan, et al. Expires 20 April 2024 [Page 2]
Internet-Draft Abbreviated Title October 2023
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.
1.1. Requirements Language
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.
2. Power of Attorney based authorization
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:
* The agent can work on behalf of the principal, even if the user
(principal) is not online.
* The agent can send the PoA to another agent using the multi-level
authorization feature of PoA based authorization.
* The PoA model in its base form is completely decentralized (like
for example Pretty Good Privacy (PGP)).
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:
* Principal: The entity that generates, signs, and sends the PoA to
the agent.
* Agent: The device which receives the PoA to act on behalf of the
principal with limited credentials for a pre-defined time.
Sudarsan, et al. Expires 20 April 2024 [Page 3]
Internet-Draft Abbreviated Title October 2023
* Resource server: The third party with a server that stores the
information and credentials entitled to the principal. It serves
agents according to subgrants defined in PoAs.
* 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 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.
3. 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:
3.1. 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
Sudarsan, et al. Expires 20 April 2024 [Page 4]
Internet-Draft Abbreviated Title October 2023
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.
Sudarsan, et al. Expires 20 April 2024 [Page 5]
Internet-Draft Abbreviated Title October 2023
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.
3.2. 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].
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
Sudarsan, et al. Expires 20 April 2024 [Page 6]
Internet-Draft Abbreviated Title October 2023
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.
3.3. UMA
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.
Sudarsan, et al. Expires 20 April 2024 [Page 7]
Internet-Draft Abbreviated Title October 2023
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.
3.4. 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.
Sudarsan, et al. Expires 20 April 2024 [Page 8]
Internet-Draft Abbreviated Title October 2023
3.5. 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 [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.
4. 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 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
Sudarsan, et al. Expires 20 April 2024 [Page 9]
Internet-Draft Abbreviated Title October 2023
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.
5. Summary
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.
6. References
6.1. Normative References
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
6.2. Informative References
[proxy-signature]
"Proxy signatures: Delegation of the power to sign
messages,” IEICE transactions on fundamentals of
electronics, communications and computer sciences, vol.
79, no. 9, pp. 1338–1354", 1996.
[OAuth] Internet Engineering Task Force, "The OAuth 2.0
authorization framework", 2012.
Sudarsan, et al. Expires 20 April 2024 [Page 10]
Internet-Draft Abbreviated Title October 2023
[GNAP] Internet Engineering Task Force, "draft-ietf-gnap-core-
protocol-12", 2022.
[UMA] Internet Engineering Task Force, "User-Managed Access
(UMA) 2.0 Grant for OAuth 2.0 Authorization-12", 2019.
[SSO] Internet Engineering Task Force, "Architecture for
Implementing Network Single Sign-", 2000.
[Kerberos] Internet Engineering Task Force, "The Kerberos Network
Authentication Service (V5)", 2005.
Contributors
Thanks to all of the contributors.
Authors' Addresses
Sreelakshmi Vattaparambil Sudarsan
Lulea University of Technology
SE-97187 Lulea
Sweden
Email: srevat@ltu.se
Olov Schelen
Lulea University of Technology
SE-97187 Lulea
Sweden
Email: olov.schelen@ltu.se
Ulf Bodin
Lulea University of Technology
SE-97187 Lulea
Sweden
Email: ulf.bodin@ltu.se
Sudarsan, et al. Expires 20 April 2024 [Page 11]
