idnits 2.17.1 draft-ietf-oauth-pop-key-distribution-07.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (March 27, 2019) is 1856 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) == Unused Reference: '3' is defined on line 573, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 608, but no explicit reference was found in the text == Unused Reference: '18' is defined on line 640, but no explicit reference was found in the text == Unused Reference: '20' is defined on line 650, but no explicit reference was found in the text == Unused Reference: '21' is defined on line 655, but no explicit reference was found in the text == Unused Reference: '26' is defined on line 677, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5246 (ref. '4') (Obsoleted by RFC 8446) == Outdated reference: A later version (-11) exists of draft-ietf-ace-cwt-proof-of-possession-06 ** Obsolete normative reference: RFC 8152 (ref. '14') (Obsoleted by RFC 9052, RFC 9053) == Outdated reference: A later version (-19) exists of draft-ietf-oauth-token-exchange-16 == Outdated reference: A later version (-08) exists of draft-ietf-oauth-resource-indicators-02 == Outdated reference: A later version (-46) exists of draft-ietf-ace-oauth-authz-24 Summary: 2 errors (**), 0 flaws (~~), 12 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Bradley 3 Internet-Draft Ping Identity 4 Intended status: Standards Track P. Hunt 5 Expires: September 28, 2019 Oracle Corporation 6 M. Jones 7 Microsoft 8 H. Tschofenig 9 Arm Ltd. 10 M. Meszaros 11 GITDA 12 March 27, 2019 14 OAuth 2.0 Proof-of-Possession: Authorization Server to Client Key 15 Distribution 16 draft-ietf-oauth-pop-key-distribution-07 18 Abstract 20 RFC 6750 specified the bearer token concept for securing access to 21 protected resources. Bearer tokens need to be protected in transit 22 as well as at rest. When a client requests access to a protected 23 resource it hands-over the bearer token to the resource server. 25 The OAuth 2.0 Proof-of-Possession security concept extends bearer 26 token security and requires the client to demonstrate possession of a 27 key when accessing a protected resource. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on September 28, 2019. 46 Copyright Notice 48 Copyright (c) 2019 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3. Processing Instructions . . . . . . . . . . . . . . . . . . . 4 66 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 4.1. Symmetric Key Transport . . . . . . . . . . . . . . . . . 5 68 4.1.1. Client-to-AS Request . . . . . . . . . . . . . . . . 5 69 4.1.2. Client-to-AS Response . . . . . . . . . . . . . . . . 6 70 4.2. Asymmetric Key Transport . . . . . . . . . . . . . . . . 9 71 4.2.1. Client-to-AS Request . . . . . . . . . . . . . . . . 9 72 4.2.2. Client-to-AS Response . . . . . . . . . . . . . . . . 10 73 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 74 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 75 6.1. OAuth Access Token Types . . . . . . . . . . . . . . . . 13 76 6.2. OAuth Parameters Registration . . . . . . . . . . . . . . 13 77 6.3. OAuth Extensions Error Registration . . . . . . . . . . . 13 78 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 79 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 80 8.1. Normative References . . . . . . . . . . . . . . . . . . 14 81 8.2. Informative References . . . . . . . . . . . . . . . . . 15 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 84 1. Introduction 86 The work on proof-of-possession tokens, an extended token security 87 mechanisms for OAuth 2.0, is motivated in [22]. This document 88 defines the ability for the client request and to obtain PoP tokens 89 from the authorization server. After successfully completing the 90 exchange the client is in possession of a PoP token and the keying 91 material bound to it. Clients that access protected resources then 92 need to demonstrate knowledge of the secret key that is bound to the 93 PoP token. 95 To best describe the scope of this specification, the OAuth 2.0 96 protocol exchange sequence is shown in Figure 1. The extension 97 defined in this document piggybacks on the message exchange marked 98 with (C) and (D). To demonstrate possession of the private/secret 99 key to the resource server protocol mechanisms outside the scope of 100 this document are used. 102 +--------+ +---------------+ 103 | |--(A)- Authorization Request ->| Resource | 104 | | | Owner | 105 | |<-(B)-- Authorization Grant ---| | 106 | | +---------------+ 107 | | 108 | | +---------------+ 109 | |--(C)-- Authorization Grant -->| | 110 | Client | (resource, req_cnf) | Authorization | 111 | | | Server | 112 | |<-(D)-- PoP Access Token ------| | 113 | | (rs_cnf, token_type) +---------------+ 114 | | 115 | | +---------------+ 116 | |--(E)-- PoP Access Token ----->| | 117 | | (with proof of private key) | Resource | 118 | | | Server | 119 | |<-(F)--- Protected Resource ---| | 120 +--------+ +---------------+ 122 Figure 1: Augmented OAuth 2.0 Protocol Flow 124 In OAuth 2.0 [2] access tokens can be obtained via authorization 125 grants and using refresh tokens. The core OAuth specification 126 defines four authorization grants, see Section 1.3 of [2], and [19] 127 adds an assertion-based authorization grant to that list. The token 128 endpoint, which is described in Section 3.2 of [2], is used with 129 every authorization grant except for the implicit grant type. In the 130 implicit grant type the access token is issued directly. 132 This specification extends the functionality of the token endpoint, 133 i.e., the protocol exchange between the client and the authorization 134 server, to allow keying material to be bound to an access token. Two 135 types of keying material can be bound to an access token, namely 136 symmetric keys and asymmetric keys. Conveying symmetric keys from 137 the authorization server to the client is described in Section 4.1 138 and the procedure for dealing with asymmetric keys is described in 139 Section 4.2. 141 This document describes how the client requests and obtains a PoP 142 access token from the authorization server for use with HTTPS-based 143 transport. The use of alternative transports, such as Constrained 144 Application Protocol (CoAP), is described in [24]. 146 2. Terminology 148 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 149 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this 150 specification are to be interpreted as described in [1]. 152 Session Key: 154 In the context of this specification 'session key' refers to fresh 155 and unique keying material established between the client and the 156 resource server. This session key has a lifetime that corresponds 157 to the lifetime of the access token, is generated by the 158 authorization server and bound to the access token. 160 This document uses the following abbreviations: 162 JWA: JSON Web Algorithms[7] 164 JWT: JSON Web Token[9] 166 JWS: JSON Web Signature[6] 168 JWK: JSON Web Key[5] 170 JWE: JSON Web Encryption[8] 172 CWT: CBOR Web Token[13] 174 COSE: CBOR Object Signing and Encryption[14] 176 3. Processing Instructions 178 Step (0): As an initial step the client typically determines the 179 resource server it wants to interact with. This may, for example, 180 happen as part of a discovery procedure or via manual 181 configuration. 183 Step (1): The client starts the OAuth 2.0 protocol interaction 184 based on the selected grant type. 186 Step (2): When the client interacts with the token endpoint to 187 obtain an access token it MUST use the resource identicator 188 parameter, defined in [16], or the audience parameter, defined in 189 [15], when symmetric PoP tokens are used. For asymmetric PoP 190 tokens the use of resource indicators and audience is optional but 191 RECOMMENDED. The parameters 'audience' and 'resource' both allow 192 the client to express the location of the target service and the 193 difference between the two is described in [15]. As a summary, 194 'audience' allows expressing a logical name while 'resource' 195 contains an absolute URI. More details about the 'resource' 196 parameter can be found in [16]. 198 Step (3): The authorization server parses the request from the 199 server and determines the suitable response based on OAuth 2.0 and 200 the PoP token credential procedures. 202 Note that PoP access tokens may be encoded in a variety of ways: 204 JWT The access token may be encoded using the JSON Web Token (JWT) 205 format [9]. The proof-of-possession token functionality is 206 described in [10]. A JWT encoded PoP token MUST be protected 207 against modification by either using a digital signature or a 208 keyed message digest, as described in [6]. The JWT may also be 209 encrypted using [8]. 211 CWT [13] defines an alternative token format based on CBOR. The 212 proof-of-possession token functionality is defined in [12]. A CWT 213 encoded PoP token MUST be protected against modification by either 214 using a digital signature or a keyed message digest, as described 215 in [12]. 217 If the access token is only a reference then a look-up by the 218 resource server is needed, as described in the token introspection 219 specification [23]. 221 Note that the OAuth 2.0 framework nor this specification does not 222 mandate a specific PoP token format but using a standardized format 223 will improve interoperability and will lead to better code re-use. 225 Application layer interactions between the client and the resource 226 server are beyond the scope of this document. 228 4. Examples 230 This section provides a number of examples. 232 4.1. Symmetric Key Transport 234 4.1.1. Client-to-AS Request 236 The client starts with a request to the authorization server 237 indicating that it is interested to obtain a token for 238 https://resource.example.com 239 POST /token HTTP/1.1 240 Host: authz.example.com 241 Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW 242 Content-Type: application/x-www-form-urlencoded;charset=UTF-8 244 grant_type=authorization_code 245 &code=SplxlOBeZQQYbYS6WxSbIA 246 &scope=calendar%20contacts 247 &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb 248 &resource=https%3A%2F%2Fresource.example.com 250 Example Request to the Authorization Server 252 4.1.2. Client-to-AS Response 254 If the access token request has been successfully verified by the 255 authorization server and the client is authorized to obtain a PoP 256 token for the indicated resource server, the authorization server 257 issues an access token and optionally a refresh token. 259 Figure 2 shows a response containing a token and a "cnf" parameter 260 with a symmetric proof-of-possession key both encoded in a JSON-based 261 serialization format. The "cnf" parameter contains the RFC 7517 [5] 262 encoded key element. 264 HTTP/1.1 200 OK 265 Content-Type: application/json 266 Cache-Control: no-store 268 { 269 "access_token":"SlAV32hkKG ... 270 (remainder of JWT omitted for brevity; 271 JWT contains JWK in the cnf claim)", 272 "token_type":"pop", 273 "expires_in":3600, 274 "refresh_token":"8xLOxBtZp8", 275 "cnf":{ 276 {"keys": 277 [ 278 {"kty":"oct", 279 "alg":"A128KW", 280 "k":"GawgguFyGrWKav7AX4VKUg" 281 } 282 ] 283 } 284 } 285 } 287 Figure 2: Example: Response from the Authorization Server (Symmetric 288 Variant) 290 Note that the cnf payload in Figure 2 is not encrypted at the 291 application layer since Transport Layer Security is used between the 292 AS and the client and the content of the cnf payload is consumed by 293 the client itself. Alternatively, a JWE could be used to encrypt the 294 key distribution, as shown in Figure 3. 296 { 297 "access_token":"SlAV32hkKG ... 298 (remainder of JWT omitted for brevity; 299 JWT contains JWK in the cnf claim)", 300 "token_type":"pop", 301 "expires_in":3600, 302 "refresh_token":"8xLOxBtZp8", 303 "cnf":{ 304 "jwe": 305 "eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkExMjhDQkMtSFMyNTYifQ. 306 (remainder of JWE omitted for brevity)" 307 } 308 } 309 } 311 Figure 3: Example: Encrypted Symmmetric Key 313 The content of the 'access_token' in JWT format contains the 'cnf' 314 (confirmation) claim. The confirmation claim is defined in [10]. 315 The digital signature or the keyed message digest offering integrity 316 protection is not shown in this example but has to be present in a 317 real deployment to mitigate a number of security threats. 319 The JWK in the key element of the response from the authorization 320 server, as shown in Figure 2, contains the same session key as the 321 JWK inside the access token, as shown in Figure 4. It is, in this 322 example, protected by TLS and transmitted from the authorization 323 server to the client (for processing by the client). 325 { 326 "iss": "https://server.example.com", 327 "sub": "24400320", 328 "aud": "s6BhdRkqt3", 329 "exp": 1311281970, 330 "iat": 1311280970, 331 "cnf":{ 332 "jwe": 333 "eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkExMjhDQkMtSFMyNTYifQ. 334 (remainder of JWE omitted for brevity)" 335 } 336 } 338 Figure 4: Example: Access Token in JWT Format 340 Note: When the JWK inside the access token contains a symmetric key 341 it must be confidentiality protected using a JWE to maintain the 342 security goals of the PoP architecture since content is meant for 343 consumption by the selected resource server only. The details are 344 described in [22]. 346 4.2. Asymmetric Key Transport 348 4.2.1. Client-to-AS Request 350 This example illustrates the case where an asymmetric key shall be 351 bound to an access token. The client makes the following HTTPS 352 request shown in Figure 5. Extra line breaks are for display 353 purposes only. 355 POST /token HTTP/1.1 356 Host: server.example.com 357 Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW 358 Content-Type: application/x-www-form-urlencoded;charset=UTF-8 360 grant_type=authorization_code 361 &code=SplxlOBeZQQYbYS6WxSbIA 362 &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb 363 &token_type=pop 364 &req_cnf=eyJhbGciOiJSU0ExXzUi ... 365 (remainder of JWK omitted for brevity) 367 Figure 5: Example Request to the Authorization Server (Asymmetric Key 368 Variant) 370 As shown in Figure 6 the content of the 'req_cnf' parameter contains 371 the ECC public key the client would like to associate with the access 372 token (in JSON format). 374 "jwk":{ 375 "kty": "EC", 376 "use": "sig", 377 "crv": "P-256", 378 "x": "18wHLeIgW9wVN6VD1Txgpqy2LszYkMf6J8njVAibvhM", 379 "y": "-V4dS4UaLMgP_4fY4j8ir7cl1TXlFdAgcx55o7TkcSA" 380 } 382 Figure 6: Client Providing Public Key to Authorization Server 384 4.2.2. Client-to-AS Response 386 If the access token request is valid and authorized, the 387 authorization server issues an access token and optionally a refresh 388 token. The authorization server also places information about the 389 public key used by the client into the access token to create the 390 binding between the two. The new token type "pop" is placed into the 391 'token_type' parameter. 393 An example of a successful response is shown in Figure 7. 395 HTTP/1.1 200 OK 396 Content-Type: application/json;charset=UTF-8 397 Cache-Control: no-store 398 Pragma: no-cache 400 { 401 "access_token":"2YotnFZFE....jr1zCsicMWpAA", 402 "token_type":"pop", 403 "expires_in":3600, 404 "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA" 405 } 407 Figure 7: Example: Response from the Authorization Server (Asymmetric 408 Variant) 410 The content of the 'access_token' field contains an encoded JWT, as 411 shown in Figure 8. The digital signature covering the access token 412 offering authenticity and integrity protection is not shown below 413 (but must be present). 415 { 416 "iss":"https://authz.example.com", 417 "aud":"https://resource.example.com", 418 "exp":"1361398824", 419 "nbf":"1360189224", 420 "cnf":{ 421 "jwk" : { 422 "kty" : "EC", 423 "crv" : "P-256", 424 "x" : "usWxHK2PmfnHKwXPS54m0kTcGJ90UiglWiGahtagnv8", 425 "y" : "IBOL+C3BttVivg+lSreASjpkttcsz+1rb7btKLv8EX4" 426 } 427 } 428 } 430 Figure 8: Example: Access Token Structure (Asymmetric Variant) 432 Note: In this example there is no need for the authorization server 433 to convey further keying material to the client since the client is 434 already in possession of the private key (as well as the public key). 436 5. Security Considerations 438 [22] describes the architecture for the OAuth 2.0 proof-of-possession 439 security architecture, including use cases, threats, and 440 requirements. This requirements describes one solution component of 441 that architecture, namely the mechanism for the client to interact 442 with the authorization server to either obtain a symmetric key from 443 the authorization server, to obtain an asymmetric key pair, or to 444 offer a public key to the authorization. In any case, these keys are 445 then bound to the access token by the authorization server. 447 To summarize the main security recommendations: A large range of 448 threats can be mitigated by protecting the contents of the access 449 token by using a digital signature or a keyed message digest. 450 Consequently, the token integrity protection MUST be applied to 451 prevent the token from being modified, particularly since it contains 452 a reference to the symmetric key or the asymmetric key. If the 453 access token contains the symmetric key (see Section 2.2 of [10] for 454 a description about how symmetric keys can be securely conveyed 455 within the access token) this symmetric key MUST be encrypted by the 456 authorization server with a long-term key shared with the resource 457 server. 459 To deal with token redirect, it is important for the authorization 460 server to include the identity of the intended recipient (the 461 audience), typically a single resource server (or a list of resource 462 servers), in the token. Using a single shared secret with multiple 463 authorization server to simplify key management is NOT RECOMMENDED 464 since the benefit from using the proof-of-possession concept is 465 significantly reduced. 467 Token replay is also not possible since an eavesdropper will also 468 have to obtain the corresponding private key or shared secret that is 469 bound to the access token. Nevertheless, it is good practice to 470 limit the lifetime of the access token and therefore the lifetime of 471 associated key. 473 The authorization server MUST offer confidentiality protection for 474 any interactions with the client. This step is extremely important 475 since the client will obtain the session key from the authorization 476 server for use with a specific access token. Not using 477 confidentiality protection exposes this secret (and the access token) 478 to an eavesdropper thereby making the OAuth 2.0 proof-of-possession 479 security model completely insecure. OAuth 2.0 [2] relies on TLS to 480 offer confidentiality protection and additional protection can be 481 applied using the JWK [5] offered security mechanism, which would add 482 an additional layer of protection on top of TLS for cases where the 483 keying material is conveyed, for example, to a hardware security 484 module. Which version(s) of TLS ought to be implemented will vary 485 over time, and depend on the widespread deployment and known security 486 vulnerabilities at the time of implementation. At the time of this 487 writing, TLS version 1.2 [4] is the most recent version. The client 488 MUST validate the TLS certificate chain when making requests to 489 protected resources, including checking the validity of the 490 certificate. 492 Similarly to the security recommendations for the bearer token 493 specification [17] developers MUST ensure that the ephemeral 494 credentials (i.e., the private key or the session key) is not leaked 495 to third parties. An adversary in possession of the ephemeral 496 credentials bound to the access token will be able to impersonate the 497 client. Be aware that this is a real risk with many smart phone app 498 and Web development environments. 500 Clients can at any time request a new proof-of-possession capable 501 access token. Using a refresh token to regularly request new access 502 tokens that are bound to fresh and unique keys is important. Keeping 503 the lifetime of the access token short allows the authorization 504 server to use shorter key sizes, which translate to a performance 505 benefit for the client and for the resource server. Shorter keys 506 also lead to shorter messages (particularly with asymmetric keying 507 material). 509 When authorization servers bind symmetric keys to access tokens then 510 they SHOULD scope these access tokens to a specific permissions. 512 6. IANA Considerations 514 6.1. OAuth Access Token Types 516 This specification registers the following error in the IANA "OAuth 517 Access Token Types" [25] established by [17]. 519 o Name: pop 520 o Change controller: IESG 521 o Specification document(s): [[ this specification ]] 523 6.2. OAuth Parameters Registration 525 This specification registers the following value in the IANA "OAuth 526 Parameters" registry [25] established by [2]. 528 o Parameter name: cnf_req 529 o Parameter usage location: authorization request, token request 530 o Change controller: IESG 531 o Specification document(s): [[ this specification ]] 533 o Parameter name: cnf 534 o Parameter usage location: authorization response, token response 535 o Change controller: IESG 536 o Specification document(s): [[ this specification ]] 538 o Parameter name: rs_cnf 539 o Parameter usage location: token response 540 o Change controller: IESG 541 o Specification document(s): [[ this specification ]] 543 6.3. OAuth Extensions Error Registration 545 This specification registers the following error in the IANA "OAuth 546 Extensions Error Registry" [25] established by [2]. 548 o Error name: invalid_token_type 549 o Error usage location: implicit grant error response, token error 550 response 551 o Related protocol extension: token_type parameter 552 o Change controller: IESG 553 o Specification document(s): [[ this specification ]] 555 7. Acknowledgements 557 We would like to thank Chuck Mortimore and James Manger for their 558 review comments. 560 8. References 562 8.1. Normative References 564 [1] Bradner, S., "Key words for use in RFCs to Indicate 565 Requirement Levels", BCP 14, RFC 2119, 566 DOI 10.17487/RFC2119, March 1997, 567 . 569 [2] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 570 RFC 6749, DOI 10.17487/RFC6749, October 2012, 571 . 573 [3] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 574 Resource Identifier (URI): Generic Syntax", STD 66, 575 RFC 3986, DOI 10.17487/RFC3986, January 2005, 576 . 578 [4] Dierks, T. and E. Rescorla, "The Transport Layer Security 579 (TLS) Protocol Version 1.2", RFC 5246, 580 DOI 10.17487/RFC5246, August 2008, 581 . 583 [5] Jones, M., "JSON Web Key (JWK)", RFC 7517, 584 DOI 10.17487/RFC7517, May 2015, 585 . 587 [6] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 588 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 589 2015, . 591 [7] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, 592 DOI 10.17487/RFC7518, May 2015, 593 . 595 [8] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", 596 RFC 7516, DOI 10.17487/RFC7516, May 2015, 597 . 599 [9] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 600 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 601 . 603 [10] Jones, M., Bradley, J., and H. Tschofenig, "Proof-of- 604 Possession Key Semantics for JSON Web Tokens (JWTs)", 605 RFC 7800, DOI 10.17487/RFC7800, April 2016, 606 . 608 [11] Jones, M. and N. Sakimura, "JSON Web Key (JWK) 609 Thumbprint", RFC 7638, DOI 10.17487/RFC7638, September 610 2015, . 612 [12] Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. 613 Tschofenig, "Proof-of-Possession Key Semantics for CBOR 614 Web Tokens (CWTs)", draft-ietf-ace-cwt-proof-of- 615 possession-06 (work in progress), February 2019. 617 [13] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 618 "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, 619 May 2018, . 621 [14] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 622 RFC 8152, DOI 10.17487/RFC8152, July 2017, 623 . 625 [15] Jones, M., Nadalin, A., Campbell, B., Bradley, J., and C. 626 Mortimore, "OAuth 2.0 Token Exchange", draft-ietf-oauth- 627 token-exchange-16 (work in progress), October 2018. 629 [16] Campbell, B., Bradley, J., and H. Tschofenig, "Resource 630 Indicators for OAuth 2.0", draft-ietf-oauth-resource- 631 indicators-02 (work in progress), January 2019. 633 8.2. Informative References 635 [17] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization 636 Framework: Bearer Token Usage", RFC 6750, 637 DOI 10.17487/RFC6750, October 2012, 638 . 640 [18] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 641 Specifications: ABNF", STD 68, RFC 5234, 642 DOI 10.17487/RFC5234, January 2008, 643 . 645 [19] Campbell, B., Mortimore, C., Jones, M., and Y. Goland, 646 "Assertion Framework for OAuth 2.0 Client Authentication 647 and Authorization Grants", RFC 7521, DOI 10.17487/RFC7521, 648 May 2015, . 650 [20] Sakimura, N., Ed., Bradley, J., and N. Agarwal, "Proof Key 651 for Code Exchange by OAuth Public Clients", RFC 7636, 652 DOI 10.17487/RFC7636, September 2015, 653 . 655 [21] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and 656 P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol", 657 RFC 7591, DOI 10.17487/RFC7591, July 2015, 658 . 660 [22] Hunt, P., Richer, J., Mills, W., Mishra, P., and H. 661 Tschofenig, "OAuth 2.0 Proof-of-Possession (PoP) Security 662 Architecture", draft-ietf-oauth-pop-architecture-08 (work 663 in progress), July 2016. 665 [23] Richer, J., Ed., "OAuth 2.0 Token Introspection", 666 RFC 7662, DOI 10.17487/RFC7662, October 2015, 667 . 669 [24] Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 670 H. Tschofenig, "Authentication and Authorization for 671 Constrained Environments (ACE) using the OAuth 2.0 672 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-24 673 (work in progress), March 2019. 675 [25] IANA, "OAuth Parameters", October 2018. 677 [26] IANA, "JSON Web Token Claims", June 2018. 679 Authors' Addresses 681 John Bradley 682 Ping Identity 684 Email: ve7jtb@ve7jtb.com 685 URI: http://www.thread-safe.com/ 687 Phil Hunt 688 Oracle Corporation 690 Email: phil.hunt@yahoo.com 691 URI: http://www.indepdentid.com 693 Michael B. Jones 694 Microsoft 696 Email: mbj@microsoft.com 697 URI: http://self-issued.info/ 698 Hannes Tschofenig 699 Arm Ltd. 700 Absam 6067 701 Austria 703 Email: Hannes.Tschofenig@gmx.net 704 URI: http://www.tschofenig.priv.at 706 Mihaly Meszaros 707 GITDA 708 Debrecen 4033 709 Hungary 711 Email: bakfitty@gmail.com 712 URI: https://github.com/misi