idnits 2.17.1 draft-ietf-oauth-pop-key-distribution-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 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 1871 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 532, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 567, but no explicit reference was found in the text == Unused Reference: '17' is defined on line 597, but no explicit reference was found in the text == Unused Reference: '19' is defined on line 607, but no explicit reference was found in the text == Unused Reference: '20' is defined on line 612, but no explicit reference was found in the text == Unused Reference: '23' is defined on line 626, 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 (-46) exists of draft-ietf-ace-oauth-authz-22 == Outdated reference: A later version (-11) exists of draft-ietf-ace-cwt-proof-of-possession-06 ** Obsolete normative reference: RFC 8152 (ref. '15') (Obsoleted by RFC 9052, RFC 9053) Summary: 2 errors (**), 0 flaws (~~), 10 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-05 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 This document describes how the client requests and obtains a PoP 30 access token from the authorization server for use with HTTPS-based 31 transport. Alternative transports, for example using the Constrained 32 Application Protocol (CoAP), have been specified in companion 33 specifications. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at https://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on September 12, 2019. 51 Copyright Notice 53 Copyright (c) 2019 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (https://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 69 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 3. Processing Instructions . . . . . . . . . . . . . . . . . . . 4 71 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 4.1. Symmetric Key Transport . . . . . . . . . . . . . . . . . 5 73 4.1.1. Client-to-AS Request . . . . . . . . . . . . . . . . 5 74 4.1.2. Client-to-AS Response . . . . . . . . . . . . . . . . 5 75 4.2. Asymmetric Key Transport . . . . . . . . . . . . . . . . 8 76 4.2.1. Client-to-AS Request . . . . . . . . . . . . . . . . 8 77 4.2.2. Client-to-AS Response . . . . . . . . . . . . . . . . 9 78 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 79 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 80 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 81 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 82 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 83 8.2. Informative References . . . . . . . . . . . . . . . . . 14 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 86 1. Introduction 88 The work on proof-of-possession tokens, an extended token security 89 mechanisms for OAuth 2.0, is motivated in [21]. This document 90 defines the ability for the client request and to obtain PoP tokens 91 from the authorization server. After successfully completing the 92 exchange the client is in possession of a PoP token and the keying 93 material bound to it. Clients that access protected resources then 94 need to demonstrate knowledge of the secret key that is bound to the 95 PoP token. 97 To best describe the scope of this specification, the OAuth 2.0 98 protocol exchange sequence is shown in Figure 1. The extension 99 defined in this document piggybacks on the message exchange marked 100 with (C) and (D). To demonstrate possession of the private/secret 101 key to the resource server protocol mechanisms outside the scope of 102 this document are used. 104 +--------+ +---------------+ 105 | |--(A)- Authorization Request ->| Resource | 106 | | | Owner | 107 | |<-(B)-- Authorization Grant ---| | 108 | | +---------------+ 109 | | 110 | | +---------------+ 111 | |--(C)-- Authorization Grant -->| | 112 | Client | (aud, cnf) | Authorization | 113 | | | Server | 114 | |<-(D)-- PoP Access Token ------| | 115 | | (profile, cnf, rs_cnf, +---------------+ 116 | | token_type) 117 | | +---------------+ 118 | |--(E)-- PoP Access Token ----->| | 119 | | (with proof of private key) | Resource | 120 | | | Server | 121 | |<-(F)--- Protected Resource ---| | 122 +--------+ +---------------+ 124 Figure 1: Augmented OAuth 2.0 Protocol Flow 126 In OAuth 2.0 [2] access tokens can be obtained via authorization 127 grants and using refresh tokens. The core OAuth specification 128 defines four authorization grants, see Section 1.3 of [2], and [18] 129 adds an assertion-based authorization grant to that list. The token 130 endpoint, which is described in Section 3.2 of [2], is used with 131 every authorization grant except for the implicit grant type. In the 132 implicit grant type the access token is issued directly. 134 This document extends the functionality of the token endpoint, i.e., 135 the protocol exchange between the client and the authorization 136 server, to allow keying material to be bound to an access token. Two 137 types of keying material can be bound to an access token, namely 138 symmetric keys and asymmetric keys. Conveying symmetric keys from 139 the authorization server to the client is described in Section 4.1 140 and the procedure for dealing with asymmetric keys is described in 141 Section 4.2. 143 2. Terminology 145 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 146 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this 147 specification are to be interpreted as described in [1]. 149 Session Key: 151 In the context of this specification 'session key' refers to fresh 152 and unique keying material established between the client and the 153 resource server. This session key has a lifetime that corresponds 154 to the lifetime of the access token, is generated by the 155 authorization server and bound to the access token. 157 This document uses the following abbreviations: 159 JWA: JSON Web Algorithms[7] 161 JWT: JSON Web Token[9] 163 JWS: JSON Web Signature[6] 165 JWK: JSON Web Key[5] 167 JWE: JSON Web Encryption[8] 169 CWT: CBOR Web Token[14] 171 COSE: CBOR Object Signing and Encryption[15] 173 3. Processing Instructions 175 Step (0): As an initial step the client typically determines the 176 resource server it wants to interact with. This may, for example, 177 happen as part of a discovery procedure or via manual 178 configuration. 180 Step (1): The client starts the OAuth 2.0 protocol interaction 181 based on the selected grant type. 183 Step (2): When the client interacts with the token endpoint to 184 obtain an access token it MUST follow the processing steps for the 185 HTTPS-based transport described in Section 5.6.1 of [12]. This 186 includes determining whether to use the 'aud' and the 'cnf' 187 parameters. 189 Step (3): The authorization server parses the request from the 190 server and determines the suitable response based on the 191 description in Section 5.6.2 of [12]. In case of an error the 192 procedure in Section 5.6.3 of [12] is applicable. 194 Note that PoP access tokens may be encoded in a variety of ways. In 195 case the access token is encoded using the JSON Web Token (JWT) 196 format [9] it MUST be protected against modification by either using 197 a digital signature or a keyed message digest, as described in [6]. 198 The JWT may also be encrypted using [8]. [14] defines an alternative 199 token format based on CBOR. The proof-of-possession token 200 functionality is defined in [13]. Finally, access tokens can also be 201 passed by reference, which then requires the token introspection 202 endpoint (or a similiar, proprietary protocol mechanism) to be used. 203 This specification does not mandate a specific PoP token format. 205 Subsequent steps for the interaction between the client and the 206 resource server are beyond the scope of this document. 208 4. Examples 210 This section provides a number of examples. 212 4.1. Symmetric Key Transport 214 4.1.1. Client-to-AS Request 216 The client starts with a request to the authorization server 217 indicating that it is interested to obtain a token for example- 218 server. 220 POST /token HTTP/1.1 221 Host: server.example.com 222 Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW 223 Content-Type: application/x-www-form-urlencoded;charset=UTF-8 225 grant_type=authorization_code 226 &code=SplxlOBeZQQYbYS6WxSbIA 227 &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb 228 &aud=example-server 230 Example Request to the Authorization Server 232 4.1.2. Client-to-AS Response 234 If the access token request has been successfully verified by the 235 authorization server and the client is authorized to obtain a PoP 236 token for the indicated resource server, the authorization server 237 issues an access token and optionally a refresh token. 239 Figure 2 shows a response containing a token and a "cnf" parameter 240 with a symmetric proof-of-possession key. 242 HTTP/1.1 200 OK 243 Content-Type: application/json 244 Cache-Control: no-store 246 { 247 "access_token":"SlAV32hkKG ... 248 (remainder of JWT omitted for brevity; 249 JWT contains JWK in the cnf claim)", 250 "token_type":"pop", 251 "expires_in":3600, 252 "refresh_token":"8xLOxBtZp8", 253 "cnf":{ 254 "keys" : { 255 "kty" : "Symmetric", 256 "kid" : b64'39Gqlw', 257 "k" : b64'hJtXhkV8FJG+Onbc6mxCcQh' 258 } 259 } 260 } 262 Figure 2: Example: Response from the Authorization Server (Symmetric 263 Variant) 265 Note that the cnf payload in Figure 2 is not encrypted at the 266 application layer since Transport Layer Security is used between the 267 AS and the client and the content of the cnf payload is consumed by 268 the client itself. Alternatively, a JWE could be used to encrypt the 269 key distribution, as shown in Figure 3. 271 { 272 "access_token":"SlAV32hkKG ... 273 (remainder of JWT omitted for brevity; 274 JWT contains JWK in the cnf claim)", 275 "token_type":"pop", 276 "expires_in":3600, 277 "refresh_token":"8xLOxBtZp8", 278 "cnf":{ 279 "jwe": 280 "eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkExMjhDQkMtSFMyNTYifQ. 281 (remainder of JWE omitted for brevity)" 282 } 283 } 284 } 286 Figure 3: Example: Encrypted Symmmetric Key 288 The content of the key parameter, which is a JWK in our example, is 289 shown in Figure 4. 291 { 292 "kty":"oct", 293 "kid":"id123", 294 "alg":"HS256", 295 "k":"ZoRSOrFzN_FzUA5XKMYoVHyzff5oRJxl-IXRtztJ6uE" 296 } 298 Figure 4: Example: Key Transport to Client via a JWK 300 The content of the 'access_token' in JWT format contains the 'cnf' 301 (confirmation) claim, as shown in Figure 5. The confirmation claim 302 is defined in [10]. The digital signature or the keyed message 303 digest offering integrity protection is not shown in this example but 304 has to be present in a real deployment to mitigate a number of 305 security threats. 307 The JWK in the key element of the response from the authorization 308 server, as shown in Figure 2, contains the same session key as the 309 JWK inside the access token, as shown in Figure 5. It is, in this 310 example, protected by TLS and transmitted from the authorization 311 server to the client (for processing by the client). 313 { 314 "iss": "https://server.example.com", 315 "sub": "24400320", 316 "aud": "s6BhdRkqt3", 317 "nonce": "n-0S6_WzA2Mj", 318 "exp": 1311281970, 319 "iat": 1311280970, 320 "cnf":{ 321 "jwk": 322 "JDLUhTMjU2IiwiY3R5Ijoi ... 323 (remainder of JWK protected by JWE omitted for brevity)" 324 } 325 } 327 Figure 5: Example: Access Token in JWT Format 329 Note: When the JWK inside the access token contains a symmetric key 330 it must be confidentiality protected using a JWE to maintain the 331 security goals of the PoP architecture, as described in [21] since 332 content is meant for consumption by the selected resource server 333 only. 335 Note: This document does not impose requirements on the encoding of 336 the access token. The examples used in this document make use of the 337 JWT structure but the CWT format is an equally appropriate format to 338 use. 340 If the access token is only a reference then a look-up by the 341 resource server is needed, as described in the token introspection 342 specification [22]. 344 4.2. Asymmetric Key Transport 346 4.2.1. Client-to-AS Request 348 This example illustrates the case where an asymmetric key shall be 349 bound to an access token. The client makes the following HTTPS 350 request shown in Figure 6. Extra line breaks are for display 351 purposes only. 353 POST /token HTTP/1.1 354 Host: server.example.com 355 Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW 356 Content-Type: application/x-www-form-urlencoded;charset=UTF-8 358 grant_type=authorization_code 359 &code=SplxlOBeZQQYbYS6WxSbIA 360 &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb 361 &token_type=pop 362 &cnf=eyJhbGciOiJSU0ExXzUi ... 363 (remainder of JWK omitted for brevity) 365 Figure 6: Example Request to the Authorization Server (Asymmetric Key 366 Variant) 368 As shown in Figure 7 the content of the 'cnf' parameter contains the 369 ECC public key the client would like to associate with the access 370 token. 372 "jwk":{ 373 "kty": "EC", 374 "use": "sig", 375 "crv": "P-256", 376 "x": "18wHLeIgW9wVN6VD1Txgpqy2LszYkMf6J8njVAibvhM", 377 "y": "-V4dS4UaLMgP_4fY4j8ir7cl1TXlFdAgcx55o7TkcSA" 378 } 380 Figure 7: Client Providing Public Key to Authorization Server 382 4.2.2. Client-to-AS Response 384 If the access token request is valid and authorized, the 385 authorization server issues an access token and optionally a refresh 386 token. The authorization server also places information about the 387 public key used by the client into the access token to create the 388 binding between the two. The new token type "public_key" is placed 389 into the 'token_type' parameter. 391 An example of a successful response is shown in Figure 8. 393 HTTP/1.1 200 OK 394 Content-Type: application/json;charset=UTF-8 395 Cache-Control: no-store 396 Pragma: no-cache 398 { 399 "access_token":"2YotnFZFE....jr1zCsicMWpAA", 400 "token_type":"pop", 401 "expires_in":3600, 402 "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA" 403 } 405 Figure 8: Example: Response from the Authorization Server (Asymmetric 406 Variant) 408 The content of the 'access_token' field contains an encoded JWT, as 409 shown in Figure 9. The digital signature covering the access token 410 offering authenticity and integrity protection is not shown below 411 (but must be present). 413 { 414 "iss":"xas.example.com", 415 "aud":"http://auth.example.com", 416 "exp":"1361398824", 417 "nbf":"1360189224", 418 "cnf":{ 419 "jwk" : { 420 "kty" : "EC", 421 "kid" : h'11', 422 "crv" : "P-256", 423 "x" : b64'usWxHK2PmfnHKwXPS54m0kTcGJ90UiglWiGahtagnv8', 424 "y" : b64'IBOL+C3BttVivg+lSreASjpkttcsz+1rb7btKLv8EX4' 425 } 426 } 427 } 429 Figure 9: Example: Access Token Structure (Asymmetric Variant) 431 Note: In this example there is no need for the authorization server 432 to convey further keying material to the client since the client is 433 already in possession of the private key. 435 5. Security Considerations 437 [21] describes the architecture for the OAuth 2.0 proof-of-possession 438 security architecture, including use cases, threats, and 439 requirements. This requirements describes one solution component of 440 that architecture, namely the mechanism for the client to interact 441 with the authorization server to either obtain a symmetric key from 442 the authorization server, to obtain an asymmetric key pair, or to 443 offer a public key to the authorization. In any case, these keys are 444 then bound to the access token by the authorization server. 446 To summarize the main security recommendations: A large range of 447 threats can be mitigated by protecting the contents of the access 448 token by using a digital signature or a keyed message digest. 449 Consequently, the token integrity protection MUST be applied to 450 prevent the token from being modified, particularly since it contains 451 a reference to the symmetric key or the asymmetric key. If the 452 access token contains the symmetric key (see Section 2.2 of [10] for 453 a description about how symmetric keys can be securely conveyed 454 within the access token) this symmetric key MUST be encrypted by the 455 authorization server with a long-term key shared with the resource 456 server. 458 To deal with token redirect, it is important for the authorization 459 server to include the identity of the intended recipient (the 460 audience), typically a single resource server (or a list of resource 461 servers), in the token. Using a single shared secret with multiple 462 authorization server to simplify key management is NOT RECOMMENDED 463 since the benefit from using the proof-of-possession concept is 464 significantly reduced. 466 Token replay is also not possible since an eavesdropper will also 467 have to obtain the corresponding private key or shared secret that is 468 bound to the access token. Nevertheless, it is good practice to 469 limit the lifetime of the access token and therefore the lifetime of 470 associated key. 472 The authorization server MUST offer confidentiality protection for 473 any interactions with the client. This step is extremely important 474 since the client will obtain the session key from the authorization 475 server for use with a specific access token. Not using 476 confidentiality protection exposes this secret (and the access token) 477 to an eavesdropper thereby making the OAuth 2.0 proof-of-possession 478 security model completely insecure. OAuth 2.0 [2] relies on TLS to 479 offer confidentiality protection and additional protection can be 480 applied using the JWK [5] offered security mechanism, which would add 481 an additional layer of protection on top of TLS for cases where the 482 keying material is conveyed, for example, to a hardware security 483 module. Which version(s) of TLS ought to be implemented will vary 484 over time, and depend on the widespread deployment and known security 485 vulnerabilities at the time of implementation. At the time of this 486 writing, TLS version 1.2 [4] is the most recent version. The client 487 MUST validate the TLS certificate chain when making requests to 488 protected resources, including checking the validity of the 489 certificate. 491 Similarly to the security recommendations for the bearer token 492 specification [16] developers MUST ensure that the ephemeral 493 credentials (i.e., the private key or the session key) is not leaked 494 to third parties. An adversary in possession of the ephemeral 495 credentials bound to the access token will be able to impersonate the 496 client. Be aware that this is a real risk with many smart phone app 497 and Web development environments. 499 Clients can at any time request a new proof-of-possession capable 500 access token. Using a refresh token to regularly request new access 501 tokens that are bound to fresh and unique keys is important. Keeping 502 the lifetime of the access token short allows the authorization 503 server to use shorter key sizes, which translate to a performance 504 benefit for the client and for the resource server. Shorter keys 505 also lead to shorter messages (particularly with asymmetric keying 506 material). 508 When authorization servers bind symmetric keys to access tokens then 509 they SHOULD scope these access tokens to a specific permissions. 511 6. IANA Considerations 513 This document does not require any actions by IANA. 515 7. Acknowledgements 517 We would like to thank Chuck Mortimore for his review comments. 519 8. References 521 8.1. Normative References 523 [1] Bradner, S., "Key words for use in RFCs to Indicate 524 Requirement Levels", BCP 14, RFC 2119, 525 DOI 10.17487/RFC2119, March 1997, 526 . 528 [2] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 529 RFC 6749, DOI 10.17487/RFC6749, October 2012, 530 . 532 [3] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 533 Resource Identifier (URI): Generic Syntax", STD 66, 534 RFC 3986, DOI 10.17487/RFC3986, January 2005, 535 . 537 [4] Dierks, T. and E. Rescorla, "The Transport Layer Security 538 (TLS) Protocol Version 1.2", RFC 5246, 539 DOI 10.17487/RFC5246, August 2008, 540 . 542 [5] Jones, M., "JSON Web Key (JWK)", RFC 7517, 543 DOI 10.17487/RFC7517, May 2015, 544 . 546 [6] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 547 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 548 2015, . 550 [7] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, 551 DOI 10.17487/RFC7518, May 2015, 552 . 554 [8] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", 555 RFC 7516, DOI 10.17487/RFC7516, May 2015, 556 . 558 [9] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 559 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 560 . 562 [10] Jones, M., Bradley, J., and H. Tschofenig, "Proof-of- 563 Possession Key Semantics for JSON Web Tokens (JWTs)", 564 RFC 7800, DOI 10.17487/RFC7800, April 2016, 565 . 567 [11] Jones, M. and N. Sakimura, "JSON Web Key (JWK) 568 Thumbprint", RFC 7638, DOI 10.17487/RFC7638, September 569 2015, . 571 [12] Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 572 H. Tschofenig, "Authentication and Authorization for 573 Constrained Environments (ACE) using the OAuth 2.0 574 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-22 575 (work in progress), March 2019. 577 [13] Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. 578 Tschofenig, "Proof-of-Possession Key Semantics for CBOR 579 Web Tokens (CWTs)", draft-ietf-ace-cwt-proof-of- 580 possession-06 (work in progress), February 2019. 582 [14] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 583 "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, 584 May 2018, . 586 [15] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 587 RFC 8152, DOI 10.17487/RFC8152, July 2017, 588 . 590 8.2. Informative References 592 [16] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization 593 Framework: Bearer Token Usage", RFC 6750, 594 DOI 10.17487/RFC6750, October 2012, 595 . 597 [17] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 598 Specifications: ABNF", STD 68, RFC 5234, 599 DOI 10.17487/RFC5234, January 2008, 600 . 602 [18] Campbell, B., Mortimore, C., Jones, M., and Y. Goland, 603 "Assertion Framework for OAuth 2.0 Client Authentication 604 and Authorization Grants", RFC 7521, DOI 10.17487/RFC7521, 605 May 2015, . 607 [19] Sakimura, N., Ed., Bradley, J., and N. Agarwal, "Proof Key 608 for Code Exchange by OAuth Public Clients", RFC 7636, 609 DOI 10.17487/RFC7636, September 2015, 610 . 612 [20] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and 613 P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol", 614 RFC 7591, DOI 10.17487/RFC7591, July 2015, 615 . 617 [21] Hunt, P., Richer, J., Mills, W., Mishra, P., and H. 618 Tschofenig, "OAuth 2.0 Proof-of-Possession (PoP) Security 619 Architecture", draft-ietf-oauth-pop-architecture-08 (work 620 in progress), July 2016. 622 [22] Richer, J., Ed., "OAuth 2.0 Token Introspection", 623 RFC 7662, DOI 10.17487/RFC7662, October 2015, 624 . 626 [23] IANA, "JSON Web Token Claims", March 2019. 628 Authors' Addresses 629 John Bradley 630 Ping Identity 632 Email: ve7jtb@ve7jtb.com 633 URI: http://www.thread-safe.com/ 635 Phil Hunt 636 Oracle Corporation 638 Email: phil.hunt@yahoo.com 639 URI: http://www.indepdentid.com 641 Michael B. Jones 642 Microsoft 644 Email: mbj@microsoft.com 645 URI: http://self-issued.info/ 647 Hannes Tschofenig 648 Arm Ltd. 649 Absam 6067 650 Austria 652 Email: Hannes.Tschofenig@gmx.net 653 URI: http://www.tschofenig.priv.at 655 Mihaly Meszaros 656 GITDA 657 Debrecen 4033 658 Hungary 660 Email: bakfitty@gmail.com 661 URI: https://github.com/misi