< draft-ietf-ace-aif-05.txt		draft-ietf-ace-aif-06.txt >
	ACE Working Group C. Bormann		ACE Working Group C. Bormann
	Internet-Draft Universität Bremen TZI		Internet-Draft Universität Bremen TZI
	Intended status: Standards Track 15 February 2022		Intended status: Standards Track 5 March 2022
	Expires: 19 August 2022		Expires: 6 September 2022
	An Authorization Information Format (AIF) for ACE		An Authorization Information Format (AIF) for ACE
	draft-ietf-ace-aif-05		draft-ietf-ace-aif-06
	Abstract		Abstract
	Information about which entities are authorized to perform what		Information about which entities are authorized to perform what
	operations on which constituents of other entities is a crucial		operations on which constituents of other entities is a crucial
	component of producing an overall system that is secure. Conveying		component of producing an overall system that is secure. Conveying
	precise authorization information is especially critical in highly		precise authorization information is especially critical in highly
	automated systems with large numbers of entities, such as the		automated systems with large numbers of entities, such as the
	"Internet of Things".		"Internet of Things".
	skipping to change at page 2, line 10 ¶		skipping to change at page 2, line 10 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on 19 August 2022.		This Internet-Draft will expire on 6 September 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2022 IETF Trust and the persons identified as the		Copyright (c) 2022 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	skipping to change at page 2, line 37 ¶		skipping to change at page 2, line 37 ¶
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3		1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Information Model . . . . . . . . . . . . . . . . . . . . . . 3		2. Information Model . . . . . . . . . . . . . . . . . . . . . . 3
	2.1. REST-specific Model . . . . . . . . . . . . . . . . . . . 4		2.1. REST-specific Model . . . . . . . . . . . . . . . . . . . 4
	2.2. Limitations . . . . . . . . . . . . . . . . . . . . . . . 5		2.2. Limitations . . . . . . . . . . . . . . . . . . . . . . . 5
	2.3. REST-specific Model With Dynamic Resource Creation . . . 6		2.3. REST-specific Model With Dynamic Resource Creation . . . 6
	3. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 6		3. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 6
	4. Media Types . . . . . . . . . . . . . . . . . . . . . . . . . 8		4. Media Types . . . . . . . . . . . . . . . . . . . . . . . . . 8
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
	5.1. Media Types . . . . . . . . . . . . . . . . . . . . . . . 8		5.1. Media Types . . . . . . . . . . . . . . . . . . . . . . . 9
	5.2. Registries . . . . . . . . . . . . . . . . . . . . . . . 10		5.2. Registries . . . . . . . . . . . . . . . . . . . . . . . 10
	5.3. Content-Format . . . . . . . . . . . . . . . . . . . . . 11		5.3. Content-Format . . . . . . . . . . . . . . . . . . . . . 11
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 11		6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
	7.1. Normative References . . . . . . . . . . . . . . . . . . 12		7.1. Normative References . . . . . . . . . . . . . . . . . . 12
	7.2. Informative References . . . . . . . . . . . . . . . . . 13		7.2. Informative References . . . . . . . . . . . . . . . . . 13
	Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 15		Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 15
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15
	1. Introduction		1. Introduction
	skipping to change at page 3, line 28 ¶		skipping to change at page 3, line 28 ¶
	[I-D.ietf-ace-oauth-authz]) to a device, a compact representation		[I-D.ietf-ace-oauth-authz]) to a device, a compact representation
	format is needed. This document defines such a format, the		format is needed. This document defines such a format, the
	Authorization Information Format (AIF). AIF is defined both as a		Authorization Information Format (AIF). AIF is defined both as a
	general structure that can be used for many different applications		general structure that can be used for many different applications
	and as a specific instantiation tailored to REST resources and the		and as a specific instantiation tailored to REST resources and the
	permissions on them, including some provision for dynamically created		permissions on them, including some provision for dynamically created
	resources.		resources.
	1.1. Terminology		1.1. Terminology
	This memo uses terms from [RFC7252] and [RFC4949]; CoAP is used for		This memo uses terms from CoAP [RFC7252] and the Internet Security
	the explanatory examples as it is a good fit for Constrained Devices.		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 CDDL [RFC8610] [RFC9165].		The shape of data is specified in CDDL [RFC8610] [RFC9165].
	Terminology for Constrained Devices is defined in [RFC7228].		Terminology for Constrained Devices is defined in [RFC7228].
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in		"OPTIONAL" in this document are to be interpreted as described in
	BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all		BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	skipping to change at page 4, line 37 ¶		skipping to change at page 4, line 40 ¶
	Figure 2: Commonly used shape of a specific AIF		Figure 2: Commonly used shape of a specific AIF
	2.1. REST-specific Model		2.1. REST-specific Model
	In the specific instantiation of the REST resources and the		In the specific instantiation of the REST resources and the
	permissions on them, for the object identifiers (Toid), we use the		permissions on them, for the object identifiers (Toid), we use the
	URI of a resource on a CoAP server. More specifically, since the		URI of a resource on a CoAP server. More specifically, since the
	parts of the URI that identify the server ("authority" in [RFC3986])		parts of the URI that identify the server ("authority" in [RFC3986])
	are what are authenticated during REST resource access (Section 4.2.2		are what are authenticated during REST resource access (Section 4.2.2
	of [I-D.ietf-httpbis-semantics] and Section 6.2 of [RFC7252]), they		of [I-D.ietf-httpbis-semantics] and Section 6.2 of [RFC7252]), they
	naturally fall into the realm handled by the cryptographic armor); we		naturally fall into the realm handled by the cryptographic armor; we
	therefore focus on the "path" ("path-abempty") and "query" parts of		therefore focus on the "path" ("path-abempty") and "query" parts of
	the URI (URI "local-part" in this specification, as expressed by the		the URI (_URI-local-part_ in this specification, as expressed by the
	Uri-Path and Uri-Query options in CoAP). As a consequence, AIF MUST		Uri-Path and Uri-Query options in CoAP). As a consequence, AIF MUST
	be used in a way that it is clear who is the target (enforcement		be used in a way that it is clear who is the target (enforcement
	point) of these authorizations (note that there may be more than one		point) of these authorizations (note that there may be more than one
	target that the same authorization applies to, e.g., in a situation		target that the same authorization applies to, e.g., in a situation
	with homogeneous devices).		with homogeneous devices).
	For the permissions (Tperm), we use a simple permissions model that		For the permissions (Tperm), we use a simple permissions model that
	lists the subset of the REST (CoAP or HTTP) methods permitted. This		lists the subset of the REST (CoAP or HTTP) methods permitted. This
	model is summarized in Table 1.		model is summarized in Table 1.
	+============+================+		+================+================+
	| local-part | Permission Set |		| URI-local-part | Permission Set |
	+============+================+		+================+================+
	| /s/temp | GET |		| /s/temp | GET |
	+------------+----------------+		+----------------+----------------+
	| /a/led | PUT, GET |		| /a/led | PUT, GET |
	+------------+----------------+		+----------------+----------------+
	| /dtls | POST |		| /dtls | POST |
	+------------+----------------+		+----------------+----------------+
	Table 1: An authorization		Table 1: An authorization
	instance in the AIF		instance in the AIF Information
	Information Model		Model
	In this example, a device offers a temperature sensor /s/temp for		In this example, a device offers a temperature sensor /s/temp for
	read-only access, a LED actuator /a/led for read/write, and a /dtls		read-only access, a LED actuator /a/led for read/write, and a /dtls
	resource for POST access.		resource for POST access.
	As will be seen in the data model (Section 3), the representations of		As will be seen in the data model (Section 3), the representations of
	REST methods provided are limited to those that have a CoAP method		REST methods provided are limited to those that have a CoAP method
	number assigned; an extension to the model may be necessary to		number assigned; an extension to the model may be necessary to
	represent permissions for exotic HTTP methods.		represent permissions for exotic HTTP methods.
	2.2. Limitations		2.2. Limitations
	This simple information model only allows granting permissions for		This simple information model only allows granting permissions for
	statically identifiable objects, e.g., URIs for the REST-specific		statically identifiable objects, e.g., URIs for the REST-specific
	instantiation. One might be tempted to extend the model towards URI		instantiation. One might be tempted to extend the model towards URI
	templates [RFC6570] (for instance, to open up an authorization for		templates [RFC6570] (for instance, to open up an authorization for
	many parameter values as in /s/temp{?any*}), however, that requires		many parameter values as in /s/temp{?any*}). However, that requires
	some considerations of the ease and unambiguity of matching a given		some considerations of the ease and unambiguity of matching a given
	URI against a set of templates in an AIF object.		URI against a set of templates in an AIF data item.
	This simple information model also does not allow further		This simple information model also does not allow expressing
	conditionalizing access based on state outside the identification of		conditionalized access based on state outside the identification of
	objects (e.g., "opening a door is allowed if that is not locked").		objects (e.g., "opening a door is allowed if that is not locked").
	Finally, the model does not provide any special access for a set of		Finally, the model does not provide any special access for a set of
	resources that are specific to a subject, e.g., that the subject		resources that are specific to a subject, e.g., that the subject
	created itself by previous operations (PUT, POST, or PATCH/iPATCH		created itself by previous operations (PUT, POST, or PATCH/iPATCH
	[RFC8132]) or that were specifically created for the subject by		[RFC8132]) or that were specifically created for the subject by
	others.		others.
	2.3. REST-specific Model With Dynamic Resource Creation		2.3. REST-specific Model With Dynamic Resource Creation
	skipping to change at page 6, line 20 ¶		skipping to change at page 6, line 20 ¶
	the subject by providing Location-* options in a CoAP response or		the subject by providing Location-* options in a CoAP response or
	using the Location header field in HTTP [I-D.ietf-httpbis-semantics]		using the Location header field in HTTP [I-D.ietf-httpbis-semantics]
	(the Location-indicating mechanisms). (The concept is somewhat		(the Location-indicating mechanisms). (The concept is somewhat
	comparable to "ACL inheritance" in NFSv4 [RFC8881], except that it		comparable to "ACL inheritance" in NFSv4 [RFC8881], except that it
	does not use a containment relationship but the fact that the dynamic		does not use a containment relationship but the fact that the dynamic
	resource was created from a resource to which the subject had		resource was created from a resource to which the subject had
	access.) In other words, it addresses an important subset of the		access.) In other words, it addresses an important subset of the
	third limitation mentioned in Section 2.2.		third limitation mentioned in Section 2.2.
	+================+===================================+		+================+===================================+
	| local-part | Permission Set |		| URI-local-part | Permission Set |
	+================+===================================+		+================+===================================+
	| /a/make-coffee | POST, Dynamic-GET, Dynamic-DELETE |		| /a/make-coffee | POST, Dynamic-GET, Dynamic-DELETE |
	+----------------+-----------------------------------+		+----------------+-----------------------------------+
	Table 2: An authorization instance in the AIF		Table 2: An authorization instance in the AIF
	Information Model		Information Model
	For a method X, the presence of a Dynamic-X permission means that the		For a method X, the presence of a Dynamic-X permission means that the
	subject holds permission to exercise the method X on resources that		subject holds permission to exercise the method X on resources that
	have been returned in a 2.01 (201) response by a Location-indicating		have been returned in a 2.01 (201) response by a Location-indicating
	skipping to change at page 6, line 50 ¶		skipping to change at page 6, line 50 ¶
	presumed once a Dynamic-X permission is present.		presumed once a Dynamic-X permission is present.
	3. Data Model		3. Data Model
	Different data model specializations can be defined for the generic		Different data model specializations can be defined for the generic
	information model given above.		information model given above.
	In this section, we will give the data model for simple REST		In this section, we will give the data model for simple REST
	authorization as per Section 2.1 and Section 2.3. As discussed, in		authorization as per Section 2.1 and Section 2.3. As discussed, in
	this case the object identifier is specialized as a text string		this case the object identifier is specialized as a text string
	giving a relative URI (local-part as absolute path on the server		giving a relative URI (URI-local-part as absolute path on the server
	serving as enforcement point). The permission set is specialized to		serving as enforcement point). The permission set is specialized to
	a single number by the following steps:		a single number REST-method-set by the following steps:
	* The entries in the table that specify the same local-part are		* The entries in the table that specify the same URI-local-part are
	merged into a single entry that specifies the union of the		merged into a single entry that specifies the union of the
	permission sets.		permission sets.
	* The (non-dynamic) methods in the permission sets are converted		* The (non-dynamic) methods in the permission sets are converted
	into their CoAP method numbers, minus 1.		into their CoAP method numbers, minus 1.
	* Dynamic-X permissions are converted into what the number would		* Dynamic-X permissions are converted into what the number would
	have been for X, plus a Dynamic-Offset chosen as 32 (e.g., 35 for		have been for X, plus a Dynamic-Offset chosen as 32 (e.g., 35 is
	Dynamic-DELETE).		the number for Dynamic-DELETE as the number for DELETE is 3).
	* The set of numbers is converted into a single number by taking		* The set of numbers is converted into a single number REST-method-
	each number to the power of two and computing the inclusive OR of		set by taking each number to the power of two and computing the
	the binary representations of all the power values.		inclusive OR of the binary representations of all the power
			values.
	This data model could be interchanged in the JSON [RFC8259]		This data model could be interchanged in the JSON [RFC8259]
	representation given in Figure 3.		representation given in Figure 3.
	[["/s/temp",1],["/a/led",5],["/dtls",2]]		[["/s/temp",1],["/a/led",5],["/dtls",2]]
	Figure 3: An authorization instance encoded in JSON (40 bytes)		Figure 3: An authorization instance encoded in JSON (40 bytes)
	In Figure 4, a straightforward specification of the data model		In Figure 4, a straightforward specification of the data model
	(including both the methods from [RFC7252] and the new ones from		(including both the methods from [RFC7252] and the new ones from
	[RFC8132], identified by the method code minus 1) is shown in CDDL		[RFC8132], identified by the method code minus 1) is shown in CDDL
	[RFC8610] [RFC9165]:		[RFC8610] [RFC9165]:
	AIF-REST = AIF-Generic<path, permissions>		AIF-REST = AIF-Generic<local-path, REST-method-set>
	path = tstr ; URI relative to enforcement point		local-path = tstr ; URI relative to enforcement point
	permissions = uint .bits methods		REST-method-set = uint .bits methods
	methods = &(		methods = &(
	GET: 0		GET: 0
	POST: 1		POST: 1
	PUT: 2		PUT: 2
	DELETE: 3		DELETE: 3
	FETCH: 4		FETCH: 4
	PATCH: 5		PATCH: 5
	iPATCH: 6		iPATCH: 6
	Dynamic-GET: 32; 0 .plus Dynamic-Offset		Dynamic-GET: 32; 0 .plus Dynamic-Offset
	Dynamic-POST: 33; 1 .plus Dynamic-Offset		Dynamic-POST: 33; 1 .plus Dynamic-Offset
	skipping to change at page 8, line 35 ¶		skipping to change at page 8, line 36 ¶
	Note that choosing 32 as Dynamic-Offset means that all future CoAP		Note that choosing 32 as Dynamic-Offset means that all future CoAP
	methods that can be registered can be represented both as themselves		methods that can be registered can be represented both as themselves
	and in the Dynamic-X variant, but only the dynamic forms of methods 1		and in the Dynamic-X variant, but only the dynamic forms of methods 1
	to 21 are typically usable in a JSON form [RFC7493].		to 21 are typically usable in a JSON form [RFC7493].
	4. Media Types		4. Media Types
	This specification defines media types for the generic information		This specification defines media types for the generic information
	model, expressed in JSON (application/aif+json) or in CBOR		model, expressed in JSON (application/aif+json) or in CBOR
	(application/aif+cbor). These media types have parameters for		(application/aif+cbor). These media types have parameters for
	specifying Toid and Tperm; default values are the values "local-uri"		specifying Toid and Tperm; default values are the values "URI-local-
	for Toid and "REST-method-set" for Tperm.		part" for Toid and "REST-method-set" for Tperm, as per Section 3 of
			the present specification.
	A specification that wants to use Generic AIF with different Toid		A specification that wants to use Generic AIF with different Toid
	and/or Tperm is expected to request these as media type parameters		and/or Tperm is expected to request these as media type parameters
	(Section 5.2) and register a corresponding Content-Format		(Section 5.2) and register a corresponding Content-Format
	(Section 5.3).		(Section 5.3).
	5. IANA Considerations		5. IANA Considerations
	// RFC Ed.: throughout this section, please replace RFC XXXX with the		// RFC Ed.: throughout this section, please replace RFC XXXX with the
	// RFC number of this specification and remove this note.		// RFC number of this specification and remove this note.
	skipping to change at page 9, line 23 ¶		skipping to change at page 9, line 28 ¶
	Table 3		Table 3
	For application/aif+cbor:		For application/aif+cbor:
	Type name: application		Type name: application
	Subtype name: aif+cbor		Subtype name: aif+cbor
	Required parameters: none		Required parameters: none
	Optional parameters:		Optional parameters:
	* Toid: the identifier for the object for which permissions are		* Toid: the identifier for the object for which permissions are
	supplied. A value from the media-type parameter sub-registry		supplied. A value from the media-type parameter sub-registry
	for Toid. Default value: "local-uri" (RFC XXXX).		for Toid. Default value: "URI-local-part" (RFC XXXX).
	* Tperm: the data type of a permission set for the object		* Tperm: the data type of a permission set for the object
	identified via a Toid. A value from the media-type parameter		identified via a Toid. A value from the media-type parameter
	sub-registry for Tperm. Default value: "REST-method-set" (RFC		sub-registry for Tperm. Default value: "REST-method-set" (RFC
	XXXX).		XXXX).
	Encoding considerations: binary (CBOR)		Encoding considerations: binary (CBOR)
	Security considerations: Section 6 of RFC XXXX		Security considerations: Section 6 of RFC XXXX
	Interoperability considerations: none		Interoperability considerations: none
	Published specification: Section 4 of RFC XXXX		Published specification: Section 4 of RFC XXXX
	Applications that use this media type: Applications that need to		Applications that use this media type: Applications that need to
	skipping to change at page 9, line 47 ¶		skipping to change at page 10, line 4 ¶
	fragment identifiers is as specified for "application/cbor". (At		fragment identifiers is as specified for "application/cbor". (At
	publication of RFC XXXX, there is no fragment identification		publication of RFC XXXX, there is no fragment identification
	syntax defined for "application/cbor".)		syntax defined for "application/cbor".)
	Person & email address to contact for further information: ACE WG		Person & email address to contact for further information: ACE WG
	mailing list (ace@ietf.org), or IETF Applications and Real-Time		mailing list (ace@ietf.org), or IETF Applications and Real-Time
	Area (art@ietf.org)		Area (art@ietf.org)
	Intended usage: COMMON		Intended usage: COMMON
	Restrictions on usage: none		Restrictions on usage: none
	Author/Change controller: IETF		Author/Change controller: IETF
	Provisional registration: no		Provisional registration: no
	For application/aif+json:		For application/aif+json:
	Type name: application		Type name: application
	Subtype name: aif+json		Subtype name: aif+json
	Required parameters: none		Required parameters: none
	Optional parameters:		Optional parameters:
	* Toid: the identifier for the object for which permissions are		* Toid: the identifier for the object for which permissions are
	supplied. A value from the media-type parameter sub-registry		supplied. A value from the media-type parameter sub-registry
	for Toid. Default value: "local-uri" (RFC XXXX).		for Toid. Default value: "URI-local-part" (RFC XXXX).
	* Tperm: the data type of a permission set for the object		* Tperm: the data type of a permission set for the object
	identified via a Toid. A value from the media-type parameter		identified via a Toid. A value from the media-type parameter
	sub-registry for Tperm. Default value: "REST-method-set" (RFC		sub-registry for Tperm. Default value: "REST-method-set" (RFC
	XXXX).		XXXX).
	Encoding considerations: binary (JSON is UTF-8-encoded text)		Encoding considerations: binary (JSON is UTF-8-encoded text)
	Security considerations: Section 6 of RFC XXXX		Security considerations: Section 6 of RFC XXXX
	Interoperability considerations: none		Interoperability considerations: none
	Published specification: Section 4 of RFC XXXX		Published specification: Section 4 of RFC XXXX
	Applications that use this media type: Applications that need to		Applications that use this media type: Applications that need to
	skipping to change at page 10, line 34 ¶		skipping to change at page 10, line 39 ¶
	Person & email address to contact for further information: ACE WG		Person & email address to contact for further information: ACE WG
	mailing list (ace@ietf.org), or IETF Applications and Real-Time		mailing list (ace@ietf.org), or IETF Applications and Real-Time
	Area (art@ietf.org)		Area (art@ietf.org)
	Intended usage: COMMON		Intended usage: COMMON
	Restrictions on usage: none		Restrictions on usage: none
	Author/Change controller: IETF		Author/Change controller: IETF
	Provisional registration: no		Provisional registration: no
	5.2. Registries		5.2. Registries
	IANA is requested to create a sub-registry for application/aif+cbor		For the media types application/aif+cbor and application/aif+json,
	and application/aif+json within [IANA.media-type-sub-parameters] for		IANA is requested to create a sub-registry within
	the two media-type parameters Toid and Tperm, populated with:		[IANA.media-type-sub-parameters] for the two media-type parameters
			Toid and Tperm, populated with:
	+===========+=================+=====================+===========+		+===========+=================+=====================+===========+
	| Parameter | name | Description/ | Reference |		| Parameter | name | Description/ | Reference |
	| | | Specification | |		| | | Specification | |
	+===========+=================+=====================+===========+		+===========+=================+=====================+===========+
	| Toid | local-part | local-part of URI | RFC XXXX |		| Toid | URI-local-part | local-part of URI | RFC XXXX |
	+-----------+-----------------+---------------------+-----------+		+-----------+-----------------+---------------------+-----------+
	| Tperm | REST-method-set | set of REST methods | RFC XXXX |		| Tperm | REST-method-set | set of REST methods | RFC XXXX |
	| | | represented | |		| | | represented | |
	+-----------+-----------------+---------------------+-----------+		+-----------+-----------------+---------------------+-----------+
	Table 4		Table 4
	The registration policy is Specification required [RFC8126]. The		The registration policy is Specification required [RFC8126]. The
	designated expert will engage with the submitter to ascertain the		designated expert will engage with the submitter to ascertain the
	requirements of this document are addressed.		requirements of this document are addressed.
	5.3. Content-Format		5.3. Content-Format
	IANA is requested to register Content-Format numbers in the "CoAP		IANA is requested to register Content-Format numbers in the "CoAP
	Content-Formats" sub-registry, within the "Constrained RESTful		Content-Formats" sub-registry, within the "Constrained RESTful
	Environments (CoRE) Parameters" Registry [IANA.core-parameters], as		Environments (CoRE) Parameters" Registry [IANA.core-parameters], as
	follows:		follows:
	+======================+================+======+===========+		+======================+================+======+===========+
	| Media Type | Content Coding | ID | Reference |		| Content-Type | Content Coding | ID | Reference |
	+======================+================+======+===========+		+======================+================+======+===========+
	| application/aif+cbor | - | TBD1 | RFC XXXX |		| application/aif+cbor | - | TBD1 | RFC XXXX |
	+----------------------+----------------+------+-----------+		+----------------------+----------------+------+-----------+
	| application/aif+json | - | TBD2 | RFC XXXX |		| application/aif+json | - | TBD2 | RFC XXXX |
	+----------------------+----------------+------+-----------+		+----------------------+----------------+------+-----------+
	Table 5		Table 5
	// RFC Ed.: please replace TBD1 and TBD2 with assigned IDs and remove		// RFC Ed.: please replace TBD1 and TBD2 with assigned IDs and remove
	this note.		this note.
			In the registry as defined by Section 12.3 of [RFC7252] at the time
			of writing, the column "Content-Type" is called "Media type" and the
			column "Content Coding" is called "Encoding".
	Note that applications that register Toid and Tperm values are		Note that applications that register Toid and Tperm values are
	encouraged to also register Content-Formats for the relevant		encouraged to also register Content-Formats for the relevant
	combinations.		combinations.
	6. Security Considerations		6. Security Considerations
	The security considerations of [RFC7252] apply. Some wider issues		The security considerations of [RFC7252] apply. Some wider issues
	are discussed in [RFC8576].		are discussed in [RFC8576].
	The semantics of the authorization information defined in this		The semantics of the authorization information defined in this
	documents are that of an _allow-list_: everything is denied until it		document are that of an _allow-list_: everything is denied until it
	is explicitly allowed.		is explicitly allowed.
	When applying these formats, the referencing specification needs to		When applying these formats, the referencing specification needs to
	be careful to:		be careful to:
	* ensure that the cryptographic armor employed around this format		* ensure that the cryptographic armor employed around this format
	fulfills the referencing specification's security objectives, and		fulfills the referencing specification's security objectives, and
	that the armor or some additional information included in it with		that the armor or some additional information included in it with
	the AIF information (1) unambiguously identifies the subject to		the AIF data item (1) unambiguously identifies the subject to
	which the authorizations shall apply and provides (2) any context		which the authorizations shall apply and (2) provides any context
	information needed to derive the identity of the object to which		information needed to derive the identity of the object to which
	authorization is being granted from the object identifiers (such		authorization is being granted from the object identifiers (such
	as, for the data models defined in the present specification, the		as, for the data models defined in the present specification, the
	scheme and authority information that is used to construct the		scheme and authority information that is used to construct the
	full URI), and		full URI), and
	* ensure that the types used for Toid and Tperm provide the		* ensure that the types used for Toid and Tperm provide the
	appropriate granularity and precision so that application		appropriate granularity and precision so that application
	requirements on the precision of the authorization information are		requirements on the precision of the authorization information are
	fulfilled, and that all parties understand Toid/Tperm pairs to		fulfilled, and that all parties have the same understanding of
	signify the same operations.		each Toid/Tperm pair in terms of specified objects (resources) and
			operations on those.
	For the data formats, the security considerations of [RFC8259] and		For the data formats, the security considerations of [RFC8259] and
	[RFC8949] apply.		[RFC8949] apply.
	A plain implementation of AIF might implement just the basic REST		A plain implementation of AIF might implement just the basic REST
	model as per Section 2.1. If it receives authorizations that include		model as per Section 2.1. If it receives authorizations that include
	permissions that use the REST-specific Model With Dynamic Resource		permissions that use the REST-specific Model With Dynamic Resource
	Creation Section 2.3, it needs to either reject the AIF data item		Creation Section 2.3, it needs to either reject the AIF data item
	entirely or act only on the permissions that it does understand. In		entirely or act only on the permissions that it does understand. In
	other words, the semantics underlying an allow-list as discussed		other words, the semantics underlying an allow-list as discussed
End of changes. 30 change blocks.
	51 lines changed or deleted		59 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/