idnits 2.17.1 draft-ietf-ace-oauth-params-02.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 (January 29, 2019) is 1886 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 (-11) exists of draft-ietf-ace-cwt-proof-of-possession-05 == Outdated reference: A later version (-46) exists of draft-ietf-ace-oauth-authz-18 == Outdated reference: A later version (-07) exists of draft-ietf-oauth-pop-key-distribution-04 == Outdated reference: A later version (-08) exists of draft-ietf-oauth-resource-indicators-02 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ACE Working Group L. Seitz 3 Internet-Draft RISE 4 Intended status: Standards Track January 29, 2019 5 Expires: August 2, 2019 7 Additional OAuth Parameters for Authorization in Constrained 8 Environments (ACE) 9 draft-ietf-ace-oauth-params-02 11 Abstract 13 This specification defines new parameters for the OAuth 2.0 token and 14 introspection endpoints when used with the framework for 15 authentication and authorization for constrained environments (ACE). 16 These are used to express the desired audience of a requested access 17 token, the desired proof-of-possession key, the proof-of-possession 18 key that the AS has selected, and the key the RS should use to 19 authenticate to the client. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on August 2, 2019. 38 Copyright Notice 40 Copyright (c) 2019 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 57 3. Parameters for the Token Endpoint . . . . . . . . . . . . . . 3 58 3.1. Client-to-AS Request . . . . . . . . . . . . . . . . . . 3 59 3.2. AS-to-Client Response . . . . . . . . . . . . . . . . . . 4 60 3.3. The Resource Server Confirmation Claim . . . . . . . . . 6 61 4. Parameters for the Introspection Endpoint . . . . . . . . . . 6 62 4.1. AS-to-RS Response . . . . . . . . . . . . . . . . . . . . 6 63 5. Confirmation Method Parameters . . . . . . . . . . . . . . . 7 64 6. CBOR Mappings . . . . . . . . . . . . . . . . . . . . . . . . 8 65 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 66 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 9 67 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 68 9.1. JSON Web Token Claims . . . . . . . . . . . . . . . . . . 9 69 9.2. CBOR Web Token Claims . . . . . . . . . . . . . . . . . . 10 70 9.3. OAuth Parameter Registration . . . . . . . . . . . . . . 10 71 9.4. OAuth Introspection Response Parameter Registration . . . 10 72 9.5. Token Endpoint CBOR Mappings Registraton . . . . . . . . 11 73 9.6. Introspection Endpoint CBOR Mappings Registraton . . . . 11 74 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 75 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 76 11.1. Normative References . . . . . . . . . . . . . . . . . . 12 77 11.2. Informative References . . . . . . . . . . . . . . . . . 13 78 Appendix A. Overlap with OAuth work . . . . . . . . . . . . . . 13 79 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 81 1. Introduction 83 The Authentication and Authorization for Constrained Environments 84 (ACE) specification [I-D.ietf-ace-oauth-authz] requires some new 85 parameters for interactions with the OAuth 2.0 [RFC6749] token and 86 introspection endpoints, as well as some new claims to be used in 87 access tokens. These parameters and claims can also be used in other 88 contexts, and may need to be updated to align them with ongoing OAuth 89 work. Therefore they have been split out into this document, which 90 can be used and updated independently of [I-D.ietf-ace-oauth-authz]. 92 2. Terminology 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 96 "OPTIONAL" in this document are to be interpreted as described in BCP 97 14 [RFC2119] [RFC8174] when, and only when, they appear in all 98 capitals, as shown here. 100 Readers are assumed to be familiar with the terminology from 101 [I-D.ietf-ace-oauth-authz]. 103 Note that the term "endpoint" is used here following its OAuth 2.0 104 [RFC6749] definition, which is to denote resources such as token and 105 introspection at the AS and authz-info at the RS. The CoAP [RFC7252] 106 definition, which is "An entity participating in the CoAP protocol" 107 is not used in this specification. 109 3. Parameters for the Token Endpoint 111 3.1. Client-to-AS Request 113 This document defines the following additional parameters for 114 requesting an access token from a token endpoint in the ACE framework 115 [I-D.ietf-ace-oauth-authz]: 117 req_aud 118 OPTIONAL. Specifies the audience for which the client is 119 requesting an access token. If this parameter is missing, it is 120 assumed that the AS has a default audience for access tokens 121 issued to this client. If a client submits a request for an 122 access token without specifying a "req_aud" parameter, and the AS 123 does not have a default audience value for this client, then the 124 AS MUST respond with an error message using a response code 125 equivalent to the CoAP response code 4.00 (Bad Request). Values 126 of this parameter follow the syntax of the "aud" claim from 127 section 3.1.3 of [RFC8392]. 129 req_cnf 130 OPTIONAL. This field contains information about the key the 131 client would like to bind to the access token for proof-of- 132 possession. It is RECOMMENDED that an AS reject a request 133 containing a symmetric key value in the 'req_cnf' field, since the 134 AS is expected to be able to generate better symmetric keys than a 135 potentially constrained client. The AS MUST verify that the 136 client really is in possession of the corresponding key. Values 137 of this parameter follow the syntax of the "cnf" claim from 138 section 3.1 of [I-D.ietf-ace-cwt-proof-of-possession]. 140 Figure 1 shows a request for an access token using the "req_aud" 141 parameter to request a specific audience and the "req_cnf" parameter 142 to request a specific public key as proof-of-possession key. The 143 content is displayed in CBOR diagnostic notation, without 144 abbreviations for better readability. 146 Header: POST (Code=0.02) 147 Uri-Host: "as.example.com" 148 Uri-Path: "token" 149 Content-Format: "application/ace+cbor" 150 Payload: 151 { 152 "req_aud" : "tempSensor4711", 153 "req_cnf" : { 154 "COSE_Key" : { 155 "kty" : "EC", 156 "kid" : h'11', 157 "crv" : "P-256", 158 "x" : b64'usWxHK2PmfnHKwXPS54m0kTcGJ90UiglWiGahtagnv8', 159 "y" : b64'IBOL+C3BttVivg+lSreASjpkttcsz+1rb7btKLv8EX4' 160 } 161 } 162 } 164 Figure 1: Example request for an access token bound to an asymmetric 165 key. 167 3.2. AS-to-Client Response 169 This document defines the following additional parameters for an AS 170 response to a request to the token endpoint: 172 cnf 173 REQUIRED if the token type is "pop" and a symmetric key is used. 174 MAY be present for asymmetric proof-of-possession keys. This 175 field contains the proof-of-possession key that the AS selected 176 for the token. Values of this parameter follow the syntax of the 177 "cnf" claim from section 3.1 of 178 [I-D.ietf-ace-cwt-proof-of-possession]. See Section 5 for details 179 on the use of this parameter. 181 rs_cnf 182 OPTIONAL if the token type is "pop" and asymmetric keys are used. 183 MUST NOT be present otherwise. This field contains information 184 about the public key used by the RS to authenticate. If this 185 parameter is absent, either the RS does not use a public key or 186 the AS assumes that the client already knows the public key of the 187 RS. Values of this parameter follow the syntax of the "cnf" claim 188 from section 3.1 of [I-D.ietf-ace-cwt-proof-of-possession]. See 189 Section 5 for details on the use of this parameter. 191 Figure 2 shows an AS response containing a token and a "cnf" 192 parameter with a symmetric proof-of-possession key. 194 Header: Created (Code=2.01) 195 Content-Format: "application/ace+cbor" 196 Payload: 197 { 198 "access_token" : b64'SlAV32hkKG ... 199 (remainder of CWT omitted for brevity; 200 CWT contains COSE_Key in the "cnf" claim)', 201 "cnf" : { 202 "COSE_Key" : { 203 "kty" : "Symmetric", 204 "kid" : b64'39Gqlw', 205 "k" : b64'hJtXhkV8FJG+Onbc6mxCcQh' 206 } 207 } 208 } 210 Figure 2: Example AS response with an access token bound to a 211 symmetric key. 213 Figure 3 shows an AS response containing a token bound to a 214 previously requested asymmetric proof-of-possession key (not shown) 215 and a "rs_cnf" parameter containing the public key of the RS. 217 Header: Created (Code=2.01) 218 Content-Format: "application/ace+cbor" 219 Payload: 220 { 221 "access_token" : b64'SlAV32hkKG ... 222 (remainder of CWT omitted for brevity; 223 CWT contains COSE_Key in the "cnf" claim)', 224 "rs_cnf" : { 225 "COSE_Key" : { 226 "kty" : "EC", 227 "kid" : h'12', 228 "crv" : "P-256", 229 "x" : b64'vO5+qsFi+R5vMw9XcSEeIguLVGyWWJsKxK0P0kx34fE', 230 "y" : b64'xkezjFXvu8TmLmUXIPAC1ddbLgwCzRMm5mK8oiK5BBY' 231 } 232 } 233 } 235 Figure 3: Example AS response with an access token bound to a 236 symmetric key. 238 3.3. The Resource Server Confirmation Claim 240 If the AS needs to convey a hint to the RS about which key it should 241 use to authenticate towards the client, this specification defines 242 the "rs_cnf" claim, which MAY be used in the access token, with the 243 same syntax and semantics as defined in for the "rs_cnf" parameter. 245 4. Parameters for the Introspection Endpoint 247 4.1. AS-to-RS Response 249 This document defines the following additional parameters for an AS 250 response to a request to the introspection endpoint: 252 cnf 253 OPTIONAL. This field contains information about the proof-of- 254 possession key that binds the client to the access token. Values 255 of this parameter follow the syntax of the "cnf" claim from 256 section 3.1 of [I-D.ietf-ace-cwt-proof-of-possession]. See 257 Section 5 for more details on the use of the "cnf" parameter. 259 rs_cnf 260 OPTIONAL. If the RS uses asymmetric keys to authenticate towards 261 the client (e.g. with a DTLS-RPK handshake) and it has several 262 such keys (e.g. for different elliptic curves), the AS can give 263 the RS a hint using this parameter, as to which key it should use. 264 Values of this parameter follow the syntax of the "cnf" claim from 265 section 3.1 of [I-D.ietf-ace-cwt-proof-of-possession]. See 266 Section 5 for details on the use of this parameter. 268 Figure 4 shows an AS response to an introspection request including 269 the "cnf" parameter to indicate the proof-of-possession key bound to 270 the token and the "rs_cnf" parameter to indicate the key the RS is 271 supposed to use to authenticate to the client. 273 Header: Created Code=2.01) 274 Content-Format: "application/ace+cbor" 275 Payload: 276 { 277 "active" : true, 278 "scope" : "read", 279 "aud" : "tempSensor4711", 280 "cnf" : { 281 "COSE_Key" : { 282 "kty" : "EC", 283 "kid" : h'11', 284 "crv" : "P-256", 285 "x" : b64'usWxHK2PmfnHKwXPS54m0kTcGJ90UiglWiGahtagnv8', 286 "y" : b64'IBOL+C3BttVivg+lSreASjpkttcsz+1rb7btKLv8EX4' 287 } 288 }, 289 "rs_cnf" : { 290 "COSE_Key" : { 291 "kty" : "EC", 292 "kid" : h'12', 293 "crv" : "P-256", 294 "x" : b64'vO5+qsFi+R5vMw9XcSEeIguLVGyWWJsKxK0P0kx34fE', 295 "y" : b64'xkezjFXvu8TmLmUXIPAC1ddbLgwCzRMm5mK8oiK5BBY' 296 } 297 } 298 } 300 Figure 4: Example introspection response. 302 5. Confirmation Method Parameters 304 The confirmation method parameters are used as follows: 306 o "req_cnf" in the access token request C -> AS, OPTIONAL to 307 indicate the client's raw public key, or the key-identifier of a 308 previously established key between C and RS that the client wishes 309 to use for proof-of-possession of the access token. 310 o "cnf" in the token response AS -> C, OPTIONAL if using an 311 asymmetric key or a key that the client requested via a key 312 identifier in the request. REQUIRED if the client didn't specify 313 a "req_cnf" and symmetric keys are used. Used to indicate the 314 symmetric key generated by the AS for proof-of-possession of the 315 access token. 316 o "cnf" in the introspection response AS -> RS, REQUIRED if the 317 access token that was subject to introspection is a proof-of- 318 possession token, absent otherwise. Indicates the proof-of- 319 possession key bound to the access token. 321 o "rs_cnf" in the token response AS -> C, OPTIONAL to indicate the 322 public key of the RS, if it uses one to authenticate to the 323 client. 324 o "rs_cnf" in the introspection response AS -> RS, OPTIONAL, 325 contains the public key that the RS should use for authenticating 326 to the client (e.g. if the RS has several different public keys). 328 Note that the COSE_Key structure in a confirmation claim or parameter 329 may contain an "alg" or "key_ops" parameter. If such parameters are 330 present, a client MUST NOT use a key that is not compatible with the 331 profile or proof-of-possession algorithm according to those 332 parameters. An RS MUST reject a proof-of-possession using such a 333 key. 335 If an access token is issued for an audience that includes several 336 RS, the "rs_cnf" parameter MUST NOT be used, since the client cannot 337 determine for which RS the key applies. This document recommends to 338 specify a different endpoint that the client can use to acquire RS 339 authentication keys in such cases. The specification of such an 340 endpoint is out of scope for this document. 342 6. CBOR Mappings 344 If CBOR is used, the new parameters and claims defined in this 345 document MUST be mapped to CBOR types as specified in Figure 5, using 346 the given integer abbreviation for the map key. 348 /-----------------+----------+----------------------------------\ 349 | Parameter name | CBOR Key | Value Type | 350 |-----------------+----------+----------------------------------| 351 | req_aud | 3 | text string | 352 | cnf | 8 | map | 353 | rs_cnf | 11 | map | 354 | req_cnf | 12 | map | 355 \-----------------+----------+----------------------------------/ 357 Figure 5: CBOR mappings for new parameters. 359 7. Security Considerations 361 This document is an extension to [I-D.ietf-ace-oauth-authz]. All 362 security considerations from that document apply here as well. 364 The audience claim as defined in [RFC7519] and the equivalent 365 "req_aud" parameter are intentionally vague on how to match the 366 audience value to a specific RS. This is intended to allow 367 application specific semantics to be used. This section attempts to 368 give some general guidance for the use of audiences in constrained 369 environments. 371 URLs are not a good way of identifying mobile devices that can switch 372 networks and thus be associated with new URLs. If the audience 373 represents a single RS, and asymmetric keys are used, the RS can be 374 uniquely identified by a hash of its public key. If this approach is 375 used this framework RECOMMENDS to apply the procedure from section 3 376 of [RFC6920]. 378 If the audience addresses a group of resource servers, the mapping of 379 group identifier to individual RS has to be provisioned to each RS 380 before the group-audience is usable. Managing dynamic groups could 381 be an issue, if the RS is not always reachable when the group 382 memberships change. Furthermore issuing access tokens bound to 383 symmetric proof-of-possession keys that apply to a group-audience is 384 problematic, as an RS that is in possession of the access token can 385 impersonate the client towards the other RSs that are part of the 386 group. It is therefore NOT RECOMMENDED to issue access tokens bound 387 to a group audience and symmetric proof-of possession keys. 389 Even the client must be able to determine the correct values to put 390 into the "req_aud" parameter, in order to obtain a token for the 391 intended RS. Errors in this process can lead to the client 392 inadvertantly communicating with the wrong RS. The correct values 393 for "req_aud" can either be provisioned to the client as part of its 394 configuration, or dynamically looked up by the client in some 395 directory. In the latter case the integrity and correctness of the 396 directory data must be assured. 398 8. Privacy Considerations 400 This document is an extension to [I-D.ietf-ace-oauth-authz]. All 401 privacy considerations from that document apply here as well. 403 9. IANA Considerations 405 9.1. JSON Web Token Claims 407 This specification registers the following new claim in the JSON Web 408 Token (JWT) registry of JSON Web Token Claims 409 [IANA.JsonWebTokenClaims]: 411 o Claim Name: "rs_cnf" 412 o Claim Description: The public key the RS is supposed to use to 413 authenticate to the client wielding this token. 414 o Change Controller: IESG 415 o Reference: Section 3.3 of [this document] 417 9.2. CBOR Web Token Claims 419 This specification registers the following new claim in the "CBOR Web 420 Token (CWT) Claims" registry [IANA.CborWebTokenClaims]. 422 o Claim Name: "rs_cnf" 423 o Claim Description: The public key the RS is supposed to use to 424 authenticate to the client wielding this token. 425 o JWT Claim Name: N/A 426 o Claim Key: TBD (suggested: 40) 427 o Claim Value Type(s): map 428 o Change Controller: IESG 429 o Specification Document(s): Section 3.3 of [this document] 431 9.3. OAuth Parameter Registration 433 This section registers the following parameters in the "OAuth 434 Parameters" registry [IANA.OAuthParameters]: 436 o Name: "req_aud" 437 o Parameter Usage Location: authorization request, token request 438 o Change Controller: IESG 439 o Reference: Section 3.1 of [this document] 441 o Name: "req_cnf" 442 o Parameter Usage Location: token request 443 o Change Controller: IESG 444 o Reference: Section 5 of [this document] 446 o Name: "rs_cnf" 447 o Parameter Usage Location: token response 448 o Change Controller: IESG 449 o Reference: Section 5 of [this document] 451 o Name: "cnf" 452 o Parameter Usage Location: token response 453 o Change Controller: IESG 454 o Reference: Section 5 of [this document] 456 9.4. OAuth Introspection Response Parameter Registration 458 This section registers the following parameters in the OAuth Token 459 Introspection Response registry [IANA.TokenIntrospectionResponse]. 461 o Name: "cnf" 462 o Description: Key to prove the right to use a PoP token. 463 o Change Controller: IESG 464 o Reference: Section 4.1 of [this document] 465 o Name: "rs_cnf" 466 o Description: The key the RS should use to authenticate to the 467 client. 468 o Change Controller: IESG 469 o Reference: Section 4.1 of [this document] 471 9.5. Token Endpoint CBOR Mappings Registraton 473 This section registers teh following parameter mappings in the "Token 474 Endpoint CBOR Mappings" registry established in section 8.9. of 475 [I-D.ietf-ace-oauth-authz]. 477 o Name: "req_aud" 478 o CBOR key: 18 479 o Change Controller: IESG 480 o Reference: Section 3.1 of [this document] 482 o Name: "req_cnf" 483 o CBOR key: 19 484 o Change Controller: IESG 485 o Reference: Section 3.1 of [this document] 487 o Name: "cnf" 488 o CBOR key: 8 489 o Change Controller: IESG 490 o Reference: Section 3.2 of [this document] 492 o Name: "rs_cnf" 493 o CBOR key: 17 494 o Change Controller: IESG 495 o Reference: Section 3.2 of [this document] 497 9.6. Introspection Endpoint CBOR Mappings Registraton 499 This section registers teh following parameter mappings in the 500 "Introspection Endpoint CBOR Mappings" registry established in 501 section 8.11. of [I-D.ietf-ace-oauth-authz]. 503 o Name: "cnf" 504 o CBOR key: 8 505 o Change Controller: IESG 506 o Reference: Section 4.1 of [this document] 508 o Name: "rs_cnf" 509 o CBOR key: 17 510 o Change Controller: IESG 511 o Reference: Section 4.1 of [this document] 513 10. Acknowledgments 515 This document is a product of the ACE working group of the IETF. 517 Ludwig Seitz worked on this document as part of the CelticPlus 518 project CyberWI, with funding from Vinnova. 520 11. References 522 11.1. Normative References 524 [I-D.ietf-ace-cwt-proof-of-possession] 525 Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. 526 Tschofenig, "Proof-of-Possession Key Semantics for CBOR 527 Web Tokens (CWTs)", draft-ietf-ace-cwt-proof-of- 528 possession-05 (work in progress), November 2018. 530 [I-D.ietf-ace-oauth-authz] 531 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 532 H. Tschofenig, "Authentication and Authorization for 533 Constrained Environments (ACE) using the OAuth 2.0 534 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-18 535 (work in progress), January 2019. 537 [IANA.CborWebTokenClaims] 538 IANA, "CBOR Web Token (CWT) Claims", 539 . 542 [IANA.JsonWebTokenClaims] 543 IANA, "JSON Web Token Claims", 544 . 546 [IANA.OAuthParameters] 547 IANA, "OAuth Parameters", 548 . 551 [IANA.TokenIntrospectionResponse] 552 IANA, "OAuth Token Introspection Response", 553 . 556 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 557 Requirement Levels", BCP 14, RFC 2119, 558 DOI 10.17487/RFC2119, March 1997, . 561 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 562 RFC 6749, DOI 10.17487/RFC6749, October 2012, 563 . 565 [RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., 566 Keranen, A., and P. Hallam-Baker, "Naming Things with 567 Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013, 568 . 570 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 571 Application Protocol (CoAP)", RFC 7252, 572 DOI 10.17487/RFC7252, June 2014, . 575 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 576 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 577 May 2017, . 579 [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 580 "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, 581 May 2018, . 583 11.2. Informative References 585 [I-D.ietf-oauth-pop-key-distribution] 586 Bradley, J., Hunt, P., Jones, M., Tschofenig, H., and M. 587 Mihaly, "OAuth 2.0 Proof-of-Possession: Authorization 588 Server to Client Key Distribution", draft-ietf-oauth-pop- 589 key-distribution-04 (work in progress), October 2018. 591 [I-D.ietf-oauth-resource-indicators] 592 Campbell, B., Bradley, J., and H. Tschofenig, "Resource 593 Indicators for OAuth 2.0", draft-ietf-oauth-resource- 594 indicators-02 (work in progress), January 2019. 596 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 597 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 598 . 600 Appendix A. Overlap with OAuth work 602 This document overlaps with draft work from OAuth, namely 603 [I-D.ietf-oauth-pop-key-distribution] and 604 [I-D.ietf-oauth-resource-indicators]. 606 The former specifies the use of "req_cnf" and "cnf" for requesting 607 proof-of-possession tokens and indicating the key that the AS has 608 selected. It it was initially deemed that the work at OAuth had been 609 discontinued and therefore equivalent functionality was defined here. 610 Work in OAuth has since resumed, but it is lagging behind the planned 611 milestones of the ACE working group. We have therefore split this 612 work out into a separate document so that it can later be updated or 613 obsoleted to align it with the final result of the OAuth work, 614 without affecting [I-D.ietf-ace-oauth-authz]. 616 The latter defines the use of the "resource" parameter, allowing to 617 indicate the location fo the target service or resource where access 618 is being requested. This partially overlaps with the "req_aud" 619 parameter specified here, however the definition of "req_aud" is more 620 broad, since it can be used in an application specific way that is 621 not necessarily bound to the location of the target audience (e.g. a 622 group identifier referring to several resource servers, or the public 623 key of a resource server). 625 Author's Address 627 Ludwig Seitz 628 RISE 629 Scheelevaegen 17 630 Lund 223 70 631 Sweden 633 Email: ludwig.seitz@ri.se