idnits 2.17.1 draft-ietf-gnap-resource-servers-01.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 : ---------------------------------------------------------------------------- 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 (12 July 2021) is 1019 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: Non-RFC (?) normative reference: ref. 'BCP195' == Outdated reference: A later version (-20) exists of draft-ietf-gnap-core-protocol-05 ** Downref: Normative reference to an Informational RFC: RFC 8792 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 GNAP J. Richer, Ed. 3 Internet-Draft Bespoke Engineering 4 Intended status: Standards Track A. Parecki 5 Expires: 13 January 2022 Okta 6 F. Imbault 7 acert.io 8 12 July 2021 10 Grant Negotiation and Authorization Protocol Resource Server Connections 11 draft-ietf-gnap-resource-servers-01 13 Abstract 15 GNAP defines a mechanism for delegating authorization to a piece of 16 software, and conveying that delegation to the software. This 17 extension defines methods for resource servers (RS) to communicate 18 with authorization servers (AS) in an interoperable fashion. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on 13 January 2022. 37 Copyright Notice 39 Copyright (c) 2021 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 44 license-info) in effect on the date of publication of this document. 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. Code Components 47 extracted from this document must include Simplified BSD License text 48 as described in Section 4.e of the Trust Legal Provisions and are 49 provided without warranty as described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Access Token Formats . . . . . . . . . . . . . . . . . . . . 3 56 3. Resource-Server-Facing API . . . . . . . . . . . . . . . . . 4 57 3.1. RS-facing AS Discovery . . . . . . . . . . . . . . . . . 4 58 3.2. Protecting RS requests to the AS . . . . . . . . . . . . 5 59 3.3. Token Introspection . . . . . . . . . . . . . . . . . . . 6 60 3.4. Registering a Resource Set . . . . . . . . . . . . . . . 9 61 4. Deriving a downstream token . . . . . . . . . . . . . . . . . 11 62 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 63 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 64 6.1. GNAP Token Format Registry . . . . . . . . . . . . . . . 13 65 6.1.1. Registry Template . . . . . . . . . . . . . . . . . . 13 66 6.1.2. Initial Registry Contents . . . . . . . . . . . . . . 13 67 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 68 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 14 69 9. Normative References . . . . . . . . . . . . . . . . . . . . 14 70 Appendix A. Document History . . . . . . . . . . . . . . . . . . 15 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 73 1. Introduction 75 The core GNAP protocol does not define any one specific mechanism for 76 the resource server (RS) to communicate with the authorization server 77 (AS), allowing the connection between these components to be solved 78 orthogonally to the core protocol's concerns. For example, the RS 79 and AS roles could be fulfilled by the same piece of software with 80 common storage, obviating the need for any connecting protocol. 81 However, it is often desirable to have the RS and AS communicate at 82 runtime for a variety of purposes, including allowing the RS to 83 validate and understand the rights and privileges associated with a 84 grant of access represented by an access token issued by the AS, or 85 negotiating the capabilities of either party. These types of 86 connections are particularly useful for connecting an AS and RS from 87 different vendors, allowing interoperable distributed deployments of 88 GNAP-protected systems. 90 This specification defines several means for a RS and AS to 91 communicate these aspects with each other, including structured 92 access tokens and RS-facing APIs. This specification also discusses 93 methods for an RS to derive a downstream token for calling another 94 chained RS. 96 The means of the authorization server issuing the access token to the 97 client instance and the means of the client instance presenting the 98 access token to the resource server are the subject of the GNAP core 99 protocol specification [I-D.ietf-gnap-core-protocol]. 101 1.1. Terminology 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 105 "OPTIONAL" in this document are to be interpreted as described in 106 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 107 capitals, as shown here. 109 This document contains non-normative examples of partial and complete 110 HTTP messages, JSON structures, URLs, query components, keys, and 111 other elements. Some examples use a single trailing backslash '' to 112 indicate line wrapping for long values, as per [RFC8792]. The "\" 113 character and leading spaces on wrapped lines are not part of the 114 value. 116 Terminology specific to GNAP is defined in the terminology section of 117 the core specification [I-D.ietf-gnap-core-protocol], and provides 118 definitions for the protocol roles: Authorization Server (AS), 119 Client, Resource Server (RS), Resource Owner (RO), End-user; as well 120 as the protocol elements: Attribute, Access Token, Grant, Privilege, 121 Protected Resource, Right, Subject, Subject Information. The same 122 definitions are used in this document. 124 2. Access Token Formats 126 When the AS issues an access token for use at an RS, the RS needs to 127 have some means of understanding what the access token is for in 128 order to determine how to respond to the request. The core GNAP 129 protocol makes no assumptions or demands on the format or contents of 130 the access token, and in fact the token format and contents are 131 opaque to the client instance. However, such token formats can be 132 the topic of agreements between the AS and RS. 134 Self-contained structured token formats allow for the conveyance of 135 information between the AS and RS without requiring the RS to call 136 the AS at runtime as described in Section 3.3. Structured tokens can 137 also be used in combination with introspection, allowing the token 138 itself to carry one class of information and the introspection 139 response to carry another. 141 Some token formats, such as Macaroons and Biscuits, allow for the RS 142 to derive sub-tokens without having to call the AS as described in 143 Section 4. 145 The supported token formats can be communicated dynamically at 146 runtime between the AS and RS in several places. 148 * The AS can declare its supported token formats as part of RS- 149 facing discovery Section 3.1 151 * The RS can require a specific token format be used to access a 152 registered resource set Section 3.4 154 * The AS can return the token's format in an introspection response 155 Section 3.3 157 In all places where the token format is listed explicitly, it MUST be 158 one of the registered values in the GNAP Token Formats Registry 159 Section 6.1. 161 3. Resource-Server-Facing API 163 To facilitate runtime and dynamic connections, the AS can offer an 164 RS-Facing API consisting of one or more of the following optional 165 pieces. 167 * Discovery 169 * Introspection 171 * Token chaining 173 * Resource reference registration 175 3.1. RS-facing AS Discovery 177 A GNAP AS offering RS-facing services can publish its features on a 178 well-known discovery document using the URL ".well-known/gnap-as-rs" 179 appended to the grant request endpoint URL. 181 The discovery response is a JSON document [RFC8259] consisting of a 182 single JSON object with the following fields: 184 introspection_endpoint (string): OPTIONAL. The URL of the endpoint 185 offering introspection. The location MUST be a URL [RFC3986] with 186 a scheme component that MUST be https, a host component, and 187 optionally, port, path and query components and no fragment 188 components. Section 3.3 190 token_formats_supported (array of strings): A list of token formats 191 supported by this AS. The values in this list MUST be registered 192 in the GNAP Token Format Registry. Section 6.1 194 resource_registration_endpoint (string): The URL of the endpoint 195 offering resource registration. The location MUST be a URL 196 [RFC3986] with a scheme component that MUST be https, a host 197 component, and optionally, port, path and query components and no 198 fragment components. Section 3.4 200 grant_request_endpoint (string): REQUIRED. The location of the AS's 201 grant request endpoint, used by the RS to derive downstream access 202 tokens. The location MUST be a URL [RFC3986] with a scheme 203 component that MUST be https, a host component, and optionally, 204 port, path and query components and no fragment components. This 205 URL MUST be the same URL used by client instances in support of 206 GNAP requests. Section 4 208 key_proofs_supported (array of strings) OPTIONAL. A list of the 209 AS's supported key proofing mechanisms. The values of this list 210 correspond to possible values of the "proof" field of the key 211 section of the request. 213 3.2. Protecting RS requests to the AS 215 Unless otherwise specified, the RS MUST protect its calls to the AS 216 using any of the signature methods defined by GNAP. This signing 217 method MUST cover all of the appropriate portions of the HTTP request 218 message, including any body elements, tokens, or headers required for 219 functionality. 221 The RS MAY present its keys by reference or by value in a similar 222 fashion to a client instance calling the AS in the core protocol of 223 GNAP, described in [I-D.ietf-gnap-core-protocol]. In the protocols 224 defined here, this takes the form of the resource server identifying 225 itself using a "key" field or by passing an instance identifier 226 directly. 228 "resource_server": { 229 "key": { 230 "proof": "httpsig", 231 "jwk": { 232 "kty": "EC", 233 "crv": "secp256k1", 234 "kid": "2021-07-06T20:22:03Z", 235 "x": "-J9OJIZj4nmopZbQN7T8xv3sbeS5-f_vBNSy_EHnBZc", 236 "y": "sjrS51pLtu3P4LUTVvyAIxRfDV_be2RYpI5_f-Yjivw" 237 } 238 } 239 } 241 or by reference: 243 "resource_server": "7C7C4AZ9KHRS6X63AJAO" 245 The AS MAY require an RS to pre-register its keys or could allow 246 calls from arbitrary keys in a trust-on-first-use model. 248 3.3. Token Introspection 250 The AS issues access tokens representing a set of delegated access 251 rights to be used at one or more RSs. The AS can offer an 252 introspection service to allow an RS to validate that a given access 253 token: 255 * has been issued by the AS 257 * has not expired 259 * has not been revoked 261 * is appropriate for the RS identified in the call 263 When the RS receives an access token, it can call the introspection 264 endpoint at the AS to get token information. [[ See issue #115 265 (https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/115) ]] 267 +--------+ +------+ +------+ 268 | Client |--(1)->| RS | | AS | 269 |Instance| | |--(2)->| | 270 | | | | | | 271 | | | |<-(3)--| | 272 | | | | +------+ 273 | |<-(4)--| | 274 +--------+ +------+ 275 1. The client instance calls the RS with its access token. 277 2. The RS introspects the access token value at the AS. The RS 278 signs the request with its own key (not the client instance's key 279 or the token's key). 281 3. The AS validates the access token value and the Resource Server's 282 request and returns the introspection response for the token. 284 4. The RS fulfills the request from the client instance. 286 The RS signs the request with its own key and sends the access token 287 as the body of the request. 289 access_token (string): REQUIRED. The access token value presented 290 to the RS by the client instance. 292 proof (string): RECOMMENDED. The proofing method used by the client 293 instance to bind the token to the RS request. 295 resource_server (string or object): REQUIRED. The identification 296 used to authenticate the resource server making this call, either 297 by value or by reference as described in Section 3.2. 299 access (array of strings/objects): OPTIONAL. The minimum access 300 rights required to fulfill the request. This MUST be in the 301 format described in the Resource Access Rights section of 302 [I-D.ietf-gnap-core-protocol]. 304 POST /introspect HTTP/1.1 305 Host: server.example.com 306 Content-Type: application/json 307 Signature-Input: sig1=... 308 Signature: sig1=... 309 Digest: sha256=... 311 { 312 "access_token": "OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0", 313 "proof": "httpsig", 314 "resource_server": "7C7C4AZ9KHRS6X63AJAO" 315 } 317 The AS MUST validate the access token value and determine if the 318 token is active. An active access token is defined as a token that 320 * was issued by the processing AS, 322 * has not been revoked, 323 * has not expired, and 325 * is appropriate for presentation at the identified RS. 327 The AS responds with a data structure describing the token's current 328 state and any information the RS would need to validate the token's 329 presentation, such as its intended proofing mechanism and key 330 material. 332 active (boolean): REQUIRED. If "true", the access token presented 333 is active, as defined above. If any of the criteria for an active 334 token are not true, or if the AS is unable to make a determination 335 (such as the token is not found), the value is set to "false" and 336 other fields are omitted. 338 If the access token is active, additional fields from the single 339 access token response structure defined in 340 [I-D.ietf-gnap-core-protocol] are included. In particular, these 341 include the following: 343 access (array of strings/objects): REQUIRED. The access rights 344 associated with this access token. This MUST be in the format 345 described in the Resource Access Rights section of 346 [I-D.ietf-gnap-core-protocol]. This array MAY be filtered or 347 otherwise limited for consumption by the identified RS, including 348 being an empty array. 350 key (object/string): REQUIRED if the token is bound. The key bound 351 to the access token, to allow the RS to validate the signature of 352 the request from the client instance. If the access token is a 353 bearer token, this MUST NOT be included. 355 flags (array of strings): OPTIONAL. The set of flags associated 356 with the access token. 358 The response MAY include any additional fields defined in an access 359 token response and MUST NOT include the access token "value" itself. 361 HTTP/1.1 200 OK 362 Content-Type: application/json 363 Cache-Control: no-store 365 { 366 "active": true, 367 "access": [ 368 "dolphin-metadata", "some other thing" 369 ], 370 "key": { 371 "proof": "httpsig", 372 "jwk": { 373 "kty": "RSA", 374 "e": "AQAB", 375 "kid": "xyz-1", 376 "alg": "RS256", 377 "n": "kOB5rR4Jv0GMeL...." 378 } 379 } 380 } 382 3.4. Registering a Resource Set 384 If the RS needs to, it can post a set of resources as described in 385 the Resource Access Rights section of [I-D.ietf-gnap-core-protocol] 386 to the AS's resource registration endpoint along with information 387 about what the RS will need to validate the request. 389 access (array of objects/strings): REQUIRED. The list of access 390 rights associated with the request in the format described in the 391 "Resource Access Rights" section of [I-D.ietf-gnap-core-protocol]. 393 resource_server (string or object): REQUIRED. The identification 394 used to authenticate the resource server making this call, either 395 by value or by reference as described in Section 3.2. 397 token_format_required (string): OPTIONAL. The token format required 398 to access the identified resource. If the field is omitted, the 399 token format is at the discretion of the AS. If the AS does not 400 support the requested token format, the AS MUST return an error to 401 the RS. 403 token_introspection_required (boolean): OPTIONAL. If present and 404 set to "true", the RS expects to make a token introspection 405 request as described in Section 3.3. If absent or set to "false", 406 the RS does not anticipate needing to make an introspection 407 request for tokens relating to this resource set. 409 The RS MUST identify itself with its own key and sign the request. 411 POST /resource HTTP/1.1 412 Host: server.example.com 413 Content-Type: application/json 414 Signature-Input: sig1=... 415 Signature: sig1=... 416 Digest: ... 418 { 419 "access": [ 420 { 421 "actions": [ 422 "read", 423 "write", 424 "dolphin" 425 ], 426 "locations": [ 427 "https://server.example.net/", 428 "https://resource.local/other" 429 ], 430 "datatypes": [ 431 "metadata", 432 "images" 433 ] 434 }, 435 "dolphin-metadata" 436 ], 437 "resource_server": "7C7C4AZ9KHRS6X63AJAO" 439 } 441 The AS responds with a reference appropriate to represent the 442 resources list that the RS presented in its request as well as any 443 additional information the RS might need in future requests. 445 resource_reference (string): REQUIRED. A single string representing 446 the list of resources registered in the request. The RS MAY make 447 this handle available to a client instance as part of a discovery 448 response as described in [I-D.ietf-gnap-core-protocol] or as 449 documentation to client software developers. 451 instance_id (string): OPTIONAL. An instance identifier that the RS 452 can use to refer to itself in future calls to the AS, in lieu of 453 sending its key by value. 455 introspection_endpoint (string): OPTIONAL. The introspection 456 endpoint of this AS, used to allow the RS to perform token 457 introspection. Section 3.3 459 HTTP/1.1 200 OK 460 Content-Type: application/json 461 Cache-Control: no-store 463 { 464 "resource_reference": "FWWIKYBQ6U56NL1" 465 } 467 4. Deriving a downstream token 469 Some architectures require an RS to act as a client instance and use 470 a derived access token for a secondary RS. Since the RS is not the 471 same entity that made the initial grant request, the RS is not 472 capable of referencing or modifying the existing grant. As such, the 473 RS needs to request or generate a new token access token for its use 474 at the secondary RS. This internal secondary token is issued in the 475 context of the incoming access token. 477 While it is possible to use a token format (Section 2) that allows 478 for the RS to generate its own secondary token, the AS can allow the 479 RS to request this secondary access token using the same process used 480 by the original client instance to request the primary access token. 481 Since the RS is acting as its own client instance from the 482 perspective of GNAP, this process uses the same grant endpoint, 483 request structure, and response structure as a client instance's 484 request. 486 +--------+ +-------+ +------+ +-------+ 487 | Client |--(1)->| RS1 | | AS | | RS2 | 488 |Instance| | |--(2)->| | | | 489 | | | |<-(3)--| | | | 490 | | | | +------+ | | 491 | | | | | | 492 | | | |-----------(4)------->| | 493 | | | |<----------(5)--------| | 494 | |<-(6)--| | | | 495 +--------+ +-------+ +-------+ 497 1. The client instance calls RS1 with an access token. 499 2. RS1 presents that token to the AS to get a derived token for use 500 at RS2. RS1 indicates that it has no ability to interact with 501 the RO. Note that RS1 signs its request with its own key, not 502 the token's key or the client instance's key. 504 3. The AS returns a derived token to RS1 for use at RS2. 506 4. RS1 calls RS2 with the token from (3). 508 5. RS2 fulfills the call from RS1. 510 6. RS1 fulfills the call from the original client instance. 512 If the RS needs to derive a token from one presented to it, it can 513 request one from the AS by making a token request as described in 514 [I-D.ietf-gnap-core-protocol] and presenting the existing access 515 token's value in the "existing_access_token" field. 517 Since the RS is acting as a client instance, the RS MUST identify 518 itself with its own key in the "client" field and sign the request 519 just as any client instance would, as described in Section 3.2. 521 POST /tx HTTP/1.1 522 Host: server.example.com 523 Content-Type: application/json 524 Detached-JWS: ejy0... 526 { 527 "access_token": { 528 "access": [ 529 { 530 "actions": [ 531 "read", 532 "write", 533 "dolphin" 534 ], 535 "locations": [ 536 "https://server.example.net/", 537 "https://resource.local/other" 538 ], 539 "datatypes": [ 540 "metadata", 541 "images" 542 ] 543 }, 544 "dolphin-metadata" 545 ] 546 }, 547 "client": "7C7C4AZ9KHRS6X63AJAO", 548 "existing_access_token": "OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0" 549 } 550 The AS responds with a token for the downstream RS2 as described in 551 [I-D.ietf-gnap-core-protocol]. The downstream RS2 could repeat this 552 process as necessary for calling further RS's. 554 5. Acknowledgements 556 (TODO: the ACK section should probably be split between the 557 documents) 559 6. IANA Considerations 561 [[ TBD: There are a lot of items in the document that are expandable 562 through the use of value registries. ]] 564 6.1. GNAP Token Format Registry 566 This specification establishes the GNAP Token Format Registry to 567 define token formats. 569 6.1.1. Registry Template 571 6.1.2. Initial Registry Contents 573 The table below contains the initial contents of the GNAP Token 574 Format Registry. 576 +===============+========+====================+===========+ 577 | Name | Status | Description | Reference | 578 +===============+========+====================+===========+ 579 | jwt-signed | Active | JSON Web Token, | [RFC7519] | 580 | | | signed with JWS | | 581 +---------------+--------+--------------------+-----------+ 582 | jwt-encrypted | Active | JSON Web Token, | [RFC7519] | 583 | | | encrypted with JWE | | 584 +---------------+--------+--------------------+-----------+ 585 | macaroon | Active | Macaroon | | 586 +---------------+--------+--------------------+-----------+ 587 | biscuit | Active | Biscuit | | 588 +---------------+--------+--------------------+-----------+ 589 | zcap | Active | ZCAP | | 590 +---------------+--------+--------------------+-----------+ 592 Table 1: Initial contents of the GNAP Token Format 593 Registry. 595 7. Security Considerations 597 [[ TBD: There are a lot of security considerations to add. ]] 599 All requests have to be over TLS or equivalent as per [BCP195]. Many 600 handles act as shared secrets, though they can be combined with a 601 requirement to provide proof of a key as well. 603 8. Privacy Considerations 605 [[ TBD: There are a lot of privacy considerations to add. ]] 607 When introspection is used, the AS is made aware of a particular 608 token being used at a particular AS, and the AS would not otherwise 609 have insight into this. 611 When the client instance receives information about the protecting AS 612 from an RS, this can be used to derive information about the 613 resources being protected without releasing the resources themselves. 615 9. Normative References 617 [BCP195] Sheffer, Y., Holz, R., and P. Saint-Andre, 618 "Recommendations for Secure Use of Transport Layer 619 Security (TLS) and Datagram Transport Layer Security 620 (DTLS)", May 2015, 621 . 623 [I-D.ietf-gnap-core-protocol] 624 Richer, J., Parecki, A., and F. Imbault, "Grant 625 Negotiation and Authorization Protocol", Work in Progress, 626 Internet-Draft, draft-ietf-gnap-core-protocol-05, 28 April 627 2021, . 630 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 631 Requirement Levels", BCP 14, RFC 2119, 632 DOI 10.17487/RFC2119, March 1997, 633 . 635 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 636 Resource Identifier (URI): Generic Syntax", STD 66, 637 RFC 3986, DOI 10.17487/RFC3986, January 2005, 638 . 640 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 641 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 642 . 644 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 645 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 646 May 2017, . 648 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 649 Interchange Format", STD 90, RFC 8259, 650 DOI 10.17487/RFC8259, December 2017, 651 . 653 [RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu, 654 "Handling Long Lines in Content of Internet-Drafts and 655 RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020, 656 . 658 Appendix A. Document History 660 * -01 662 - Better described RS authentication. 664 - Added access token format registry. 666 - Filled out introspection protocol. 668 - Filled out resource registration protocol. 670 - Expanded RS-facing discovery mechanisms. 672 - Moved client-facing RS response back to GNAP core document. 674 * -00 676 - Extracted resource server section. 678 Authors' Addresses 680 Justin Richer (editor) 681 Bespoke Engineering 683 Email: ietf@justin.richer.org 684 URI: https://bspk.io/ 686 Aaron Parecki 687 Okta 689 Email: aaron@parecki.com 690 URI: https://aaronparecki.com 691 Fabien Imbault 692 acert.io 694 Email: fabien.imbault@acert.io 695 URI: https://acert.io/