Internet Engineering Task Force (IETF) C. Bormann Request for Comments: 9237 Universität Bremen TZI Category: Standards Track April 2022 ISSN: 2070-1721 An Authorization Information Format (AIF) for Authentication and Authorization for Constrained Environments (ACE) Abstract Information about which entities are authorized to perform what operations on which constituents of other entities is a crucial component of producing an overall system that is secure. Conveying precise authorization information is especially critical in highly automated systems with large numbers of entities, such as the Internet of Things. This specification provides a generic information model and format for representing such authorization information, as well as two variants of a specific instantiation of that format for use with Representational State Transfer (REST) resources identified by URI path. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9237. Copyright Notice Copyright (c) 2022 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. Table of Contents 1. Introduction 1.1. Terminology 2. Information Model 2.1. REST-Specific Model 2.2. Limitations 2.3. REST-Specific Model with Dynamic Resource Creation 3. Data Model 4. Media Types 5. IANA Considerations 5.1. Media Types 5.1.1. application/aif+cbor 5.1.2. application/aif+json 5.2. Registries 5.3. Content-Format 6. Security Considerations 7. References 7.1. Normative References 7.2. Informative References Acknowledgements Author's Address 1. Introduction Constrained devices, as they are used in the Internet of Things, need security in order to operate correctly and prevent misuse. One important element of this security is that devices in the Internet of Things need to be able to decide which operations requested of them should be considered authorized, ascertain that the authorization to request the operation does apply to the actual requester as authenticated, and ascertain that other devices they make requests of are the ones they intended. To transfer detailed authorization information from an authorization manager (such as an ACE-OAuth authorization server [RFC9200]) to a device, a compact representation format is needed. This document defines such a format -- the Authorization Information Format (AIF). AIF is defined both as a general structure that can be used for many different applications and as a specific instantiation tailored to REST resources and the permissions on them, including some provision for dynamically created resources. 1.1. Terminology This memo uses terms from the Constrained Application Protocol (CoAP) [RFC7252] and the Internet Security Glossary [RFC4949]; CoAP is used for the explanatory examples as it is a good fit for constrained devices. The shape of data is specified in Concise Data Definition Language (CDDL) [RFC8610] [RFC9165]. Terminology for constrained devices is defined in [RFC7228]. The term "byte", abbreviated by "B", is used in its now customary sense as a synonym for "octet". 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.