idnits 2.17.1 draft-ietf-oauth-rar-04.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 (7 February 2021) is 1166 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) == Outdated reference: A later version (-12) exists of draft-ietf-oauth-jwt-introspection-response-10 == Outdated reference: A later version (-34) exists of draft-ietf-oauth-jwsreq-30 == Outdated reference: A later version (-25) exists of draft-ietf-oauth-security-topics-16 == Outdated reference: A later version (-10) exists of draft-ietf-oauth-par-05 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Web Authorization Protocol T. Lodderstedt 3 Internet-Draft yes.com 4 Intended status: Standards Track J. Richer 5 Expires: 11 August 2021 Bespoke Engineering 6 B. Campbell 7 Ping Identity 8 7 February 2021 10 OAuth 2.0 Rich Authorization Requests 11 draft-ietf-oauth-rar-04 13 Abstract 15 This document specifies a new parameter "authorization_details" that 16 is used to carry fine grained authorization data in the OAuth 17 authorization request. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on 11 August 2021. 36 Copyright Notice 38 Copyright (c) 2021 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 43 license-info) in effect on the date of publication of this document. 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. Code Components 46 extracted from this document must include Simplified BSD License text 47 as described in Section 4.e of the Trust Legal Provisions and are 48 provided without warranty as described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1. Conventions and Terminology . . . . . . . . . . . . . . . 4 54 2. Request parameter "authorization_details" . . . . . . . . . . 4 55 2.1. Authorization data elements types . . . . . . . . . . . . 6 56 2.2. Authorization Data Types . . . . . . . . . . . . . . . . 10 57 3. Authorization Request . . . . . . . . . . . . . . . . . . . . 11 58 3.1. Relationship to "scope" parameter . . . . . . . . . . . . 12 59 3.2. Relationship to "resource" parameter . . . . . . . . . . 13 60 4. Authorization Response . . . . . . . . . . . . . . . . . . . 13 61 5. Authorization Error Response . . . . . . . . . . . . . . . . 13 62 6. Token Request . . . . . . . . . . . . . . . . . . . . . . . . 13 63 7. Token Response . . . . . . . . . . . . . . . . . . . . . . . 14 64 7.1. Enriched authorization details in Token Response . . . . 15 65 8. Resource Servers . . . . . . . . . . . . . . . . . . . . . . 18 66 8.1. JWT-based Access Tokens . . . . . . . . . . . . . . . . . 19 67 8.2. Token Introspection . . . . . . . . . . . . . . . . . . . 20 68 9. Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . 21 69 10. Scope value "openid" and "claims" parameter . . . . . . . . . 22 70 11. Implementation Considerations . . . . . . . . . . . . . . . . 22 71 11.1. Using authorization details in a certain deployment . . 22 72 11.2. Minimal product support . . . . . . . . . . . . . . . . 22 73 11.3. Large requests . . . . . . . . . . . . . . . . . . . . . 23 74 12. Security Considerations . . . . . . . . . . . . . . . . . . . 24 75 13. Privacy Considerations . . . . . . . . . . . . . . . . . . . 24 76 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 77 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 78 16. Normative References . . . . . . . . . . . . . . . . . . . . 26 79 17. Informative References . . . . . . . . . . . . . . . . . . . 26 80 Appendix A. Additional Examples . . . . . . . . . . . . . . . . 28 81 A.1. OpenID Connect . . . . . . . . . . . . . . . . . . . . . 28 82 A.2. Remote Electronic Signing . . . . . . . . . . . . . . . . 29 83 A.3. Access to Tax Data . . . . . . . . . . . . . . . . . . . 30 84 A.4. eHealth . . . . . . . . . . . . . . . . . . . . . . . . . 31 85 Appendix B. Document History . . . . . . . . . . . . . . . . . . 34 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 88 1. Introduction 90 The OAuth 2.0 authorization framework [RFC6749] defines the parameter 91 "scope" that allows OAuth clients to specify the requested scope, 92 i.e., the permission, of an access token. This mechanism is 93 sufficient to implement static scenarios and coarse-grained 94 authorization requests, such as "give me read access to the resource 95 owner's profile" but it is not sufficient to specify fine-grained 96 authorization requirements, such as "please let me make a payment 97 with the amount of 45 Euros" or "please give me read access to folder 98 A and write access to file X". 100 This draft introduces a new parameter "authorization_details" that 101 allows clients to specify their fine-grained authorization 102 requirements using the expressiveness of JSON data structures. 104 For example, a request for payment authorization can be represented 105 using a JSON object like this: 107 { 108 "type": "payment_initiation", 109 "locations": [ 110 "https://example.com/payments" 111 ], 112 "instructedAmount": { 113 "currency": "EUR", 114 "amount": "123.50" 115 }, 116 "creditorName": "Merchant123", 117 "creditorAccount": { 118 "iban": "DE02100100109307118603" 119 }, 120 "remittanceInformationUnstructured": "Ref Number Merchant" 121 } 123 This object contains detailed information about the intended payment, 124 such as amount, currency, and creditor, that are required to inform 125 the user and obtain her consent. The AS and the respective RS 126 (providing the payment initiation API) will together enforce this 127 consent. 129 For a comprehensive discussion of the challenges arising from new use 130 cases in the open banking and electronic signing spaces see 131 [transaction-authorization]. 133 In addition to facilitating custom authorization requests, this draft 134 also introduces a set of common data type fields for use across 135 different APIs. 137 Most notably, the field "locations" allows a client to specify where 138 it intends to use a certain authorization, i.e., it is now possible 139 to unambiguously assign permissions to resource servers. In 140 situations with multiple resource servers, this prevents unintended 141 client authorizations (e.g. a "read" scope value potentially 142 applicable for an email as well as a cloud service). In combination 143 with the "resource" token request parameter as specified in [RFC8707] 144 it enables the AS to mint RS-specific structured access tokens that 145 only contain the permissions applicable to the respective RS. 147 1.1. Conventions and Terminology 149 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 150 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 151 "OPTIONAL" in this document are to be interpreted as described in BCP 152 14 [RFC2119] [RFC8174] when, and only when, they appear in all 153 capitals, as shown here. 155 This specification uses the terms "access token", "refresh token", 156 "authorization server", "resource server", "authorization endpoint", 157 "authorization request", "authorization response", "token endpoint", 158 "grant type", "access token request", "access token response", and 159 "client" defined by The OAuth 2.0 Authorization Framework [RFC6749]. 161 2. Request parameter "authorization_details" 163 The request parameter "authorization_details" contains, in JSON 164 notation, an array of objects. Each JSON object contains the data to 165 specify the authorization requirements for a certain type of 166 resource. The type of resource or access requirement is determined 167 by the "type" field. 169 This example shows the specification of authorization details using 170 the payment authorization object shown above: 172 [ 173 { 174 "type": "payment_initiation", 175 "actions": [ 176 "initiate", 177 "status", 178 "cancel" 179 ], 180 "locations": [ 181 "https://example.com/payments" 182 ], 183 "instructedAmount": { 184 "currency": "EUR", 185 "amount": "123.50" 186 }, 187 "creditorName": "Merchant123", 188 "creditorAccount": { 189 "iban": "DE02100100109307118603" 190 }, 191 "remittanceInformationUnstructured": "Ref Number Merchant" 192 } 193 ] 195 This example shows a combined request asking for access to account 196 information and permission to initiate a payment: 198 [ 199 { 200 "type": "account_information", 201 "actions": [ 202 "list_accounts", 203 "read_balances", 204 "read_transactions" 205 ], 206 "locations": [ 207 "https://example.com/accounts" 208 ] 209 }, 210 { 211 "type": "payment_initiation", 212 "actions": [ 213 "initiate", 214 "status", 215 "cancel" 216 ], 217 "locations": [ 218 "https://example.com/payments" 219 ], 220 "instructedAmount": { 221 "currency": "EUR", 222 "amount": "123.50" 223 }, 224 "creditorName": "Merchant123", 225 "creditorAccount": { 226 "iban": "DE02100100109307118603" 227 }, 228 "remittanceInformationUnstructured": "Ref Number Merchant" 229 } 230 ] 232 The JSON objects with "type" fields of "account_information" and 233 "payment_initiation" represent the different authorization data to be 234 used by the AS to ask for consent and MUST subsequently also be made 235 available to the respective resource servers. The array MAY contain 236 several elements of the same "type". 238 2.1. Authorization data elements types 240 The allowable contents of the authorization details object are 241 determined by the "type" parameter. 243 "type": The type of authorization data as a string. This field MAY 244 define which other elements are allowed in the request. This 245 element is REQUIRED. 247 This field MUST be compared using an exact byte match of the string 248 value against known types by the AS. The AS MUST ensure that there 249 is no collision between different authorization data types that it 250 supports. The AS MUST NOT do any collation or normalization of data 251 types during comparison. 253 This draft defines a set of common data elements that are designed to 254 be usable across different types of APIs. These data elements MAY be 255 combined in different ways depending on the needs of the API. All 256 data elements are OPTIONAL. 258 "locations": An array of strings representing the location of the 259 resource or resource server. This is typically composed of URIs. 261 "actions": An array of strings representing the kinds of actions to 262 be taken at the resource. The values of the strings are 263 determined by the API being protected. 265 "datatypes": An array of strings representing the kinds of data 266 being requested from the resource. 268 "identifier": A string identifier indicating a specific resource 269 available at the API. 271 When different element types are used in combination, the permissions 272 the client requests is the cartesian product of the values. That is 273 to say, the object represents a request for all "action" values 274 listed within the object to be used at all "locations" values listed 275 within the object for all "datatype" values listed within the object. 276 In the following example, the client is requesting "read" and "write" 277 access to both the "contacts" and "photos" belonging to customers in 278 a "customer_information" API. If this request is granted, the client 279 would assume it would be able to use any combination of rights 280 defined by the API, such as reading the photos and writing the 281 contacts. 283 [ 284 { 285 "type": "customer_information", 286 "locations": [ 287 "https://example.com/customers", 288 ] 289 "actions": [ 290 "read", 291 "write" 292 ], 293 "datatypes": [ 294 "contacts", 295 "photos" 296 ] 297 } 298 ] 300 If the client wishes to have finer control over its access, it can 301 send multiple objects. In this example, the client is asking for 302 "read" access to the "contacts" and "write" access to the "photos" in 303 the same API endpoint. If this request is granted, the client would 304 not be able to write to the contacts. 306 [ 307 { 308 "type": "customer_information", 309 "locations": [ 310 "https://example.com/customers" 311 ], 312 "actions": [ 313 "read" 314 ], 315 "datatypes": [ 316 "contacts" 317 ] 318 }, 319 { 320 "type": "customer_information", 321 "locations": [ 322 "https://example.com/customers" 323 ], 324 "actions": [ 325 "write" 326 ], 327 "datatypes": [ 328 "photos" 329 ] 330 } 331 ] 333 An API MAY define its own extensions, subject to the "type" of the 334 respective authorization object. It is anticipated that API 335 designers will use a combination of common fields defined in this 336 specification as well as fields specific to the API itself. The 337 following non-normative example shows the use of both common and API- 338 specific fields as part of two different fictitious API "type" 339 values. The first access request includes the "actions", 340 "locations", and "datatypes" fields specified here as well as the 341 API-specific "geolocation" field. The second access request includes 342 the "actions" and "identifier" fields specified here as well as the 343 API-specific "currency" field. 345 "resources": [ 346 { 347 "type": "photo-api", 348 "actions": [ 349 "read", 350 "write" 351 ], 352 "locations": [ 353 "https://server.example.net/", 354 "https://resource.local/other" 355 ], 356 "datatypes": [ 357 "metadata", 358 "images" 359 ], 360 "geolocation": [ 361 { lat: -32.364, lng: 153.207 }, 362 { lat: -35.364, lng: 158.207 } 363 ] 364 }, 365 { 366 "type": "financial-transaction", 367 "actions": [ 368 "withdraw" 369 ], 370 "identifier": "account-14-32-32-3", 371 "currency": "USD" 372 } 373 ] 375 If this request is approved, the resulting access token's access 376 rights will be the union of the requested types of access for each of 377 the two APIs, just as above. 379 2.2. Authorization Data Types 381 Interpretation of the value of the "type" parameter, and the object 382 elements that the "type" parameter allows, is under the control of 383 the AS. However, the value of the "type" parameter is also generally 384 documented and intended to be used by developers, it is RECOMMENDED 385 that API designers choose "type" values that are easily copied 386 without ambiguity. For example, some glyphs have multiple unicode 387 code points for the same visual character, and a developer could 388 potentially type a different character depending than what the AS has 389 defined. Possible means of reducing potential confusion are limiting 390 the value to ASCII characters, providing a machine-readable listing 391 of data type values, or instructing developers to copy and paste 392 directly from documentation. 394 If an application or API is expected to be deployed across different 395 servers, such as the case in an open standard, the API designer is 396 RECOMMENDED to use a collision-resistant namespace under their 397 control, such as a URI that the API designer controls. 399 The following example shows how an implementation could utilize the 400 namespace "https://scheme.example.org/" to ensure collision resistant 401 element names. 403 { 404 "type": "https://scheme.example.org/files", 405 "locations": [ 406 "https://example.com/files" 407 ], 408 "permissions": [ 409 { 410 "path": "/myfiles/A", 411 "access": [ 412 "read" 413 ] 414 }, 415 { 416 "path": "/myfiles/A/X", 417 "access": [ 418 "read", 419 "write" 420 ] 421 } 422 ] 423 } 425 3. Authorization Request 427 The "authorization_details" request parameter can be used to specify 428 authorization requirements in all places where the "scope" parameter 429 is used for the same purpose, examples include: 431 * Authorization requests as specified in [RFC6749], 433 * Access token requests as specified in [RFC6749], if also used as 434 authorization requests, e.g. in the case of assertion grant types 435 [RFC7521], 437 * Request objects as specified in [I-D.ietf-oauth-jwsreq], 439 * Device Authorization Request as specified in [RFC8628], 441 * Backchannel Authentication Requests as defined in [OpenID.CIBA]. 443 Parameter encoding is determined by the respective context. In the 444 context of an authorization request according to [RFC6749], the 445 parameter is encoded using the "application/x-www-form-urlencoded" 446 format of the serialized JSON as shown in the following using the 447 example from Section 2 (line breaks for display purposes only): 449 GET /authorize?response_type=code 450 &client_id=s6BhdRkqt3 451 &state=af0ifjsldkj 452 &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb 453 &code_challenge_method=S256 454 &code_challenge=K2-ltc83acc4h0c9w6ESC_rEMTJ3bwc-uCHaoeK1t8U 455 &authorization_details=%5B%7B%22type%22%3A%22account%5Finfo 456 rmation%22%2C%22actions%22%3A%5B%22list%5Faccounts%22%2C%22 457 read%5Fbalances%22%2C%22read%5Ftransactions%22%5D%2C%22loca 458 tions%22%3A%5B%22https%3A%2F%2Fexample%2Ecom%2Faccounts%22% 459 5D%7D%2C%7B%22type%22%3A%22payment%5Finitiation%22%2C%22act 460 ions%22%3A%5B%22initiate%22%2C%22status%22%2C%22cancel%22%5 461 D%2C%22locations%22%3A%5B%22https%3A%2F%2Fexample%2Ecom%2Fp 462 ayments%22%5D%2C%22instructedAmount%22%3A%7B%22currency%22% 463 3A%22EUR%22%2C%22amount%22%3A%22123%2E50%22%7D%2C%22credito 464 rName%22%3A%22Merchant123%22%2C%22creditorAccount%22%3A%7B% 465 22iban%22%3A%22DE02100100109307118603%22%7D%2C%22remittance 466 InformationUnstructured%22%3A%22RefNumberMerchant%22%7D%5D HTTP/1.1 467 Host: server.example.com 469 Based on the data provided in the "authorization_details" parameter 470 the AS will ask the user for consent to the requested access 471 permissions. 473 3.1. Relationship to "scope" parameter 475 "authorization_details" and "scope" can be used in the same 476 authorization request for carrying independent authorization 477 requirements. 479 The AS MUST consider both sets of requirements in combination with 480 each other for the given authorization request. The details of how 481 the AS combines these parameters are specific to the APIs being 482 protected and outside the scope of this specification. 484 It is RECOMMENDED that a given API uses only one form of requirement 485 specification. 487 When gathering user consent, the AS MUST present the merged set of 488 requirements represented by the authorization request. 490 If the resource owner grants the client the requested access, the AS 491 will issue tokens to the client that are associated with the 492 respective "authorization_details" (and scope values, if applicable). 494 3.2. Relationship to "resource" parameter 496 The "resource" authorization request parameter as defined in 497 [RFC8707] can be used to further determine the resources where the 498 requested scope can be applied. The "resource" parameter does not 499 have any impact on the way the AS processes the 500 "authorization_details" parameter. 502 4. Authorization Response 504 This specification does not define extensions to the authorization 505 response. 507 5. Authorization Error Response 509 The AS MUST refuse to process any unknown authorization data type or 510 authorization details not conforming to the respective type 511 definition. If any of the objects in "authorization_details" 512 contains an unknown authorization data type or an object of known 513 type but containing unknown elements or elements of the wrong type, 514 the AS MUST abort processing and respond with an error 515 "invalid_authorization_details" to the client. 517 6. Token Request 519 The "resource" token request parameter as defined in [RFC8707] MAY be 520 used in the token request to request the creation of an audience 521 restricted access token (as recommended in 522 [I-D.ietf-oauth-security-topics]). If the client uses this 523 parameter, the AS MUST consider the audience restriction defined by 524 the "locations" elements of the "authorization_details" to filter the 525 authorization data objects applicable to the respective resource(s). 527 The logic is as follows: 529 * For every authorization details object without a "locations" 530 element: the authorization server treats it as applicable to all 531 resources, i.e. it assigns this authorization details object to 532 the access token. 534 * For every authorization details object with a "locations" element: 535 the authorization server adds this object to the access token, if 536 at least one of the "locations" values exactly matches the 537 "resource" token request parameter value. The authorization 538 server MUST compare both values using an exact byte match of the 539 string values. 541 For example the following token request selects authorization details 542 applicable for the resource server represented by the URI 543 "https://example.com/payments". 545 POST /token HTTP/1.1 546 Host: as.example.com 547 Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW 548 Content-Type: application/x-www-form-urlencoded 550 grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA 551 &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb 552 &resource=https%3A%2F%2Fexample%2Ecom%2Fpayments 554 Using the example given above, this request would result in the 555 assignment of the "payment_initiation" authorization details object 556 from (#authz_details) to the access token to be issued (see below). 558 7. Token Response 560 In addition to the token response parameters as defined in [RFC6749], 561 the authorization server MUST also return the authorization details 562 as granted by the resource owner and assigned to the respective 563 access token. 565 For our running example, this would look like this: 567 HTTP/1.1 200 OK 568 Content-Type: application/json 569 Cache-Control: no-cache, no-store 571 { 572 "access_token": "2YotnFZFEjr1zCsicMWpAA", 573 "token_type": "example", 574 "expires_in": 3600, 575 "refresh_token": "tGzv3JOkF0XG5Qx2TlKWIA", 576 "authorization_details": [ 577 { 578 "type": "https://www.someorg.com/payment_initiation", 579 "actions": [ 580 "initiate", 581 "status", 582 "cancel" 583 ], 584 "locations": [ 585 "https://example.com/payments" 586 ], 587 "instructedAmount": { 588 "currency": "EUR", 589 "amount": "123.50" 590 }, 591 "creditorName": "Merchant123", 592 "creditorAccount": { 593 "iban": "DE02100100109307118603" 594 }, 595 "remittanceInformationUnstructured": "Ref Number Merchant" 596 } 597 ] 598 } 600 7.1. Enriched authorization details in Token Response 602 The authorization details attached to the access token MAY differ 603 from what the client requests. In addition to the user authorizing 604 less than what the client requested, there are use cases where the 605 authorization server enriches the data in an authorization details 606 object. For example, a client may ask for access to account 607 information but leave the decision about the accounts it will be able 608 to access to the user. The user would select the sub set of accounts 609 they wants the client to entitle to access in the course of the 610 authorization process. In order to allow the client to determine the 611 accounts it is entitled to access, the authorization server will add 612 this information to the respective authorization details object. 614 As an example, the requested authorization detail parameter could 615 look like this: 617 "authorization_details": [ 618 { 619 "type": "account_information", 620 "access": { 621 "accounts": [], 622 "balances": [], 623 "transactions": [] 624 }, 625 "recurringIndicator":true 626 } 627 ] 629 The authorization server then would expand the authorization details 630 object and add the respective account identifiers. 632 HTTP/1.1 200 OK 633 Content-Type: application/json 634 Cache-Control: no-cache, no-store 636 { 637 "access_token":"2YotnFZFEjr1zCsicMWpAA", 638 "token_type":"example", 639 "expires_in":3600, 640 "refresh_token":"tGzv3JokF0XG5Qx2TlKWIA", 641 "authorization_details":[ 642 { 643 "type":"account_information", 644 "access":{ 645 "accounts":[ 646 { 647 "iban":"DE2310010010123456789" 648 }, 649 { 650 "maskedPan":"123456xxxxxx1234" 651 } 652 ], 653 "balances":[ 654 { 655 "iban":"DE2310010010123456789" 656 } 657 ], 658 "transactions":[ 659 { 660 "iban":"DE2310010010123456789" 661 }, 662 { 663 "maskedPan":"123456xxxxxx1234" 664 } 665 ] 666 }, 667 "recurringIndicator":true 668 } 669 ] 670 } 672 For another example, the client is asking for access to a medical 673 record but does not know the record number at request time. In this 674 example, the client specifies the type of access it wants but doesn't 675 specify the location or identifier of that access. 677 { 678 "authorization_details": [ 679 { 680 "type": "medical_record", 681 "sens": [ "HIV", "ETH", "MART" ], 682 "actions": [ "read" ], 683 "datatypes": [ "Patient", "Observation", "Appointment" ] 684 } 685 ] 687 When the user interacts with the AS, they select which of the medical 688 records they are responsible for to give to the client. This 689 information gets returned with the access token. 691 { 692 "access_token":"2YotnFZFEjr1zCsicMWpAA", 693 "token_type":"example", 694 "expires_in":3600, 695 "refresh_token":"tGzv3JokF0XG5Qx2TlKWIA", 696 "authorization_details":[ 697 { 698 "type": "medical_record", 699 "sens": [ "HIV", "ETH", "MART" ], 700 "actions": [ "read" ], 701 "datatypes": [ "Patient", "Observation", "Appointment" ] 702 "identifier": "patient-541235", 703 "locations": [ "https://records.example.com/" ] 704 } 705 ] 706 } 708 Note: the client needs to be aware upfront of the possibility that a 709 certain authorization details object can be enriched. It is assumned 710 that this property is part of the definition of the respective 711 authorization details type. 713 8. Resource Servers 715 In order to enable the RS to enforce the authorization details as 716 approved in the authorization process, the AS MUST make this data 717 available to the RS. The AS MAY add the "authorization_details" 718 element to access tokens in JWT format or to Token Introspection 719 responses. 721 8.1. JWT-based Access Tokens 723 If the access token is a JWT [RFC7519], the AS is RECOMMENDED to add 724 the "authorization_details" object, filtered to the specific 725 audience, as top-level claim. 727 The AS will typically also add further claims to the JWT the RS 728 requires for request processing, e.g., user id, roles, and 729 transaction specific data. What claims the particular RS requires is 730 defined by the RS-specific policy with the AS. 732 The following shows the contents of an example JWT for the payment 733 initation example above: 735 { 736 "iss": "https://as.example.com", 737 "sub": "24400320", 738 "aud": "a7AfcPcsl2", 739 "exp": 1311281970, 740 "acr": "psd2_sca", 741 "txn": "8b4729cc-32e4-4370-8cf0-5796154d1296", 742 "authorization_details": [ 743 { 744 "type": "https://www.someorg.com/payment_initiation", 745 "actions": [ 746 "initiate", 747 "status", 748 "cancel" 749 ], 750 "locations": [ 751 "https://example.com/payments" 752 ], 753 "instructedAmount": { 754 "currency": "EUR", 755 "amount": "123.50" 756 }, 757 "creditorName": "Merchant123", 758 "creditorAccount": { 759 "iban": "DE02100100109307118603" 760 }, 761 "remittanceInformationUnstructured": "Ref Number Merchant" 762 } 763 ], 764 "debtorAccount": { 765 "iban": "DE40100100103307118608", 766 "user_role": "owner" 767 } 768 } 769 In this case, the AS added the following example claims: 771 * "sub": conveys the user on which behalf the client is asking for 772 payment initation 774 * "txn": transaction id used to trace the transaction across the 775 services of provider "example.com" 777 * "debtorAccount": API-specific element containing the debtor 778 account. In the example, this account was not passed in the 779 authorization details but selected by the user during the 780 authorization process. The field "user_role" conveys the role the 781 user has with respect to this particuar account. In this case, 782 they is the owner. This data is used for access control at the 783 payment API (the RS). 785 8.2. Token Introspection 787 In case of opaque access tokens, the data provided to a certain RS is 788 determined using the RS's identifier with the AS (see 789 [I-D.ietf-oauth-jwt-introspection-response], section 3). 791 The token endpoint response provides the RS with the authorization 792 details applicable to it as a top-level JSON element along with the 793 claims the RS requires for request processing. 795 Here is an example for the payment initation example RS: 797 { 798 "active": true, 799 "sub": "24400320", 800 "aud": "s6BhdRkqt3", 801 "exp": 1311281970, 802 "acr": "psd2_sca", 803 "txn": "8b4729cc-32e4-4370-8cf0-5796154d1296", 804 "authorization_details": [ 805 { 806 "type": "https://www.someorg.com/payment_initiation", 807 "actions": [ 808 "initiate", 809 "status", 810 "cancel" 811 ], 812 "locations": [ 813 "https://example.com/payments" 814 ], 815 "instructedAmount": { 816 "currency": "EUR", 817 "amount": "123.50" 818 }, 819 "creditorName": "Merchant123", 820 "creditorAccount": { 821 "iban": "DE02100100109307118603" 822 }, 823 "remittanceInformationUnstructured": "Ref Number Merchant" 824 } 825 ], 826 "debtorAccount": { 827 "iban": "DE40100100103307118608", 828 "user_role": "owner" 829 } 830 } 832 9. Metadata 834 The AS advertises support for "authorization_details" using the 835 metadata parameter "authorization_details_supported" of type boolean. 837 The authorization data types supported can be determined using the 838 metadata parameter "authorization_data_types_supported", which is an 839 JSON array. 841 Clients announce the authorization data types they use in the new 842 dynamic client registration parameter "authorization_data_types". 844 The registration of new authorization data types with the AS is out 845 of scope of this draft. 847 10. Scope value "openid" and "claims" parameter 849 OpenID Connect [OIDC] specifies the JSON-based "claims" request 850 parameter that can be used to specify the claims a client (acting as 851 OpenID Connect Relying Party) wishes to receive in a fine-grained and 852 privacy preserving way as well as assign those claims to a certain 853 delivery mechanisms, i.e. ID Token or userinfo response. 855 The combination of the scope value "openid" and the additional 856 parameter "claims" can be used beside "authorization_details" in the 857 same way as every non-OIDC scope value. 859 Alternatively, there could be an authorization data type for OpenID 860 Connect. Appendix A.1 gives an example of what such an authorization 861 data type could look like. 863 11. Implementation Considerations 865 11.1. Using authorization details in a certain deployment 867 Using authorization details in a certain deployment will require the 868 follwowing steps: 870 * Define authorization details types (might include definition and 871 publication of JSON schemas) 873 * Publish authorization details types in the OAuth server metadata 875 * Determine how authorization details are shown to the user in the 876 user consent 878 * (if needed) Enrich authorization details in the user consent 879 process (e.g. add selected accounts or set expirations) 881 * (if needed) Determine how authorization details are reflected in 882 access token content or introspection responses 884 * Determine how the resource server(s) process(s) the authorization 885 details or token data derived from authorization details 887 11.2. Minimal product support 889 Products supporting this specification should provide the following 890 basic functions: 892 * Support advertisement of supported authorization details types in 893 OAuth server metadata 895 * Accept "authorization_details" parameter in authorization requests 896 including basic syntax check for compliance with this 897 specification 899 * Support storage of consented authorization_details as part of a 900 grant 902 * Implement default behavior for adding authorization details to 903 access tokens and token introspection responses in order to make 904 them available to resource servers (similar to scope values). 905 This should work with any grant type, espceially 906 "authorization_code" and "refresh_token". 908 * If the product supports resource indicators, it should also 909 support filtering of the authorization details to be assigned to 910 access tokens using the "resource" token request parameter. 912 Processing and presentation of authorization details will vary 913 significantly among different authorization data types. Products 914 should therefore support customization of the respective behavior. 915 In particular products should 917 * allow deployments to determine presentation of the 918 authorization_details 920 * allow deployments to modify requested authorization_details in the 921 user consent process, e.g. adding fields 923 * allow deployments to merge requested and pre-existing 924 authorization_details 926 One option would be to have a mechanism allowing the registration of 927 extension modules, each of them responsible for rendering the 928 respective user consent and any transformation needed to provide the 929 data needed to the resource server by way of structured access tokens 930 or token introspection responses. 932 11.3. Large requests 934 Authorization request URIs containing authorization details in a 935 request parameter or a request object can become very long. 936 Implementers SHOULD therefore consider using the "request_uri" 937 parameter as defined in [I-D.ietf-oauth-jwsreq] in combination with 938 the pushed request object mechanism as defined in 939 [I-D.ietf-oauth-par] to pass authorization details in a reliable and 940 secure manner. Here is an example of such a pushed authorization 941 request that sends the authorization request data directly to the AS 942 via a HTTPS-protected connection: 944 POST /as/par HTTP/1.1 945 Host: as.example.com 946 Content-Type: application/x-www-form-urlencoded 947 Authorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3 949 response_type=code& 950 client_id=s6BhdRkqt3 951 &state=af0ifjsldkj 952 &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb 953 &code_challenge_method=S256 954 &code_challenge=K2-ltc83acc4h0c9w6ESC_rEMTJ3bwc-uCHaoeK1t8U 955 &authorization_details=%5B%7B%22type%22%3A%22account_information%22 956 %2C%22actions%22%3A%5B%22list_accounts%22%2C%22read_balances%22%2C% 957 22read_transactions%22%5D%2C%22locations%22%3A%5B%22https%3A%2F%2Fe 958 xample.com%2Faccounts%22%5D%7D%2C%7B%22type%22%3A%22payment_initiat 959 ion%22%2C%22actions%22%3A%5B%22initiate%22%2C%22status%22%2C%22canc 960 el%22%5D%2C%22locations%22%3A%5B%22https%3A%2F%2Fexample.com%2Fpaym 961 ents%22%5D%2C%22instructedAmount%22%3A%7B%22currency%22%3A%22EUR%22 962 %2C%22amount%22%3A%22123.50%22%7D%2C%22creditorName%22%3A%22Merchan 963 t123%22%2C%22creditorAccount%22%3A%7B%22iban%22%3A%22DE021001001093 964 07118603%22%7D%2C%22remittanceInformationUnstructured%22%3A%22Ref%2 965 0Number%20Merchant%22%7D%5D 967 12. Security Considerations 969 Authorization details are sent through the user agent in case of an 970 OAuth authorization request, which makes them vulnerable to 971 modifications by the user. In order to ensure their integrity, the 972 client SHOULD send authorization details in a signed request object 973 as defined in [I-D.ietf-oauth-jwsreq] or use the "request_uri" 974 authorization request parameter as defined in [I-D.ietf-oauth-jwsreq] 975 to pass the URI of the request object to the authorization server. 977 All strings MUST be compared using the exact byte representation of 978 the characters as defined by [RFC8259]. This is especially true for 979 the "type" field, which dictates which other fields and functions are 980 allowed in the request. The server MUST NOT perform any form of 981 collation, transformation, or equivalence on the string values. 983 13. Privacy Considerations 985 Implementers MUST design and use authorization details in a privacy 986 preserving manner. 988 Any sensitive personal data included in authorization details MUST be 989 prevented from leaking, e.g., through referrer headers. 990 Implementation options include encrypted request objects as defined 991 in [I-D.ietf-oauth-jwsreq] or transmission of authorization details 992 via end-to-end encrypted connections between client and authorization 993 server by utilizing the "request_uri" authorization request parameter 994 as defined in [I-D.ietf-oauth-jwsreq]. 996 Even if the request data is encrypted, an attacker could use the 997 authorization server to learn the user data by injecting the 998 encrypted request data into an authorization request on a device 999 under his control and use the authorization server's user consent 1000 screens to show the (decrypted) user data in the clear. 1001 Implementations MUST consider this attacker vector and implement 1002 appropriate counter measures, e.g. by only showing portions of the 1003 data or, if possible, determing whether the assumed user context is 1004 still the same (after user authentication). 1006 The AS MUST take into consideration the privacy implications when 1007 sharing authorization details with the resource servers. The AS 1008 SHOULD share this data with the resource servers on a "need to know" 1009 basis. 1011 14. Acknowledgements 1013 We would would like to thank Daniel Fett, Sebastian Ebling, Dave 1014 Tonge, Mike Jones, Nat Sakimura, and Rob Otto for their valuable 1015 feedback during the preparation of this draft. 1017 We would also like to thank Vladimir Dzhuvinov, Takahiko Kawasaki, 1018 Daniel Fett, Dave Tonge, Travis Spencer, Jørgen Binningsbø, 1019 Aamund Bremer, Steinar Noem, and Aaron Parecki for their valuable 1020 feedback to this draft. 1022 15. IANA Considerations 1024 TBD 1026 * "authorization_details" as JWT claim 1028 * "authorization_details_supported" and 1029 "authorization_data_types_supported" as metadata parameters 1031 * "authorization_data_types" as dynamic client registration 1032 parameter 1034 * [[ possibly establish authorization data type registry (and 1035 declare: "type", "actions", "locations", "datatypes", 1036 "identifier", others?) ]] 1038 * [[ register type "openid_claims" on a URL by the OpenID 1039 foundation? ]] 1041 * register invalid_authorization_details to OAuth Extensions Error 1042 Registry 1044 16. Normative References 1046 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 1047 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 1048 . 1050 [RFC8707] Campbell, B., Bradley, J., and H. Tschofenig, "Resource 1051 Indicators for OAuth 2.0", RFC 8707, DOI 10.17487/RFC8707, 1052 February 2020, . 1054 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1055 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1056 May 2017, . 1058 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 1059 RFC 6749, DOI 10.17487/RFC6749, October 2012, 1060 . 1062 [RFC7521] Campbell, B., Mortimore, C., Jones, M., and Y. Goland, 1063 "Assertion Framework for OAuth 2.0 Client Authentication 1064 and Authorization Grants", RFC 7521, DOI 10.17487/RFC7521, 1065 May 2015, . 1067 [RFC8628] Denniss, W., Bradley, J., Jones, M., and H. Tschofenig, 1068 "OAuth 2.0 Device Authorization Grant", RFC 8628, 1069 DOI 10.17487/RFC8628, August 2019, 1070 . 1072 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1073 Requirement Levels", BCP 14, RFC 2119, 1074 DOI 10.17487/RFC2119, March 1997, 1075 . 1077 17. Informative References 1079 [I-D.ietf-oauth-jwt-introspection-response] 1080 Lodderstedt, T. and V. Dzhuvinov, "JWT Response for OAuth 1081 Token Introspection", Work in Progress, Internet-Draft, 1082 draft-ietf-oauth-jwt-introspection-response-10, 18 October 1083 2020, . 1086 [OIDC] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and 1087 C. Mortimore, "OpenID Connect Core 1.0 incorporating 1088 errata set 1", 8 November 2014, 1089 . 1091 [ETSI] ETSI, "ETSI TS 119 432, Electronic Signatures and 1092 Infrastructures (ESI); Protocols for remote digital 1093 signature creation", 20 March 2019, 1094 . 1098 [OpenID.CIBA] 1099 Fernandez, G., Walter, F., Nennker, A., Tonge, D., and B. 1100 Campbell, "OpenID Connect Client Initiated Backchannel 1101 Authentication Flow - Core 1.0", 16 January 2019, 1102 . 1105 [I-D.ietf-oauth-jwsreq] 1106 Sakimura, N., Bradley, J., and M. Jones, "The OAuth 2.0 1107 Authorization Framework: JWT Secured Authorization Request 1108 (JAR)", Work in Progress, Internet-Draft, draft-ietf- 1109 oauth-jwsreq-30, 10 September 2020, 1110 . 1112 [I-D.ietf-oauth-security-topics] 1113 Lodderstedt, T., Bradley, J., Labunets, A., and D. Fett, 1114 "OAuth 2.0 Security Best Current Practice", Work in 1115 Progress, Internet-Draft, draft-ietf-oauth-security- 1116 topics-16, 5 October 2020, . 1119 [I-D.ietf-oauth-par] 1120 Lodderstedt, T., Campbell, B., Sakimura, N., Tonge, D., 1121 and F. Skokan, "OAuth 2.0 Pushed Authorization Requests", 1122 Work in Progress, Internet-Draft, draft-ietf-oauth-par-05, 1123 14 December 2020, 1124 . 1126 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 1127 Interchange Format", STD 90, RFC 8259, 1128 DOI 10.17487/RFC8259, December 2017, 1129 . 1131 [CSC] Consortium, C. S., "Architectures and protocols for remote 1132 signature applications", 1 June 2019, 1133 . 1136 [transaction-authorization] 1137 Lodderstedt, T., "Transaction Authorization or why we need 1138 to re-think OAuth scopes", 20 April 2019, 1139 . 1142 Appendix A. Additional Examples 1144 A.1. OpenID Connect 1146 These hypothetical examples try to encapsulate all details specific 1147 to the OpenID Connect part of an authorization process into an 1148 authorization JSON object. 1150 The top-level elements are based on the definitions given in [OIDC]: 1152 * "claim_sets": names of predefined claim sets, replacement for 1153 respective scope values, such as "profile" 1155 * "max_age": Maximum Authentication Age 1157 * "acr_values": array of ACR values 1159 * "claims": the "claims" JSON structure as defined in [OIDC] 1161 This is a simple request for some claim sets. 1163 [ 1164 { 1165 "type": "openid", 1166 "locations": [ 1167 "https://op.example.com/userinfo" 1168 ], 1169 "claim_sets": [ 1170 "email", 1171 "profile" 1172 ] 1173 } 1174 ] 1176 Note: "locations" specifies the location of the userinfo endpoint 1177 since this is the only place where an access token is used by a 1178 client (RP) in OpenID Connect to obtain claims. 1180 A more sophisticated example is shown in the following 1182 [ 1183 { 1184 "type": "openid", 1185 "locations": [ 1186 "https://op.example.com/userinfo" 1187 ], 1188 "max_age": 86400, 1189 "acr_values": "urn:mace:incommon:iap:silver", 1190 "claims": { 1191 "userinfo": { 1192 "given_name": { 1193 "essential": true 1194 }, 1195 "nickname": null, 1196 "email": { 1197 "essential": true 1198 }, 1199 "email_verified": { 1200 "essential": true 1201 }, 1202 "picture": null, 1203 "http://example.info/claims/groups": null 1204 }, 1205 "id_token": { 1206 "auth_time": { 1207 "essential": true 1208 } 1209 } 1210 } 1211 } 1212 ] 1214 A.2. Remote Electronic Signing 1216 The following example is based on the concept layed out for remote 1217 electronic signing in ETSI TS 119 432 [ETSI] and the CSC API for 1218 remote signature creation [CSC]. 1220 [ 1221 { 1222 "type": "sign", 1223 "locations": [ 1224 "https://signing.example.com/signdoc" 1225 ], 1226 "credentialID": "60916d31-932e-4820-ba82-1fcead1c9ea3", 1227 "documentDigests": [ 1228 { 1229 "hash": "sTOgwOm+474gFj0q0x1iSNspKqbcse4IeiqlDg/HWuI=", 1230 "label": "Credit Contract" 1231 }, 1232 { 1233 "hash": "HZQzZmMAIWekfGH0/ZKW1nsdt0xg3H6bZYztgsMTLw0=", 1234 "label": "Contract Payment Protection Insurance" 1235 } 1236 ], 1237 "hashAlgorithmOID": "2.16.840.1.101.3.4.2.1" 1238 } 1239 ] 1241 The top-level elements have the following meaning: 1243 * "credentialID": identifier of the certificate to be used for 1244 signing 1246 * "documentDigests": array containing the hash of every document to 1247 be signed ("hash" elements). Additionally, the corresponding 1248 "label" element identifies the respective document to the user, 1249 e.g. to be used in user consent. 1251 * "hashAlgorithm": algomrithm that was used to calculate the hash 1252 values. 1254 The AS is supposed to ask the user for consent for the creation of 1255 signatues for the documents listed in the structure. The client uses 1256 the access token issued as result of the process to call the sign doc 1257 endpoint at the respective signing service to actually create the 1258 signature. This access token is bound to the client, the user id and 1259 the hashes (and signature algorithm) as consented by the user. 1261 A.3. Access to Tax Data 1263 This example is inspired by an API allowing third parties to access 1264 citizen's tax declarations and income statements, for example to 1265 determine their credit worthiness. 1267 [ 1268 { 1269 "type": "tax_data", 1270 "locations": [ 1271 "https://taxservice.govehub.no" 1272 ], 1273 "actions":"read_tax_declaration", 1274 "periods": ["2018"], 1275 "duration_of_access": 30, 1276 "tax_payer_id": "23674185438934" 1277 } 1278 ] 1280 The top-level elements have the following meaning: 1282 * "periods": determines the periods the client wants to access 1284 * "duration_of_access": how long does the client intend to access 1285 the data in days 1287 * "tax_payer_id": identifier of the tax payer (if known to the 1288 client) 1290 A.4. eHealth 1292 These two examples are inspired by requirements for APIs used in the 1293 Norwegian eHealth system. 1295 In this use case the physical therapist sits in front of her computer 1296 using a local Electronic Health Records (EHR) system. They wants to 1297 look at the electronic patient records of a certain patient and they 1298 also wants to fetch the patients journal entries in another system, 1299 perhaps at another institution or a national service. Access to this 1300 data is provided by an API. 1302 The information necessary to authorize the request at the API is only 1303 known by the EHR system, and must be presented to the API. 1305 In the first example the authorization details object contains the 1306 identifier of an organization. In this case the API needs to know if 1307 the given organization has the lawful basis for processing personal 1308 health information to give access to sensitive data. 1310 "authorization_details":{ 1311 "type":"patient_record", 1312 "requesting_entity": { 1313 "type": "Practitioner", 1314 "identifier": [ 1315 { 1316 "system": " urn:oid:2.16.578.1.12.4.1.4.4", 1317 "value": "1234567" 1318 }], 1319 "practitioner_role":{ 1320 "organization":{ 1321 "identifier": { 1322 "system":"urn:oid:2.16.578.1.12.4.1.2.101", 1323 "type":"ENH", 1324 "value":"[organizational number]" 1325 } 1326 } 1327 } 1328 } 1329 } 1331 In the second example the API requires more information to authorize 1332 the request. In this case the authorization details object contains 1333 additional information about the health institution and the current 1334 profession the user has at the time of the request. The additional 1335 level of detail could be used for both authorization and data 1336 minimization. 1338 [ 1339 { 1340 "type": "patient_record", 1341 "location": "https://fhir.example.com/patient", 1342 "actions": [ 1343 "read" 1344 ], 1345 "patient_identifier": [ 1346 { 1347 "system": "urn:oid:2.16.578.1.12.4.1.4.1", 1348 "value": "12345678901" 1349 } 1350 ], 1351 "reason_for_request": "Clinical treatment", 1352 "requesting_entity": { 1353 "type": "Practitioner", 1354 "identifier": [ 1355 { 1356 "system": " urn:oid:2.16.578.1.12.4.1.4.4", 1357 "value": "1234567" 1359 } 1360 ], 1361 "practitioner_role": { 1362 "organization": { 1363 "identifier": [ 1364 { 1365 "system": "urn:oid:2.16.578.1.12.4.1.2.101", 1366 "type": "ENH", 1367 "value": "" 1368 } 1369 ], 1370 "type": { 1371 "coding": [ 1372 { 1373 "system": 1374 "http://hl7.org/fhir/organization-type", 1375 "code": "dept", 1376 "display": "Hospital Department" 1377 } 1378 ] 1379 }, 1380 "name": "Akuttmottak" 1381 }, 1382 "profession": { 1383 "coding": [ 1384 { 1385 "system": "http://snomed.info/sct", 1386 "code": "36682004", 1387 "display": "Physical therapist" 1388 } 1389 ] 1390 } 1391 } 1392 } 1393 } 1394 ] 1396 Description of the elements: 1398 * "patient_identifier": the identifier of the patient composed of a 1399 system identifier in OID format (namespace) and the acutal value 1400 within this namespace. 1402 * "reason_for_request": the reason why the user wants to access a 1403 certain API 1405 * "requesting_entity": specification of the requester by means of 1406 identity, role and organizational context. This data is provided 1407 to facilitate authorization and for auditing purposes. 1409 In this use case, the AS authenticates the requester, who is not the 1410 patient, and approves access based on policies. 1412 Appendix B. Document History 1414 [[ To be removed from the final specification ]] 1416 -04 1418 * restructured draft for better readability 1420 * added implemnentation considerations for deployments and products 1422 * added type union language from GNAP 1424 -03 1426 * Updated references to current revisions or RFC numbers 1428 * Added section about enrichment of authorization details objects by 1429 the AS 1431 * Clarified processing of unknown authorization details parameters 1433 * clarified dependencies between "resource" and 1434 "authorization_details" parameters 1436 -02 1438 * Clarify "type" parameter processing 1440 -01 1442 * Minor fix-up in a few examples 1444 -00 (WG draft) 1446 * initial WG revision 1448 -03 1450 * Reworked examples to illustrate privacy preserving use of 1451 "authorization_details" 1453 * Added text on audience restriction 1455 * Added description of relationship between "scope" and 1456 "authorization_details" 1458 * Added text on token request & response and "authorization_details" 1460 * Added text on how authorization details are conveyed to RSs by 1461 JWTs or token endpoint response 1463 * Added description of relationship between "claims" and 1464 "authorization_details" 1466 * Added more example from different sectors 1468 * Clarified string comparison to be byte-exact without collation 1470 -02 1472 * Added Security Considerations 1474 * Added Privacy Considerations 1476 * Added notes on URI size and authorization details 1478 * Added requirement to return the effective authorization details 1479 granted by the resource owner in the token response 1481 * changed "authorization_details" structure from object to array 1483 * added Justin Richer & Brian Campbell as Co-Authors 1485 -00 / -01 1487 * first draft 1489 Authors' Addresses 1491 Torsten Lodderstedt 1492 yes.com 1494 Email: torsten@lodderstedt.net 1496 Justin Richer 1497 Bespoke Engineering 1499 Email: ietf@justin.richer.org 1500 Brian Campbell 1501 Ping Identity 1503 Email: bcampbell@pingidentity.com