idnits 2.17.1 draft-ietf-oauth-pop-key-distribution-06.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 11, 2019) is 1873 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 567, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 602, but no explicit reference was found in the text == Unused Reference: '17' is defined on line 630, but no explicit reference was found in the text == Unused Reference: '19' is defined on line 640, but no explicit reference was found in the text == Unused Reference: '20' is defined on line 645, but no explicit reference was found in the text == Unused Reference: '25' is defined on line 667, 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 (-08) exists of draft-ietf-oauth-resource-indicators-02 == Outdated reference: A later version (-46) exists of draft-ietf-ace-oauth-authz-22 Summary: 2 errors (**), 0 flaws (~~), 11 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 12, 2019 Oracle Corporation 6 M. Jones 7 Microsoft 8 H. Tschofenig 9 Arm Ltd. 10 M. Meszaros 11 GITDA 12 March 11, 2019 14 OAuth 2.0 Proof-of-Possession: Authorization Server to Client Key 15 Distribution 16 draft-ietf-oauth-pop-key-distribution-06 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 12, 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 . . . . . . . . . . . . . . . . . . . . . . 14 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 [21]. 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 [18] 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 [23]. 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 defined in [15] when symmetric PoP tokens are used. For 189 asymmetric PoP tokens the use of resource indicators is optional 190 but recommended. 192 Step (3): The authorization server parses the request from the 193 server and determines the suitable response based on OAuth 2.0 and 194 the PoP token credential procedures. 196 Note that PoP access tokens may be encoded in a variety of ways: 198 JWT The access token may be encoded using the JSON Web Token (JWT) 199 format [9]. The proof-of-possession token functionality is 200 described in [10]. A JWT encoded PoP token MUST be protected 201 against modification by either using a digital signature or a 202 keyed message digest, as described in [6]. The JWT may also be 203 encrypted using [8]. 205 CWT [13] defines an alternative token format based on CBOR. The 206 proof-of-possession token functionality is defined in [12]. A CWT 207 encoded PoP token MUST be protected against modification by either 208 using a digital signature or a keyed message digest, as described 209 in [12]. 211 If the access token is only a reference then a look-up by the 212 resource server is needed, as described in the token introspection 213 specification [22]. 215 Note that the OAuth 2.0 framework nor this specification does not 216 mandate a specific PoP token format but using a standardized format 217 will improve interoperability and will lead to better code re-use. 219 Application layer interactions between the client and the resource 220 server are beyond the scope of this document. 222 4. Examples 224 This section provides a number of examples. 226 4.1. Symmetric Key Transport 228 4.1.1. Client-to-AS Request 230 The client starts with a request to the authorization server 231 indicating that it is interested to obtain a token for 232 https://www.example.com 233 POST /token HTTP/1.1 234 Host: server.example.com 235 Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW 236 Content-Type: application/x-www-form-urlencoded;charset=UTF-8 238 grant_type=authorization_code 239 &code=SplxlOBeZQQYbYS6WxSbIA 240 &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb 241 &resource=https://www.example.com 243 Example Request to the Authorization Server 245 4.1.2. Client-to-AS Response 247 If the access token request has been successfully verified by the 248 authorization server and the client is authorized to obtain a PoP 249 token for the indicated resource server, the authorization server 250 issues an access token and optionally a refresh token. 252 Figure 2 shows a response containing a token and a "cnf" parameter 253 with a symmetric proof-of-possession key both encoded in a JSON-based 254 serialization format. The "cnf" parameter contains the RFC 7517 [5] 255 encoded key element. 257 HTTP/1.1 200 OK 258 Content-Type: application/json 259 Cache-Control: no-store 261 { 262 "access_token":"SlAV32hkKG ... 263 (remainder of JWT omitted for brevity; 264 JWT contains JWK in the cnf claim)", 265 "token_type":"pop", 266 "expires_in":3600, 267 "refresh_token":"8xLOxBtZp8", 268 "cnf":{ 269 {"keys": 270 [ 271 {"kty":"oct", 272 "alg":"A128KW", 273 "k":"GawgguFyGrWKav7AX4VKUg" 274 } 275 ] 276 } 277 } 278 } 280 Figure 2: Example: Response from the Authorization Server (Symmetric 281 Variant) 283 Note that the cnf payload in Figure 2 is not encrypted at the 284 application layer since Transport Layer Security is used between the 285 AS and the client and the content of the cnf payload is consumed by 286 the client itself. Alternatively, a JWE could be used to encrypt the 287 key distribution, as shown in Figure 3. 289 { 290 "access_token":"SlAV32hkKG ... 291 (remainder of JWT omitted for brevity; 292 JWT contains JWK in the cnf claim)", 293 "token_type":"pop", 294 "expires_in":3600, 295 "refresh_token":"8xLOxBtZp8", 296 "cnf":{ 297 "jwe": 298 "eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkExMjhDQkMtSFMyNTYifQ. 299 (remainder of JWE omitted for brevity)" 300 } 301 } 302 } 304 Figure 3: Example: Encrypted Symmmetric Key 306 The content of the 'access_token' in JWT format contains the 'cnf' 307 (confirmation) claim. The confirmation claim is defined in [10]. 308 The digital signature or the keyed message digest offering integrity 309 protection is not shown in this example but has to be present in a 310 real deployment to mitigate a number of security threats. 312 The JWK in the key element of the response from the authorization 313 server, as shown in Figure 2, contains the same session key as the 314 JWK inside the access token, as shown in Figure 4. It is, in this 315 example, protected by TLS and transmitted from the authorization 316 server to the client (for processing by the client). 318 { 319 "iss": "https://server.example.com", 320 "sub": "24400320", 321 "aud": "s6BhdRkqt3", 322 "nonce": "n-0S6_WzA2Mj", 323 "exp": 1311281970, 324 "iat": 1311280970, 325 "cnf":{ 326 "jwe": 327 "eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkExMjhDQkMtSFMyNTYifQ. 328 (remainder of JWE omitted for brevity)" 329 } 330 } 332 Figure 4: Example: Access Token in JWT Format 334 Note: When the JWK inside the access token contains a symmetric key 335 it must be confidentiality protected using a JWE to maintain the 336 security goals of the PoP architecture since content is meant for 337 consumption by the selected resource server only. The details are 338 described in [21]. 340 4.2. Asymmetric Key Transport 342 4.2.1. Client-to-AS Request 344 This example illustrates the case where an asymmetric key shall be 345 bound to an access token. The client makes the following HTTPS 346 request shown in Figure 5. Extra line breaks are for display 347 purposes only. 349 POST /token HTTP/1.1 350 Host: server.example.com 351 Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW 352 Content-Type: application/x-www-form-urlencoded;charset=UTF-8 354 grant_type=authorization_code 355 &code=SplxlOBeZQQYbYS6WxSbIA 356 &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb 357 &token_type=pop 358 &req_cnf=eyJhbGciOiJSU0ExXzUi ... 359 (remainder of JWK omitted for brevity) 361 Figure 5: Example Request to the Authorization Server (Asymmetric Key 362 Variant) 364 As shown in Figure 6 the content of the 'req_cnf' parameter contains 365 the ECC public key the client would like to associate with the access 366 token (in JSON format). 368 "jwk":{ 369 "kty": "EC", 370 "use": "sig", 371 "crv": "P-256", 372 "x": "18wHLeIgW9wVN6VD1Txgpqy2LszYkMf6J8njVAibvhM", 373 "y": "-V4dS4UaLMgP_4fY4j8ir7cl1TXlFdAgcx55o7TkcSA" 374 } 376 Figure 6: Client Providing Public Key to Authorization Server 378 4.2.2. Client-to-AS Response 380 If the access token request is valid and authorized, the 381 authorization server issues an access token and optionally a refresh 382 token. The authorization server also places information about the 383 public key used by the client into the access token to create the 384 binding between the two. The new token type "pop" is placed into the 385 'token_type' parameter. 387 An example of a successful response is shown in Figure 7. 389 HTTP/1.1 200 OK 390 Content-Type: application/json;charset=UTF-8 391 Cache-Control: no-store 392 Pragma: no-cache 394 { 395 "access_token":"2YotnFZFE....jr1zCsicMWpAA", 396 "token_type":"pop", 397 "expires_in":3600, 398 "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA" 399 } 401 Figure 7: Example: Response from the Authorization Server (Asymmetric 402 Variant) 404 The content of the 'access_token' field contains an encoded JWT, as 405 shown in Figure 8. The digital signature covering the access token 406 offering authenticity and integrity protection is not shown below 407 (but must be present). 409 { 410 "iss":"xas.example.com", 411 "aud":"http://auth.example.com", 412 "exp":"1361398824", 413 "nbf":"1360189224", 414 "cnf":{ 415 "jwk" : { 416 "kty" : "EC", 417 "kid" : h'11', 418 "crv" : "P-256", 419 "x" : b64'usWxHK2PmfnHKwXPS54m0kTcGJ90UiglWiGahtagnv8', 420 "y" : b64'IBOL+C3BttVivg+lSreASjpkttcsz+1rb7btKLv8EX4' 421 } 422 } 423 } 425 Figure 8: Example: Access Token Structure (Asymmetric Variant) 427 Note: In this example there is no need for the authorization server 428 to convey further keying material to the client since the client is 429 already in possession of the private key (as well as the public key). 431 5. Security Considerations 433 [21] describes the architecture for the OAuth 2.0 proof-of-possession 434 security architecture, including use cases, threats, and 435 requirements. This requirements describes one solution component of 436 that architecture, namely the mechanism for the client to interact 437 with the authorization server to either obtain a symmetric key from 438 the authorization server, to obtain an asymmetric key pair, or to 439 offer a public key to the authorization. In any case, these keys are 440 then bound to the access token by the authorization server. 442 To summarize the main security recommendations: A large range of 443 threats can be mitigated by protecting the contents of the access 444 token by using a digital signature or a keyed message digest. 445 Consequently, the token integrity protection MUST be applied to 446 prevent the token from being modified, particularly since it contains 447 a reference to the symmetric key or the asymmetric key. If the 448 access token contains the symmetric key (see Section 2.2 of [10] for 449 a description about how symmetric keys can be securely conveyed 450 within the access token) this symmetric key MUST be encrypted by the 451 authorization server with a long-term key shared with the resource 452 server. 454 To deal with token redirect, it is important for the authorization 455 server to include the identity of the intended recipient (the 456 audience), typically a single resource server (or a list of resource 457 servers), in the token. Using a single shared secret with multiple 458 authorization server to simplify key management is NOT RECOMMENDED 459 since the benefit from using the proof-of-possession concept is 460 significantly reduced. 462 Token replay is also not possible since an eavesdropper will also 463 have to obtain the corresponding private key or shared secret that is 464 bound to the access token. Nevertheless, it is good practice to 465 limit the lifetime of the access token and therefore the lifetime of 466 associated key. 468 The authorization server MUST offer confidentiality protection for 469 any interactions with the client. This step is extremely important 470 since the client will obtain the session key from the authorization 471 server for use with a specific access token. Not using 472 confidentiality protection exposes this secret (and the access token) 473 to an eavesdropper thereby making the OAuth 2.0 proof-of-possession 474 security model completely insecure. OAuth 2.0 [2] relies on TLS to 475 offer confidentiality protection and additional protection can be 476 applied using the JWK [5] offered security mechanism, which would add 477 an additional layer of protection on top of TLS for cases where the 478 keying material is conveyed, for example, to a hardware security 479 module. Which version(s) of TLS ought to be implemented will vary 480 over time, and depend on the widespread deployment and known security 481 vulnerabilities at the time of implementation. At the time of this 482 writing, TLS version 1.2 [4] is the most recent version. The client 483 MUST validate the TLS certificate chain when making requests to 484 protected resources, including checking the validity of the 485 certificate. 487 Similarly to the security recommendations for the bearer token 488 specification [16] developers MUST ensure that the ephemeral 489 credentials (i.e., the private key or the session key) is not leaked 490 to third parties. An adversary in possession of the ephemeral 491 credentials bound to the access token will be able to impersonate the 492 client. Be aware that this is a real risk with many smart phone app 493 and Web development environments. 495 Clients can at any time request a new proof-of-possession capable 496 access token. Using a refresh token to regularly request new access 497 tokens that are bound to fresh and unique keys is important. Keeping 498 the lifetime of the access token short allows the authorization 499 server to use shorter key sizes, which translate to a performance 500 benefit for the client and for the resource server. Shorter keys 501 also lead to shorter messages (particularly with asymmetric keying 502 material). 504 When authorization servers bind symmetric keys to access tokens then 505 they SHOULD scope these access tokens to a specific permissions. 507 6. IANA Considerations 509 6.1. OAuth Access Token Types 511 This specification registers the following error in the IANA "OAuth 512 Access Token Types" [24] established by [16]. 514 o Name: pop 515 o Change controller: IESG 516 o Specification document(s): [[ this specification ]] 518 6.2. OAuth Parameters Registration 520 This specification registers the following value in the IANA "OAuth 521 Parameters" registry [24] established by [2]. 523 o Parameter name: cnf_req 524 o Parameter usage location: authorization request, token request 525 o Change controller: IESG 526 o Specification document(s): [[ this specification ]] 528 o Parameter name: cnf 529 o Parameter usage location: authorization response, token response 530 o Change controller: IESG 531 o Specification document(s): [[ this specification ]] 533 o Parameter name: rs_cnf 534 o Parameter usage location: token response 535 o Change controller: IESG 536 o Specification document(s): [[ this specification ]] 538 6.3. OAuth Extensions Error Registration 540 This specification registers the following error in the IANA "OAuth 541 Extensions Error Registry" [24] established by [2]. 543 o Error name: invalid_token_type 544 o Error usage location: implicit grant error response, token error 545 response 546 o Related protocol extension: token_type parameter 547 o Change controller: IESG 548 o Specification document(s): [[ this specification ]] 550 7. Acknowledgements 552 We would like to thank Chuck Mortimore for his review comments. 554 8. References 556 8.1. Normative References 558 [1] Bradner, S., "Key words for use in RFCs to Indicate 559 Requirement Levels", BCP 14, RFC 2119, 560 DOI 10.17487/RFC2119, March 1997, 561 . 563 [2] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 564 RFC 6749, DOI 10.17487/RFC6749, October 2012, 565 . 567 [3] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 568 Resource Identifier (URI): Generic Syntax", STD 66, 569 RFC 3986, DOI 10.17487/RFC3986, January 2005, 570 . 572 [4] Dierks, T. and E. Rescorla, "The Transport Layer Security 573 (TLS) Protocol Version 1.2", RFC 5246, 574 DOI 10.17487/RFC5246, August 2008, 575 . 577 [5] Jones, M., "JSON Web Key (JWK)", RFC 7517, 578 DOI 10.17487/RFC7517, May 2015, 579 . 581 [6] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 582 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 583 2015, . 585 [7] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, 586 DOI 10.17487/RFC7518, May 2015, 587 . 589 [8] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", 590 RFC 7516, DOI 10.17487/RFC7516, May 2015, 591 . 593 [9] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 594 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 595 . 597 [10] Jones, M., Bradley, J., and H. Tschofenig, "Proof-of- 598 Possession Key Semantics for JSON Web Tokens (JWTs)", 599 RFC 7800, DOI 10.17487/RFC7800, April 2016, 600 . 602 [11] Jones, M. and N. Sakimura, "JSON Web Key (JWK) 603 Thumbprint", RFC 7638, DOI 10.17487/RFC7638, September 604 2015, . 606 [12] Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. 607 Tschofenig, "Proof-of-Possession Key Semantics for CBOR 608 Web Tokens (CWTs)", draft-ietf-ace-cwt-proof-of- 609 possession-06 (work in progress), February 2019. 611 [13] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 612 "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, 613 May 2018, . 615 [14] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 616 RFC 8152, DOI 10.17487/RFC8152, July 2017, 617 . 619 [15] Campbell, B., Bradley, J., and H. Tschofenig, "Resource 620 Indicators for OAuth 2.0", draft-ietf-oauth-resource- 621 indicators-02 (work in progress), January 2019. 623 8.2. Informative References 625 [16] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization 626 Framework: Bearer Token Usage", RFC 6750, 627 DOI 10.17487/RFC6750, October 2012, 628 . 630 [17] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 631 Specifications: ABNF", STD 68, RFC 5234, 632 DOI 10.17487/RFC5234, January 2008, 633 . 635 [18] Campbell, B., Mortimore, C., Jones, M., and Y. Goland, 636 "Assertion Framework for OAuth 2.0 Client Authentication 637 and Authorization Grants", RFC 7521, DOI 10.17487/RFC7521, 638 May 2015, . 640 [19] Sakimura, N., Ed., Bradley, J., and N. Agarwal, "Proof Key 641 for Code Exchange by OAuth Public Clients", RFC 7636, 642 DOI 10.17487/RFC7636, September 2015, 643 . 645 [20] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and 646 P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol", 647 RFC 7591, DOI 10.17487/RFC7591, July 2015, 648 . 650 [21] Hunt, P., Richer, J., Mills, W., Mishra, P., and H. 651 Tschofenig, "OAuth 2.0 Proof-of-Possession (PoP) Security 652 Architecture", draft-ietf-oauth-pop-architecture-08 (work 653 in progress), July 2016. 655 [22] Richer, J., Ed., "OAuth 2.0 Token Introspection", 656 RFC 7662, DOI 10.17487/RFC7662, October 2015, 657 . 659 [23] Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 660 H. Tschofenig, "Authentication and Authorization for 661 Constrained Environments (ACE) using the OAuth 2.0 662 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-22 663 (work in progress), March 2019. 665 [24] IANA, "OAuth Parameters", October 2018. 667 [25] IANA, "JSON Web Token Claims", June 2018. 669 Authors' Addresses 671 John Bradley 672 Ping Identity 674 Email: ve7jtb@ve7jtb.com 675 URI: http://www.thread-safe.com/ 677 Phil Hunt 678 Oracle Corporation 680 Email: phil.hunt@yahoo.com 681 URI: http://www.indepdentid.com 683 Michael B. Jones 684 Microsoft 686 Email: mbj@microsoft.com 687 URI: http://self-issued.info/ 688 Hannes Tschofenig 689 Arm Ltd. 690 Absam 6067 691 Austria 693 Email: Hannes.Tschofenig@gmx.net 694 URI: http://www.tschofenig.priv.at 696 Mihaly Meszaros 697 GITDA 698 Debrecen 4033 699 Hungary 701 Email: bakfitty@gmail.com 702 URI: https://github.com/misi