An Authorization Information Format (AIF) for Authentication and Authorization for Constrained Environments (ACE)
Extracted elements (19)
AIF uses allow-list semantics: everything is denied until explicitly allowed. This is a fundamental design choice for the access model underlying the format.
Dynamic-Offset was chosen as 32 so that all future CoAP methods that are registered (method codes 1–21 are practically usable in JSON per RFC 7493) can be represented both as direct and Dynamic-X variants without overlap with non-dynamic method bits.
The URI authority parts (scheme and host) are excluded from the AIF object identifier because they are authenticated during REST resource access at the transport layer; the AIF data item focuses on path and query only.
URI templates (RFC 6570) were considered but not adopted for Toid because matching a given URI against a set of templates in an AIF data item requires careful consideration of ease and unambiguity of matching.
A basic AIF implementation that only supports the static REST model (Section 2.1) must handle receipt of dynamic-resource-creation permissions (Section 2.3) by either rejecting the whole AIF item or ignoring unrecognized permissions; it MUST NOT partially apply an authorization it does not fully understand.
AIF MUST be used in a way that it is clear who is the target (enforcement point) of the authorizations, since multiple homogeneous devices may be covered by the same authorization.
AIF is defined generically as AIF-Generic<Toid, Tperm> = [* [Toid, Tperm]], a list of pairs of object identifiers and permission sets. The commonly used specific form is AIF-Specific = AIF-Generic<tstr, uint>, where object identifiers are text strings and permissions are bit-encoded numbers.
The REST-specific AIF instantiation uses the URI-local-part (path and query components) as the object identifier (Toid) and a bit-encoded set of CoAP/HTTP methods as the permission set (Tperm). The URI authority components are excluded as they are authenticated via the cryptographic armor.
The REST-specific model with dynamic resource creation adds Dynamic-X permissions (e.g., Dynamic-GET, Dynamic-DELETE). A Dynamic-X permission grants the right to exercise method X on resources returned via Location-indicating mechanisms (Location header or CoAP Location-* options) in a 2.01 Created response to a request the subject made to the listed resource.
Two media types are defined for AIF: application/aif+cbor and application/aif+json. Both have optional parameters Toid and Tperm whose default values are 'URI-local-part' and 'REST-method-set' respectively, as specified in Section 3.
IANA created a 'Sub-Parameter Registry for application/aif+cbor and application/aif+json' under MIME Media Type Sub-Parameter Registries, initially populated with Toid='URI-local-part' and Tperm='REST-method-set'. Registration policy is Specification Required.
IANA created media types application/aif+cbor (CBOR-encoded AIF) and application/aif+json (JSON-encoded AIF) in the Media Types registry, with optional parameters Toid and Tperm that reference a new sub-parameter subregistry.
IANA registered CoAP Content-Format IDs 290 (application/aif+cbor) and 291 (application/aif+json) in the CoAP Content-Formats subregistry of the CoRE Parameters registry.
An implementation of the dynamic resource creation model must carefully track dynamically created objects and the subjects to which Dynamic-X permissions apply, both on the server (enforcement) and client (capability awareness) sides.
Implementations that receive an AIF data item containing Dynamic-X permissions they do not understand must either reject the entire data item or act only on permissions they do understand; they must not silently grant unrecognized permissions, preserving allow-list semantics.
The cryptographic armor around an AIF data item must (1) unambiguously identify the subject to which authorizations apply, and (2) provide context information to derive the full identity of the object (e.g., scheme and authority for constructing full URIs from URI-local-part values).
A JSON-encoded AIF example for three resources is [["/ s/temp",1],["/a/led",5],["/dtls",2]], totaling 40 bytes. The CBOR encoding of the same data is 28 bytes, structured as an array of 2-element arrays each containing a text string and an unsigned integer.
AIF is defined in CDDL as AIF-REST = AIF-Generic<local-path, REST-method-set>, where local-path is a tstr (relative URI to enforcement point) and REST-method-set is a uint constrained with .bits over the named method constants.
The REST-method-set is encoded as an unsigned integer bit field. Each method's bit position equals its CoAP method number minus 1 (GET=0, POST=1, PUT=2, DELETE=3, FETCH=4, PATCH=5, iPATCH=6). Dynamic-X variants use the same bit position plus Dynamic-Offset=32 (e.g., Dynamic-DELETE=35).