idnits 2.17.1 draft-ietf-oauth-resource-indicators-05.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 (July 23, 2019) is 1737 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 (-34) exists of draft-ietf-oauth-jwsreq-19 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: January 24, 2020 Yubico 6 H. Tschofenig 7 Arm Limited 8 July 23, 2019 10 Resource Indicators for OAuth 2.0 11 draft-ietf-oauth-resource-indicators-05 13 Abstract 15 An extension to the OAuth 2.0 Authorization Framework defining 16 request parameters that enable a client to explicitly signal to an 17 authorization server about the identity of the protected resource(s) 18 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 January 24, 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. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 62 4.1. OAuth Parameters Registration . . . . . . . . . . . . . . 10 63 4.2. OAuth Extensions Error Registration . . . . . . . . . . . 10 64 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 65 5.1. Normative References . . . . . . . . . . . . . . . . . . 10 66 5.2. Informative References . . . . . . . . . . . . . . . . . 11 67 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11 68 Appendix B. Document History . . . . . . . . . . . . . . . . . . 12 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 71 1. Introduction 73 Several years of deployment and implementation experience with the 74 OAuth 2.0 Authorization Framework [RFC6749] has uncovered a need, in 75 some circumstances, for the client to explicitly signal to the 76 authorization server where it intends to use the access token it is 77 requesting. 79 Knowing the protected resource (a.k.a. resource server, application, 80 API, etc.) that will process the access token enables the 81 authorization server to construct the token as necessary for that 82 entity. Properly encrypting the token (or content within the token) 83 to a particular resource, for example, requires knowing which 84 resource will receive and decrypt the token. Furthermore, various 85 resources oftentimes have different requirements with respect to the 86 data contained in, or referenced by, the token and knowing the 87 resource where the client intends to use the token allows the 88 authorization server to mint the token accordingly. 90 Specific knowledge of the intended recipient(s) of the access token 91 also helps facilitate improved security characteristics of the token 92 itself. Bearer tokens, currently the most commonly utilized type of 93 OAuth access token, allow any party in possession of a token to get 94 access to the associated resources. To prevent misuse, several 95 important security assumptions must hold, one of which is that an 96 access token must only be valid for use at a specific protected 97 resource and for a specific scope of access. Section 5.2 of 98 [RFC6750], for example, prescribes including the token's intended 99 recipients within the token to prevent token redirect. When the 100 authorization server is informed of the resource that will process 101 the access token, it can restrict the intended audience of that token 102 to the given resource such that the token cannot be used successfully 103 at other resources. 105 OAuth scope, from Section 3.3 of [RFC6749], is sometimes overloaded 106 to convey the location or identity of the protected resource, 107 however, doing so isn't always feasible or desirable. Scope is 108 typically about what access is being requested rather than where that 109 access will be redeemed (e.g. "email", "admin:org", "user_photos", 110 "channels:read", and "channels:write" are a small sample of scope 111 values in use in the wild that convey only the type of access and not 112 the location or identity). 114 In some circumstances and for some deployments, a means for the 115 client to signal to the authorization server where it intends to use 116 the access token it's requesting is important and useful. A number 117 of implementations and deployments of OAuth 2.0 have already employed 118 proprietary parameters toward that end. Going forward, this 119 specification aspires to provide a standardized and interoperable 120 alternative to the proprietary approaches. 122 1.1. Requirements Notation and Conventions 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 126 "OPTIONAL" in this document are to be interpreted as described in BCP 127 14 [RFC2119] [RFC8174] when, and only when, they appear in all 128 capitals, as shown here. 130 1.2. Terminology 132 This specification uses the terms "access token", "refresh token", 133 "authorization server", "resource server", "authorization endpoint", 134 "authorization request", "authorization response", "token endpoint", 135 "grant type", "access token request", "access token response", and 136 "client" defined by The OAuth 2.0 Authorization Framework [RFC6749]. 138 2. Resource Parameter 140 In requests to the authorization server, a client MAY indicate the 141 protected resource (a.k.a. resource server, application, API, etc.) 142 to which it is requesting access by including the following parameter 143 in the request. 145 resource 146 Indicates the target service or resource to which access is being 147 requested. Its value MUST be an absolute URI, as specified by 148 Section 4.3 of [RFC3986], which MAY include a query component but 149 MUST NOT include a fragment component. The "resource" parameter 150 URI value is an identifier representing the identity of the 151 resource, which MAY be a locator that corresponds to a network 152 addressable location where the target resource is hosted. 153 Multiple "resource" parameters MAY be used to indicate that the 154 requested token is intended to be used at multiple resources. 156 The parameter value identifies a resource to which the client is 157 requesting access. The parameter can carry the location of a 158 protected resource, typically as an https URL, or a more abstract 159 identifier. This enables the authorization server to apply policy as 160 appropriate for the resource, such as determining the type and 161 content of tokens to be issued, if and how tokens are encrypted, and 162 applying appropriate audience restrictions. 164 The client SHOULD provide the most specific URI that it can for the 165 complete API or set of resources it intends to access. In practice a 166 client will know a base URI for the application or resource that it 167 interacts with, which is appropriate to use as the value of the 168 "resource" parameter. The client SHOULD use the base URI of the API 169 as the "resource" parameter value unless specific knowledge of the 170 resource dictates otherwise. For example, the value 171 "https://api.example.com/" would be used for a resource that is the 172 exclusive application on that host, however, if the resource is one 173 of many applications on that host, something like 174 "https://api.example.com/app/" would be used as a more specific 175 value. Another example, for an API like SCIM [RFC7644] that has 176 multiple endpoints such as "https://apps.example.com/scim/Users", 177 "https://apps.example.com/scim/Groups", and 178 "https://apps.example.com/scim/Schemas" The client would use 179 "https://apps.example.com/scim/" as the resource so that the issued 180 access token is valid for all the endpoints of the SCIM API. 182 The following error code is provided for an authorization server to 183 indicate problems with the requested resource(s) in response to an 184 authorization request or access token request. It can also be used 185 to inform the client that it has requested an invalid combination of 186 resource and scope. 188 invalid_target 189 The requested resource is invalid, unknown, or malformed. 191 The authorization server SHOULD audience restrict issued access 192 tokens to the resource(s) indicated by the "resource" parameter. 194 Audience restrictions can be communicated in JSON Web Tokens 195 [RFC7519] with the "aud" claim and the top-level member of the same 196 name provides the audience restriction information in a Token 197 Introspection [RFC7662] response. The authorization server may use 198 the exact "resource" value as the audience or it may map from that 199 value to a more general URI or abstract identifier for the given 200 resource. 202 2.1. Authorization Request 204 When the "resource" parameter is used in an authorization request to 205 the authorization endpoint, it indicates the identity of the 206 protected resource(s) to which access is being requested. When an 207 access token will be returned directly from the authorization 208 endpoint via the implicit flow (Section 4.2 of OAuth 2.0 [RFC6749]), 209 the requested resource is applicable to that access token. In the 210 code flow (Section 4.1 of OAuth 2.0 [RFC6749]) where an intermediate 211 representation of the authorization grant (the authorization code) is 212 returned from the authorization endpoint, the requested resource is 213 applicable to the full authorization grant. 215 For authorization requests sent as a JWTs, such as when using JWT 216 Secured Authorization Request [I-D.ietf-oauth-jwsreq], a single 217 "resource" parameter value is represented as a JSON string while 218 multiple values are represented as an array of strings. 220 If the client omits the "resource" parameter when requesting 221 authorization, the authorization server MAY process the request with 222 no specific resource or by using a pre-defined default resource 223 value. Alternatively, the authorization server MAY require clients 224 to specify the resource(s) they intend to access and MAY fail 225 requests that omit the parameter with an "invalid_target" error. The 226 authorization server might use this data to inform the user about the 227 resources the client is going to access on her behalf, to meet policy 228 decision (e.g. refuse the request due to unknown resources), and 229 determine the set of resources that can be used in subsequent access 230 token requests. 232 If the authorization server fails to parse the provided value(s) or 233 does not consider the resource(s) acceptable, it should reject the 234 request with an error response using the error code "invalid_target" 235 as the value of the "error" parameter and can provide additional 236 information regarding the reasons for the error using the 237 "error_description". 239 An example of an authorization request where the client tells the 240 authorization server that it wants an access token for use at 241 "https://api.example.com/app/" is shown in Figure 1 below (extra line 242 breaks and indentation are for display purposes only). 244 GET /as/authorization.oauth2?response_type=token 245 &client_id=example-client 246 &state=XzZaJlcwYew1u0QBrRv_Gw 247 &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Eorg%2Fcb 248 &resource=https%3A%2F%2Fapi.example.com%2Fapp%2F HTTP/1.1 249 Host: authorization-server.example.com 251 Figure 1: Implicit Flow Authorization Request 253 Below in Figure 2 is an example of an authorization request using the 254 "code" response type where the client is requesting access to the 255 resource owner's contacts and calendar data at 256 "https://cal.example.com/" and "https://contacts.example.com/" (extra 257 line breaks and indentation are for display purposes only). 259 GET /as/authorization.oauth2?response_type=code 260 &client_id=s6BhdRkqt3 261 &state=tNwzQ87pC6llebpmac_IDeeq-mCR2wLDYljHUZUAWuI 262 &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Eorg%2Fcb 263 &scope=calendar%20contacts 264 &resource=https%3A%2F%2Fcal.example.com%2F 265 &resource=https%3A%2F%2Fcontacts.example.com%2F HTTP/1.1 266 Host: authorization-server.example.com 268 Figure 2: Code Flow Authorization Request 270 2.2. Access Token Request 272 When the "resource" parameter is used on an access token request made 273 to the token endpoint, for all grant types, it indicates the target 274 service or protected resource where the client intends to use the 275 requested access token. 277 The resource value(s) that are acceptable to an authorization server 278 in fulfilling an access token request are at its sole discretion 279 based on local policy or configuration. In the case of a 280 "refresh_token" or "authorization_code" grant type request, such 281 policy may limit the acceptable resources to those that were 282 originally granted by the resource owner or a subset thereof. In the 283 "authorization_code" case where the requested resources are a subset 284 of the set of resources originally granted, the authorization server 285 will issue an access token based on that subset of requested 286 resources while any refresh token that is returned is bound to the 287 full original grant. 289 When requesting a token, the client can indicate the desired target 290 service(s) where it intends to use that token by way of the 291 "resource" parameter and can indicate the desired scope of the 292 requested token using the "scope" parameter. The semantics of such a 293 request are that the client is asking for a token with the requested 294 scope that is usable at all the requested target services. 295 Effectively, the requested access rights of the token are the 296 cartesian product of all the scopes at all the target services. To 297 the extent possible, when issuing access tokens, the authorization 298 server should downscope the scope value associated with an access 299 token to the value the respective resource is able to process and 300 needs to know. This further improves privacy as scope values give an 301 indication of what services the resource owner uses and downscoping a 302 token to only that which is needed for a particular service can limit 303 the extent to which such information is revealed across different 304 services. As specified in Section 5.1 of [RFC6749], the 305 authorization server must indicate the access token's effective scope 306 to the client in the "scope" response parameter value when it differs 307 from the scope requested by the client. 309 Following from the code flow authorization request shown in Figure 2, 310 the below examples show an "authorization_code" grant type access 311 token request (Figure 3) and response (Figure 4) where the client 312 tells the authorization server that it wants the access token for use 313 at "https://cal.example.com/" (extra line breaks and indentation are 314 for display purposes only). 316 POST /as/token.oauth2 HTTP/1.1 317 Host: authorization-server.example.com 318 Authorization: Basic czZCaGRSa3F0Mzpoc3FFelFsVW9IQUU5cHg0RlNyNHlJ 319 Content-Type: application/x-www-form-urlencoded 321 grant_type=authorization_code 322 &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Eorg%2Fcb 323 &code=10esc29BWC2qZB0acc9v8zAv9ltc2pko105tQauZ 324 &resource=https%3A%2F%2Fcal.example.com%2F 326 Figure 3: Access Token Request 328 HTTP/1.1 200 OK 329 Content-Type: application/json 330 Cache-Control: no-cache, no-store 332 { 333 "access_token":"eyJhbGciOiJFUzI1NiIsImtpZCI6Ijc3In0.eyJpc3MiOi 334 JodHRwOi8vYXV0aG9yaXphdGlvbi1zZXJ2ZXIuZXhhbXBsZS5jb20iLCJzdWI 335 iOiJfX2JfYyIsImV4cCI6MTU4ODQyMDgwMCwic2NvcGUiOiJjYWxlbmRhciIs 336 ImF1ZCI6Imh0dHBzOi8vY2FsLmV4YW1wbGUuY29tLyJ9.nNWJ2dXSxaDRdMUK 337 lzs-cYIj8MDoM6Gy7pf_sKrLGsAFf1C2bDhB60DQfW1DZL5npdko1_Mmk5sUf 338 zkiQNVpYw", 339 "token_type":"Bearer", 340 "expires_in":3600, 341 "refresh_token":"4LTC8lb0acc6Oy4esc1Nk9BWC0imAwH7kic16BDC2", 342 "scope":"calendar" 343 } 345 Figure 4: Access Token Response 347 A subsequent access token request, using the refresh token, where the 348 client tells the authorization server that it wants an access token 349 for use at "https://contacts.example.com/" is shown in Figure 5 below 350 with the response shown in Figure 6 (extra line breaks and 351 indentation are for display purposes only). 353 POST /as/token.oauth2 HTTP/1.1 354 Host: authorization-server.example.com 355 Authorization: Basic czZCaGRSa3F0Mzpoc3FFelFsVW9IQUU5cHg0RlNyNHlJ 356 Content-Type: application/x-www-form-urlencoded 358 grant_type=refresh_token 359 &refresh_token=4LTC8lb0acc6Oy4esc1Nk9BWC0imAwH7kic16BDC2 360 &resource=https%3A%2F%2Fcontacts.example.com%2Fapp%2F 362 Figure 5: Access Token Request 364 HTTP/1.1 200 OK 365 Content-Type: application/json 366 Cache-Control: no-cache, no-store 368 { 369 "access_token":"eyJhbGciOiJFUzI1NiIsImtpZCI6Ijc3In0.eyJpc3MiOi 370 JodHRwOi8vYXV0aG9yaXphdGlvbi1zZXJ2ZXIuZXhhbXBsZS5jb20iLCJzdWI 371 iOiJfX2JfYyIsImV4cCI6MTU4ODQyMDgyNiwic2NvcGUiOiJjb250YWN0cyIs 372 ImF1ZCI6Imh0dHBzOi8vY29udGFjdHMuZXhhbXBsZS5jb20vIn0.5f4yhqazc 373 OSlJw4y94KPeWNEFQqj2cfeO8x4hr3YbHtIl3nQXnBMw5wREY5O1YbZED-GfH 374 UowfmtNaA5EikYAw", 375 "token_type":"Bearer", 376 "expires_in":3600, 377 "scope":"contacts" 378 } 380 Figure 6: Access Token Response 382 3. Security Considerations 384 An access token that is audience restricted to a protected resource 385 that obtains that token legitimately cannot be used to access 386 resources on behalf of the resource owner at other protected 387 resources. The "resource" parameter enables a client to indicate the 388 protected resources where the requested access token will be used, 389 which in turn enables the authorization server to apply the 390 appropriate audience restrictions to the token. 392 Some servers may host user content or be multi-tenant. In order to 393 avoid attacks that might confuse a client into sending an access 394 token to a resource that is user controlled or is owned by a 395 different tenant, it is important to use a specific resource URI 396 including a path component. This will cause any access token issued 397 for accessing the user controlled resource to have an invalid 398 audience if replayed against the legitimate resource API. 400 Although multiple occurrences of the "resource" parameter may be 401 included in a request, using only a single "resource" parameter is 402 encouraged. A bearer token that has multiple intended recipients 403 (audiences) indicating that the token is valid at more than one 404 protected resource can be used by any one of those protected 405 resources to access any of the other protected resources. Thus, a 406 high degree of trust between the involved parties is needed when 407 using access tokens with multiple audiences. Furthermore an 408 authorization server may be unwilling or unable to fulfill a token 409 request with multiple resources. 411 Whenever feasible, the "resource" parameter should correspond to the 412 network addressable location of the protected resource. This makes 413 it possible for the client to validate that the resource being 414 requested controls the corresponding network location, reducing the 415 risk of malicious endpoints obtaining tokens meant for other 416 resources. If the "resource" parameter contains an abstract 417 identifier, it is the client's responsibility to validate out of band 418 that any network endpoint to which tokens are sent are the intended 419 audience for that identifier. 421 4. IANA Considerations 423 4.1. OAuth Parameters Registration 425 This specification updates the following value in the IANA "OAuth 426 Parameters" registry [IANA.OAuth.Parameters] established by 427 [RFC6749]. 429 o Parameter name: resource 430 o Parameter usage location: authorization request, token request 431 o Change controller: IESG 432 o Specification document(s): [[ this specification ]] 434 4.2. OAuth Extensions Error Registration 436 This specification updates the following error in the IANA "OAuth 437 Extensions Error Registry" [IANA.OAuth.Parameters] established by 438 [RFC6749]. 440 o Error name: invalid_target 441 o Error usage location: implicit grant error response, token error 442 response 443 o Related protocol extension: resource parameter 444 o Change controller: IESG 445 o Specification document(s): [[ this specification ]] 447 5. References 449 5.1. Normative References 451 [IANA.OAuth.Parameters] 452 IANA, "OAuth Parameters", 453 . 455 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 456 Requirement Levels", BCP 14, RFC 2119, 457 DOI 10.17487/RFC2119, March 1997, 458 . 460 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 461 Resource Identifier (URI): Generic Syntax", STD 66, 462 RFC 3986, DOI 10.17487/RFC3986, January 2005, 463 . 465 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 466 RFC 6749, DOI 10.17487/RFC6749, October 2012, 467 . 469 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 470 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 471 May 2017, . 473 5.2. Informative References 475 [I-D.ietf-oauth-jwsreq] 476 Sakimura, N. and J. Bradley, "The OAuth 2.0 Authorization 477 Framework: JWT Secured Authorization Request (JAR)", 478 draft-ietf-oauth-jwsreq-19 (work in progress), June 2019. 480 [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization 481 Framework: Bearer Token Usage", RFC 6750, 482 DOI 10.17487/RFC6750, October 2012, 483 . 485 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 486 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 487 . 489 [RFC7644] Hunt, P., Ed., Grizzle, K., Ansari, M., Wahlstroem, E., 490 and C. Mortimore, "System for Cross-domain Identity 491 Management: Protocol", RFC 7644, DOI 10.17487/RFC7644, 492 September 2015, . 494 [RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection", 495 RFC 7662, DOI 10.17487/RFC7662, October 2015, 496 . 498 Appendix A. Acknowledgements 500 This specification was developed within the OAuth Working Group under 501 the chairmanship of Hannes Tschofenig and Rifaat Shekh-Yusef with 502 Eric Rescorla, Benjamin Kaduk and Roman Danyliw serving as Security 503 Area Directors. Additionally, the following individuals contributed 504 ideas, feedback, and wording that helped shape this specification: 506 Vittorio Bertocci, Sergey Beryozkin, Roman Danyliw, William Denniss, 507 Vladimir Dzhuvinov, George Fletcher, Dick Hardt, Phil Hunt, Michael 508 Jones, Torsten Lodderstedt, Anthony Nadalin, Justin Richer, Nat 509 Sakimura, Rifaat Shekh-Yusef, Filip Skokan, and Hans Zandbelt. 511 Appendix B. Document History 513 [[ to be removed by the RFC Editor before publication as an RFC ]] 515 draft-ietf-oauth-resource-indicators-05 517 o Remove specific mention of error_uri, which is rarely (if ever) 518 used and seems to only confuse things for readers of extensions 519 like this one. 521 draft-ietf-oauth-resource-indicators-04 523 o Editorial updates from AD review that were overlooked in -03. 525 draft-ietf-oauth-resource-indicators-03 527 o Editorial updates from AD review. 528 o Update draft-ietf-oauth-jwsreq ref to -19. 529 o Update the IANA requests to say they update the registries. 531 draft-ietf-oauth-resource-indicators-02 533 o Clarify that the value of the "resource" parameter is a URI which 534 can be an abstract identifier for the target resource and doesn't 535 necessarily have to correspond to a network addressable location. 537 draft-ietf-oauth-resource-indicators-01 539 o Significant rework of the main section of the document attempting 540 to clarify a number of things that came up at, around and after 541 IETF 102 and the call for adoption. 542 o Change the "invalid_resource" error to "invalid_target" to align 543 with draft-ietf-oauth-token-exchange, which has some overlap in 544 functionality. 545 o Allow the "resource" parameter value to have a query component 546 (aligning with draft-ietf-oauth-token-exchange). 547 o Moved the Security Considerations section to before the IANA 548 Considerations. 549 o Other editorial updates. 550 o Rework the Acknowledgements section. 551 o Use RFC 8174 boilerplate. 553 draft-ietf-oauth-resource-indicators-00 554 o First version of the working group document. A replica of draft- 555 campbell-oauth-resource-indicators-02. 557 draft-campbell-oauth-resource-indicators-02 559 o No changes. 561 draft-campbell-oauth-resource-indicators-01 563 o Move Hannes Tschofenig, who wrote https://tools.ietf.org/html/ 564 draft-tschofenig-oauth-audience in '13, from Acknowledgements to 565 Authors. 566 o Added IANA Considerations to register the "resource" parameter and 567 "invalid_resource" error code. 569 draft-campbell-oauth-resource-indicators-00 571 o Initial draft to define a resource parameter for OAuth 2.0. 573 Authors' Addresses 575 Brian Campbell 576 Ping Identity 578 Email: brian.d.campbell@gmail.com 580 John Bradley 581 Yubico 583 Email: ve7jtb@ve7jtb.com 585 Hannes Tschofenig 586 Arm Limited 588 Email: hannes.tschofenig@gmx.net