idnits 2.17.1 draft-maler-oauth-umafedauthz-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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 12 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 176 has weird spacing: '... push toke...' -- The document date (February 13, 2019) is 1893 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3986' is defined on line 1291, but no explicit reference was found in the text == Unused Reference: 'RFC5785' is defined on line 1296, but no explicit reference was found in the text == Unused Reference: 'RFC6819' is defined on line 1310, but no explicit reference was found in the text == Unused Reference: 'RFC7009' is defined on line 1315, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-oauth-discovery-08 ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 5785 (Obsoleted by RFC 8615) ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Maler, Ed. 3 Internet-Draft ForgeRock 4 Intended status: Informational M. Machulak 5 Expires: August 17, 2019 HSBC 6 J. Richer 7 Bespoke Engineering 8 T. Hardjono 9 MIT 10 February 13, 2019 12 Federated Authorization for User-Managed Access (UMA) 2.0 13 draft-maler-oauth-umafedauthz-00 15 Abstract 17 This specification defines a means for an UMA-enabled authorization 18 server and resource server to be loosely coupled, or federated, in a 19 secure and authorized resource owner context. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on August 17, 2019. 38 Copyright Notice 40 Copyright (c) 2019 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3 57 1.2. Abstract Flow . . . . . . . . . . . . . . . . . . . . . . 4 58 1.3. HTTP Usage, API Security, and Identity Context . . . . . 5 59 1.4. Separation of Responsibility and Authority . . . . . . . 6 60 1.5. Protection API Summary . . . . . . . . . . . . . . . . . 7 61 1.5.1. Permissions . . . . . . . . . . . . . . . . . . . . . 8 62 2. Authorization Server Metadata . . . . . . . . . . . . . . . . 8 63 3. Resource Registration Endpoint . . . . . . . . . . . . . . . 9 64 3.1. Resource Description . . . . . . . . . . . . . . . . . . 11 65 3.1.1. Scope Description . . . . . . . . . . . . . . . . . . 12 66 3.2. Resource Registration API . . . . . . . . . . . . . . . . 13 67 3.2.1. Create Resource Description . . . . . . . . . . . . . 14 68 3.2.2. Read Resource Description . . . . . . . . . . . . . . 15 69 3.2.3. Update Resource Description . . . . . . . . . . . . . 16 70 3.2.4. Delete Resource Description . . . . . . . . . . . . . 17 71 3.2.5. List Resource Descriptions . . . . . . . . . . . . . 17 72 4. Permission Endpoint . . . . . . . . . . . . . . . . . . . . . 18 73 4.1. Resource Server Request to Permission Endpoint . . . . . 20 74 4.2. Authorization Server Response to Resource Server on 75 Permission Request Success . . . . . . . . . . . . . . . 22 76 4.3. Authorization Server Response to Resource Server on 77 Permission Request Failure . . . . . . . . . . . . . . . 23 78 5. Token Introspection Endpoint . . . . . . . . . . . . . . . . 23 79 5.1. Resource Server Request to Token Introspection Endpoint . 24 80 5.1.1. Authorization Server Response to Resource Server on 81 Token Introspection Success . . . . . . . . . . . . . 25 82 6. Error Messages . . . . . . . . . . . . . . . . . . . . . . . 26 83 7. Security Considerations . . . . . . . . . . . . . . . . . . . 27 84 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 27 85 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 86 9.1. OAuth 2.0 Authorization Server Metadata Registry . . . . 28 87 9.1.1. Registry Contents . . . . . . . . . . . . . . . . . . 28 88 9.2. OAuth Token Introspection Response Registration . . . . . 28 89 9.2.1. Registry Contents . . . . . . . . . . . . . . . . . . 28 90 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 91 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 92 11.1. Normative References . . . . . . . . . . . . . . . . . . 29 93 11.2. Informative References . . . . . . . . . . . . . . . . . 31 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 96 1. Introduction 98 This specification extends and complements [UMAGrant] to loosely 99 couple, or federate, its authorization process. This enables 100 multiple resource servers operating in different domains to 101 communicate with a single authorization server operating in yet 102 another domain that acts on behalf of a resource owner. A service 103 ecosystem can thus automate resource protection, and the resource 104 owner can monitor and control authorization grant rules through the 105 authorization server over time. Further, authorization grants can 106 increase and decrease at the level of individual resources and 107 scopes. 109 Building on the example provided in the introduction in [UMAGrant], 110 bank customer (resource owner) Alice has a bank account service 111 (resource server), a cloud file system (different resource server 112 hosted elsewhere), and a dedicated sharing management service 113 (authorization server) hosted by the bank. She can manage access to 114 her various protected resources by spouse Bob, accounting 115 professional Charline, financial information aggregation company 116 DecideAccount, and neighbor Erik (requesting parties), all using 117 different client applications. Her bank accounts and her various 118 files and folders are protected resources, and she can use the same 119 sharing management service to monitor and control different scopes of 120 access to them by these different parties, such as viewing, editing, 121 or printing files and viewing account data or accessing payment 122 functions. 124 This specification, together with [UMAGrant], constitutes UMA 2.0. 125 This specification is OPTIONAL to use with the UMA grant. 127 1.1. Notational Conventions 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 131 "OPTIONAL" in this document are to be interpreted as described in 132 [RFC2119]. 134 Unless otherwise noted, all parameter names and values are case 135 sensitive. JSON [RFC7159] data structures defined in this 136 specification MAY contain extension parameters that are not defined 137 in this specification. Any entity receiving or retrieving a JSON 138 data structure SHOULD ignore extension parameters it is unable to 139 understand. Extension names that are unprotected from collisions are 140 outside the scope of this specification. 142 1.2. Abstract Flow 144 The UMA grant defined in [UMAGrant] enhances the abstract protocol 145 flow of OAuth. This specification enhances the UMA grant by defining 146 formal communications between the UMA-enabled authorization server 147 and resource server as they act on behalf of the resource owner, 148 responding to authorization and resource requests, respectively, by a 149 client that is acting on behalf of a requesting party. 151 A summary of UMA 2.0 communications, combining the UMA grant with 152 federated authorization, is shown in Figure 1. 154 +------------------+ 155 | resource | 156 +------------manage (out of scope)----| owner | 157 | +------------------+ 158 | | 159 | protection | 160 | API access control 161 | token (PAT) (out of scope) 162 | | 163 v v 164 +------------+ +----------+------------------+ 165 | | |protection| | 166 | resource | | API | authorization | 167 | server |<-----protect-------| (needs | server | 168 | | | PAT) | | 169 +------------+ +----------+------------------+ 170 | protected | | UMA | 171 | resource | | grant | 172 |(needs RPT) | requesting | (PCT optional) | 173 +------------+ party token +------------------+ 174 ^ (RPT) ^ persisted ^ 175 | | claims | 176 | push token | 177 | claim (PCT) | 178 | tokens interact 179 | +--------+ for 180 +------------access--------------------| client | claims 181 +--------+ gathering 182 +---------------+ 183 | requesting | 184 | party | 185 +---------------+ 187 Figure 1: Federated Authorization Enhancements to UMA Grant Flow 189 This specification uses all of the terms and concepts in [UMAGrant]. 190 This figure introduces the following new concepts: 192 protection API The API presented by the authorization server to the 193 resource server, defined in this specification. This API is 194 OAuth-protected. 196 protection API access token (PAT) An [RFC6749] access token with the 197 scope "uma_protection", used by the resource server as a client 198 of the authorization server's protection API. The resource 199 owner involved in the UMA grant is the same entity taking on 200 the role of the resource owner authorizing issuance of the PAT. 202 1.3. HTTP Usage, API Security, and Identity Context 204 This specification is designed for use with HTTP [RFC2616], and for 205 interoperability and security in the context of loosely coupled 206 services and applications operated by independent parties in 207 independent domains. The use of UMA over any protocol other than 208 HTTP is undefined. In such circumstances, it is RECOMMENDED to 209 define profiles or extensions to achieve interoperability among 210 independent implementations (see Section 4 of [UMAGrant]). 212 The authorization server MUST use TLS protection over its protection 213 API endpoints, as governed by [BCP195], which discusses deployment 214 and adoption characteristics of different TLS versions. 216 The authorization server MUST use OAuth and require a valid PAT to 217 secure its protection API endpoints. The authorization server and 218 the resource server (as an OAuth client) MUST support bearer usage of 219 the PAT, as defined in [RFC6750]. All examples in this specification 220 show the use of bearer-style PATs in this format. 222 As defined in [UMAGrant], the resource owner -- the entity here 223 authorizing PAT issuance -- MAY be an end-user (natural person) or a 224 non-human entity treated as a person for limited legal purposes 225 (legal person), such as a corporation. A PAT is unique to a resource 226 owner, resource server used for resource management, and 227 authorization server used for protection of those resources. The 228 issuance of the PAT represents the authorization of the resource 229 owner for the resource server to use the authorization server for 230 protecting those resources. 232 Different grant types for PAT issuance might be appropriate for 233 different types of resource owners; for example, the client 234 credentials grant is useful in the case of an organization acting as 235 a resource owner, whereas an interactive grant type is typically more 236 appropriate for capturing the approval of an end-user resource owner. 238 Where an identity token is desired in addition to an access token, it 239 is RECOMMENDED to use [OIDCCore] in addition. 241 1.4. Separation of Responsibility and Authority 243 Federation of authorization for the UMA grant delivers a conceptual 244 separation of responsibility and authority: 246 o The resource owner can control access to resources residing at 247 multiple resource servers from a single authorization server, by 248 virtue of authorizing PAT issuance for each resource server. Any 249 one resource server MAY be operated by a party different from the 250 one operating the authorization server. 252 o The resource server defines the boundaries of resources and the 253 scopes available to each resource, and interprets how clients' 254 resource requests map to permission requests, by virtue of being 255 the publisher of the API being protected and using the protection 256 API to communicate to the authorization server. 258 o The resource owner works with the authorization server to 259 configure policy conditions (authorization grant rules), which the 260 authorization server executes in the process of issuing access 261 tokens. The authorization process makes use of claims gathered 262 from the requesting party and client in order to satisfy all 263 operative operative policy conditions. 265 The separation of authorization decision making and authorization 266 enforcement is similar to the architectural separation often used in 267 enterprises between policy decision points and policy enforcement 268 points. However, the resource server MAY apply additional 269 authorization controls beyond those imposed by the authorization 270 server. For example, even if an RPT provides sufficient permissions 271 for a particular case, the resource server can choose to bar access 272 based on its own criteria. 274 Practical control of access among loosely coupled parties typically 275 requires more than just messaging protocols. It is outside the scope 276 of this specification to define more than the technical contract 277 between UMA-conforming entities. Laws may govern authorization- 278 granting relationships. It is RECOMMENDED for the resource owner, 279 authorization server, and resource server to establish agreements 280 about which parties are responsible for establishing and maintaining 281 authorization grant rules and other authorization rules on a legal or 282 contractual level, and parties operating entities claiming to be UMA- 283 conforming should provide documentation of rights and obligations 284 between and among them. See Section 4 of [UMAGrant] for more 285 information. 287 Except for PAT issuance, the resource owner-resource server and 288 resource owner-authorization server interfaces -- including the 289 setting of policy conditions -- are outside the scope of this 290 specification (see Section 8 and Section 6.1 of [UMAGrant] for 291 privacy considerations). Some elements of the protection API enable 292 the building of user interfaces for policy condition setting (for 293 example, see Section 3.2, which can be used in concert with user 294 interaction for resource protection and sharing and offers an end- 295 user redirection mechanism for policy interactions). 297 Note: The resource server typically requires access to at least the 298 permission and token introspection endpoints when an end-user 299 resource owner is not available ("offline" access). Thus, the 300 authorization server needs to manage the PAT in a way that ensures 301 this outcome. [UMA-Impl] discusses ways the resource server can 302 enhance its error handling when the PAT is invalid. 304 1.5. Protection API Summary 306 The protection API defines the following endpoints: 308 o Resource registration endpoint as defined in Section 3. The API 309 available at this endpoint provides a means for the resource 310 server to put resources under the protection of an authorization 311 server on behalf of the resource owner and manage them over time. 313 o Permission endpoint as defined in Section 4. This endpoint 314 provides a means for the resource server to request a set of one 315 or more permissions on behalf of the client based on the client's 316 resource request when that request is unaccompanied by an access 317 token or is accompanied by an RPT that is insufficient for access 318 to that resource. 320 o OPTIONAL token introspection endpoint as defined in [RFC7662] and 321 as extended in Section 5. This endpoint provides a means for the 322 resource server to introspect the RPT. 324 Use of these endpoints assumes that the resource server has acquired 325 OAuth client credentials from the authorization server by static or 326 dynamic means, and has a valid PAT. Note: Although the resource 327 identifiers that appear in permission and token introspection request 328 messages could sufficiently identify the resource owner, the PAT is 329 still required because it represents the resource owner's 330 authorization to use the protection API, as noted in Section 1.3. 332 The authorization server MUST declare its protection API endpoints in 333 the discovery document (see Section 2). 335 1.5.1. Permissions 337 A permission is (requested or granted) authorized access to a 338 particular resource with some number of scopes bound to that 339 resource. The concept of permissions is used in authorization 340 assessment, results calculation, and RPT issuance in [UMAGrant]. 341 This concept takes on greater significance in relation to the 342 protection API. 344 The resource server's resource registration operations at the 345 authorization server result in a set of resource owner-specific 346 resource identifiers. When the client makes a resource request that 347 is unaccompanied by an access token or its resource request fails, 348 the resource server is responsible for interpreting that request and 349 mapping it to a choice of authorization server, resource owner, 350 resource identifier(s), and set of scopes for each identifier, in 351 order to request one or more permissions -- resource identifiers and 352 a set of scopes -- and obtain a permission ticket on the client's 353 behalf. Finally, when the client has made a resource request 354 accompanied by an RPT and token introspection is in use, the returned 355 token introspection object reveals the structure of permissions, 356 potentially including expiration of individual permissions. 358 2. Authorization Server Metadata 360 This specification makes use of the authorization server discovery 361 document structure and endpoint defined in [UMAGrant]. The resource 362 server uses this discovery document to discover the endpoints it 363 needs. 365 In addition to the metadata defined in that specification and 366 [OAuthMeta], this specification defines the following metadata for 367 inclusion in the discovery document: 369 permission_endpoint 370 REQUIRED. The endpoint URI at which the resource server requests 371 permissions on the client's behalf. 373 resource_registration_endpoint 374 REQUIRED. The endpoint URI at which the resource server registers 375 resources to put them under authorization manager protection. 377 Following are additional requirements related to metadata: 379 introspection_endpoint 380 If the authorization server supports token introspection as 381 defined in this specification, it MUST supply this metadata value 382 (defined in [OAuthMeta]). 384 The authorization server SHOULD document any profiled or extended 385 features it supports explicitly, ideally by supplying the URI 386 identifying each UMA profile and extension as an 387 "uma_profiles_supported" metadata array value (defined in 388 [UMAGrant]), and by using extension metadata to indicate specific 389 usage details as necessary. 391 3. Resource Registration Endpoint 393 The API available at the resource registration endpoint enables the 394 resource server to put resources under the protection of an 395 authorization server on behalf of the resource owner and manage them 396 over time. Protection of a resource at the authorization server 397 begins on successful registration and ends on successful 398 deregistration. 400 The resource server uses a RESTful API at the authorization server's 401 resource registration endpoint to create, read, update, and delete 402 resource descriptions, along with retrieving lists of such 403 descriptions. The descriptions consist of JSON documents that are 404 maintained as web resources at the authorization server. (Note 405 carefully the similar but distinct senses in which the word 406 "resource" is used in this section.) 408 Figure 2 illustrates the resource registration API operations, with 409 requests and success responses shown. 411 authorization resource resource 412 server server owner 413 | | | 414 |*PROTECTION API: | | 415 |*Resource registration | | 416 |endpoint/API | | 417 | | | 418 |*Create resource (POST)| | 419 |<----------------------| | 420 |*201 Created with | | 421 |resource ID | | 422 |---------------------->| | 423 | | | 424 |Set policy conditions (anytime | 425 |before deletion/deregistration) | 426 |<- - - - - - - - - - - - - - - - - - - -| 427 | | | 428 |*Read (GET) with | | 429 |resource ID | | 430 |<----------------------| | 431 |*200 OK with resource | | 432 |representation | | 433 |---------------------->| | 434 |*Update (PUT) with | | 435 |resource ID | | 436 |<----------------------| | 437 |*200 OK with resource | | 438 |ID | | 439 |---------------------->| | 440 |*List (GET) | | 441 |<----------------------| | 442 |*200 OK with list of | | 443 |resource IDs | | 444 |---------------------->| | 445 |*Delete (DELETE) with | | 446 |resource ID | | 447 |<----------------------| | 448 |*200 OK or 204 No | | 449 |Content | | 450 |---------------------->| | 452 Figure 2: Resource Registration Endpoint and API: Requests and 453 Success Responses 455 The resource server MAY protect any subset of the resource owner's 456 resources using different authorization servers or other means 457 entirely, or to protect some resources and not others. Additionally, 458 the choice of protection regimes MAY be made explicitly by the 459 resource owner or implicitly by the resource server. Any such 460 partitioning by the resource server or owner is outside the scope of 461 this specification. 463 The resource server MAY register a single resource for protection 464 that, from its perspective, has multiple parts, or has dynamic 465 elements such as the capacity for querying or filtering, or otherwise 466 has internal complexity. The resource server alone is responsible 467 for maintaining any required mappings between internal 468 representations and the resource identifiers and scopes known to the 469 authorization server. 471 Note: The resource server is responsible for managing the process and 472 timing of registering resources, maintaining the registration of 473 resources, and deregistering resources at the authorization server. 474 Motivations for updating a resource might include, for example, new 475 scopes added to a new API version or resource owner actions at a 476 resource server that result in new resource description text. See 477 [UMA-Impl] for a discussion of initial resource registration timing 478 options. 480 3.1. Resource Description 482 A resource description is a JSON document that describes the 483 characteristics of a resource sufficiently for an authorization 484 server to protect it. A resource description has the following 485 parameters: 487 resource_scopes REQUIRED. An array of strings, serving as scope 488 identifiers, indicating the available scopes for this resource. 489 Any of the strings MAY be either a plain string or a URI. 491 description OPTIONAL. A human-readable string describing the 492 resource at length. The authorization server MAY use this 493 description in any user interface it presents to a resource owner, 494 for example, for resource protection monitoring or policy setting. 495 The value of this parameter MAY be internationalized, as described 496 in Section 2.2 of [RFC7591]. 498 icon_uri OPTIONAL. A URI for a graphic icon representing the 499 resource. The authorization server MAY use the referenced icon in 500 any user interface it presents to a resource owner, for example, 501 for resource protection monitoring or policy setting. 503 name OPTIONAL. A human-readable string naming the resource. The 504 authorization server MAY use this name in any user interface it 505 presents to a resource owner, for example, for resource protection 506 monitoring or policy setting. The value of this parameter MAY be 507 internationalized, as described in Section 2.2 of [RFC7591]. 509 type OPTIONAL. A string identifying the semantics of the resource. 510 For example, if the resource is an identity claim that leverages 511 standardized claim semantics for "verified email address", the 512 value of this parameter could be an identifying URI for this 513 claim. The authorization server MAY use this information in 514 processing information about the resource or displaying 515 information about it in any user interface it presents to a 516 resource owner. 518 For example, this description characterizes a resource (a photo 519 album) that can potentially be viewed or printed; the scope URI 520 points to a scope description as defined in Section 3.1.1: 522 { 523 "resource_scopes":[ 524 "view", 525 "http://photoz.example.com/dev/scopes/print" 526 ], 527 "description":"Collection of digital photographs", 528 "icon_uri":"http://www.example.com/icons/flower.png", 529 "name":"Photo Album", 530 "type":"http://www.example.com/rsrcs/photoalbum" 531 } 533 3.1.1. Scope Description 535 A scope description is a JSON document that describes the 536 characteristics of a scope sufficiently for an authorization server 537 to protect the resource with this available scope. 539 While a scope URI appearing in a resource description (see 540 Section 3.1) MAY resolve to a scope description document, and thus 541 scope description documents are possible to standardize and reference 542 publicly, the authorization server is not expected to resolve scope 543 description details at resource registration time or at any other 544 run-time requirement. The resource server and authorization server 545 are presumed to have negotiated any required interpretation of scope 546 handling out of band. 548 A scope description has the following parameters: 550 description OPTIONAL. A human-readable string describing the 551 resource at length. The authorization server MAY use this 552 description in any user interface it presents to a resource owner, 553 for example, for resource protection monitoring or policy setting. 555 The value of this parameter MAY be internationalized, as described 556 in Section 2.2 of [RFC7591]. 558 icon_uri OPTIONAL. A URI for a graphic icon representing the scope. 559 The authorization server MAY use the referenced icon in any user 560 interface it presents to a resource owner, for example, for 561 resource protection monitoring or policy setting. 563 name OPTIONAL. A human-readable string naming the scope. The 564 authorization server MAY use this name in any user interface it 565 presents to a resource owner, for example, for resource protection 566 monitoring or policy setting. The value of this parameter MAY be 567 internationalized, as described in Section 2.2 of [RFC7591]. 569 For example, this scope description characterizes a scope that 570 involves printing (as opposed to, say, creating or editing in some 571 fashion): 573 { 574 "description":"Print out and produce PDF files of photos", 575 "icon_uri":"http://www.example.com/icons/printer", 576 "name":"Print" 577 } 579 3.2. Resource Registration API 581 The authorization server MUST support the following five registration 582 options and MUST require a valid PAT for access to them; any other 583 operations are undefined by this specification. Here, _rreguri_ 584 stands for the resource registration endpoint and __id_ stands for 585 the authorization server-assigned identifier for the web resource 586 corresponding to the resource at the time it was created, included 587 within the URL returned in the Location header. Each operation is 588 defined in its own section below. 590 o Create resource description: POST _rreguri_/ 592 o Read resource description: GET _rreguri_/__id_ 594 o Update resource description: PUT _rreguri_/__id_ 596 o Delete resource description: DELETE _rreguri_/__id_ 598 o List resource descriptions: GET _rreguri_/ 600 Within the JSON body of a successful response, the authorization 601 server includes common parameters, possibly in addition to method- 602 specific parameters, as follows: 604 _id REQUIRED (except for the Delete and List methods). A string 605 value repeating the authorization server-defined identifier for 606 the web resource corresponding to the resource. Its appearance in 607 the body makes it readily available as an identifier for various 608 protected resource management tasks. 610 user_access_policy_uri OPTIONAL. A URI that allows the resource 611 server to redirect an end-user resource owner to a specific user 612 interface within the authorization server where the resource owner 613 can immediately set or modify access policies subsequent to the 614 resource registration action just completed. The authorization 615 server is free to choose the targeted user interface, for example, 616 in the case of a deletion action, enabling the resource server to 617 direct the end-user to a policy-setting interface for an overall 618 "folder" resource formerly "containing" the deleted resource (a 619 relationship the authorization server is not aware of), to enable 620 adjustment of related policies. 622 If the request to the resource registration endpoint is incorrect, 623 then the authorization server instead responds as follows (see 624 Section 6 for information about error messages): 626 o If the referenced resource cannot be found, the authorization 627 server MUST respond with an HTTP 404 (Not Found) status code and 628 MAY respond with a "not_found" error code. 630 o If the resource server request used an unsupported HTTP method, 631 the authorization server MUST respond with the HTTP 405 (Method 632 Not Allowed) status code and MAY respond with an 633 "unsupported_method_type" error code. 635 o If the request is missing a required parameter, includes an 636 invalid parameter value, includes a parameter more than once, or 637 is otherwise malformed, the authorization server MUST respond with 638 the HTTP 400 (Bad Request) status code and MAY respond with an 639 "invalid_request" error code. 641 3.2.1. Create Resource Description 643 Adds a new resource description to the authorization server using the 644 POST method. If the request is successful, the resource is thereby 645 registered and the authorization server MUST respond with an HTTP 201 646 status message that includes a "Location" header and an "_id" 647 parameter. 649 Form of a create request, with a PAT in the header: 651 POST /rreg/ HTTP/1.1 Content-Type: application/json 652 Authorization: Bearer MHg3OUZEQkZBMjcx 653 ... 654 { 655 "resource_scopes":[ 656 "read-public", 657 "post-updates", 658 "read-private", 659 "http://www.example.com/scopes/all" 660 ], 661 "icon_uri":"http://www.example.com/icons/sharesocial.png", 662 "name":"Tweedl Social Service", 663 "type":"http://www.example.com/rsrcs/socialstream/140-compatible" 664 } 666 Form of a successful response, also containing an optional 667 "user_access_policy_uri" parameter: 669 HTTP/1.1 201 Created 670 Content-Type: application/json 671 Location: /rreg/KX3A-39WE 672 ... 673 { 674 "_id":"KX3A-39WE", 675 "user_access_policy_uri":"http://as.example.com/rs/222/resource/KX3A-39WE/policy" 676 } 678 3.2.2. Read Resource Description 680 Reads a previously registered resource description using the GET 681 method. If the request is successful, the authorization server MUST 682 respond with an HTTP 200 status message that includes a body 683 containing the referenced resource description, along with an "_id" 684 parameter. 686 Form of a read request, with a PAT in the header: 688 GET /rreg/KX3A-39WE HTTP/1.1 689 Authorization: Bearer MHg3OUZEQkZBMjcx 690 ... 692 Form of a successful response, containing all the parameters that 693 were registered as part of the description: 695 HTTP/1.1 200 OK 696 Content-Type: application/json 697 ... 698 { 699 "_id":"KX3A-39WE", 700 "resource_scopes":[ 701 "read-public", 702 "post-updates", 703 "read-private", 704 "http://www.example.com/scopes/all" 705 ], 706 "icon_uri":"http://www.example.com/icons/sharesocial.png", 707 "name":"Tweedl Social Service", 708 "type":"http://www.example.com/rsrcs/socialstream/140-compatible" 709 } 711 3.2.3. Update Resource Description 713 Updates a previously registered resource description, by means of a 714 complete replacement of the previous resource description, using the 715 PUT method. If the request is successful, the authorization server 716 MUST respond with an HTTP 200 status message that includes an "_id" 717 parameter. 719 Form of an update request adding a "description" parameter to a 720 resource description that previously had none, with a PAT in the 721 header: 723 PUT /rreg/9UQU-DUWW HTTP/1.1 724 Content-Type: application/json 725 Authorization: Bearer 204c69636b6c69 726 ... 727 { 728 "resource_scopes":[ 729 "http://photoz.example.com/dev/scopes/view", 730 "public-read" 731 ], 732 "description":"Collection of digital photographs", 733 "icon_uri":"http://www.example.com/icons/sky.png", 734 "name":"Photo Album", 735 "type":"http://www.example.com/rsrcs/photoalbum" 736 } 737 Form of a successful response, not containing the optional 738 "user_access_policy_uri" parameter: 740 HTTP/1.1 200 OK 741 ... 742 { 743 "_id":"9UQU-DUWW" 744 } 746 3.2.4. Delete Resource Description 748 Deletes a previously registered resource description using the DELETE 749 method. If the request is successful, the resource is thereby 750 deregistered and the authorization server MUST respond with an HTTP 751 200 or 204 status message. 753 Form of a delete request, with a PAT in the header: 755 DELETE /rreg/9UQU-DUWW 756 Authorization: Bearer 204c69636b6c69 757 ... 759 Form of a successful response: 761 HTTP/1.1 204 No content 762 ... 764 3.2.5. List Resource Descriptions 766 Lists all previously registered resource identifiers for this 767 resource owner using the GET method. The authorization server MUST 768 return the list in the form of a JSON array of "_id" string values. 770 The resource server can use this method as a first step in checking 771 whether its understanding of protected resources is in full 772 synchronization with the authorization server's understanding. 774 Form of a list request, with a PAT in the header: 776 GET /rreg/ HTTP/1.1 777 Authorization: Bearer 204c69636b6c69 778 ... 780 Form of a successful response: 782 HTTP/1.1 200 OK 783 ... 784 [ 785 "KX3A-39WE", 786 "9UQU-DUWW" 787 ] 789 4. Permission Endpoint 791 The permission endpoint defines a means for the resource server to 792 request one or more permissions (resource identifiers and 793 corresponding scopes) with the authorization server on the client's 794 behalf, and to receive a permission ticket in return, in order to 795 respond as indicated in Section 3.2 of [UMAGrant]. The resource 796 server uses this endpoint on the following occasions: 798 o After the client's initial resource request without an access 799 token 801 o After the client's resource request that was accompanied by an 802 invalid RPT or a valid RPT that had insufficient permissions 803 associated with it 805 The use of the permission endpoint is illustrated in Figure 3, with a 806 request and a success response shown. 808 authorization resource 809 client server server 810 | | | 811 |Request resource (no or insufficient | 812 |access token) | | 813 |--------------------------------------->| 814 | | | 815 | |*PROTECTION API: | 816 | |*Permission endpoint | 817 | | | 818 | |*Request permissions | 819 | |(POST) | 820 | |<--------------------| 821 | |*201 Created with | 822 | |permission ticket | 823 | |-------------------->| 824 | | | 825 |401 response with permission ticket, | 826 |authz server location | 827 |<---------------------------------------| 829 Figure 3: Permission Endpoint: Request and Success Response 831 The PAT provided in the API request enables the authorization server 832 to map the resource server's request to the appropriate resource 833 owner. It is only possible to request permissions for access to the 834 resources of a single resource owner, protected by a single 835 authorization server, at a time. 837 In its response, the authorization server returns a permission ticket 838 for the resource server to give to the client that represents the 839 same permissions that the resource server requested. 841 The process of choosing what permissions to request from the 842 authorization server may require interpretation and mapping of the 843 client's resource request. The resource server SHOULD request a set 844 of permissions with scopes that is reasonable for the client's 845 resource request. The resource server MAY request multiple 846 permissions, and any permission MAY have zero scopes associated with 847 it. Requesting multiple permissions might be appropriate, for 848 example, in cases where the resource server expects the requesting 849 party to need access to several related resources if they need access 850 to any one of the resources (see Section 3.3.4 of [UMAGrant] for an 851 example). Requesting a permission with no scopes might be 852 appropriate, for example, in cases where an access attempt involves 853 an API call that is ambiguous without further context (role-based 854 scopes such as "user" and "admin" could have this ambiguous quality, 855 and an explicit client request for a particular scope at the token 856 endpoint later can clarify the desired access). The resource server 857 SHOULD document its intended pattern of permission requests in order 858 to assist the client in pre-registering for and requesting 859 appropriate scopes at the authorization server. See [UMA-Impl] for a 860 discussion of permission request patterns. 862 Note: In order for the resource server to know which authorization 863 server to approach for the permission ticket and on which resource 864 owner's behalf (enabling a choice of permission endpoint and PAT), it 865 needs to derive the necessary information using cues provided by the 866 structure of the API where the resource request was made, rather than 867 by an access token. Commonly, this information can be passed through 868 the URI, headers, or body of the client's request. Alternatively, 869 the entire interface could be dedicated to the use of a single 870 resource owner and protected by a single authorization server. 872 4.1. Resource Server Request to Permission Endpoint 874 The resource server uses the POST method at the permission endpoint. 875 The body of the HTTP request message contains a JSON object for 876 requesting a permission for single resource identifier, or an array 877 of one or more objects for requesting permissions for a corresponding 878 number of resource identifiers. The object format in both cases is 879 derived from the resource description format specified in 880 Section 3.1; it has the following parameters: 882 resource_id REQUIRED. The identifier for a resource to which the 883 resource server is requesting a permission on behalf of the 884 client. The identifier MUST correspond to a resource that was 885 previously registered. 887 resource_scopes REQUIRED. An array referencing zero or more 888 identifiers of scopes to which the resource server is requesting 889 access for this resource on behalf of the client. Each scope 890 identifier MUST correspond to a scope that was previously 891 registered by this resource server for the referenced resource. 893 Example of an HTTP request for a single permission at the 894 authorization server's permission endpoint, with a PAT in the header: 896 POST /perm HTTP/1.1 897 Content-Type: application/json 898 Host: as.example.com 899 Authorization: Bearer 204c69636b6c69 900 ... 902 { 903 "resource_id":"112210f47de98100", 904 "resource_scopes":[ 905 "view", 906 "http://photoz.example.com/dev/actions/print" 907 ] 908 } 909 Example of an HTTP request for multiple permissions at the 910 authorization server's permission endpoint, with a PAT in the header: 912 POST /perm HTTP/1.1 913 Content-Type: application/json 914 Host: as.example.com 915 Authorization: Bearer 204c69636b6c69 916 ... 918 [ 919 { 920 "resource_id":"7b727369647d", 921 "resource_scopes":[ 922 "view", 923 "crop", 924 "lightbox" 925 ] 926 }, 927 { 928 "resource_id":"7b72736964327d", 929 "resource_scopes":[ 930 "view", 931 "layout", 932 "print" 933 ] 934 }, 935 { 936 "resource_id":"7b72736964337d", 937 "resource_scopes":[ 938 "http://www.example.com/scopes/all" 939 ] 940 } 941 ] 943 4.2. Authorization Server Response to Resource Server on Permission 944 Request Success 946 If the authorization server is successful in creating a permission 947 ticket in response to the resource server's request, it responds with 948 an HTTP 201 (Created) status code and includes the "ticket" parameter 949 in the JSON-formatted body. Regardless of whether the request 950 contained one or multiple permissions, only a single permission 951 ticket is returned. 953 For example: 955 HTTP/1.1 201 Created 956 Content-Type: application/json 957 ... 959 { 960 "ticket":"016f84e8-f9b9-11e0-bd6f-0021cc6004de" 961 } 963 4.3. Authorization Server Response to Resource Server on Permission 964 Request Failure 966 If the resource server's permission registration request is 967 authenticated properly but fails due to other reasons, the 968 authorization server responds with an HTTP 400 (Bad Request) status 969 code and includes one of the following error codes (see Section 6 for 970 more information about error codes and responses): 972 invalid_resource_id At least one of the provided resource 973 identifiers was not found at the authorization server. 975 invalid_scope At least one of the scopes included in the request was 976 not registered previously by this resource server for the 977 referenced resource. 979 5. Token Introspection Endpoint 981 When the client makes a resource request accompanied by an RPT, the 982 resource server needs to determine whether the RPT is active and, if 983 so, its associated permissions. Depending on the nature of the RPT 984 and operative caching parameters, the resource server MAY take any of 985 the following actions as appropriate to determine the RPT's status: 987 o Introspect the RPT at the authorization server using the OAuth 988 token introspection endpoint (defined in [RFC7662] and this 989 section) that is part of the protection API. The authorization 990 server's response contains an extended version of the 991 introspection response. If the authorization server supports this 992 specification's version of the token introspection endpoint, it 993 MUST declare the endpoint in its discovery document (see 994 Section 2) and support this extended version of the response. 996 o Use a cached copy of the token introspection response if allowed 997 (see Section 4 of [RFC7662]). 999 o Validate the RPT locally if it is self-contained. 1001 The use of the token introspection endpoint is illustrated in 1002 Figure 4, with a request and a success response shown. 1004 authorization resource 1005 client server server 1006 | | | 1007 |Resource request with RPT | 1008 |----------------------------------------->| 1009 | | | 1010 | |*PROTECTION API: | 1011 | |*Introspection endpoint| 1012 | | | 1013 | |*Request to introspect | 1014 | |token (POST) | 1015 | |<----------------------| 1016 | |*Response with token | 1017 | |introspection object | 1018 | |---------------------->| 1019 | | | 1020 |Protected resource | 1021 |<-----------------------------------------| 1023 Figure 4: Token Introspection Endpoint: Request and Success Response 1025 The authorization server MAY support both UMA-extended and non-UMA 1026 introspection requests and responses. 1028 5.1. Resource Server Request to Token Introspection Endpoint 1030 Note: In order for the resource server to know which authorization 1031 server, PAT (representing a resource owner), and endpoint to use in 1032 making the token introspection API call, it may need to interpret the 1033 client's resource request. 1035 Example of the resource server's request to the authorization server 1036 for introspection of an RPT, with a PAT in the header: 1038 POST /introspect HTTP/1.1 1039 Host: as.example.com 1040 Authorization: Bearer 204c69636b6c69 1041 ... 1042 token=sbjsbhs(/SSJHBSUSSJHVhjsgvhsgvshgsv 1044 Because an RPT is an access token, if the resource server chooses to 1045 supply a token type hint, it would use a "token_type_hint" of 1046 "access_token". 1048 5.1.1. Authorization Server Response to Resource Server on Token 1049 Introspection Success 1051 The authorization server's response to the resource server MUST use 1052 [RFC7662], responding with a JSON object with the structure dictated 1053 by that specification, extended as follows. 1055 If the introspection object's "active" parameter has a Boolean value 1056 of "true", then the object MUST NOT contain a "scope" parameter, and 1057 MUST contain an extension parameter named "permissions" that contains 1058 an array of objects, each one (representing a single permission) 1059 containing these parameters: 1061 resource_id REQUIRED. A string that uniquely identifies the 1062 protected resource, access to which has been granted to this 1063 client on behalf of this requesting party. The identifier MUST 1064 correspond to a resource that was previously registered as 1065 protected. 1067 resource_scopes REQUIRED. An array referencing zero or more strings 1068 representing scopes to which access was granted for this resource. 1069 Each string MUST correspond to a scope that was registered by this 1070 resource server for the referenced resource. 1072 exp OPTIONAL. Integer timestamp, measured in the number of seconds 1073 since January 1 1970 UTC, indicating when this permission will 1074 expire. If the token-level "exp" value pre-dates a permission- 1075 level "exp" value, the token-level value takes precedence. 1077 iat OPTIONAL. Integer timestamp, measured in the number of seconds 1078 since January 1 1970 UTC, indicating when this permission was 1079 originally issued. If the token-level "iat" value post-dates a 1080 permission-level "iat" value, the token-level value takes 1081 precedence. 1083 nbf OPTIONAL. Integer timestamp, measured in the number of seconds 1084 since January 1 1970 UTC, indicating the time before which this 1085 permission is not valid. If the token-level "nbf" value post- 1086 dates a permission-level "nbf" value, the token-level value takes 1087 precedence. 1089 Example of a response containing the introspection object with the 1090 "permissions" parameter containing a single permission: 1092 HTTP/1.1 200 OK 1093 Content-Type: application/json 1094 Cache-Control: no-store 1095 ... 1097 { 1098 "active":true, 1099 "exp":1256953732, 1100 "iat":1256912345, 1101 "permissions":[ 1102 { 1103 "resource_id":"112210f47de98100", 1104 "resource_scopes":[ 1105 "view", 1106 "http://photoz.example.com/dev/actions/print" 1107 ], 1108 "exp":1256953732 1109 } 1110 ] 1111 } 1113 6. Error Messages 1115 If a request is successfully authenticated, but is invalid for 1116 another reason, the authorization server produces an error response 1117 by supplying a JSON-encoded object with the following members in the 1118 body of the HTTP response: 1120 error REQUIRED except as noted. A single error code. Values for 1121 this parameter are defined throughout this specification. 1123 error_description OPTIONAL. Human-readable text providing 1124 additional information. 1126 error_uri OPTIONAL. A URI identifying a human-readable web page 1127 with information about the error. 1129 HTTP/1.1 400 Bad Request 1130 Content-Type: application/json 1131 Cache-Control: no-store 1132 ... 1134 { 1135 "error": "invalid_resource_id", 1136 "error_description": "Permission request failed with bad resource ID.", 1137 "error_uri": "https://as.example.com/uma_errors/invalid_resource_id" 1138 } 1140 7. Security Considerations 1142 This specification inherits the security considerations of [UMAGrant] 1143 and has the following additional security considerations. 1145 In the context of federated authorization, more parties may be 1146 operating and using UMA software entities, and thus may need to 1147 establish agreements about the parties' rights and responsibilities 1148 on a legal or contractual level, as discussed in Section 5.8 of 1149 [UMAGrant]. 1151 The protection API is secured by means of OAuth (through the use of 1152 the PAT). Therefore, it is susceptible to OAuth threats. 1154 8. Privacy Considerations 1156 This specification inherits the privacy considerations of [UMAGrant] 1157 and has the following additional privacy considerations. 1159 As noted in Section 6.1 of [UMAGrant], the authorization server 1160 should apply authorization, security, and time-to-live strategies in 1161 a way that favors resource owner needs and action so that removal of 1162 authorization grants is achieved in a timely fashion. PATs are 1163 another construct to which it can apply these strategies. 1165 In the context of federated authorization, more parties may be 1166 operating and using UMA software entities, and thus may need to 1167 establish agreements about mutual rights, responsibilities, and 1168 common interpretations of UMA constructs for consistent and expected 1169 software behavior, as discussed in Section 6.4 of [UMAGrant]. 1171 The authorization server comes to be in possession of resource 1172 details that may reveal information about the resource owner, which 1173 the authorization server's trust relationship with the resource 1174 server is assumed to accommodate. The more information about a 1175 resource that is registered, the more risk of privacy compromise 1176 there is through a less-trusted authorization server. For example, 1177 if resource owner Alice introduces her electronic health record 1178 resource server to an authorization server in the cloud, the 1179 authorization server may come to learn a great deal of detail about 1180 Alice's health information just so that she can control access by 1181 others to that information. 1183 9. IANA Considerations 1185 This document makes the following requests of IANA. 1187 9.1. OAuth 2.0 Authorization Server Metadata Registry 1189 This specification registers OAuth 2.0 authorization server metadata 1190 defined in Section 2, as required by Section 7.1 of [OAuthMeta]. 1192 9.1.1. Registry Contents 1194 o Metadata name: "permission_endpoint" 1196 o Metadata description: endpoint metadata 1198 o Change controller: Kantara Initiative User-Managed Access Work 1199 Group - staff@kantarainitiative.org 1201 o Specification document: Section 2 in this document 1203 o Metadata name: "resource_registration_endpoint" 1205 o Metadata description: endpoint metadata 1207 o Change controller: Kantara Initiative User-Managed Access Work 1208 Group - staff@kantarainitiative.org 1210 o Specification document: Section 2 in this document 1212 9.2. OAuth Token Introspection Response Registration 1214 This specification registers the name defined in Section 5.1.1, as 1215 required by Section 3.1 of [RFC7662]. 1217 9.2.1. Registry Contents 1219 o Name: "permissions" 1221 o Description: array of objects, each describing a scoped, time- 1222 limitable permission for a resource 1224 o Change controller: Kantara Initiative User-Managed Access Work 1225 Group - staff@kantarainitiative.org 1227 o Specification document: Section 5.1.1 in this document 1229 10. Acknowledgments 1231 The following people made significant text contributions to the 1232 specification: 1234 o Paul C. Bryan, ForgeRock US, Inc. (former editor) 1236 o Domenico Catalano, Oracle (former author) 1238 o Mark Dobrinic, Cozmanova 1240 o George Fletcher, AOL 1242 o Thomas Hardjono, MIT (former editor) 1244 o Andrew Hindle, Hindle Consulting Limited 1246 o Lukasz Moren, Cloud Identity Ltd 1248 o James Phillpotts, ForgeRock 1250 o Christian Scholz, COMlounge GmbH (former editor) 1252 o Mike Schwartz, Gluu 1254 o Cigdem Sengul, Nominet UK 1256 o Jacek Szpot, Newcastle University 1258 Additional contributors to this specification include the Kantara UMA 1259 Work Group participants, a list of whom can be found at 1260 [UMAnitarians]. 1262 11. References 1264 11.1. Normative References 1266 [BCP195] Sheffer, Y., "Recommendations for Secure Use of Transport 1267 Layer Security (TLS) and Datagram Transport Layer Security 1268 (DTLS)", May 2015, . 1270 [OAuthMeta] 1271 Jones, M., "OAuth 2.0 Authorization Server Metadata", 1272 November 2017, . 1275 [OIDCCore] 1276 Sakimura, N., "OpenID Connect Core 1.0 incorporating 1277 errata set 1", November 2014, 1278 . 1280 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1281 Requirement Levels", BCP 14, RFC 2119, 1282 DOI 10.17487/RFC2119, March 1997, 1283 . 1285 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1286 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1287 Transfer Protocol -- HTTP/1.1", RFC 2616, 1288 DOI 10.17487/RFC2616, June 1999, 1289 . 1291 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1292 Resource Identifier (URI): Generic Syntax", STD 66, 1293 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1294 . 1296 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 1297 Uniform Resource Identifiers (URIs)", RFC 5785, 1298 DOI 10.17487/RFC5785, April 2010, 1299 . 1301 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 1302 RFC 6749, DOI 10.17487/RFC6749, October 2012, 1303 . 1305 [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization 1306 Framework: Bearer Token Usage", RFC 6750, 1307 DOI 10.17487/RFC6750, October 2012, 1308 . 1310 [RFC6819] Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0 1311 Threat Model and Security Considerations", RFC 6819, 1312 DOI 10.17487/RFC6819, January 2013, 1313 . 1315 [RFC7009] Lodderstedt, T., Ed., Dronia, S., and M. Scurtescu, "OAuth 1316 2.0 Token Revocation", RFC 7009, DOI 10.17487/RFC7009, 1317 August 2013, . 1319 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 1320 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 1321 2014, . 1323 [RFC7591] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and 1324 P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol", 1325 RFC 7591, DOI 10.17487/RFC7591, July 2015, 1326 . 1328 [RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection", 1329 RFC 7662, DOI 10.17487/RFC7662, October 2015, 1330 . 1332 [UMAGrant] 1333 Maler, E., "User-Managed Access (UMA) Grant for OAuth 2.0 1334 Authorization", January 2019, 1335 . 1338 11.2. Informative References 1340 [UMA-Impl] 1341 Maler, E., "UMA Implementer's Guide", 2017, 1342 . 1345 [UMAnitarians] 1346 Maler, E., "UMA Participant Roster", 2017, 1347 . 1350 Authors' Addresses 1352 Eve Maler (editor) 1353 ForgeRock 1355 Email: eve.maler@forgerock.com 1357 Maciej Machulak 1358 HSBC 1360 Email: maciej.p.machulak@hsbc.com 1361 Justin Richer 1362 Bespoke Engineering 1364 Email: justin@bspk.io 1366 Thomas Hardjono 1367 MIT 1369 Email: hardjono@mit.edu