idnits 2.17.1 draft-ietf-ace-aif-07.txt: -(3): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 3 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (15 March 2022) is 772 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-httpbis-semantics' Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ACE Working Group C. Bormann 3 Internet-Draft Universität Bremen TZI 4 Intended status: Standards Track 15 March 2022 5 Expires: 16 September 2022 7 An Authorization Information Format (AIF) for ACE 8 draft-ietf-ace-aif-07 10 Abstract 12 Information about which entities are authorized to perform what 13 operations on which constituents of other entities is a crucial 14 component of producing an overall system that is secure. Conveying 15 precise authorization information is especially critical in highly 16 automated systems with large numbers of entities, such as the 17 "Internet of Things". 19 This specification provides a generic information model and format 20 for representing such authorization information, as well as two 21 variants of a specific instantiation of that format for use with REST 22 resources identified by URI path. 24 About This Document 26 This note is to be removed before publishing as an RFC. 28 Status information for this document may be found at 29 https://datatracker.ietf.org/doc/draft-ietf-ace-aif/. 31 Discussion of this document takes place on the Authentication and 32 Authorization for Constrained Environments (ace) Working Group 33 mailing list (mailto:ace@ietf.org), which is archived at 34 https://mailarchive.ietf.org/arch/browse/ace/. 36 Source for this draft and an issue tracker can be found at 37 https://github.com/cabo/ace-aif. 39 Status of This Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at https://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 This Internet-Draft will expire on 16 September 2022. 56 Copyright Notice 58 Copyright (c) 2022 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 63 license-info) in effect on the date of publication of this document. 64 Please review these documents carefully, as they describe your rights 65 and restrictions with respect to this document. Code Components 66 extracted from this document must include Revised BSD License text as 67 described in Section 4.e of the Trust Legal Provisions and are 68 provided without warranty as described in the Revised BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 73 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 74 2. Information Model . . . . . . . . . . . . . . . . . . . . . . 3 75 2.1. REST-specific Model . . . . . . . . . . . . . . . . . . . 4 76 2.2. Limitations . . . . . . . . . . . . . . . . . . . . . . . 5 77 2.3. REST-specific Model With Dynamic Resource Creation . . . 6 78 3. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 6 79 4. Media Types . . . . . . . . . . . . . . . . . . . . . . . . . 9 80 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 81 5.1. Media Types . . . . . . . . . . . . . . . . . . . . . . . 9 82 5.2. Registries . . . . . . . . . . . . . . . . . . . . . . . 11 83 5.3. Content-Format . . . . . . . . . . . . . . . . . . . . . 12 84 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 85 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 86 7.1. Normative References . . . . . . . . . . . . . . . . . . 13 87 7.2. Informative References . . . . . . . . . . . . . . . . . 14 88 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 16 89 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 91 1. Introduction 93 Constrained Devices as they are used in the "Internet of Things" need 94 security in order to operate correctly and prevent misuse. One 95 important element of this security is that devices in the Internet of 96 Things need to be able to decide which operations requested of them 97 should be considered authorized, need to ascertain that the 98 authorization to request the operation does apply to the actual 99 requester as authenticated, and need to ascertain that other devices 100 they make requests of are the ones they intended. 102 To transfer detailed authorization information from an authorization 103 manager (such as an ACE-OAuth Authorization Server 104 [I-D.ietf-ace-oauth-authz]) to a device, a compact representation 105 format is needed. This document defines such a format, the 106 Authorization Information Format (AIF). AIF is defined both as a 107 general structure that can be used for many different applications 108 and as a specific instantiation tailored to REST resources and the 109 permissions on them, including some provision for dynamically created 110 resources. 112 1.1. Terminology 114 This memo uses terms from CoAP [RFC7252] and the Internet Security 115 Glossary [RFC4949]; CoAP is used for the explanatory examples as it 116 is a good fit for Constrained Devices. 118 The shape of data is specified in CDDL [RFC8610] [RFC9165]. 119 Terminology for Constrained Devices is defined in [RFC7228]. 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 123 "OPTIONAL" in this document are to be interpreted as described in 124 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 125 capitals, as shown here. 127 The term "byte", abbreviated by "B", is used in its now customary 128 sense as a synonym for "octet". 130 2. Information Model 132 Authorizations are generally expressed through some data structures 133 that are cryptographically secured (or transmitted in a secure way). 134 This section discusses the information model underlying the payload 135 of that data (as opposed to the cryptographic armor around it). 137 The semantics of the authorization information defined in this 138 document are that of an _allow-list_: everything is denied until it 139 is explicitly allowed. 141 For the purposes of this specification, the underlying access control 142 model will be that of an access matrix, which gives a set of 143 permissions for each possible combination of a subject and an object. 144 We are focusing the AIF data item on a single row in the access 145 matrix (such a row has often been called a capability list), without 146 concern to the subject for which the data item is issued. As a 147 consequence, AIF MUST be used in a way that the subject of the 148 authorizations is unambiguously identified (e.g., as part of the 149 armor around it). 151 The generic model of such a capability list is a list of pairs of 152 object identifiers (of type Toid) and the permissions (of type Tperm) 153 the subject has on the object(s) identified. 155 AIF-Generic = [* [Toid, Tperm]] 157 Figure 1: Definition of Generic AIF 159 In a specific data model (such as the one also specified in this 160 document), the object identifier (Toid) will often be a text string, 161 and the set of permissions (Tperm) will be represented by a bitset in 162 turn represented as a number (see Section 3). 164 AIF-Specific = AIF-Generic 166 Figure 2: Commonly used shape of a specific AIF 168 2.1. REST-specific Model 170 In the specific instantiation of the REST resources and the 171 permissions on them, for the object identifiers (Toid), we use the 172 URI of a resource on a CoAP server. More specifically, since the 173 parts of the URI that identify the server ("authority" in [RFC3986]) 174 are what are authenticated during REST resource access (Section 4.2.2 175 of [I-D.ietf-httpbis-semantics] and Section 6.2 of [RFC7252]), they 176 naturally fall into the realm handled by the cryptographic armor; we 177 therefore focus on the "path" ("path-abempty") and "query" parts of 178 the URI (_URI-local-part_ in this specification, as expressed by the 179 Uri-Path and Uri-Query options in CoAP). As a consequence, AIF MUST 180 be used in a way that it is clear who is the target (enforcement 181 point) of these authorizations (note that there may be more than one 182 target that the same authorization applies to, e.g., in a situation 183 with homogeneous devices). 185 For the permissions (Tperm), we use a simple permissions model that 186 lists the subset of the REST (CoAP or HTTP) methods permitted. This 187 model is summarized in Table 1. 189 +================+================+ 190 | URI-local-part | Permission Set | 191 +================+================+ 192 | /s/temp | GET | 193 +----------------+----------------+ 194 | /a/led | PUT, GET | 195 +----------------+----------------+ 196 | /dtls | POST | 197 +----------------+----------------+ 199 Table 1: An authorization 200 instance in the AIF Information 201 Model 203 In this example, a device offers a temperature sensor /s/temp for 204 read-only access, a LED actuator /a/led for read/write, and a /dtls 205 resource for POST access. 207 As will be seen in the data model (Section 3), the representations of 208 REST methods provided are limited to those that have a CoAP method 209 number assigned; an extension to the model may be necessary to 210 represent permissions for exotic HTTP methods. 212 2.2. Limitations 214 This simple information model only allows granting permissions for 215 statically identifiable objects, e.g., URIs for the REST-specific 216 instantiation. One might be tempted to extend the model towards URI 217 templates [RFC6570] (for instance, to open up an authorization for 218 many parameter values as in /s/temp{?any*}). However, that requires 219 some considerations of the ease and unambiguity of matching a given 220 URI against a set of templates in an AIF data item. 222 This simple information model also does not allow expressing 223 conditionalized access based on state outside the identification of 224 objects (e.g., "opening a door is allowed if that is not locked"). 226 Finally, the model does not provide any special access for a set of 227 resources that are specific to a subject, e.g., that the subject 228 created itself by previous operations (PUT, POST, or PATCH/iPATCH 229 [RFC8132]) or that were specifically created for the subject by 230 others. 232 2.3. REST-specific Model With Dynamic Resource Creation 234 The REST-specific Model With Dynamic Resource Creation addresses the 235 need to provide defined access to dynamic resources that were created 236 by the subject itself, specifically, a resource that is made known to 237 the subject by providing Location-* options in a CoAP response or 238 using the Location header field in HTTP [I-D.ietf-httpbis-semantics] 239 (the Location-indicating mechanisms). (The concept is somewhat 240 comparable to "ACL inheritance" in NFSv4 [RFC8881], except that it 241 does not use a containment relationship but the fact that the dynamic 242 resource was created from a resource to which the subject had 243 access.) In other words, it addresses an important subset of the 244 third limitation mentioned in Section 2.2. 246 +================+===================================+ 247 | URI-local-part | Permission Set | 248 +================+===================================+ 249 | /a/make-coffee | POST, Dynamic-GET, Dynamic-DELETE | 250 +----------------+-----------------------------------+ 252 Table 2: An authorization instance in the AIF 253 Information Model With Dynamic Resource Creation 255 For a method X, the presence of a Dynamic-X permission means that the 256 subject holds permission to exercise the method X on resources that 257 have been returned in a 2.01 (201 Created) response by a Location- 258 indicating mechanism to a request that the subject made to the 259 resource listed. In the example shown in Table 2, POST operations on 260 /a/make-coffee might return the location of a resource dynamically 261 created on the coffee machine that allows GET to find out about the 262 status of, and DELETE to cancel, the coffee-making operation. 264 Since the use of the extension defined in this section can be 265 detected by the mentioning of the Dynamic-X permissions, there is no 266 need for another explicit switch between the basic and the model 267 extended by dynamic resource creation; the extended model is always 268 presumed once a Dynamic-X permission is present. 270 3. Data Model 272 Different data model specializations can be defined for the generic 273 information model given above. 275 In this section, we will give the data model for simple REST 276 authorization as per Section 2.1 and Section 2.3. As discussed, in 277 this case the object identifier is specialized as a text string 278 giving a relative URI (URI-local-part as absolute path on the server 279 serving as enforcement point). The permission set is specialized to 280 a single number REST-method-set by the following steps: 282 * The entries in the table that specify the same URI-local-part are 283 merged into a single entry that specifies the union of the 284 permission sets. 286 * The (non-dynamic) methods in the permission sets are converted 287 into their CoAP method numbers, minus 1. 289 * Dynamic-X permissions are converted into what the number would 290 have been for X, plus a Dynamic-Offset chosen as 32 (e.g., 35 is 291 the number for Dynamic-DELETE as the number for DELETE is 3). 293 * The set of numbers is converted into a single number REST-method- 294 set by taking two to the power of each (decremented) method number 295 and computing the inclusive OR of the binary representations of 296 all the power values. 298 This data model could be interchanged in the JSON [RFC8259] 299 representation given in Figure 3. 301 [["/s/temp",1],["/a/led",5],["/dtls",2]] 303 Figure 3: An authorization instance encoded in JSON (40 bytes) 305 In Figure 4, a straightforward specification of the data model 306 (including both the methods from [RFC7252] and the new ones from 307 [RFC8132], identified by the method code minus 1) is shown in CDDL 308 [RFC8610] [RFC9165]: 310 AIF-REST = AIF-Generic 311 local-path = tstr ; URI relative to enforcement point 312 REST-method-set = uint .bits methods 313 methods = &( 314 GET: 0 315 POST: 1 316 PUT: 2 317 DELETE: 3 318 FETCH: 4 319 PATCH: 5 320 iPATCH: 6 321 Dynamic-GET: 32; 0 .plus Dynamic-Offset 322 Dynamic-POST: 33; 1 .plus Dynamic-Offset 323 Dynamic-PUT: 34; 2 .plus Dynamic-Offset 324 Dynamic-DELETE: 35; 3 .plus Dynamic-Offset 325 Dynamic-FETCH: 36; 4 .plus Dynamic-Offset 326 Dynamic-PATCH: 37; 5 .plus Dynamic-Offset 327 Dynamic-iPATCH: 38; 6 .plus Dynamic-Offset 328 ) 330 Figure 4: AIF in CDDL 332 For the information shown in Table 1 and Figure 3, a representation 333 in CBOR [RFC8949] is given in Figure 5; again, several optimizations/ 334 improvements are possible. 336 83 # array(3) 337 82 # array(2) 338 67 # text(7) 339 2f732f74656d70 # "/s/temp" 340 01 # unsigned(1) 341 82 # array(2) 342 66 # text(6) 343 2f612f6c6564 # "/a/led" 344 05 # unsigned(5) 345 82 # array(2) 346 65 # text(5) 347 2f64746c73 # "/dtls" 348 02 # unsigned(2) 350 Figure 5: An authorization instance encoded in CBOR (28 bytes) 352 Note that choosing 32 as Dynamic-Offset means that all future CoAP 353 methods that can be registered can be represented both as themselves 354 and in the Dynamic-X variant, but only the dynamic forms of methods 1 355 to 21 are typically usable in a JSON form [RFC7493]. 357 4. Media Types 359 This specification defines media types for the generic information 360 model, expressed in JSON (application/aif+json) or in CBOR 361 (application/aif+cbor). These media types have parameters for 362 specifying Toid and Tperm; default values are the values "URI-local- 363 part" for Toid and "REST-method-set" for Tperm, as per Section 3 of 364 the present specification. 366 A specification that wants to use Generic AIF with different Toid 367 and/or Tperm is expected to request these as media type parameters 368 (Section 5.2) and register a corresponding Content-Format 369 (Section 5.3). 371 5. IANA Considerations 373 // RFC Ed.: throughout this section, please replace RFC XXXX with the 374 // RFC number of this specification and remove this note. 376 5.1. Media Types 378 IANA is requested to add the following Media-Types to the "Media 379 Types" registry. 381 +==========+======================+=====================+ 382 | Name | Template | Reference | 383 +==========+======================+=====================+ 384 | aif+cbor | application/aif+cbor | RFC XXXX, Section 4 | 385 +----------+----------------------+---------------------+ 386 | aif+json | application/aif+json | RFC XXXX, Section 4 | 387 +----------+----------------------+---------------------+ 389 Table 3: New Media Types 391 For application/aif+cbor: 393 Type name: application 394 Subtype name: aif+cbor 395 Required parameters: N/A 396 Optional parameters: 397 * Toid: the identifier for the object for which permissions are 398 supplied. A value from the media-type parameter sub-registry 399 for Toid. Default value: "URI-local-part" (RFC XXXX). 401 * Tperm: the data type of a permission set for the object 402 identified via a Toid. A value from the media-type parameter 403 sub-registry for Tperm. Default value: "REST-method-set" (RFC 404 XXXX). 405 Encoding considerations: binary (CBOR) 406 Security considerations: Section 6 of RFC XXXX 407 Interoperability considerations: none 408 Published specification: Section 4 of RFC XXXX 409 Applications that use this media type: Applications that need to 410 convey structured authorization data for identified resources, 411 conveying sets of permissions. 412 Fragment identifier considerations: The syntax and semantics of 413 fragment identifiers is as specified for "application/cbor". (At 414 publication of RFC XXXX, there is no fragment identification 415 syntax defined for "application/cbor".) 416 Person & email address to contact for further information: ACE WG 417 mailing list (ace@ietf.org), or IETF Applications and Real-Time 418 Area (art@ietf.org) 419 Intended usage: COMMON 420 Restrictions on usage: none 421 Author/Change controller: IETF 422 Provisional registration: no 424 For application/aif+json: 426 Type name: application 427 Subtype name: aif+json 428 Required parameters: N/A 429 Optional parameters: 430 * Toid: the identifier for the object for which permissions are 431 supplied. A value from the media-type parameter sub-registry 432 for Toid. Default value: "URI-local-part" (RFC XXXX). 434 * Tperm: the data type of a permission set for the object 435 identified via a Toid. A value from the media-type parameter 436 sub-registry for Tperm. Default value: "REST-method-set" (RFC 437 XXXX). 438 Encoding considerations: binary (JSON is UTF-8-encoded text) 439 Security considerations: Section 6 of RFC XXXX 440 Interoperability considerations: none 441 Published specification: Section 4 of RFC XXXX 442 Applications that use this media type: Applications that need to 443 convey structured authorization data for identified resources, 444 conveying sets of permissions. 445 Fragment identifier considerations: The syntax and semantics of 446 fragment identifiers is as specified for "application/json". (At 447 publication of RFC XXXX, there is no fragment identification 448 syntax defined for "application/json".) 450 Person & email address to contact for further information: ACE WG 451 mailing list (ace@ietf.org), or IETF Applications and Real-Time 452 Area (art@ietf.org) 453 Intended usage: COMMON 454 Restrictions on usage: none 455 Author/Change controller: IETF 456 Provisional registration: no 458 5.2. Registries 460 For the media types application/aif+cbor and application/aif+json, 461 IANA is requested to create a sub-registry within 462 [IANA.media-type-sub-parameters] for the two media-type parameters 463 Toid and Tperm, populated with: 465 +===========+=================+=====================+===========+ 466 | Parameter | name | Description/ | Reference | 467 | | | Specification | | 468 +===========+=================+=====================+===========+ 469 | Toid | URI-local-part | local-part of URI | RFC XXXX | 470 +-----------+-----------------+---------------------+-----------+ 471 | Tperm | REST-method-set | set of REST methods | RFC XXXX | 472 | | | represented | | 473 +-----------+-----------------+---------------------+-----------+ 475 Table 4: New Media Type Parameters 477 The registration policy is Specification required [RFC8126]. The 478 designated expert will engage with the submitter to ascertain the 479 requirements of this document are addressed: 481 * The specifications for Toid and Tperm need to realize the general 482 ideas of unambiguous object identifiers and permission lists in 483 the context where the AIF data item is intended to be used, and 484 their structure needs to be usable with the intended media types 485 (application/aif+cbor and application/aif+json) as identified in 486 the specification. 488 * The parameter names need to conform to Section 4.3 of [RFC6838], 489 but preferably are in [KebabCase] so they can easily be translated 490 into names used in popular programming language APIs. 492 The designated experts will develop further criteria and guidelines 493 as needed. 495 5.3. Content-Format 497 IANA is requested to register Content-Format numbers in the "CoAP 498 Content-Formats" sub-registry, within the "Constrained RESTful 499 Environments (CoRE) Parameters" Registry [IANA.core-parameters], as 500 follows: 502 +======================+================+======+===========+ 503 | Content-Type | Content Coding | ID | Reference | 504 +======================+================+======+===========+ 505 | application/aif+cbor | - | TBD1 | RFC XXXX | 506 +----------------------+----------------+------+-----------+ 507 | application/aif+json | - | TBD2 | RFC XXXX | 508 +----------------------+----------------+------+-----------+ 510 Table 5: New Content-Formats 512 // RFC Ed.: please replace TBD1 and TBD2 with assigned IDs and remove 513 this note. 515 In the registry as defined by Section 12.3 of [RFC7252] at the time 516 of writing, the column "Content-Type" is called "Media type" and the 517 column "Content Coding" is called "Encoding". 519 Note that applications that register Toid and Tperm values are 520 encouraged to also register Content-Formats for the relevant 521 combinations. 523 6. Security Considerations 525 The security considerations of [RFC7252] apply when AIF is used with 526 CoAP, and, if complex formats such as URIs are used for Toid or 527 Tperm, specifically Section 11.1 of [RFC7252]. Some wider issues are 528 discussed in [RFC8576]. 530 When applying these formats, the referencing specification needs to 531 be careful to: 533 * ensure that the cryptographic armor employed around this format 534 fulfills the referencing specification's security objectives, and 535 that the armor or some additional information included in it with 536 the AIF data item (1) unambiguously identifies the subject to 537 which the authorizations shall apply and (2) provides any context 538 information needed to derive the identity of the object to which 539 authorization is being granted from the object identifiers (such 540 as, for the data models defined in the present specification, the 541 scheme and authority information that is used to construct the 542 full URI), and 544 * ensure that the types used for Toid and Tperm provide the 545 appropriate granularity and precision so that application 546 requirements on the precision of the authorization information are 547 fulfilled, and that all parties have the same understanding of 548 each Toid/Tperm pair in terms of specified objects (resources) and 549 operations on those. 551 For the data formats, the security considerations of [RFC8259] and 552 [RFC8949] apply. 554 A plain implementation of AIF might implement just the basic REST 555 model as per Section 2.1. If it receives authorizations that include 556 permissions that use the REST-specific Model With Dynamic Resource 557 Creation Section 2.3, it needs to either reject the AIF data item 558 entirely or act only on the permissions that it does understand. In 559 other words, the semantics underlying an allow-list as discussed 560 above need to hold here as well. 562 An implementation of the REST-specific Model With Dynamic Resource 563 Creation Section 2.3 needs to carefully keep track of the dynamically 564 created objects and the subjects to which the Dynamic-X permissions 565 apply -- both on the server side to enforce the permissions and on 566 the client side to know which permissions are available. 568 7. References 570 7.1. Normative References 572 [I-D.ietf-httpbis-semantics] 573 Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP 574 Semantics", Work in Progress, Internet-Draft, draft-ietf- 575 httpbis-semantics-19, 12 September 2021, 576 . 579 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 580 Requirement Levels", BCP 14, RFC 2119, 581 DOI 10.17487/RFC2119, March 1997, 582 . 584 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 585 Resource Identifier (URI): Generic Syntax", STD 66, 586 RFC 3986, DOI 10.17487/RFC3986, January 2005, 587 . 589 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 590 Specifications and Registration Procedures", BCP 13, 591 RFC 6838, DOI 10.17487/RFC6838, January 2013, 592 . 594 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 595 Application Protocol (CoAP)", RFC 7252, 596 DOI 10.17487/RFC7252, June 2014, 597 . 599 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 600 Writing an IANA Considerations Section in RFCs", BCP 26, 601 RFC 8126, DOI 10.17487/RFC8126, June 2017, 602 . 604 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 605 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 606 May 2017, . 608 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 609 Definition Language (CDDL): A Notational Convention to 610 Express Concise Binary Object Representation (CBOR) and 611 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 612 June 2019, . 614 [RFC9165] Bormann, C., "Additional Control Operators for the Concise 615 Data Definition Language (CDDL)", RFC 9165, 616 DOI 10.17487/RFC9165, December 2021, 617 . 619 7.2. Informative References 621 [I-D.ietf-ace-oauth-authz] 622 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 623 H. Tschofenig, "Authentication and Authorization for 624 Constrained Environments (ACE) using the OAuth 2.0 625 Framework (ACE-OAuth)", Work in Progress, Internet-Draft, 626 draft-ietf-ace-oauth-authz-46, 8 November 2021, 627 . 630 [IANA.core-parameters] 631 IANA, "Constrained RESTful Environments (CoRE) 632 Parameters", 633 . 635 [IANA.media-type-sub-parameters] 636 IANA, "MIME Media Type Sub-Parameter Registries", 637 . 640 [KebabCase] 641 "KebabCase", 29 August 2014, 642 . 644 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 645 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 646 . 648 [RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., 649 and D. Orchard, "URI Template", RFC 6570, 650 DOI 10.17487/RFC6570, March 2012, 651 . 653 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 654 Constrained-Node Networks", RFC 7228, 655 DOI 10.17487/RFC7228, May 2014, 656 . 658 [RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, 659 DOI 10.17487/RFC7493, March 2015, 660 . 662 [RFC8132] van der Stok, P., Bormann, C., and A. Sehgal, "PATCH and 663 FETCH Methods for the Constrained Application Protocol 664 (CoAP)", RFC 8132, DOI 10.17487/RFC8132, April 2017, 665 . 667 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 668 Interchange Format", STD 90, RFC 8259, 669 DOI 10.17487/RFC8259, December 2017, 670 . 672 [RFC8576] Garcia-Morchon, O., Kumar, S., and M. Sethi, "Internet of 673 Things (IoT) Security: State of the Art and Challenges", 674 RFC 8576, DOI 10.17487/RFC8576, April 2019, 675 . 677 [RFC8881] Noveck, D., Ed. and C. Lever, "Network File System (NFS) 678 Version 4 Minor Version 1 Protocol", RFC 8881, 679 DOI 10.17487/RFC8881, August 2020, 680 . 682 [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object 683 Representation (CBOR)", STD 94, RFC 8949, 684 DOI 10.17487/RFC8949, December 2020, 685 . 687 Acknowledgements 689 Jim Schaad, Francesca Palombini, Olaf Bergmann, Marco Tiloca, and 690 Christian Amsüss provided comments that shaped the direction of this 691 document. Alexey Melnikov pointed out that there were gaps in the 692 media type specifications, and Loganaden Velvindron provided a 693 shepherd review with further comments. Many thanks also to the IESG 694 reviewers, which provided several small but significant observations. 695 Benjamin Kaduk provided an extensive review as responsible Area 696 Director, and indeed is responsible for much improvement in the 697 document. 699 Author's Address 701 Carsten Bormann 702 Universität Bremen TZI 703 Postfach 330440 704 D-28359 Bremen 705 Germany 706 Phone: +49-421-218-63921 707 Email: cabo@tzi.org