idnits 2.17.1 draft-schaad-core-reef-00.txt: 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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 114: '...he endpoint name MUST be present for t...' RFC 2119 keyword, line 141: '... that equivalent MUST be used. Where ...' RFC 2119 keyword, line 142: '... that equivalent SHOULD be used when i...' RFC 2119 keyword, line 144: '...tributes, the RD SHOULD NOT attempt to...' RFC 2119 keyword, line 155: '...point. Endpoints SHOULD NOT advertise...' (3 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (3 January 2020) is 1574 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '2' on line 388 -- Looks like a reference, but probably isn't: '1' on line 388 -- Looks like a reference, but probably isn't: '99599' on line 388 == Unused Reference: 'RFC7193' is defined on line 724, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-core-coral-01 == Outdated reference: A later version (-28) exists of draft-ietf-core-resource-directory-23 == Outdated reference: A later version (-46) exists of draft-ietf-ace-oauth-authz-29 ** Obsolete normative reference: RFC 7049 (ref. 'CBOR') (Obsoleted by RFC 8949) ** Obsolete normative reference: RFC 8152 (ref. 'COSE') (Obsoleted by RFC 9052, RFC 9053) Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Schaad 3 Internet-Draft August Cellars 4 Intended status: Experimental 3 January 2020 5 Expires: 6 July 2020 7 CoAP Application version of Resource Directory 8 draft-schaad-core-reef-00 10 Abstract 12 This is a draft of what I think a CoRE Application should look like. 14 Status of This Memo 16 This Internet-Draft is submitted in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF). Note that other groups may also distribute 21 working documents as Internet-Drafts. The list of current Internet- 22 Drafts is at https://datatracker.ietf.org/drafts/current/. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 This Internet-Draft will expire on 6 July 2020. 31 Copyright Notice 33 Copyright (c) 2020 IETF Trust and the persons identified as the 34 document authors. All rights reserved. 36 This document is subject to BCP 78 and the IETF Trust's Legal 37 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 38 license-info) in effect on the date of publication of this document. 39 Please review these documents carefully, as they describe your rights 40 and restrictions with respect to this document. Code Components 41 extracted from this document must include Simplified BSD License text 42 as described in Section 4.e of the Trust Legal Provisions and are 43 provided without warranty as described in the Simplified BSD License. 45 Internet-DrafCoAP Application version of Resource Directory January 2020 47 Table of Contents 49 1. Preamble . . . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 3. Vocabulary . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3.1. Containers . . . . . . . . . . . . . . . . . . . . . . . 3 53 3.2. Leafs . . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 4. Resource Interfaces . . . . . . . . . . . . . . . . . . . . . 5 55 5. Model Objects . . . . . . . . . . . . . . . . . . . . . . . . 6 56 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 6 57 6.1. Interop Items . . . . . . . . . . . . . . . . . . . . . . 6 58 6.2. Retrieve Resource Directory Information . . . . . . . . . 7 59 6.3. Registering Endpoints . . . . . . . . . . . . . . . . . . 9 60 6.4. Query Endpoints . . . . . . . . . . . . . . . . . . . . . 13 61 6.5. Query Resources . . . . . . . . . . . . . . . . . . . . . 13 62 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 63 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 64 9. Normative References . . . . . . . . . . . . . . . . . . . . 15 65 Appendix A. Missing CoRAL things . . . . . . . . . . . . . . . . 16 66 A.1. Rules for doing a FETCH . . . . . . . . . . . . . . . . . 16 67 A.2. Rules for doing a PATCH . . . . . . . . . . . . . . . . . 16 68 Appendix B. Authorization Vocabulary . . . . . . . . . . . . . . 16 69 B.1. Containers . . . . . . . . . . . . . . . . . . . . . . . 16 70 B.2. Leafs . . . . . . . . . . . . . . . . . . . . . . . . . . 16 71 B.3. ACE Authority Type . . . . . . . . . . . . . . . . . . . 17 72 B.4. X.509 Authority Type . . . . . . . . . . . . . . . . . . 17 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 75 1. Preamble 77 This document explores how a CoRE Resource Directory 78 [I-D.ietf-core-resource-directory] might look if based on [CoRAL]. 79 This document is not currently intended as something to be 80 standardized at this time. 82 2. Introduction 84 Refer to the introduction of [I-D.ietf-core-resource-directory]. 85 Concise Binary Object Representation (CBOR) [CBOR] is a compact self- 86 describing binary encoding formation that is starting to be used in 87 many different applications. One of the primary uses of CBOR is in 88 the Internet of Things where the constrained nature means that having 89 minimal size of encodings becomes very important. The use of the 90 Cryptographic Message System (CMS) [CMS] is still one of the most 91 common method for providing message-based security, although in many 92 cases the CBOR Object Signing and Encryption (COSE) [COSE] message- 93 based security system is starting to be used. Given that CBOR is 94 going to be transported using CMS, it makes sense to define CMS 96 Internet-DrafCoAP Application version of Resource Directory January 2020 98 content types for the purpose of denoting that the embedded content 99 is CBOR. This document defines two new content types: CBOR Content 100 Type and CBOR Sequence Content Type [I-D.ietf-cbor-sequence]. 102 3. Vocabulary 104 Unless otherwise noted, all of the vocabulary defined in this 105 document are prefixed with "http://jimsch.example.org/rd#". For 106 convience, all item defined in this vocabulary is tagged with 107 *strong*. 109 3.1. Containers 111 *rd-endpoint* This container represents a single endpoint on a 112 resource server. The content module of this container is: 114 * An *endpointName*. The endpoint name MUST be present for third 115 party registrations and is required for first party 116 registrations unless the RD can infer the endpoint name from 117 the security context. 119 * An optional *sector* 121 * An optional *endpointBase* URI. The value is required for 122 third party registrations. For first party registrations, it 123 is inferred from the registration request if not present. 125 * Zero or more *rfc-item* containers. Each container represents 126 a resource or form on the endpoint. Some actions require that 127 the rfc-items are present, where others will omit them. 129 *rd-item* This container represents a single resource that is 130 provided by a server. There is no requirement on the content 131 model for this container type. 133 *rd-linkAttribute* This container provides a method of pulling link 134 attributes into the RD content model. The target of the container 135 is the name of the link attribute. The values of the container is 136 *value* with one field occurring for each different value. Unlink 137 link attributes, space separated values are listed at multiple 138 values. 140 Where this document as defined an equivalent to a link attribute, 141 that equivalent MUST be used. Where equivalents are defined in 142 other documents, that equivalent SHOULD be used when it is new. 143 Where equivalents are defined in other documents for long standing 144 attributes, the RD SHOULD NOT attempt to map between them but to 145 keep them as they were registered. In this case it is a 147 Internet-DrafCoAP Application version of Resource Directory January 2020 149 requirement on the registering agent to ensure that when things 150 are registered both ways they are the same. 152 *rd-group* This container allows for grouping together a set of 153 resources. The purpose of the container is to be able to allow 154 for an endpoint to advertise resources at different addresses but 155 associated with that endpoint. Endpoints SHOULD NOT advertise 156 resources on other systems, even if those resources are copies of 157 a resource on the system. Instead, *alternative* should be used 158 for that purpose. 160 3.2. Leafs 162 alternative 164 *endpointBase* The endpoint base URI of a registration. This 165 represents a URI that typically gives the scheme and authority 166 information about an endpoint. The endpoint base URI is provided 167 at registration or update time, and is used by the RD to resolve 168 relative references when returning resource descriptions. 169 Separating the base URI allows for it to be patched independently 170 of the resource items. 172 This is equivalent to the _base_ link attribute defined in 173 [I-D.ietf-core-resource-directory]. 175 content-type This is equivalent to the _ct_ link attribute defined 176 in [????]. 178 describedby 180 *endpointName* A UTF8 string indicating the name of the endpoint. 181 The endpoint name MUST NOT include characters in the range 0-31 or 182 127-159. 184 This is equivalent to the _ep_ link attribute defined in 185 [I-D.ietf-core-resource-directory]. 187 lifetime The lifetime of the registration in seconds. The range of 188 lifetime is 60-294967295. If a registration does not include a 189 life time, it defaults to 90000 (25 hours). 191 resource-type 193 *sector* A string indicating the sector to which an endpoint 194 belongs. In the context of a Resource Directory, a sector is a 195 logical grouping of endpoints. 197 Internet-DrafCoAP Application version of Resource Directory January 2020 199 This is equivalent to the _d_ link attribute defined in 200 [I-D.ietf-core-resource-directory]. 202 title 204 *value* This leaf occurs in an *rd-linkAttribute* and holds a single 205 value for a link attribute. 207 4. Resource Interfaces 209 rd-endpoint The endpoint interface is used by a client to update or 210 remove an endpoint and its associated resources from the resource 211 directory. The interface supports the following operations: 213 * _DELETE_ removes the endpoint representation from the resource 214 directory. 216 * _GET_ returns the current set of endpoint attributes and 217 resources for the endpoint. Support of observe is optional for 218 a resource directory. 220 * _PATCH_ allows for an incremental update of the attributes and 221 resources of the endpoint. 223 * _PUT_ replaces the setup of attributes and resources for the 224 endpoint. 226 rd-endpointSearch 228 *rd-register* The register interface is used by a client to register 229 an endpoint and its associated resources with the ressource 230 directory. This interface is intended both for an endpoint to 231 register itself as well as third party registration of an 232 endpoint. 234 The registration interface supports one operation: POST. The 235 content of the POST operation is a CoRAL document containing the 236 content of a rd-endpoint. The rd-endpoint container itself MAY be 237 included, but only the content of the container is expected. 239 Processing a registration request involves the following steps: 241 1. Perform requisite checks that the party attempting to perform 242 the registration has the permissions to do so. 244 2. Verify that all required content is present for the endpoint 245 and for each resource to be registered. Part of this may be 246 to extract the required content from the security context used 248 Internet-DrafCoAP Application version of Resource Directory January 2020 250 for determining permissions. 252 3. If the endpoint name and domain pair map to an existing 253 endpoint registration, that registration is replaced using the 254 same link path. Otherwise a new endpoint registration is 255 created. 257 *rd-resourceSearch* The resource search interface is used by clients 258 to locate and retrieve the description of resources based on some 259 criteria. 261 The resource search interface supports one operation: FETCH. The 262 content of the FETCH operation is a set of search criteria to be 263 matched against all of the resources registered with the RD. The 264 rules for doing a match following the rules in Appendix A.1 with 265 one addition. The container *rd-group* is ignored when doing 266 matching against the criteria. Specifically, the rd-item in the 267 container are always matched against. 269 If an rd-endpoint is included in the search criteria, then the 270 endpoint which hosts the resource is matched against that 271 criteria. 273 5. Model Objects 275 (Artwork only available as svg: No external link available, see 276 draft-schaad-core-reef-00.html for artwork.) 278 Resource Directory This resource represents the entry point into the 279 Resource Directory. The resource always exists in some form on a 280 resource directory server. The resource will support the GET verb 281 to return a CoRAL document describing where the interfaces on the 282 resource directory can be found. 284 This resource can additionally support the rd-register and either 285 the rd-endpointSearch or rd-resourceSearch interfaces. 287 Endpoint Search This resource provides for where an endpoint search 288 can be done. As such, the resource supports the rd-endpoint 289 interface. This resource may additionally support the rd-register 290 interface. 292 6. Examples 294 6.1. Interop Items 296 In order to have interop, a number of items need to be defined. For 297 the example below the following assumptions are made: 299 Internet-DrafCoAP Application version of Resource Directory January 2020 301 * TBD-CoRAL content type is 99599 303 * TBD-CoRAL-Dict is 99999 (TBD6 in [CoRAL] 305 * The dictionary used is in Table 1 307 +-----+------------------------------------------------+ 308 | Key | Value | 309 +=====+================================================+ 310 | 1 | http://jimsch.example.org/rd#content-type | 311 +-----+------------------------------------------------+ 312 | 2 | http://jimsch.example.org/rd#ace-Profile | 313 +-----+------------------------------------------------+ 314 | 3 | http://jimsch.example.org/rd#authority-type | 315 +-----+------------------------------------------------+ 316 | 4 | http://jimsch.example.org/rd#authority | 317 +-----+------------------------------------------------+ 318 | 5 | http://jimsch.example.org/rd#rd-register | 319 +-----+------------------------------------------------+ 320 | 6 | http://jimsch.example.org/rd#rd-endpointSearch | 321 +-----+------------------------------------------------+ 322 | 7 | http://jimsch.example.org/rd#rd-resourceSearch | 323 +-----+------------------------------------------------+ 324 | 8 | http://jimsch.example.org/rd#ace-Audience | 325 +-----+------------------------------------------------+ 327 Table 1 329 6.2. Retrieve Resource Directory Information 331 Request: 332 GET coap://jimsch.example.org/rd 333 Accept: TBD-CoRAL 335 Response: 336 2.05 Content 337 Content-Format: TBD-CoRAL 339 #using 341 rd-register [ 342 content-type TBD-CoRAL 343 authority [ 344 authority-type "ACE" 345 ace-Profile "coap_oscore" 346 ace-Audience "jimsch.example.org" 347 ] 348 ] 350 Internet-DrafCoAP Application version of Resource Directory January 2020 352 rd-endpointSearch 354 rd-resourceSearch 356 rd-register [ 357 content-type TBD-CoRAL 358 authority [ 359 authority-type "ACE" 360 ace-Profile "coap_oscore" 361 ace-Profile "coap_dtls" 362 ace-Audience "jimsch.example.org" 363 ] 364 authority _ [ 365 authority-type "X.509" 366 ] 367 ] 369 #base 370 rd-endpointSearch 372 rd-resourceSearch 374 or 376 [[2, 5, [5, 2, 6, "endpoints"], [ 377 [2, 1, 99599], 378 [2, 4, [2, "ace.example.org", 6, "token"], [ 379 [2, 2, "coap_oscore"], 380 [2, 3, "ACE"], 381 [2, 8, "jimsch.example.org"] 382 ]] 383 ]], 384 [2, 6, [5, 2, 6, "endpoints"]], 385 [2, 7, [5, 2, 6, "resources"]], 386 [1, [1, "coaps", 2, "jimsch.example.org", 6, "rd"]], 387 [2, 5, [5, 2, 6, "endpoints"], [ 388 [2, 1, 99599], 389 [2, 4, [2, "ace.example.org", 6, "token"], [ 390 [2, 2, "coap_oscore"], 391 [2, 2, "coap_dtls"], 392 [2, 3, "ACE"], 393 [2, 8, "jimsch.example.org"] 394 ]] 395 ]], 396 [2, 6, [5, 2, 6, "endpoints"]], 397 [2, 7, [5, 2, 6, "resources"]]] 399 Internet-DrafCoAP Application version of Resource Directory January 2020 401 6.3. Registering Endpoints 403 Sample registration of an endpoint with four resources. 405 POST coaps://jimsch.example.com/rd/endpoints 406 Content-Format: TBD-CoRAL 408 rd-endpointName "node1" 409 rd-base 410 rd-item [ 411 content-type 41 412 resource-type "temperature-c" 413 rd-linkAttribute "if" [ value "sensor" ] 414 describedby 415 ] 416 rd-item [ 417 content-type 0 418 resource-type "temperature" 419 ] 420 rd-item [ 421 content-type 0 422 resource-type "light-lux" 423 ] 424 rd-item [ 425 ] 427 Example registration of a resource server which exposes resources on 428 multiple addresses. This example was made mechanically from /.well- 429 known/core for my test server, as such it is missing several items 430 which it would normally have dealing with security and other items as 431 there are no uniform link attributes for these features. At some 432 point I might go in and clean this up based on how things are 433 enforced, such as items which cannot be read due to security issues. 434 This example uses the CoRAL content type from [CoRAL]. 436 rd-group [ 437 rd-item 438 rd-item [ 439 content-type 40 440 content-type 65088 441 resource-type "core.rd" 442 ] 443 rd-item 444 rd-item 445 rd-item [ 446 content-type 40 447 content-type 65088 449 Internet-DrafCoAP Application version of Resource Directory January 2020 451 resource-type "core.rd-lookup-ep" 452 ] 453 rd-item [ 454 content-type 40 455 resource-type "core.rd-lookup-res" 456 ] 457 rd-item 458 rd-item [ 459 resource-type "BlockWiseTransferTester" 460 title "This is a large resource for testing block-wise transfer" 461 ] 462 rd-item 463 rd-item [ 464 resource-type "OSCOAP-Tester" 465 title "GET a friendly greeting!" 466 ] 467 rd-item [ 468 resource-type "BlockWiseTransferTester" 469 title "This is a large resource for testing block-wise transfer" 470 ] 471 rd-item [ 472 resource-type "OSCOAP-Tester" 473 title "GET a friendly greeting!" 474 ] 475 rd-item [ 476 resource-type "OSCOAP-Tester" 477 title "GET a friendly greeting!" 478 ] 479 rd-item [ 480 resource-type "OSCOAP-Tester" 481 title "GET a friendly greeting!" 482 ] 483 rd-item [ 484 resource-type "OSCOAP-Tester" 485 title "GET a friendly greeting!" 486 ] 487 rd-item [ 488 resource-type "OSCOAP-Tester" 489 title "GET a friendly greeting!" 490 ] 491 rd-item [ 492 resource-type "OSCOAP-Tester" 493 title "GET a friendly greeting!" 494 ] 495 rd-item [ 496 resource-type "OSCOAP-Tester" 497 title "GET a friendly greeting!" 498 ] 500 Internet-DrafCoAP Application version of Resource Directory January 2020 502 rd-item [ 503 rd-linkAttribute obs 504 resource-type "OSCOAP-Tester" 505 title "GET a friendly greeting!" 506 ] 507 rd-item [ 508 obs 509 resource-type "OSCOAP-Tester" 510 title "GET a friendly greeting!" 511 ] 512 rd-item [ 513 resource-type "OSCOAP-Tester" 514 title "GET a friendly greeting!" 515 ] 516 rd-item 517 rd-item 518 rd-item 519 rd-item [ 520 resource-type "HelloWorldDisplayer" 521 title "GET a friendly greeting!" 522 ] 523 ] 524 rd-group [ 525 rd-item 526 rd-item [ 527 content-type 40 528 content-type 65088 529 resource-type "core.rd" 530 ] 531 rd-item 532 rd-item 533 rd-item [ 534 content-type 40 535 content-type 65088 536 resource-type "core.rd-lookup-ep" 537 ] 538 rd-item [ 539 content-type 40 540 resource-type "core.rd-lookup-res" 541 ] 542 rd-item 543 rd-item [ 544 resource-type "BlockWiseTransferTester" 545 title "This is a large resource for testing block-wise transfer" 546 ] 547 rd-item 548 rd-item [ 549 resource-type "OSCOAP-Tester" 551 Internet-DrafCoAP Application version of Resource Directory January 2020 553 title "GET a friendly greeting!" 554 ] 555 rd-item [ 556 resource-type "BlockWiseTransferTester" 557 title "This is a large resource for testing block-wise transfer" 558 ] 559 rd-item [ 560 resource-type "OSCOAP-Tester" 561 title "GET a friendly greeting!" 562 ] 563 rd-item [ 564 resource-type "OSCOAP-Tester" 565 title "GET a friendly greeting!" 566 ] 567 rd-item [ 568 resource-type "OSCOAP-Tester" 569 title "GET a friendly greeting!" 570 ] 571 rd-item [ 572 resource-type "OSCOAP-Tester" 573 title "GET a friendly greeting!" 574 ] 575 rd-item [ 576 resource-type "OSCOAP-Tester" 577 title "GET a friendly greeting!" 578 ] 579 rd-item [ 580 resource-type "OSCOAP-Tester" 581 title "GET a friendly greeting!" 582 ] 583 rd-item [ 584 resource-type "OSCOAP-Tester" 585 title "GET a friendly greeting!" 586 ] 587 rd-item [ 588 rd-linkAttribute obs 589 resource-type "OSCOAP-Tester" 590 title "GET a friendly greeting!" 591 ] 592 rd-item [ 593 obs 594 resource-type "OSCOAP-Tester" 595 title "GET a friendly greeting!" 596 ] 597 rd-item [ 598 resource-type "OSCOAP-Tester" 599 title "GET a friendly greeting!" 600 ] 602 Internet-DrafCoAP Application version of Resource Directory January 2020 604 rd-item 605 rd-item 606 rd-item 607 rd-item [ 608 resource-type "HelloWorldDisplayer" 609 title "GET a friendly greeting!" 610 ] 611 ] 613 6.4. Query Endpoints 615 FETCH coaps://jimsch.example.com/rd/endpoints 616 Content-Format: TBD-CoRAL 618 rd-linkAttribute "et" [ value "oic.d.sensor" ] 620 2.05 Content 621 Conent-Type: TBD-CoRAL 623 rd-endpoint [ 624 endpoint-name "node5" 625 resource-type "core.rd-ep" 626 rd-linkAttribute "et" [ value "oic.d.sensor" ] 627 ] 628 rd-endpoint [ 629 endpoint-name "node7" 630 domain "floor-3" 631 resource-type "core.rd-ep" 632 rd-linkAttribute "et" [ value "oic.d.sensor" ] 633 ] 635 6.5. Query Resources 636 Internet-DrafCoAP Application version of Resource Directory January 2020 638 FETCH coaps://jimsch.example.com/rd/resources 639 Content-Format: TBD-CoRAL 641 rd-endpoint null [ 642 rd-linkAttribute "et" [ value "oic.d.sensor" ] 643 ] 645 2.05 Content 646 Content-Format: TBD-CoRAL 648 #base 649 rd-item [ 650 content-type 40 651 title "Sensor Index" 652 ] 653 rd-item [ 654 resource-type "temperature-c" 655 rd-linkAttribute "if" [ value "sensor" ] 656 describedby 657 alternate 658 ] 659 rd-item [ 660 resource-type "light-lux" 661 rd-linkAttribute "if" [ value "sensor" ] 662 ] 663 #base 664 rd-item [ 665 content-type 40 666 title "Sensor Index" 667 ] 668 rd-item [ 669 resource-type "temperature-c" 670 rd-linkAttribute "if" [ value "sensor" ] 671 describedby 672 alternate 673 ] 674 rd-item [ 675 resource-type "light-lux" 676 rd-linkAttribute "if" [ value "sensor" ] 677 ] 679 7. IANA Considerations 681 There are none, this is a thought experiment. 683 Internet-DrafCoAP Application version of Resource Directory January 2020 685 8. Security Considerations 687 There are some, this is a thought experiment. 689 9. Normative References 691 [CoRAL] Hartke, K., "The Constrained RESTful Application Language 692 (CoRAL)", Work in Progress, Internet-Draft, draft-ietf- 693 core-coral-01, 4 November 2019, 694 . 696 [I-D.ietf-core-resource-directory] 697 Shelby, Z., Koster, M., Bormann, C., Stok, P., and C. 698 Amsuess, "CoRE Resource Directory", Work in Progress, 699 Internet-Draft, draft-ietf-core-resource-directory-23, 8 700 July 2019, . 703 [I-D.ietf-ace-oauth-authz] 704 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 705 H. Tschofenig, "Authentication and Authorization for 706 Constrained Environments (ACE) using the OAuth 2.0 707 Framework (ACE-OAuth)", Work in Progress, Internet-Draft, 708 draft-ietf-ace-oauth-authz-29, 14 December 2019, 709 . 712 [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 713 RFC 5652, DOI 10.17487/RFC5652, September 2009, 714 . 716 [CBOR] Bormann, C. and P. Hoffman, "Concise Binary Object 717 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 718 October 2013, . 720 [COSE] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 721 RFC 8152, DOI 10.17487/RFC8152, July 2017, 722 . 724 [RFC7193] Turner, S., Housley, R., and J. Schaad, "The application/ 725 cms Media Type", RFC 7193, DOI 10.17487/RFC7193, April 726 2014, . 728 [I-D.ietf-cbor-sequence] 729 Bormann, C., "Concise Binary Object Representation (CBOR) 730 Sequences", Work in Progress, Internet-Draft, draft-ietf- 731 cbor-sequence-02, 25 September 2019, 732 . 734 Internet-DrafCoAP Application version of Resource Directory January 2020 736 Appendix A. Missing CoRAL things 738 The start for FETCH is on github for CoRAL. Nothing has been done 739 for PATCH. This appendix is merely a place for me to start thinking 740 about things. 742 A.1. Rules for doing a FETCH 744 1. Items of the same name are processed as an 'OR'. 746 2. Items of different names are processed as 'AND'. 748 3. A value of 'null' matches all values. Should really be something 749 along the lines of 'undefined' because 'null' may be a real 750 value. 752 4. Text strings ending in '*' for the search should do wild card 753 matching. 755 5. Look into adding additional items to allow for doing range, 756 relative value or set processing. 758 A.2. Rules for doing a PATCH 760 Need to look at this in detail, because it may be very complicated. 761 I am not sure that the same CoRAL document format can be used. One 762 of the issues is how to match the nth version of something. JSON 763 Patch is probably a better model than SEML patch. 765 Appendix B. Authorization Vocabulary 767 Unless otherwise noted, all of the vocabulary defined in this 768 document are prefixed with "http://jimsch.example.org/rd#". For 769 convience, all item defined in this vocabulary is tagged with 770 *strong*. 772 B.1. Containers 774 *authority* The *authority* container is used to hold information 775 about how authentication is going to be done. The container MUST 776 include a *authority-type*. The rest of the content of the 777 container is dependent on the value of the authority type. 779 B.2. Leafs 781 *authority-type* Is a string which identifies what type of authority 782 is being used. Currently defined values are in Table 2. 784 Internet-DrafCoAP Application version of Resource Directory January 2020 786 +-------+--------------------------------------------+ 787 | ACE | The ACE profile [I-D.ietf-ace-oauth-authz] | 788 +-------+--------------------------------------------+ 789 | X.509 | X.509 Certificates containing specific | 790 | | information are used for authentication. | 791 +-------+--------------------------------------------+ 793 Table 2 795 B.3. ACE Authority Type 797 Leafs 799 *ace-Profile* What ace profiles are supported by the endpoint. The 800 values of this come from the IANA registry created in 801 [I-D.ietf-ace-oauth-authz]. 803 *ace-Audience* Audience to ask for a token for 805 *ace-Scope-format* Format of the scope parameter 807 B.4. X.509 Authority Type 809 Leafs 811 *TrustAnchorCertificate* Contains the binary certificate that acts 812 as the trust anchor. This leaf is option as the trust anchor is 813 normally commonly known among all entities in the system. 815 *TrustAnchorFingerprint-SHA256* Contains the SHA-256 fingerprint of 816 the certificate that acts as the trust anchor. This leaf is 817 option as the trust anchor is normally commonly known among all 818 entities in the system. 820 Author's Address 822 Jim Schaad 823 August Cellars 825 Email: ietf@augustcellars.com