idnits 2.17.00 (12 Aug 2021) /tmp/idnits15188/draft-ietf-oauth-resource-indicators-08.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 (September 11, 2019) is 976 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: draft-ietf-oauth-jwsreq has been published as RFC 9101 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OAuth Working Group B. Campbell 3 Internet-Draft Ping Identity 4 Intended status: Standards Track J. Bradley 5 Expires: March 14, 2020 Yubico 6 H. Tschofenig 7 Arm Limited 8 September 11, 2019 10 Resource Indicators for OAuth 2.0 11 draft-ietf-oauth-resource-indicators-08 13 Abstract 15 This document specifies an extension to the OAuth 2.0 Authorization 16 Framework defining request parameters that enable a client to 17 explicitly signal to an authorization server about the identity of 18 the protected resource(s) to which it is requesting access. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on March 14, 2020. 37 Copyright Notice 39 Copyright (c) 2019 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Requirements Notation and Conventions . . . . . . . . . . 3 56 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Resource Parameter . . . . . . . . . . . . . . . . . . . . . 3 58 2.1. Authorization Request . . . . . . . . . . . . . . . . . . 5 59 2.2. Access Token Request . . . . . . . . . . . . . . . . . . 6 60 3. Security Considerations . . . . . . . . . . . . . . . . . . . 9 61 4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 10 62 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 63 5.1. OAuth Parameters Registration . . . . . . . . . . . . . . 10 64 5.2. OAuth Extensions Error Registration . . . . . . . . . . . 10 65 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 66 6.1. Normative References . . . . . . . . . . . . . . . . . . 11 67 6.2. Informative References . . . . . . . . . . . . . . . . . 11 68 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 12 69 Appendix B. Document History . . . . . . . . . . . . . . . . . . 12 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 72 1. Introduction 74 Several years of deployment and implementation experience with the 75 OAuth 2.0 Authorization Framework [RFC6749] has uncovered a need, in 76 some circumstances such as an authorization server servicing a 77 significant number of diverse resources, for the client to explicitly 78 signal to the authorization server where it intends to use the access 79 token it is requesting. 81 Knowing the protected resource (a.k.a. resource server, application, 82 API, etc.) that will process the access token enables the 83 authorization server to construct the token as necessary for that 84 entity. Properly encrypting the token (or content within the token) 85 to a particular resource, for example, requires knowing which 86 resource will receive and decrypt the token. Furthermore, various 87 resources oftentimes have different requirements with respect to the 88 data contained in, or referenced by, the token and knowing the 89 resource where the client intends to use the token allows the 90 authorization server to mint the token accordingly. 92 Specific knowledge of the intended recipient(s) of the access token 93 also helps facilitate improved security characteristics of the token 94 itself. Bearer tokens, currently the most commonly utilized type of 95 OAuth access token, allow any party in possession of a token to get 96 access to the associated resources. To prevent misuse, several 97 important security assumptions must hold, one of which is that an 98 access token must only be valid for use at a specific protected 99 resource and for a specific scope of access. Section 5.2 of 100 [RFC6750], for example, prescribes including the token's intended 101 recipients within the token to prevent token redirect. When the 102 authorization server is informed of the resource that will process 103 the access token, it can restrict the intended audience of that token 104 to the given resource such that the token cannot be used successfully 105 at other resources. 107 OAuth scope, from Section 3.3 of [RFC6749], is sometimes overloaded 108 to convey the location or identity of the protected resource, 109 however, doing so isn't always feasible or desirable. Scope is 110 typically about what access is being requested rather than where that 111 access will be redeemed (e.g., "email", "admin:org", "user_photos", 112 "channels:read", and "channels:write" are a small sample of scope 113 values in use in the wild that convey only the type of access and not 114 the location or identity). 116 In some circumstances and for some deployments, a means for the 117 client to signal to the authorization server where it intends to use 118 the access token it's requesting is important and useful. A number 119 of implementations and deployments of OAuth 2.0 have already employed 120 proprietary parameters toward that end. Going forward, this 121 specification aspires to provide a standardized and interoperable 122 alternative to the proprietary approaches. 124 1.1. Requirements Notation and Conventions 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 128 "OPTIONAL" in this document are to be interpreted as described in BCP 129 14 [RFC2119] [RFC8174] when, and only when, they appear in all 130 capitals, as shown here. 132 1.2. Terminology 134 This specification uses the terms "access token", "refresh token", 135 "authorization server", "resource server", "authorization endpoint", 136 "authorization request", "authorization response", "token endpoint", 137 "grant type", "access token request", "access token response", and 138 "client" defined by The OAuth 2.0 Authorization Framework [RFC6749]. 140 2. Resource Parameter 142 In requests to the authorization server, a client MAY indicate the 143 protected resource (a.k.a. resource server, application, API, etc.) 144 to which it is requesting access by including the following parameter 145 in the request. 147 resource 148 Indicates the target service or resource to which access is being 149 requested. Its value MUST be an absolute URI, as specified by 150 Section 4.3 of [RFC3986]. The URI MUST NOT include a fragment 151 component. It SHOULD NOT include a query component, but it is 152 recognized that there are cases that make a query component a 153 useful and necessary part of the resource parameter, such as when 154 query parameter(s) are used to scope requests to an application. 155 The "resource" parameter URI value is an identifier representing 156 the identity of the resource, which MAY be a locator that 157 corresponds to a network addressable location where the target 158 resource is hosted. Multiple "resource" parameters MAY be used to 159 indicate that the requested token is intended to be used at 160 multiple resources. 162 The parameter value identifies a resource to which the client is 163 requesting access. The parameter can carry the location of a 164 protected resource, typically as an https URL, or a more abstract 165 identifier. This enables the authorization server to apply policy as 166 appropriate for the resource, such as determining the type and 167 content of tokens to be issued, if and how tokens are encrypted, and 168 applying appropriate audience restrictions. 170 The client SHOULD provide the most specific URI that it can for the 171 complete API or set of resources it intends to access. In practice a 172 client will know a base URI for the application or resource that it 173 interacts with, which is appropriate to use as the value of the 174 "resource" parameter. The client SHOULD use the base URI of the API 175 as the "resource" parameter value unless specific knowledge of the 176 resource dictates otherwise. For example, the value 177 "https://api.example.com/" would be used for a resource that is the 178 exclusive application on that host, however, if the resource is one 179 of many applications on that host, something like 180 "https://api.example.com/app/" would be used as a more specific 181 value. Another example, for an API like SCIM [RFC7644] that has 182 multiple endpoints such as "https://apps.example.com/scim/Users", 183 "https://apps.example.com/scim/Groups", and 184 "https://apps.example.com/scim/Schemas" The client would use 185 "https://apps.example.com/scim/" as the resource so that the issued 186 access token is valid for all the endpoints of the SCIM API. 188 The following error code is provided for an authorization server to 189 indicate problems with the requested resource(s) in response to an 190 authorization request or access token request. It can also be used 191 to inform the client that it has requested an invalid combination of 192 resource and scope. 194 invalid_target 195 The requested resource is invalid, missing, unknown, or malformed. 197 The authorization server SHOULD audience-restrict issued access 198 tokens to the resource(s) indicated by the "resource" parameter. 199 Audience restrictions can be communicated in JSON Web Tokens 200 [RFC7519] with the "aud" claim and the top-level member of the same 201 name provides the audience restriction information in a Token 202 Introspection [RFC7662] response. The authorization server may use 203 the exact "resource" value as the audience or it may map from that 204 value to a more general URI or abstract identifier for the given 205 resource. 207 2.1. Authorization Request 209 When the "resource" parameter is used in an authorization request to 210 the authorization endpoint, it indicates the identity of the 211 protected resource(s) to which access is being requested. When an 212 access token will be returned directly from the authorization 213 endpoint via the implicit flow (Section 4.2 of OAuth 2.0 [RFC6749]), 214 the requested resource is applicable to that access token. In the 215 code flow (Section 4.1 of OAuth 2.0 [RFC6749]) where an intermediate 216 representation of the authorization grant (the authorization code) is 217 returned from the authorization endpoint, the requested resource is 218 applicable to the full authorization grant. 220 For an authorization request sent as a JSON Web Token (JWT), such as 221 when using JWT Secured Authorization Request [I-D.ietf-oauth-jwsreq], 222 a single "resource" parameter value is represented as a JSON string 223 while multiple values are represented as an array of strings. 225 If the client omits the "resource" parameter when requesting 226 authorization, the authorization server MAY process the request with 227 no specific resource or by using a pre-defined default resource 228 value. Alternatively, the authorization server MAY require clients 229 to specify the resource(s) they intend to access and MAY fail 230 requests that omit the parameter with an "invalid_target" error. The 231 authorization server might use this data to inform the user about the 232 resources the client is going to access on her behalf, to apply 233 policy (e.g., refuse the request due to unknown resources), and to 234 determine the set of resources that can be used in subsequent access 235 token requests. 237 If the authorization server fails to parse the provided value(s) or 238 does not consider the resource(s) acceptable, it should reject the 239 request with an error response using the error code "invalid_target" 240 as the value of the "error" parameter and can provide additional 241 information regarding the reasons for the error using the 242 "error_description". 244 An example of an authorization request where the client tells the 245 authorization server that it wants an access token for use at 246 "https://api.example.com/app/" is shown in Figure 1 below (extra line 247 breaks and indentation are for display purposes only). 249 GET /as/authorization.oauth2?response_type=token 250 &client_id=example-client 251 &state=XzZaJlcwYew1u0QBrRv_Gw 252 &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb 253 &resource=https%3A%2F%2Fapi.example.com%2Fapp%2F HTTP/1.1 254 Host: authorization-server.example.com 256 Figure 1: Implicit Flow Authorization Request 258 Below in Figure 2 is an example of an authorization request using the 259 "code" response type where the client is requesting access to the 260 resource owner's contacts and calendar data at 261 "https://cal.example.com/" and "https://contacts.example.com/" (extra 262 line breaks and indentation are for display purposes only). 264 GET /as/authorization.oauth2?response_type=code 265 &client_id=s6BhdRkqt3 266 &state=tNwzQ87pC6llebpmac_IDeeq-mCR2wLDYljHUZUAWuI 267 &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb 268 &scope=calendar%20contacts 269 &resource=https%3A%2F%2Fcal.example.com%2F 270 &resource=https%3A%2F%2Fcontacts.example.com%2F HTTP/1.1 271 Host: authorization-server.example.com 273 Figure 2: Code Flow Authorization Request 275 2.2. Access Token Request 277 When the "resource" parameter is used on an access token request made 278 to the token endpoint, for all grant types, it indicates the target 279 service or protected resource where the client intends to use the 280 requested access token. 282 The resource value(s) that are acceptable to an authorization server 283 in fulfilling an access token request are at its sole discretion 284 based on local policy or configuration. In the case of a 285 "refresh_token" or "authorization_code" grant type request, such 286 policy may limit the acceptable resources to those that were 287 originally granted by the resource owner or a subset thereof. In the 288 "authorization_code" case where the requested resources are a subset 289 of the set of resources originally granted, the authorization server 290 will issue an access token based on that subset of requested 291 resources while any refresh token that is returned is bound to the 292 full original grant. 294 When requesting a token, the client can indicate the desired target 295 service(s) where it intends to use that token by way of the 296 "resource" parameter and can indicate the desired scope of the 297 requested token using the "scope" parameter. The semantics of such a 298 request are that the client is asking for a token with the requested 299 scope that is usable at all the requested target services. 300 Effectively, the requested access rights of the token are the 301 cartesian product of all the scopes at all the target services. To 302 the extent possible, when issuing access tokens, the authorization 303 server should downscope the scope value associated with an access 304 token to the value the respective resource is able to process and 305 needs to know. This further improves privacy as a list of scope 306 values is an indication that the resource owner uses the multiple 307 various services listed; downscoping a token to only that which is 308 needed for a particular service can limit the extent to which such 309 information is revealed across different services. As specified in 310 Section 5.1 of [RFC6749], the authorization server must indicate the 311 access token's effective scope to the client in the "scope" response 312 parameter value when it differs from the scope requested by the 313 client. 315 Following from the code flow authorization request shown in Figure 2, 316 the below examples show an "authorization_code" grant type access 317 token request (Figure 3) and response (Figure 4) where the client 318 tells the authorization server that it wants the access token for use 319 at "https://cal.example.com/" (extra line breaks and indentation are 320 for display purposes only). 322 POST /as/token.oauth2 HTTP/1.1 323 Host: authorization-server.example.com 324 Authorization: Basic czZCaGRSa3F0Mzpoc3FFelFsVW9IQUU5cHg0RlNyNHlJ 325 Content-Type: application/x-www-form-urlencoded 327 grant_type=authorization_code 328 &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb 329 &code=10esc29BWC2qZB0acc9v8zAv9ltc2pko105tQauZ 330 &resource=https%3A%2F%2Fcal.example.com%2F 332 Figure 3: Access Token Request 334 HTTP/1.1 200 OK 335 Content-Type: application/json 336 Cache-Control: no-cache, no-store 338 { 339 "access_token":"eyJhbGciOiJFUzI1NiIsImtpZCI6Ijc3In0.eyJpc3MiOi 340 JodHRwOi8vYXV0aG9yaXphdGlvbi1zZXJ2ZXIuZXhhbXBsZS5jb20iLCJzdWI 341 iOiJfX2JfYyIsImV4cCI6MTU4ODQyMDgwMCwic2NvcGUiOiJjYWxlbmRhciIs 342 ImF1ZCI6Imh0dHBzOi8vY2FsLmV4YW1wbGUuY29tLyJ9.nNWJ2dXSxaDRdMUK 343 lzs-cYIj8MDoM6Gy7pf_sKrLGsAFf1C2bDhB60DQfW1DZL5npdko1_Mmk5sUf 344 zkiQNVpYw", 345 "token_type":"Bearer", 346 "expires_in":3600, 347 "refresh_token":"4LTC8lb0acc6Oy4esc1Nk9BWC0imAwH7kic16BDC2", 348 "scope":"calendar" 349 } 351 Figure 4: Access Token Response 353 A subsequent access token request, using the refresh token, where the 354 client tells the authorization server that it wants an access token 355 for use at "https://contacts.example.com/" is shown in Figure 5 below 356 with the response shown in Figure 6 (extra line breaks and 357 indentation are for display purposes only). 359 POST /as/token.oauth2 HTTP/1.1 360 Host: authorization-server.example.com 361 Authorization: Basic czZCaGRSa3F0Mzpoc3FFelFsVW9IQUU5cHg0RlNyNHlJ 362 Content-Type: application/x-www-form-urlencoded 364 grant_type=refresh_token 365 &refresh_token=4LTC8lb0acc6Oy4esc1Nk9BWC0imAwH7kic16BDC2 366 &resource=https%3A%2F%2Fcontacts.example.com%2F 368 Figure 5: Access Token Request 370 HTTP/1.1 200 OK 371 Content-Type: application/json 372 Cache-Control: no-cache, no-store 374 { 375 "access_token":"eyJhbGciOiJFUzI1NiIsImtpZCI6Ijc3In0.eyJpc3MiOi 376 JodHRwOi8vYXV0aG9yaXphdGlvbi1zZXJ2ZXIuZXhhbXBsZS5jb20iLCJzdWI 377 iOiJfX2JfYyIsImV4cCI6MTU4ODQyMDgyNiwic2NvcGUiOiJjb250YWN0cyIs 378 ImF1ZCI6Imh0dHBzOi8vY29udGFjdHMuZXhhbXBsZS5jb20vIn0.5f4yhqazc 379 OSlJw4y94KPeWNEFQqj2cfeO8x4hr3YbHtIl3nQXnBMw5wREY5O1YbZED-GfH 380 UowfmtNaA5EikYAw", 381 "token_type":"Bearer", 382 "expires_in":3600, 383 "scope":"contacts" 384 } 386 Figure 6: Access Token Response 388 3. Security Considerations 390 An audience-restricted access token, legitimately presented to a 391 resource, cannot then be taken by that resource and presented 392 elsewhere for illegitimate access to other resources. The "resource" 393 parameter enables a client to indicate the protected resources where 394 the requested access token will be used, which in turn enables the 395 authorization server to apply the appropriate audience restrictions 396 to the token. 398 Some servers may host user content or be multi-tenant. In order to 399 avoid attacks where one tenant uses an access token to illegitimately 400 access resources owned by a different tenant, it is important to use 401 a specific resource URI including any portion of the URI that 402 identifies the tenant, such as a path component. This will allow 403 access tokens to be audience-restricted in a way that identifies the 404 tenant and prevent their use, due to an invalid audience, at 405 resources owned by a different tenant. 407 Although multiple occurrences of the "resource" parameter may be 408 included in a token request, using only a single "resource" parameter 409 is encouraged. A bearer token that has multiple intended recipients 410 (audiences) indicating that the token is valid at more than one 411 protected resource can be used by any one of those protected 412 resources to access any of the other protected resources. Thus, a 413 high degree of trust between the involved parties is needed when 414 using access tokens with multiple audiences. Furthermore an 415 authorization server may be unwilling or unable to fulfill a token 416 request with multiple resources. 418 Whenever feasible, the "resource" parameter should correspond to the 419 network addressable location of the protected resource. This makes 420 it possible for the client to validate that the resource being 421 requested controls the corresponding network location, reducing the 422 risk of malicious endpoints obtaining tokens meant for other 423 resources. If the "resource" parameter contains an abstract 424 identifier, it is the client's responsibility to validate out of band 425 that any network endpoint to which tokens are sent are the intended 426 audience for that identifier. 428 4. Privacy Considerations 430 In typical OAuth deployments the authorization sever is in a position 431 to observe and track a significant amount of user and client 432 behavior. It is largely just inherent to the nature of OAuth and 433 this document does little to affect that. In some cases, however, 434 such as when access token introspection is not being used, use of the 435 resource parameter defined herein may allow for tracking behavior at 436 a somewhat more granular and specific level than would otherwise be 437 possible in its absence. 439 5. IANA Considerations 441 5.1. OAuth Parameters Registration 443 This specification updates the following value in the IANA "OAuth 444 Parameters" registry [IANA.OAuth.Parameters] established by 445 [RFC6749]. 447 o Parameter name: resource 448 o Parameter usage location: authorization request, token request 449 o Change controller: IESG 450 o Specification document(s): [[ this specification ]] 452 5.2. OAuth Extensions Error Registration 454 This specification updates the following error in the IANA "OAuth 455 Extensions Error Registry" [IANA.OAuth.Parameters] established by 456 [RFC6749]. 458 o Error name: invalid_target 459 o Error usage location: implicit grant error response, token error 460 response 461 o Related protocol extension: resource parameter 462 o Change controller: IESG 463 o Specification document(s): [[ this specification ]] 465 6. References 467 6.1. Normative References 469 [IANA.OAuth.Parameters] 470 IANA, "OAuth Parameters", 471 . 473 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 474 Requirement Levels", BCP 14, RFC 2119, 475 DOI 10.17487/RFC2119, March 1997, 476 . 478 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 479 Resource Identifier (URI): Generic Syntax", STD 66, 480 RFC 3986, DOI 10.17487/RFC3986, January 2005, 481 . 483 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 484 RFC 6749, DOI 10.17487/RFC6749, October 2012, 485 . 487 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 488 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 489 May 2017, . 491 6.2. Informative References 493 [I-D.ietf-oauth-jwsreq] 494 Sakimura, N. and J. Bradley, "The OAuth 2.0 Authorization 495 Framework: JWT Secured Authorization Request (JAR)", 496 draft-ietf-oauth-jwsreq-19 (work in progress), June 2019. 498 [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization 499 Framework: Bearer Token Usage", RFC 6750, 500 DOI 10.17487/RFC6750, October 2012, 501 . 503 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 504 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 505 . 507 [RFC7644] Hunt, P., Ed., Grizzle, K., Ansari, M., Wahlstroem, E., 508 and C. Mortimore, "System for Cross-domain Identity 509 Management: Protocol", RFC 7644, DOI 10.17487/RFC7644, 510 September 2015, . 512 [RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection", 513 RFC 7662, DOI 10.17487/RFC7662, October 2015, 514 . 516 Appendix A. Acknowledgements 518 This specification was developed within the OAuth Working Group under 519 the chairmanship of Hannes Tschofenig and Rifaat Shekh-Yusef with 520 Eric Rescorla, Benjamin Kaduk and Roman Danyliw serving as Security 521 Area Directors. Additionally, the following individuals contributed 522 ideas, feedback, and wording that helped shape this specification: 524 Vittorio Bertocci, Sergey Beryozkin, Roman Danyliw, William Denniss, 525 Vladimir Dzhuvinov, George Fletcher, Dick Hardt, Phil Hunt, Michael 526 Jones, Benjamin Kaduk, Barry Leiba, Torsten Lodderstedt, Anthony 527 Nadalin, Justin Richer, Adam Roach, Nat Sakimura, Rifaat Shekh-Yusef, 528 Filip Skokan, Eric Vyncke, and Hans Zandbelt. 530 Appendix B. Document History 532 [[ to be removed by the RFC Editor before publication as an RFC ]] 534 draft-ietf-oauth-resource-indicators-08 536 o One last update from IESG evaluation comments 537 (https://mailarchive.ietf.org/arch/msg/oauth/ 538 x87EQ0Dwq3_ERrH5PzDjRSaWBt4). 540 draft-ietf-oauth-resource-indicators-07 542 o One more update from IESG evaluation comments 543 (https://mailarchive.ietf.org/arch/msg/oauth/ 544 RS0UZSsguQurHl4P18Zo77BzZnU). 546 draft-ietf-oauth-resource-indicators-06 548 o Expand JWT acronym on first use per Genart last call review. 549 o Updates from IESG evaluation comments. 551 draft-ietf-oauth-resource-indicators-05 553 o Remove specific mention of error_uri, which is rarely (if ever) 554 used and seems to only confuse things for readers of extensions 555 like this one. 557 draft-ietf-oauth-resource-indicators-04 559 o Editorial updates from AD review that were overlooked in -03. 561 o Editorial updates from AD review. 562 o Update draft-ietf-oauth-jwsreq ref to -19. 563 o Update the IANA requests to say they update the registries. 565 draft-ietf-oauth-resource-indicators-02 567 o Clarify that the value of the "resource" parameter is a URI which 568 can be an abstract identifier for the target resource and doesn't 569 necessarily have to correspond to a network addressable location. 571 draft-ietf-oauth-resource-indicators-01 573 o Significant rework of the main section of the document attempting 574 to clarify a number of things that came up at, around and after 575 IETF 102 and the call for adoption. 576 o Change the "invalid_resource" error to "invalid_target" to align 577 with draft-ietf-oauth-token-exchange, which has some overlap in 578 functionality. 579 o Allow the "resource" parameter value to have a query component 580 (aligning with draft-ietf-oauth-token-exchange). 581 o Moved the Security Considerations section to before the IANA 582 Considerations. 583 o Other editorial updates. 584 o Rework the Acknowledgements section. 585 o Use RFC 8174 boilerplate. 587 draft-ietf-oauth-resource-indicators-00 589 o First version of the working group document. A replica of draft- 590 campbell-oauth-resource-indicators-02. 592 draft-campbell-oauth-resource-indicators-02 594 o No changes. 596 draft-campbell-oauth-resource-indicators-01 598 o Move Hannes Tschofenig, who wrote https://tools.ietf.org/html/ 599 draft-tschofenig-oauth-audience in '13, from Acknowledgements to 600 Authors. 601 o Added IANA Considerations to register the "resource" parameter and 602 "invalid_resource" error code. 604 draft-campbell-oauth-resource-indicators-00 606 o Initial draft to define a resource parameter for OAuth 2.0. 608 Authors' Addresses 610 Brian Campbell 611 Ping Identity 613 Email: brian.d.campbell@gmail.com 615 John Bradley 616 Yubico 618 Email: ve7jtb@ve7jtb.com 620 Hannes Tschofenig 621 Arm Limited 623 Email: hannes.tschofenig@gmx.net