idnits 2.17.1 draft-ietf-oauth-jwt-bcp-04.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 (November 08, 2018) is 1986 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 6979 Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OAuth Working Group Y. Sheffer 3 Internet-Draft Intuit 4 Intended status: Best Current Practice D. Hardt 5 Expires: May 12, 2019 Amazon 6 M. Jones 7 Microsoft 8 November 08, 2018 10 JSON Web Token Best Current Practices 11 draft-ietf-oauth-jwt-bcp-04 13 Abstract 15 JSON Web Tokens, also known as JWTs, are URL-safe JSON-based security 16 tokens that contain a set of claims that can be signed and/or 17 encrypted. JWTs are being widely used and deployed as a simple 18 security token format in numerous protocols and applications, both in 19 the area of digital identity, and in other application areas. The 20 goal of this Best Current Practices document is to provide actionable 21 guidance leading to secure implementation and deployment of JWTs. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on May 12, 2019. 40 Copyright Notice 42 Copyright (c) 2018 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Target Audience . . . . . . . . . . . . . . . . . . . . . 3 59 1.2. Conventions used in this document . . . . . . . . . . . . 4 60 2. Threats and Vulnerabilities . . . . . . . . . . . . . . . . . 4 61 2.1. Weak Signatures and Insufficient Signature Validation . . 4 62 2.2. Weak symmetric keys . . . . . . . . . . . . . . . . . . . 4 63 2.3. Multiplicity of JSON encodings . . . . . . . . . . . . . 5 64 2.4. Incorrect Composition of Encryption and Signature . . . . 5 65 2.5. Insecure Use of Elliptic Curve Encryption . . . . . . . . 5 66 2.6. Substitution Attacks . . . . . . . . . . . . . . . . . . 5 67 2.7. Cross-JWT Confusion . . . . . . . . . . . . . . . . . . . 5 68 3. Best Practices . . . . . . . . . . . . . . . . . . . . . . . 6 69 3.1. Perform Algorithm Verification . . . . . . . . . . . . . 6 70 3.2. Use Appropriate Algorithms . . . . . . . . . . . . . . . 6 71 3.3. Validate All Cryptographic Operations . . . . . . . . . . 7 72 3.4. Validate Cryptographic Inputs . . . . . . . . . . . . . . 7 73 3.5. Ensure Cryptographic Keys have Sufficient Entropy . . . . 8 74 3.6. Avoid Length-Dependent Encryption Inputs . . . . . . . . 8 75 3.7. Use UTF-8 . . . . . . . . . . . . . . . . . . . . . . . . 8 76 3.8. Validate Issuer and Subject . . . . . . . . . . . . . . . 8 77 3.9. Use and Validate Audience . . . . . . . . . . . . . . . . 9 78 3.10. Do Not Trust Received Claims . . . . . . . . . . . . . . 9 79 3.11. Use Explicit Typing . . . . . . . . . . . . . . . . . . . 9 80 3.12. Use Mutually Exclusive Validation Rules for Different 81 Kinds of JWTs . . . . . . . . . . . . . . . . . . . . . . 10 82 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 83 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 84 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 85 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 86 7.1. Normative References . . . . . . . . . . . . . . . . . . 11 87 7.2. Informative References . . . . . . . . . . . . . . . . . 12 88 Appendix A. Document History . . . . . . . . . . . . . . . . . . 14 89 A.1. draft-ietf-oauth-jwt-bcp-04 . . . . . . . . . . . . . . . 14 90 A.2. draft-ietf-oauth-jwt-bcp-03 . . . . . . . . . . . . . . . 14 91 A.3. draft-ietf-oauth-jwt-bcp-02 . . . . . . . . . . . . . . . 14 92 A.4. draft-ietf-oauth-jwt-bcp-01 . . . . . . . . . . . . . . . 14 93 A.5. draft-ietf-oauth-jwt-bcp-00 . . . . . . . . . . . . . . . 14 94 A.6. draft-sheffer-oauth-jwt-bcp-01 . . . . . . . . . . . . . 14 95 A.7. draft-sheffer-oauth-jwt-bcp-00 . . . . . . . . . . . . . 14 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 98 1. Introduction 100 JSON Web Tokens, also known as JWTs [RFC7519], are URL-safe JSON- 101 based security tokens that contain a set of claims that can be signed 102 and/or encrypted. The JWT specification has seen rapid adoption 103 because it encapsulates security-relevant information in one, easy to 104 protect location, and because it is easy to implement using widely- 105 available tools. One application area in which JWTs are commonly 106 used is representing digital identity information, such as OpenID 107 Connect ID Tokens [OpenID.Core] and OAuth 2.0 [RFC6749] access tokens 108 and refresh tokens, the details of which are deployment-specific. 110 Since the JWT specification was published, there have been several 111 widely published attacks on implementations and deployments. Such 112 attacks are the result of under-specified security mechanisms, as 113 well as incomplete implementations and incorrect usage by 114 applications. 116 The goal of this document is to facilitate secure implementation and 117 deployment of JWTs. Many of the recommendations in this document 118 will actually be about implementation and use of the cryptographic 119 mechanisms underlying JWTs that are defined by JSON Web Signature 120 (JWS) [RFC7515], JSON Web Encryption (JWE) [RFC7516], and JSON Web 121 Algorithms (JWA) [RFC7518]. Others will be about use of the JWT 122 claims themselves. 124 These are intended to be minimum recommendations for the use of JWTs 125 in the vast majority of implementation and deployment scenarios. 126 Other specifications that reference this document can have stricter 127 requirements related to one or more aspects of the format, based on 128 their particular circumstances; when that is the case, implementers 129 are advised to adhere to those stricter requirements. Furthermore, 130 this document provides a floor, not a ceiling, so stronger options 131 are always allowed (e.g., depending on differing evaluations of the 132 importance of cryptographic strength vs. computational load). 134 Community knowledge about the strength of various algorithms and 135 feasible attacks can change quickly, and experience shows that a Best 136 Current Practice (BCP) document about security is a point-in-time 137 statement. Readers are advised to seek out any errata or updates 138 that apply to this document. 140 1.1. Target Audience 142 The targets of this document are: 144 - Implementers of JWT libraries (and the JWS and JWE libraries used 145 by them), 147 - Implementers of code that uses such libraries (to the extent that 148 some mechanisms may not be provided by libraries, or until they 149 are), and 151 - Developers of specifications that rely on JWTs, both inside and 152 outside the IETF. 154 1.2. Conventions used in this document 156 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 157 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 158 "OPTIONAL" in this document are to be interpreted as described in 159 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 160 capitals, as shown here. 162 2. Threats and Vulnerabilities 164 This section lists some known and possible problems with JWT 165 implementations and deployments. Each problem description is 166 followed by references to one or more mitigations to those problems. 168 2.1. Weak Signatures and Insufficient Signature Validation 170 Signed JSON Web Tokens carry an explicit indication of the signing 171 algorithm, in the form of the "alg" header parameter, to facilitate 172 cryptographic agility. This, in conjunction with design flaws in 173 some libraries and applications, have led to several attacks: 175 - The algorithm can be changed to "none" by an attacker, and some 176 libraries would trust this value and "validate" the JWT without 177 checking any signature. 179 - An "RS256" (RSA, 2048 bit) parameter value can be changed into 180 "HS256" (HMAC, SHA-256), and some libraries would try to validate 181 the signature using HMAC-SHA256 and using the RSA public key as 182 the HMAC shared secret. 184 For mitigations, see Section 3.1 and Section 3.2. 186 2.2. Weak symmetric keys 188 In addition, some applications sign tokens using a weak symmetric key 189 and a keyed MAC algorithm such as "HS256". In most cases, these keys 190 are human memorable passwords that are vulnerable to dictionary 191 attacks [Langkemper]. 193 For mitigations, see Section 3.5. 195 2.3. Multiplicity of JSON encodings 197 Previous versions of the JSON format [RFC8259] allowed several 198 different character encodings: UTF-8, UTF-16 and UTF-32. This is not 199 the case anymore, with the latest standard only allowing UTF-8. 200 However older implementations may result in the JWT being 201 misinterpreted by its recipient. 203 For mitigations, see Section 3.7. 205 2.4. Incorrect Composition of Encryption and Signature 207 Some libraries that decrypt a JWE-encrypted JWT to obtain a JWS- 208 signed object do not always validate the internal signature. 210 For mitigations, see Section 3.3. 212 2.5. Insecure Use of Elliptic Curve Encryption 214 Per [Sanso], several JOSE libraries fail to validate their inputs 215 correctly when performing elliptic curve key agreement (the "ECDH-ES" 216 algorithm). An attacker that is able to send JWEs of its choosing 217 that use invalid curve points and observe the cleartext outputs 218 resulting from decryption with the invalid curve points can use this 219 vulnerability to recover the recipient's private key. 221 For mitigations, see Section 3.4. 223 2.6. Substitution Attacks 225 There are attacks in which one recipient will have a JWT intended for 226 it and attempt to use it at a different recipient that it was not 227 intended for. If not caught, these attacks can result in the 228 attacker gaining access to resources that it is not entitled to 229 access. For instance, if an OAuth 2.0 [RFC6749] access token is 230 presented to an OAuth 2.0 protected resource that it is intended for, 231 that protected resource might then attempt to gain access to a 232 different protected resource by presenting that same access token to 233 the different protected resource, which the access token is not 234 intended for. 236 For mitigations, see Section 3.8 and Section 3.9. 238 2.7. Cross-JWT Confusion 240 As JWTs are being used by more different protocols in diverse 241 application areas, it becomes increasingly important to prevent cases 242 of JWT tokens that have been issued for one purpose being subverted 243 and used for another. Note that this is a specific type of 244 substitution attack. If the JWT could be used in an application 245 context in which it could be confused with other kinds of JWTs, then 246 mitigations MUST be employed to prevent these substitution attacks. 248 For mitigations, see Section 3.8, Section 3.9, Section 3.11, and 249 Section 3.12. 251 3. Best Practices 253 The best practices listed below should be applied by practitioners to 254 mitigate the threats listed in the preceding section. 256 3.1. Perform Algorithm Verification 258 Libraries MUST enable the caller to specify a supported set of 259 algorithms and MUST NOT use any other algorithms when performing 260 cryptographic operations. The library MUST ensure that the "alg" or 261 "enc" header specifies the same algorithm that is used for the 262 cryptographic operation. Moreover, each key MUST be used with 263 exactly one algorithm, and this MUST be checked when the 264 cryptographic operation is performed. 266 3.2. Use Appropriate Algorithms 268 As Section 5.2 of [RFC7515] says, "it is an application decision 269 which algorithms may be used in a given context. Even if a JWS can 270 be successfully validated, unless the algorithm(s) used in the JWS 271 are acceptable to the application, it SHOULD consider the JWS to be 272 invalid." 274 Therefore, applications MUST only allow the use of cryptographically 275 current algorithms that meet the security requirements of the 276 application. This set will vary over time as new algorithms are 277 introduced and existing algorithms are deprecated due to discovered 278 cryptographic weaknesses. Applications MUST therefore be designed to 279 enable cryptographic agility. 281 That said, if a JWT is cryptographically protected by a transport 282 layer, such as TLS using cryptographically current algorithms, there 283 may be no need to apply another layer of cryptographic protections to 284 the JWT. In such cases, the use of the "none" algorithm can be 285 perfectly acceptable. The "none" algorithm should only be used when 286 the JWT is cryptographically protected by other means. JWTs using 287 "none" are often used in application contexts in which the content is 288 optionally signed; then the URL-safe claims representation and 289 processing can be the same in both the signed and unsigned cases. 291 JWT libraries SHOULD NOT generate JWTs using "none" unless explicitly 292 requested to do by the caller. 294 Applications SHOULD follow these algorithm-specific recommendations: 296 - Avoid all RSA-PKCS1 v1.5 encryption algorithms, preferring RSA- 297 OAEP. 299 - ECDSA signatures require a unique random value for every message 300 that is signed. If even just a few bits of the random value are 301 predictable across multiple messages then the security of the 302 signature scheme may be compromised. In the worst case, the 303 private key may be recoverable by an attacker. To counter these 304 attacks, JWT libraries SHOULD implement ECDSA using the 305 deterministic approach defined in [RFC6979]. This approach is 306 completely compatible with existing ECDSA verifiers and so can be 307 implemented without new algorithm identifiers being required. 309 3.3. Validate All Cryptographic Operations 311 All cryptographic operations used in the JWT MUST be validated and 312 the entire JWT MUST be rejected if any of them fail to validate. 313 This is true not only of JWTs with a single set of Header Parameters 314 but also for Nested JWTs, in which both outer and inner operations 315 MUST be validated using the keys and algorithms supplied by the 316 application. 318 3.4. Validate Cryptographic Inputs 320 Some cryptographic operations, such as Elliptic Curve Diffie-Hellman 321 key agreement ("ECDH-ES") take inputs that may contain invalid 322 values, such as points not on the specified elliptic curve or other 323 invalid points (see e.g. [Valenta], Sec. 7.1). Either the JWS/JWE 324 library itself must validate these inputs before using them or it 325 must use underlying cryptographic libraries that do so (or both!). 327 ECDH-ES ephemeral public key (epk) inputs should be validated 328 according to the recipient's chosen elliptic curve. For the NIST 329 prime-order curves P-256, P-384 and P-521, validation MUST be 330 performed according to Section 5.6.2.3.4 "ECC Partial Public-Key 331 Validation Routine" of NIST Special Publication 800-56A revision 3 332 [nist-sp-800-56a-r3]. Likewise, if the "X25519" or "X448" [RFC8037] 333 algorithms are used, then the security considerations in [RFC8037] 334 apply. 336 3.5. Ensure Cryptographic Keys have Sufficient Entropy 338 The Key Entropy and Random Values advice in Section 10.1 of [RFC7515] 339 and the Password Considerations in Section 8.8 of [RFC7518] MUST be 340 followed. In particular, human-memorizable passwords MUST NOT be 341 directly used as the key to a keyed-MAC algorithm such as "HS256". 342 In particular, passwords should only be used to perform key 343 encryption, rather than content encryption, as described in 344 Section 4.8 of [RFC7518]. Note that even when used for key 345 encryption, password-based encryption is still subject to brute-force 346 attacks. 348 3.6. Avoid Length-Dependent Encryption Inputs 350 Many encryption algorithms leak information about the length of the 351 plaintext, with a varying amount of leakage depending on the 352 algorithm and mode of operation. Sensitive information, such as 353 passwords, SHOULD be padded before being encrypted. It is 354 RECOMMENDED to avoid any compression of data before encryption since 355 such compression often reveals information about the plaintext. 357 3.7. Use UTF-8 359 [RFC7515], [RFC7516], and [RFC7519] all specify that UTF-8 be used 360 for encoding and decoding JSON used in Header Parameters and JWT 361 Claims Sets. This is also in line with the latest JSON specification 362 [RFC8259]. Implementations and applications MUST do this, and not 363 use or admit the use of other Unicode encodings for these purposes. 365 3.8. Validate Issuer and Subject 367 When a JWT contains an "iss" (issuer) claim, the application MUST 368 validate that the cryptographic keys used for the cryptographic 369 operations in the JWT belong to the issuer. If they do not, the 370 application MUST reject the JWT. 372 The means of determining the keys owned by an issuer is application- 373 specific. As one example, OpenID Connect [OpenID.Core] issuer values 374 are "https" URLs that reference a JSON metadata document that 375 contains a "jwks_uri" value that is an "https" URL from which the 376 issuer's keys are retrieved as a JWK Set [RFC7517]. This same 377 mechanism is used by [I-D.ietf-oauth-discovery]. Other applications 378 may use different means of binding keys to issuers. 380 Similarly, when the JWT contains a "sub" (subject) claim, the 381 application MUST validate that the subject value corresponds to a 382 valid subject and/or issuer/subject pair at the application. This 383 may include confirming that the issuer is trusted by the application. 385 If the issuer, subject, or the pair are invalid, the application MUST 386 reject the JWT. 388 3.9. Use and Validate Audience 390 If the same issuer can issue JWTs that are intended for use by more 391 than one relying party or application, the JWT MUST contain an "aud" 392 (audience) claim that can be used to determine whether the JWT is 393 being used by an intended party or was substituted by an attacker at 394 an unintended party. Furthermore, the relying party or application 395 MUST validate the audience value and if the audience value is not 396 present or not associated with the recipient, it MUST reject the JWT. 398 3.10. Do Not Trust Received Claims 400 The "kid" (key ID) header is used by the relying application to 401 perform key lookup. Applications should ensure that this does not 402 create SQL or LDAP injection vulnerabilities. 404 Similarly, blindly following a "jku" (JWK set URL) header, which may 405 contain an arbitrary URL, could result in server-side request forgery 406 (SSRF) attacks. 408 3.11. Use Explicit Typing 410 Confusion of one kind of JWT for another can be prevented by having 411 all the kinds of JWTs that could otherwise potentially be confused 412 include an explicit JWT type value and include checking the type 413 value in their validation rules. Explicit JWT typing is accomplished 414 by using the "typ" header parameter. For instance, the 415 [I-D.ietf-secevent-token] specification uses the "application/ 416 secevent+jwt" media type to perform explicit typing of Security Event 417 Tokens (SETs). 419 Per the definition of "typ" in Section 4.1.9 of [RFC7515], it is 420 RECOMMENDED that the "application/" prefix be omitted from the "typ" 421 value. Therefore, for example, the "typ" value used to explicitly 422 include a type for a SET SHOULD be "secevent+jwt". When explicit 423 typing is employed for a JWT, it is RECOMMENDED that a media type 424 name of the format "application/example+jwt" be used, where "example" 425 is replaced by the identifier for the specific kind of JWT. 427 When applying explicit typing to a Nested JWT, the "typ" header 428 parameter containing the explicit type value MUST be present in the 429 inner JWT of the Nested JWT (the JWT whose payload is the JWT Claims 430 Set). The same "typ" header parameter value MAY be present in the 431 outer JWT as well, to explicitly type the entire Nested JWT. 433 Note that the use of explicit typing may not achieve disambiguation 434 from existing kinds of JWTs, as the validation rules for existing 435 kinds JWTs often do not use the "typ" header parameter value. 436 Explicit typing is RECOMMENDED for new uses of JWTs. 438 3.12. Use Mutually Exclusive Validation Rules for Different Kinds of 439 JWTs 441 Each application of JWTs defines a profile specifying the required 442 and optional JWT claims and the validation rules associated with 443 them. If more than one kind of JWT can be issued by the same issuer, 444 the validation rules for those JWTs MUST be written such that they 445 are mutually exclusive, rejecting JWTs of the wrong kind. To prevent 446 substitution of JWTs from one context into another, a number of 447 strategies may be employed: 449 - Use explicit typing for different kinds of JWTs. Then the 450 distinct "typ" values can be used to differentiate between the 451 different kinds of JWTs. 453 - Use different sets of required claims or different required claim 454 values. Then the validation rules for one kind of JWT will reject 455 those with different claims or values. 457 - Use different sets of required header parameters or different 458 required header parameter values. Then the validation rules for 459 one kind of JWT will reject those with different header parameters 460 or values. 462 - Use different keys for different kinds of JWTs. Then the keys 463 used to validate one kind of JWT will fail to validate other kinds 464 of JWTs. 466 - Use different "aud" values for different uses of JWTs from the 467 same issuer. Then audience validation will reject JWTs 468 substituted into inappropriate contexts. 470 - Use different issuers for different kinds of JWTs. Then the 471 distinct "iss" values can be used to segregate the different kinds 472 of JWTs. 474 Given the broad diversity of JWT usage and applications, the best 475 combination of types, required claims, values, header parameters, key 476 usages, and issuers to differentiate among different kinds of JWTs 477 will, in general, be application specific. For new JWT applications, 478 the use of explicit typing is RECOMMENDED. 480 4. Security Considerations 482 This entire document is about security considerations when 483 implementing and deploying JSON Web Tokens. 485 5. IANA Considerations 487 This document requires no IANA actions. 489 6. Acknowledgements 491 Thanks to Antonio Sanso for bringing the "ECDH-ES" invalid point 492 attack to the attention of JWE and JWT implementers. Tim McLean 493 published the RSA/HMAC confusion attack. Thanks to Nat Sakimura for 494 advocating the use of explicit typing. Thanks to Neil Madden for his 495 numerous comments, and to Carsten Bormann, Brian Campbell and Eric 496 Rescorla for their reviews. 498 7. References 500 7.1. Normative References 502 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 503 Requirement Levels", BCP 14, RFC 2119, 504 DOI 10.17487/RFC2119, March 1997, 505 . 507 [RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature 508 Algorithm (DSA) and Elliptic Curve Digital Signature 509 Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August 510 2013, . 512 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 513 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 514 2015, . 516 [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", 517 RFC 7516, DOI 10.17487/RFC7516, May 2015, 518 . 520 [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, 521 DOI 10.17487/RFC7518, May 2015, 522 . 524 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 525 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 526 . 528 [RFC8037] Liusvaara, I., "CFRG Elliptic Curve Diffie-Hellman (ECDH) 529 and Signatures in JSON Object Signing and Encryption 530 (JOSE)", RFC 8037, DOI 10.17487/RFC8037, January 2017, 531 . 533 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 534 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 535 May 2017, . 537 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 538 Interchange Format", STD 90, RFC 8259, 539 DOI 10.17487/RFC8259, December 2017, 540 . 542 7.2. Informative References 544 [I-D.ietf-oauth-discovery] 545 Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 546 Authorization Server Metadata", draft-ietf-oauth- 547 discovery-10 (work in progress), March 2018. 549 [I-D.ietf-secevent-token] 550 Hunt, P., Jones, M., Denniss, W., and M. Ansari, "Security 551 Event Token (SET)", draft-ietf-secevent-token-13 (work in 552 progress), May 2018. 554 [Langkemper] 555 Langkemper, S., "Attacking JWT Authentication", September 556 2016, . 559 [nist-sp-800-56a-r3] 560 Barker, E., Chen, L., Keller, S., Roginsky, A., Vassilev, 561 A., and R. Davis, "Recommendation for Pair-Wise Key 562 Establishment Schemes Using Discrete Logarithm 563 Cryptography, Draft NIST Special Publication 800-56A 564 Revision 3", April 2018, 565 . 567 [OpenID.Core] 568 Sakimura, N., Bradley, J., Jones, M., Medeiros, B., and C. 569 Mortimore, "OpenID Connect Core 1.0", November 2014, 570 . 572 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 573 RFC 6749, DOI 10.17487/RFC6749, October 2012, 574 . 576 [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, 577 DOI 10.17487/RFC7517, May 2015, 578 . 580 [Sanso] Sanso, A., "Critical Vulnerability Uncovered in JSON 581 Encryption", March 2017, 582 . 585 [Valenta] Valenta, L., Sullivan, N., Sanso, A., and N. Heninger, "In 586 search of CurveSwap: Measuring elliptic curve 587 implementations in the wild", March 2018, 588 . 590 Appendix A. Document History 592 [[ to be removed by the RFC editor before publication as an RFC ]] 594 A.1. draft-ietf-oauth-jwt-bcp-04 596 - AD review comments. 598 A.2. draft-ietf-oauth-jwt-bcp-03 600 - Acknowledgements. 602 A.3. draft-ietf-oauth-jwt-bcp-02 604 - Implemented WGLC feedback. 606 A.4. draft-ietf-oauth-jwt-bcp-01 608 - Feedback from Brian Campbell. 610 A.5. draft-ietf-oauth-jwt-bcp-00 612 - Initial WG draft. No change from the latest individual version. 614 A.6. draft-sheffer-oauth-jwt-bcp-01 616 - Added explicit typing. 618 A.7. draft-sheffer-oauth-jwt-bcp-00 620 - Initial version. 622 Authors' Addresses 624 Yaron Sheffer 625 Intuit 627 EMail: yaronf.ietf@gmail.com 629 Dick Hardt 630 Amazon 632 EMail: dick@amazon.com 633 Michael B. Jones 634 Microsoft 636 EMail: mbj@microsoft.com 637 URI: http://self-issued.info/