idnits 2.17.1 draft-ietf-oauth-dpop-00.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 (1 April 2020) is 1486 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) ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) == Outdated reference: A later version (-26) exists of draft-ietf-oauth-security-topics-14 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Web Authorization Protocol D. Fett 3 Internet-Draft yes.com 4 Intended status: Standards Track B. Campbell 5 Expires: 3 October 2020 Ping Identity 6 J. Bradley 7 Yubico 8 T. Lodderstedt 9 yes.com 10 M. Jones 11 Microsoft 12 D. Waite 13 Ping Identity 14 1 April 2020 16 OAuth 2.0 Demonstration of Proof-of-Possession at the Application Layer 17 (DPoP) 18 draft-ietf-oauth-dpop-00 20 Abstract 22 This document describes a mechanism for sender-constraining OAuth 2.0 23 tokens via a proof-of-possession mechanism on the application level. 24 This mechanism allows for the detection of replay attacks with access 25 and refresh tokens. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on 3 October 2020. 44 Copyright Notice 46 Copyright (c) 2020 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 51 license-info) in effect on the date of publication of this document. 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. Code Components 54 extracted from this document must include Simplified BSD License text 55 as described in Section 4.e of the Trust Legal Provisions and are 56 provided without warranty as described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 1.1. Conventions and Terminology . . . . . . . . . . . . . . . 3 62 2. Main Objective . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 4. DPoP Proof JWTs . . . . . . . . . . . . . . . . . . . . . . . 5 65 4.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 4.2. Checking DPoP Proofs . . . . . . . . . . . . . . . . . . 6 67 5. Token Request (Binding Tokens to a Public Key) . . . . . . . 7 68 6. Resource Access (Proof of Possession for Access Tokens) . . . 8 69 7. Public Key Confirmation . . . . . . . . . . . . . . . . . . . 9 70 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 71 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 72 9.1. DPoP Proof Replay . . . . . . . . . . . . . . . . . . . . 10 73 9.2. Signed JWT Swapping . . . . . . . . . . . . . . . . . . . 11 74 9.3. Signature Algorithms . . . . . . . . . . . . . . . . . . 11 75 9.4. Message Integrity . . . . . . . . . . . . . . . . . . . . 11 76 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 77 10.1. OAuth Access Token Type Registration . . . . . . . . . . 11 78 10.2. JSON Web Signature and Encryption Type Values 79 Registration . . . . . . . . . . . . . . . . . . . . . . 12 80 11. Normative References . . . . . . . . . . . . . . . . . . . . 12 81 12. Informative References . . . . . . . . . . . . . . . . . . . 12 82 Appendix A. Document History . . . . . . . . . . . . . . . . . . 13 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 85 1. Introduction 87 [RFC8705] describes methods to bind (sender-constrain) access tokens 88 using mutual Transport Layer Security (TLS) authentication with X.509 89 certificates. 91 [I-D.ietf-oauth-token-binding] provides mechanisms to sender- 92 constrain access tokens using HTTP token binding. 94 Due to a sub-par user experience of TLS client authentication in user 95 agents and a lack of support for HTTP token binding, neither 96 mechanism can be used if an OAuth client is a Single Page Application 97 (SPA) running in a web browser. 99 This document outlines an application-level sender-constraining for 100 access and refresh tokens that can be used in cases where neither 101 mTLS nor OAuth Token Binding are available. It uses proof-of- 102 possession based on a public/private key pair and application-level 103 signing. 105 DPoP can be used with public clients and, in case of confidential 106 clients, can be combined with any client authentication method. 108 1.1. Conventions and Terminology 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 112 "OPTIONAL" in this document are to be interpreted as described in BCP 113 14 [RFC2119] [RFC8174] when, and only when, they appear in all 114 capitals, as shown here. 116 This specification uses the terms "access token", "refresh token", 117 "authorization server", "resource server", "authorization endpoint", 118 "authorization request", "authorization response", "token endpoint", 119 "grant type", "access token request", "access token response", and 120 "client" defined by The OAuth 2.0 Authorization Framework [RFC6749]. 122 2. Main Objective 124 Under the attacker model defined in [I-D.ietf-oauth-security-topics], 125 the mechanism defined by this specification aims to prevent token 126 replay at a different endpoint. 128 More precisely, if an adversary is able to get hold of an access 129 token or refresh token because it set up a counterfeit authorization 130 server or resource server, the adversary is not able to replay the 131 respective token at another authorization or resource server. 133 Secondary objectives are discussed in Section 9. 135 3. Concept 137 The main data structure introduced by this specification is a DPoP 138 proof JWT, described in detail below. A client uses a DPoP proof JWT 139 to prove the possession of a private key belonging to a certain 140 public key. Roughly speaking, a DPoP proof is a signature over some 141 data of the HTTP request to which it is attached to and a timestamp. 143 +--------+ +---------------+ 144 | |--(A)-- Token Request ------------------->| | 145 | Client | (DPoP Proof) | Authorization | 146 | | | Server | 147 | |<-(B)-- DPoP-bound Access Token ----------| | 148 | | (token_type=DPoP) +---------------+ 149 | | PoP Refresh Token for public clients 150 | | 151 | | +---------------+ 152 | |--(C)-- DPoP-bound Access Token --------->| | 153 | | (DPoP Proof) | Resource | 154 | | | Server | 155 | |<-(D)-- Protected Resource ---------------| | 156 | | +---------------+ 157 +--------+ 159 Figure 1 161 Figure 1: Basic DPoP Flow 163 The basic steps of an OAuth flow with DPoP are shown in Figure 1: 165 * (A) In the Token Request, the client sends an authorization code 166 to the authorization server in order to obtain an access token 167 (and potentially a refresh token). The client attaches a DPoP 168 proof to the request in an HTTP header. 170 * (B) The AS binds (sender-constrains) the access token to the 171 public key claimed by the client in the DPoP proof; that is, the 172 access token cannot be used without proving possession of the 173 respective private key. This is signaled to the client by using 174 the "token_type" value "DPoP". 176 * If a refresh token is issued to a public client, it is sender- 177 constrained in the same way. For confidential clients, refresh 178 tokens are bound to the "client_id", which is more flexible than 179 binding it to a particular public key. 181 * (C) If the client wants to use the access token, it has to prove 182 possession of the private key by, again, adding a header to the 183 request that carries the DPoP proof. The resource server needs to 184 receive information about the public key to which the access token 185 is bound. This information is either encoded directly into the 186 access token (for JWT structured access tokens), or provided at 187 the token introspection endpoint of the authorization server (not 188 shown). 190 * (D) The resource server refuses to serve the request if the 191 signature check fails or the data in the DPoP proof is wrong, 192 e.g., the request URI does not match the URI claim in the DPoP 193 proof JWT. 195 * When a refresh token that is sender-constrained using DPoP is used 196 by the client, the client has to provide a DPoP proof just as in 197 the case of a resource access. The new access token will be bound 198 to the same public key. 200 The mechanism presented herein is not a client authentication method. 201 In fact, a primary use case is public clients (single page 202 applications) that do not use client authentication. Nonetheless, 203 DPoP is designed such that it is compatible with "private_key_jwt" 204 and all other client authentication methods. 206 DPoP does not directly ensure message integrity but relies on the TLS 207 layer for that purpose. See Section 9 for details. 209 4. DPoP Proof JWTs 211 DPoP uses so-called DPoP proof JWTs for binding public keys and 212 proving knowledge about private keys. 214 4.1. Syntax 216 A DPoP proof is a JWT ([RFC7519]) that is signed (using JWS, 217 [RFC7515]) using a private key chosen by the client (see below). The 218 header of a DPoP JWT contains at least the following parameters: 220 * "typ": type header, value "dpop+jwt" (REQUIRED). 222 * "alg": a digital signature algorithm identifier as per [RFC7518] 223 (REQUIRED). MUST NOT be "none" or an identifier for a symmetric 224 algorithm (MAC). 226 * "jwk": representing the public key chosen by the client, in JWK 227 format, as defined in [RFC7515] (REQUIRED) 229 The body of a DPoP proof contains at least the following claims: 231 * "jti": Unique identifier for the DPoP proof JWT (REQUIRED). The 232 value MUST be assigned such that there is a negligible probability 233 that the same value will be assigned to any other DPoP proof used 234 in the same context during the time window of validity. Such 235 uniqueness can be accomplished by encoding (base64url or any other 236 suitable encoding) at least 96 bits of pseudorandom data or by 237 using a version 4 UUID string according to [RFC4122]. The "jti" 238 SHOULD be used by the server for replay detection and prevention, 239 see Section 9.1. 241 * "htm": The HTTP method for the request to which the JWT is 242 attached, as defined in [RFC7231] (REQUIRED). 244 * "htu": The HTTP URI used for the request, without query and 245 fragment parts (REQUIRED). 247 * "iat": Time at which the JWT was created (REQUIRED). 249 Figure 2 shows the JSON header and payload of a DPoP proof JWT. 251 { 252 "typ":"dpop+jwt", 253 "alg":"ES256", 254 "jwk": { 255 "kty":"EC", 256 "x":"l8tFrhx-34tV3hRICRDY9zCkDlpBhF42UQUfWVAWBFs", 257 "y":"9VE4jf_Ok_o64zbTTlcuNJajHmt6v9TDVrU0CdvGRDA", 258 "crv":"P-256" 259 } 260 }.{ 261 "jti":"-BwC3ESc6acc2lTc", 262 "htm":"POST", 263 "htu":"https://server.example.com/token", 264 "iat":1562262616 265 } 267 Figure 2 269 Figure 2: Example JWT content for "DPoP" proof header. 271 Note: To keep DPoP simple to implement, only the HTTP method and URI 272 are signed in DPoP proofs. Nonetheless, DPoP proofs can be extended 273 to contain other information of the HTTP request (see also 274 Section 9.4). 276 4.2. Checking DPoP Proofs 278 To check if a string that was received as part of an HTTP Request is 279 a valid DPoP proof, the receiving server MUST ensure that 281 1. the string value is a well-formed JWT, 283 2. all required claims are contained in the JWT, 285 3. the "typ" field in the header has the value "dpop+jwt", 286 4. the algorithm in the header of the JWT indicates an asymmetric 287 digital signature algorithm, is not "none", is supported by the 288 application, and is deemed secure, 290 5. that the JWT is signed using the public key contained in the 291 "jwk" header of the JWT, 293 6. the "htm" claim matches the HTTP method value of the HTTP request 294 in which the JWT was received (case-insensitive), 296 7. the "htu" claims matches the HTTP URI value for the HTTP request 297 in which the JWT was received, ignoring any query and fragment 298 parts, 300 8. the token was issued within an acceptable timeframe (see 301 Section 9.1), and 303 9. that, within a reasonable consideration of accuracy and resource 304 utilization, a JWT with the same "jti" value has not been 305 received previously (see Section 9.1). 307 Servers SHOULD employ Syntax-Based Normalization and Scheme-Based 308 Normalization in accordance with Section 6.2.2. and Section 6.2.3. of 309 [RFC3986] before comparing the "htu" claim. 311 5. Token Request (Binding Tokens to a Public Key) 313 To bind a token to a public key in the token request, the client MUST 314 provide a valid DPoP proof JWT in a "DPoP" header. The HTTPS request 315 shown in Figure 3 illustrates the protocol for this (with extra line 316 breaks for display purposes only). 318 POST /token HTTP/1.1 319 Host: server.example.com 320 Content-Type: application/x-www-form-urlencoded;charset=UTF-8 321 DPoP: eyJ0eXAiOiJkcG9wK2p3dCIsImFsZyI6IkVTMjU2IiwiandrIjp7Imt0eSI6Ik 322 VDIiwieCI6Imw4dEZyaHgtMzR0VjNoUklDUkRZOXpDa0RscEJoRjQyVVFVZldWQVdCR 323 nMiLCJ5IjoiOVZFNGpmX09rX282NHpiVFRsY3VOSmFqSG10NnY5VERWclUwQ2R2R1JE 324 QSIsImNydiI6IlAtMjU2In19.eyJqdGkiOiItQndDM0VTYzZhY2MybFRjIiwiaHRtIj 325 oiUE9TVCIsImh0dSI6Imh0dHBzOi8vc2VydmVyLmV4YW1wbGUuY29tL3Rva2VuIiwia 326 WF0IjoxNTYyMjYyNjE2fQ.2-GxA6T8lP4vfrg8v-FdWP0A0zdrj8igiMLvqRMUvwnQg 327 4PtFLbdLXiOSsX0x7NVY-FNyJK70nfbV37xRZT3Lg 328 grant_type=authorization_code 329 &code=SplxlOBeZQQYbYS6WxSbIA 330 &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb 331 &code_verifier=bEaL42izcC-o-xBk0K2vuJ6U-y1p9r_wW2dFWIWgjz- 333 Figure 3 335 Figure 3: Token Request for a DPoP sender-constrained token. 337 The HTTP header "DPoP" MUST contain a valid DPoP proof. 339 The authorization server, after checking the validity of the DPoP 340 proof, MUST associate the access token issued at the token endpoint 341 with the public key. It then sets "token_type" to "DPoP" in the 342 token response. 344 A client typically cannot know whether a certain AS supports DPoP. 345 It therefore SHOULD use the value of the "token_type" parameter 346 returned from the AS to determine support for DPoP: If the token type 347 returned is "Bearer" or another value, the AS does not support DPoP. 348 If it is "DPoP", DPoP is supported. Only then, the client needs to 349 send the "DPoP" header in subsequent requests and use the token type 350 "DPoP" in the "Authorization" header as described below. 352 If a refresh token is issued to a public client at the token endpoint 353 and a valid DPoP proof is presented, the refresh token MUST be bound 354 to the public key contained in the header of the DPoP proof JWT. 356 If a DPoP-bound refresh token is to be used at the token endpoint by 357 a public client, the AS MUST ensure that the DPoP proof contains the 358 same public key as the one the refresh token is bound to. The access 359 token issued MUST be bound to the public key contained in the DPoP 360 proof. 362 6. Resource Access (Proof of Possession for Access Tokens) 364 To make use of an access token that is token-bound to a public key 365 using DPoP, a client MUST prove the possession of the corresponding 366 private key by providing a DPoP proof in the "DPoP" request header. 368 The DPoP-bound access token must be sent in the "Authorization" 369 header with the prefix "DPoP". 371 If a resource server detects that an access token that is to be used 372 for resource access is bound to a public key using DPoP (via the 373 methods described in Section 7) it MUST check that a header "DPoP" 374 was received in the HTTP request, and check the header's contents 375 according to the rules in Section 4.2. 377 The resource server MUST NOT grant access to the resource unless all 378 checks are successful. 380 GET /protectedresource HTTP/1.1 381 Host: resource.example.org 382 Authorization: DPoP eyJhbGciOiJFUzI1NiIsImtpZCI6IkJlQUxrYiJ9.eyJzdWI 383 iOiJzb21lb25lQGV4YW1wbGUuY29tIiwiaXNzIjoiaHR0cHM6Ly9zZXJ2ZXIuZXhhbX 384 BsZS5jb20iLCJhdWQiOiJodHRwczovL3Jlc291cmNlLmV4YW1wbGUub3JnIiwibmJmI 385 joxNTYyMjYyNjExLCJleHAiOjE1NjIyNjYyMTYsImNuZiI6eyJqa3QiOiIwWmNPQ09S 386 Wk5ZeS1EV3BxcTMwalp5SkdIVE4wZDJIZ2xCVjN1aWd1QTRJIn19.vsFiVqHCyIkBYu 387 50c69bmPJsj8qYlsXfuC6nZcLl8YYRNOhqMuRXu6oSZHe2dGZY0ODNaGg1cg-kVigzY 388 hF1MQ 389 DPoP: eyJ0eXAiOiJkcG9wK2p3dCIsImFsZyI6IkVTMjU2IiwiandrIjp7Imt0eSI6Ik 390 VDIiwieCI6Imw4dEZyaHgtMzR0VjNoUklDUkRZOXpDa0RscEJoRjQyVVFVZldWQVdCR 391 nMiLCJ5IjoiOVZFNGpmX09rX282NHpiVFRsY3VOSmFqSG10NnY5VERWclUwQ2R2R1JE 392 QSIsImNydiI6IlAtMjU2In19.eyJqdGkiOiJlMWozVl9iS2ljOC1MQUVCIiwiaHRtIj 393 oiR0VUIiwiaHR1IjoiaHR0cHM6Ly9yZXNvdXJjZS5leGFtcGxlLm9yZy9wcm90ZWN0Z 394 WRyZXNvdXJjZSIsImlhdCI6MTU2MjI2MjYxOH0.lNhmpAX1WwmpBvwhok4E74kWCiGB 395 NdavjLAeevGy32H3dbF0Jbri69Nm2ukkwb-uyUI4AUg1JSskfWIyo4UCbQ 397 Figure 4 399 Figure 4: Protected Resource Request with a DPoP sender-constrained 400 access token. 402 7. Public Key Confirmation 404 It MUST be ensured that resource servers can reliably identify 405 whether a token is bound using DPoP and learn the public key to which 406 the token is bound. 408 Access tokens that are represented as JSON Web Tokens (JWT) [RFC7519] 409 MUST contain information about the DPoP public key (in JWK format) in 410 the member "jkt" of the "cnf" claim, as shown in Figure 5. 412 The value in "jkt" MUST be the base64url encoding [RFC7515] of the 413 JWK SHA-256 Thumbprint (according to [RFC7638]) of the public key to 414 which the access token is bound. 416 { 417 "sub":"someone@example.com", 418 "iss":"https://server.example.com", 419 "aud":"https://resource.example.org", 420 "nbf":1562262611, 421 "exp":1562266216, 422 "cnf":{ 423 "jkt":"0ZcOCORZNYy-DWpqq30jZyJGHTN0d2HglBV3uiguA4I" 424 } 425 } 427 Figure 5 429 Figure 5: Example access token body with "cnf" claim. 431 When access token introspection is used, the same "cnf" claim as 432 above MUST be contained in the introspection response. 434 Resource servers MUST ensure that the fingerprint of the public key 435 in the DPoP proof JWT equals the value in the "jkt" claim in the 436 access token or introspection response. 438 8. Acknowledgements 440 We would like to thank David Waite, Filip Skokan, Mike Engan, and 441 Justin Richer for their valuable input and feedback. 443 This document resulted from discussions at the 4th OAuth Security 444 Workshop in Stuttgart, Germany. We thank the organizers of this 445 workshop (Ralf Kusters, Guido Schmitz). 447 9. Security Considerations 449 In DPoP, the prevention of token replay at a different endpoint (see 450 Section 2) is achieved through the binding of the DPoP proof to a 451 certain URI and HTTP method. DPoP does not, however, achieve the 452 same level of protection as TLS-based methods such as OAuth Mutual 453 TLS [RFC8705] or OAuth Token Binding [I-D.ietf-oauth-token-binding] 454 (see also Section 9.1 and Section 9.4). TLS-based mechanisms can 455 leverage a tight integration between the TLS layer and the 456 application layer to achieve a very high level of message integrity 457 and replay protection. Therefore, it is RECOMMENDED to prefer TLS- 458 based methods over DPoP if such methods are suitable for the scenario 459 at hand. 461 9.1. DPoP Proof Replay 463 If an adversary is able to get hold of a DPoP proof JWT, the 464 adversary could replay that token at the same endpoint (the HTTP 465 endpoint and method are enforced via the respective claims in the 466 JWTs). To prevent this, servers MUST only accept DPoP proofs for a 467 limited time window after their "iat" time, preferably only for a 468 relatively brief period. Servers SHOULD store the "jti" value of 469 each DPoP proof for the time window in which the respective DPoP 470 proof JWT would be accepted and decline HTTP requests for which the 471 "jti" value has been seen before. In order to guard against memory 472 exhaustion attacks a server SHOULD reject DPoP proof JWTs with 473 unnecessarily large "jti" values or store only a hash thereof. 475 Note: To accommodate for clock offsets, the server MAY accept DPoP 476 proofs that carry an "iat" time in the near future (e.g., up to a few 477 seconds in the future). 479 9.2. Signed JWT Swapping 481 Servers accepting signed DPoP proof JWTs MUST check the "typ" field 482 in the headers of the JWTs to ensure that adversaries cannot use JWTs 483 created for other purposes in the DPoP headers. 485 9.3. Signature Algorithms 487 Implementers MUST ensure that only asymmetric digital signature 488 algorithms that are deemed secure can be used for signing DPoP 489 proofs. In particular, the algorithm "none" MUST NOT be allowed. 491 9.4. Message Integrity 493 DPoP does not ensure the integrity of the payload or headers of 494 requests. The signature of DPoP proofs only contains the HTTP URI 495 and method, but not, for example, the message body or other request 496 headers. 498 This is an intentional design decision to keep DPoP simple to use, 499 but as described, makes DPoP potentially susceptible to replay 500 attacks where an attacker is able to modify message contents and 501 headers. In many setups, the message integrity and confidentiality 502 provided by TLS is sufficient to provide a good level of protection. 504 Implementers that have stronger requirements on the integrity of 505 messages are encouraged to either use TLS-based mechanisms or signed 506 requests. TLS-based mechanisms are in particular OAuth Mutual TLS 507 [RFC8705] and OAuth Token Binding [I-D.ietf-oauth-token-binding]. 509 Note: While signatures on (parts of) requests are out of the scope of 510 this specification, signatures or information to be signed can be 511 added into DPoP proofs. 513 10. IANA Considerations 515 10.1. OAuth Access Token Type Registration 517 This specification registers the following access token type in the 518 OAuth Access Token Types registry defined in [RFC6749]. 520 * Type name: "DPoP" 522 * Additional Token Endpoint Response Parameters: (none) 523 * HTTP Authentication Scheme(s): Bearer 525 * Change controller: IETF 527 * Specification document(s): [[ this specification ]] 529 10.2. JSON Web Signature and Encryption Type Values Registration 531 This specification registers the "dpop+jwt" type value in the IANA 532 JSON Web Signature and Encryption Type Values registry [RFC7515]: 534 * "typ" Header Parameter Value: "dpop+jwt" 536 * Abbreviation for MIME Type: None 538 * Change Controller: IETF 540 * Specification Document(s): [[ this specification ]] 542 11. Normative References 544 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 545 RFC 6749, DOI 10.17487/RFC6749, October 2012, 546 . 548 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 549 Resource Identifier (URI): Generic Syntax", STD 66, 550 RFC 3986, DOI 10.17487/RFC3986, January 2005, 551 . 553 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 554 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 555 . 557 [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, 558 DOI 10.17487/RFC7518, May 2015, 559 . 561 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 562 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 563 DOI 10.17487/RFC7231, June 2014, 564 . 566 [RFC7638] Jones, M. and N. Sakimura, "JSON Web Key (JWK) 567 Thumbprint", RFC 7638, DOI 10.17487/RFC7638, September 568 2015, . 570 12. Informative References 572 [RFC8705] Campbell, B., Bradley, J., Sakimura, N., and T. 573 Lodderstedt, "OAuth 2.0 Mutual-TLS Client Authentication 574 and Certificate-Bound Access Tokens", RFC 8705, 575 DOI 10.17487/RFC8705, February 2020, 576 . 578 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 579 Requirement Levels", BCP 14, RFC 2119, 580 DOI 10.17487/RFC2119, March 1997, 581 . 583 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 584 Unique IDentifier (UUID) URN Namespace", RFC 4122, 585 DOI 10.17487/RFC4122, July 2005, 586 . 588 [I-D.ietf-oauth-token-binding] 589 Jones, M., Campbell, B., Bradley, J., and W. Denniss, 590 "OAuth 2.0 Token Binding", Work in Progress, Internet- 591 Draft, draft-ietf-oauth-token-binding-08, 19 October 2018, 592 . 595 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 596 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 597 May 2017, . 599 [I-D.ietf-oauth-security-topics] 600 Lodderstedt, T., Bradley, J., Labunets, A., and D. Fett, 601 "OAuth 2.0 Security Best Current Practice", Work in 602 Progress, Internet-Draft, draft-ietf-oauth-security- 603 topics-14, 10 February 2020, . 606 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 607 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 608 2015, . 610 Appendix A. Document History 612 [[ To be removed from the final specification ]] 614 -00 [[ Working Group Draft ]] 616 * Working group draft 618 -04 619 * Update OAuth MTLS reference to RFC 8705 621 * Use the newish RFC v3 XML and HTML format 623 -03 625 * rework the text around uniqueness requirements on the jti claim in 626 the DPoP proof JWT 628 * make tokens a bit smaller by using "htm", "htu", and "jkt" rather 629 than "http_method", "http_uri", and "jkt#S256" respectively 631 * more explicit recommendation to use mTLS if that is available 633 * added David Waite as co-author 635 * editorial updates 637 -02 639 * added normalization rules for URIs 641 * removed distinction between proof and binding 643 * "jwk" header again used instead of "cnf" claim in DPoP proof 645 * renamed "Bearer-DPoP" token type to "DPoP" 647 * removed ability for key rotation 649 * added security considerations on request integrity 651 * explicit advice on extending DPoP proofs to sign other parts of 652 the HTTP messages 654 * only use the jkt#S256 in ATs 656 * iat instead of exp in DPoP proof JWTs 658 * updated guidance on token_type evaluation 660 -01 662 * fixed inconsistencies 664 * moved binding and proof messages to headers instead of parameters 666 * extracted and unified definition of DPoP JWTs 667 * improved description 669 -00 671 * first draft 673 Authors' Addresses 675 Daniel Fett 676 yes.com 678 Email: mail@danielfett.de 680 Brian Campbell 681 Ping Identity 683 Email: bcampbell@pingidentity.com 685 John Bradley 686 Yubico 688 Email: ve7jtb@ve7jtb.com 690 Torsten Lodderstedt 691 yes.com 693 Email: torsten@lodderstedt.net 695 Michael Jones 696 Microsoft 698 Email: mbj@microsoft.com 700 David Waite 701 Ping Identity 703 Email: david@alkaline-solutions.com