draft-ietf-oauth-jwt-bcp-03.txt   draft-ietf-oauth-jwt-bcp-04.txt 
OAuth Working Group Y. Sheffer OAuth Working Group Y. Sheffer
Internet-Draft Intuit Internet-Draft Intuit
Intended status: Best Current Practice D. Hardt Intended status: Best Current Practice D. Hardt
Expires: November 9, 2018 Amazon Expires: May 12, 2019 Amazon
M. Jones M. Jones
Microsoft Microsoft
May 08, 2018 November 08, 2018
JSON Web Token Best Current Practices JSON Web Token Best Current Practices
draft-ietf-oauth-jwt-bcp-03 draft-ietf-oauth-jwt-bcp-04
Abstract Abstract
JSON Web Tokens, also known as JWTs, are URL-safe JSON-based security JSON Web Tokens, also known as JWTs, are URL-safe JSON-based security
tokens that contain a set of claims that can be signed and/or tokens that contain a set of claims that can be signed and/or
encrypted. JWTs are being widely used and deployed as a simple encrypted. JWTs are being widely used and deployed as a simple
security token format in numerous protocols and applications, both in security token format in numerous protocols and applications, both in
the area of digital identity, and in other application areas. The the area of digital identity, and in other application areas. The
goal of this Best Current Practices document is to provide actionable goal of this Best Current Practices document is to provide actionable
guidance leading to secure implementation and deployment of JWTs. guidance leading to secure implementation and deployment of JWTs.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 9, 2018. This Internet-Draft will expire on May 12, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 28 skipping to change at page 2, line 28
2.3. Multiplicity of JSON encodings . . . . . . . . . . . . . 5 2.3. Multiplicity of JSON encodings . . . . . . . . . . . . . 5
2.4. Incorrect Composition of Encryption and Signature . . . . 5 2.4. Incorrect Composition of Encryption and Signature . . . . 5
2.5. Insecure Use of Elliptic Curve Encryption . . . . . . . . 5 2.5. Insecure Use of Elliptic Curve Encryption . . . . . . . . 5
2.6. Substitution Attacks . . . . . . . . . . . . . . . . . . 5 2.6. Substitution Attacks . . . . . . . . . . . . . . . . . . 5
2.7. Cross-JWT Confusion . . . . . . . . . . . . . . . . . . . 5 2.7. Cross-JWT Confusion . . . . . . . . . . . . . . . . . . . 5
3. Best Practices . . . . . . . . . . . . . . . . . . . . . . . 6 3. Best Practices . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Perform Algorithm Verification . . . . . . . . . . . . . 6 3.1. Perform Algorithm Verification . . . . . . . . . . . . . 6
3.2. Use Appropriate Algorithms . . . . . . . . . . . . . . . 6 3.2. Use Appropriate Algorithms . . . . . . . . . . . . . . . 6
3.3. Validate All Cryptographic Operations . . . . . . . . . . 7 3.3. Validate All Cryptographic Operations . . . . . . . . . . 7
3.4. Validate Cryptographic Inputs . . . . . . . . . . . . . . 7 3.4. Validate Cryptographic Inputs . . . . . . . . . . . . . . 7
3.5. Ensure Cryptographic Keys have Sufficient Entropy . . . . 7 3.5. Ensure Cryptographic Keys have Sufficient Entropy . . . . 8
3.6. Avoid Length-Dependent Encryption Inputs . . . . . . . . 7 3.6. Avoid Length-Dependent Encryption Inputs . . . . . . . . 8
3.7. Use UTF-8 . . . . . . . . . . . . . . . . . . . . . . . . 8 3.7. Use UTF-8 . . . . . . . . . . . . . . . . . . . . . . . . 8
3.8. Validate Issuer and Subject . . . . . . . . . . . . . . . 8 3.8. Validate Issuer and Subject . . . . . . . . . . . . . . . 8
3.9. Use and Validate Audience . . . . . . . . . . . . . . . . 8 3.9. Use and Validate Audience . . . . . . . . . . . . . . . . 9
3.10. Do Not Trust Received Claims . . . . . . . . . . . . . . 8 3.10. Do Not Trust Received Claims . . . . . . . . . . . . . . 9
3.11. Use Explicit Typing . . . . . . . . . . . . . . . . . . . 9 3.11. Use Explicit Typing . . . . . . . . . . . . . . . . . . . 9
3.12. Use Mutually Exclusive Validation Rules for Different 3.12. Use Mutually Exclusive Validation Rules for Different
Kinds of JWTs . . . . . . . . . . . . . . . . . . . . . . 9 Kinds of JWTs . . . . . . . . . . . . . . . . . . . . . . 10
4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. Normative References . . . . . . . . . . . . . . . . . . 11 7.1. Normative References . . . . . . . . . . . . . . . . . . 11
7.2. Informative References . . . . . . . . . . . . . . . . . 11 7.2. Informative References . . . . . . . . . . . . . . . . . 12
Appendix A. Document History . . . . . . . . . . . . . . . . . . 13 Appendix A. Document History . . . . . . . . . . . . . . . . . . 14
A.1. draft-ietf-oauth-jwt-bcp-03 . . . . . . . . . . . . . . . 13 A.1. draft-ietf-oauth-jwt-bcp-04 . . . . . . . . . . . . . . . 14
A.2. draft-ietf-oauth-jwt-bcp-02 . . . . . . . . . . . . . . . 13 A.2. draft-ietf-oauth-jwt-bcp-03 . . . . . . . . . . . . . . . 14
A.3. draft-ietf-oauth-jwt-bcp-01 . . . . . . . . . . . . . . . 13 A.3. draft-ietf-oauth-jwt-bcp-02 . . . . . . . . . . . . . . . 14
A.4. draft-ietf-oauth-jwt-bcp-00 . . . . . . . . . . . . . . . 13 A.4. draft-ietf-oauth-jwt-bcp-01 . . . . . . . . . . . . . . . 14
A.5. draft-sheffer-oauth-jwt-bcp-01 . . . . . . . . . . . . . 13 A.5. draft-ietf-oauth-jwt-bcp-00 . . . . . . . . . . . . . . . 14
A.6. draft-sheffer-oauth-jwt-bcp-00 . . . . . . . . . . . . . 13 A.6. draft-sheffer-oauth-jwt-bcp-01 . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 A.7. draft-sheffer-oauth-jwt-bcp-00 . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
JSON Web Tokens, also known as JWTs [RFC7519], are URL-safe JSON- JSON Web Tokens, also known as JWTs [RFC7519], are URL-safe JSON-
based security tokens that contain a set of claims that can be signed based security tokens that contain a set of claims that can be signed
and/or encrypted. The JWT specification has seen rapid adoption and/or encrypted. The JWT specification has seen rapid adoption
because it encapsulates security-relevant information in one, easy to because it encapsulates security-relevant information in one, easy to
protect location, and because it is easy to implement using widely- protect location, and because it is easy to implement using widely-
available tools. One application area in which JWTs are commonly available tools. One application area in which JWTs are commonly
used is representing digital identity information, such as OpenID used is representing digital identity information, such as OpenID
skipping to change at page 4, line 17 skipping to change at page 4, line 17
are), and are), and
- Developers of specifications that rely on JWTs, both inside and - Developers of specifications that rely on JWTs, both inside and
outside the IETF. outside the IETF.
1.2. Conventions used in this document 1.2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Threats and Vulnerabilities 2. Threats and Vulnerabilities
This section lists some known and possible problems with JWT This section lists some known and possible problems with JWT
implementations and deployments. Each problem description is implementations and deployments. Each problem description is
followed by references to one or more mitigations to those problems. followed by references to one or more mitigations to those problems.
2.1. Weak Signatures and Insufficient Signature Validation 2.1. Weak Signatures and Insufficient Signature Validation
Signed JSON Web Tokens carry an explicit indication of the signing Signed JSON Web Tokens carry an explicit indication of the signing
skipping to change at page 5, line 39 skipping to change at page 5, line 39
vulnerability to recover the recipient's private key. vulnerability to recover the recipient's private key.
For mitigations, see Section 3.4. For mitigations, see Section 3.4.
2.6. Substitution Attacks 2.6. Substitution Attacks
There are attacks in which one recipient will have a JWT intended for There are attacks in which one recipient will have a JWT intended for
it and attempt to use it at a different recipient that it was not it and attempt to use it at a different recipient that it was not
intended for. If not caught, these attacks can result in the intended for. If not caught, these attacks can result in the
attacker gaining access to resources that it is not entitled to attacker gaining access to resources that it is not entitled to
access. access. For instance, if an OAuth 2.0 [RFC6749] access token is
presented to an OAuth 2.0 protected resource that it is intended for,
that protected resource might then attempt to gain access to a
different protected resource by presenting that same access token to
the different protected resource, which the access token is not
intended for.
For mitigations, see Section 3.8 and Section 3.9. For mitigations, see Section 3.8 and Section 3.9.
2.7. Cross-JWT Confusion 2.7. Cross-JWT Confusion
As JWTs are being used by more different protocols in diverse As JWTs are being used by more different protocols in diverse
application areas, it becomes increasingly important to prevent cases application areas, it becomes increasingly important to prevent cases
of JWT tokens that have been issued for one purpose being subverted of JWT tokens that have been issued for one purpose being subverted
and used for another. Note that this is a specific type of and used for another. Note that this is a specific type of
substitution attack. If the JWT could be used in an application substitution attack. If the JWT could be used in an application
skipping to change at page 6, line 35 skipping to change at page 6, line 39
As Section 5.2 of [RFC7515] says, "it is an application decision As Section 5.2 of [RFC7515] says, "it is an application decision
which algorithms may be used in a given context. Even if a JWS can which algorithms may be used in a given context. Even if a JWS can
be successfully validated, unless the algorithm(s) used in the JWS be successfully validated, unless the algorithm(s) used in the JWS
are acceptable to the application, it SHOULD consider the JWS to be are acceptable to the application, it SHOULD consider the JWS to be
invalid." invalid."
Therefore, applications MUST only allow the use of cryptographically Therefore, applications MUST only allow the use of cryptographically
current algorithms that meet the security requirements of the current algorithms that meet the security requirements of the
application. This set will vary over time as new algorithms are application. This set will vary over time as new algorithms are
introduced and existing algorithms are deprecated due to discovered introduced and existing algorithms are deprecated due to discovered
cryptographic weaknesses. Applications must therefore be designed to cryptographic weaknesses. Applications MUST therefore be designed to
enable cryptographic agility. enable cryptographic agility.
That said, if a JWT is cryptographically protected by a transport That said, if a JWT is cryptographically protected by a transport
layer, such as TLS using cryptographically current algorithms, there layer, such as TLS using cryptographically current algorithms, there
may be no need to apply another layer of cryptographic protections to may be no need to apply another layer of cryptographic protections to
the JWT. In such cases, the use of the "none" algorithm can be the JWT. In such cases, the use of the "none" algorithm can be
perfectly acceptable. JWTs using "none" are often used in perfectly acceptable. The "none" algorithm should only be used when
application contexts in which the content is optionally signed; then the JWT is cryptographically protected by other means. JWTs using
the URL-safe claims representation and processing can be the same in "none" are often used in application contexts in which the content is
both the signed and unsigned cases. optionally signed; then the URL-safe claims representation and
processing can be the same in both the signed and unsigned cases.
JWT libraries SHOULD NOT generate JWTs using "none" unless explicitly
requested to do by the caller.
Applications SHOULD follow these algorithm-specific recommendations: Applications SHOULD follow these algorithm-specific recommendations:
- Avoid all RSA-PKCS1 v1.5 encryption algorithms, preferring RSA- - Avoid all RSA-PKCS1 v1.5 encryption algorithms, preferring RSA-
OAEP. OAEP.
- ECDSA signatures require a unique random value for every message - ECDSA signatures require a unique random value for every message
that is signed. If even just a few bits of the random value are that is signed. If even just a few bits of the random value are
predictable across multiple messages then the security of the predictable across multiple messages then the security of the
signature scheme may be compromised. In the worst case, the signature scheme may be compromised. In the worst case, the
skipping to change at page 7, line 38 skipping to change at page 7, line 46
values, such as points not on the specified elliptic curve or other values, such as points not on the specified elliptic curve or other
invalid points (see e.g. [Valenta], Sec. 7.1). Either the JWS/JWE invalid points (see e.g. [Valenta], Sec. 7.1). Either the JWS/JWE
library itself must validate these inputs before using them or it library itself must validate these inputs before using them or it
must use underlying cryptographic libraries that do so (or both!). must use underlying cryptographic libraries that do so (or both!).
ECDH-ES ephemeral public key (epk) inputs should be validated ECDH-ES ephemeral public key (epk) inputs should be validated
according to the recipient's chosen elliptic curve. For the NIST according to the recipient's chosen elliptic curve. For the NIST
prime-order curves P-256, P-384 and P-521, validation MUST be prime-order curves P-256, P-384 and P-521, validation MUST be
performed according to Section 5.6.2.3.4 "ECC Partial Public-Key performed according to Section 5.6.2.3.4 "ECC Partial Public-Key
Validation Routine" of NIST Special Publication 800-56A revision 3 Validation Routine" of NIST Special Publication 800-56A revision 3
[nist-sp-800-56a-r3]. [nist-sp-800-56a-r3]. Likewise, if the "X25519" or "X448" [RFC8037]
algorithms are used, then the security considerations in [RFC8037]
apply.
3.5. Ensure Cryptographic Keys have Sufficient Entropy 3.5. Ensure Cryptographic Keys have Sufficient Entropy
The Key Entropy and Random Values advice in Section 10.1 of [RFC7515] The Key Entropy and Random Values advice in Section 10.1 of [RFC7515]
and the Password Considerations in Section 8.8 of [RFC7518] MUST be and the Password Considerations in Section 8.8 of [RFC7518] MUST be
followed. In particular, human-memorizable passwords MUST NOT be followed. In particular, human-memorizable passwords MUST NOT be
directly used as the key to a keyed-MAC algorithm such as "HS256". directly used as the key to a keyed-MAC algorithm such as "HS256".
In particular, passwords should only be used to perform key
encryption, rather than content encryption, as described in
Section 4.8 of [RFC7518]. Note that even when used for key
encryption, password-based encryption is still subject to brute-force
attacks.
3.6. Avoid Length-Dependent Encryption Inputs 3.6. Avoid Length-Dependent Encryption Inputs
Many encryption algorithms leak information about the length of the Many encryption algorithms leak information about the length of the
plaintext, with a varying amount of leakage depending on the plaintext, with a varying amount of leakage depending on the
algorithm and mode of operation. Sensitive information, such as algorithm and mode of operation. Sensitive information, such as
passwords, SHOULD be padded before being encrypted. It is passwords, SHOULD be padded before being encrypted. It is
RECOMMENDED to avoid any compression of data before encryption since RECOMMENDED to avoid any compression of data before encryption since
such compression often reveals information about the plaintext. such compression often reveals information about the plaintext.
skipping to change at page 10, line 29 skipping to change at page 10, line 49
same issuer. Then audience validation will reject JWTs same issuer. Then audience validation will reject JWTs
substituted into inappropriate contexts. substituted into inappropriate contexts.
- Use different issuers for different kinds of JWTs. Then the - Use different issuers for different kinds of JWTs. Then the
distinct "iss" values can be used to segregate the different kinds distinct "iss" values can be used to segregate the different kinds
of JWTs. of JWTs.
Given the broad diversity of JWT usage and applications, the best Given the broad diversity of JWT usage and applications, the best
combination of types, required claims, values, header parameters, key combination of types, required claims, values, header parameters, key
usages, and issuers to differentiate among different kinds of JWTs usages, and issuers to differentiate among different kinds of JWTs
will, in general, be application specific. will, in general, be application specific. For new JWT applications,
the use of explicit typing is RECOMMENDED.
4. Security Considerations 4. Security Considerations
This entire document is about security considerations when This entire document is about security considerations when
implementing and deploying JSON Web Tokens. implementing and deploying JSON Web Tokens.
5. IANA Considerations 5. IANA Considerations
This document requires no IANA actions. This document requires no IANA actions.
6. Acknowledgements 6. Acknowledgements
Thanks to Antonio Sanso for bringing the "ECDH-ES" invalid point Thanks to Antonio Sanso for bringing the "ECDH-ES" invalid point
attack to the attention of JWE and JWT implementers. Tim McLean attack to the attention of JWE and JWT implementers. Tim McLean
published the RSA/HMAC confusion attack. Thanks to Nat Sakimura for published the RSA/HMAC confusion attack. Thanks to Nat Sakimura for
advocating the use of explicit typing. Thanks to Neil Madden for his advocating the use of explicit typing. Thanks to Neil Madden for his
numerous comments, and to Carsten Bormann and Brian Campbell for numerous comments, and to Carsten Bormann, Brian Campbell and Eric
their reviews. Rescorla for their reviews.
7. References 7. References
7.1. Normative References 7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 11, line 35 skipping to change at page 12, line 5
<https://www.rfc-editor.org/info/rfc7516>. <https://www.rfc-editor.org/info/rfc7516>.
[RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518,
DOI 10.17487/RFC7518, May 2015, DOI 10.17487/RFC7518, May 2015,
<https://www.rfc-editor.org/info/rfc7518>. <https://www.rfc-editor.org/info/rfc7518>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/info/rfc7519>. <https://www.rfc-editor.org/info/rfc7519>.
[RFC8037] Liusvaara, I., "CFRG Elliptic Curve Diffie-Hellman (ECDH)
and Signatures in JSON Object Signing and Encryption
(JOSE)", RFC 8037, DOI 10.17487/RFC8037, January 2017,
<https://www.rfc-editor.org/info/rfc8037>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259, Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017, DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/info/rfc8259>. <https://www.rfc-editor.org/info/rfc8259>.
7.2. Informative References 7.2. Informative References
[I-D.ietf-oauth-discovery] [I-D.ietf-oauth-discovery]
Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0
Authorization Server Metadata", draft-ietf-oauth- Authorization Server Metadata", draft-ietf-oauth-
discovery-10 (work in progress), March 2018. discovery-10 (work in progress), March 2018.
[I-D.ietf-secevent-token] [I-D.ietf-secevent-token]
Hunt, P., Jones, M., Denniss, W., and M. Ansari, "Security Hunt, P., Jones, M., Denniss, W., and M. Ansari, "Security
Event Token (SET)", draft-ietf-secevent-token-10 (work in Event Token (SET)", draft-ietf-secevent-token-13 (work in
progress), May 2018. progress), May 2018.
[Langkemper] [Langkemper]
Langkemper, S., "Attacking JWT Authentication", September Langkemper, S., "Attacking JWT Authentication", September
2016, <https://www.sjoerdlangkemper.nl/2016/09/28/ 2016, <https://www.sjoerdlangkemper.nl/2016/09/28/
attacking-jwt-authentication/>. attacking-jwt-authentication/>.
[nist-sp-800-56a-r3] [nist-sp-800-56a-r3]
Barker, E., Chen, L., Keller, S., Roginsky, A., Vassilev, Barker, E., Chen, L., Keller, S., Roginsky, A., Vassilev,
A., and R. Davis, "Recommendation for Pair-Wise Key A., and R. Davis, "Recommendation for Pair-Wise Key
Establishment Schemes Using Discrete Logarithm Establishment Schemes Using Discrete Logarithm
Cryptography, Draft NIST Special Publication 800-56A Cryptography, Draft NIST Special Publication 800-56A
Revision 3", August 2017, Revision 3", April 2018,
<https://csrc.nist.gov/CSRC/media/Publications/sp/800-56a/ <https://doi.org/10.6028/NIST.SP.800-56Ar3>.
rev-3/draft/documents/sp800-56ar3-draft.pdf>.
[OpenID.Core] [OpenID.Core]
Sakimura, N., Bradley, J., Jones, M., Medeiros, B., and C. Sakimura, N., Bradley, J., Jones, M., Medeiros, B., and C.
Mortimore, "OpenID Connect Core 1.0", November 2014, Mortimore, "OpenID Connect Core 1.0", November 2014,
<http://openid.net/specs/openid-connect-core-1_0.html>. <http://openid.net/specs/openid-connect-core-1_0.html>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012, RFC 6749, DOI 10.17487/RFC6749, October 2012,
<https://www.rfc-editor.org/info/rfc6749>. <https://www.rfc-editor.org/info/rfc6749>.
skipping to change at page 13, line 9 skipping to change at page 14, line 9
[Valenta] Valenta, L., Sullivan, N., Sanso, A., and N. Heninger, "In [Valenta] Valenta, L., Sullivan, N., Sanso, A., and N. Heninger, "In
search of CurveSwap: Measuring elliptic curve search of CurveSwap: Measuring elliptic curve
implementations in the wild", March 2018, implementations in the wild", March 2018,
<https://ia.cr/2018/298>. <https://ia.cr/2018/298>.
Appendix A. Document History Appendix A. Document History
[[ to be removed by the RFC editor before publication as an RFC ]] [[ to be removed by the RFC editor before publication as an RFC ]]
A.1. draft-ietf-oauth-jwt-bcp-03 A.1. draft-ietf-oauth-jwt-bcp-04
- AD review comments.
A.2. draft-ietf-oauth-jwt-bcp-03
- Acknowledgements. - Acknowledgements.
A.2. draft-ietf-oauth-jwt-bcp-02 A.3. draft-ietf-oauth-jwt-bcp-02
- Implemented WGLC feedback. - Implemented WGLC feedback.
A.3. draft-ietf-oauth-jwt-bcp-01 A.4. draft-ietf-oauth-jwt-bcp-01
- Feedback from Brian Campbell. - Feedback from Brian Campbell.
A.4. draft-ietf-oauth-jwt-bcp-00 A.5. draft-ietf-oauth-jwt-bcp-00
- Initial WG draft. No change from the latest individual version. - Initial WG draft. No change from the latest individual version.
A.5. draft-sheffer-oauth-jwt-bcp-01 A.6. draft-sheffer-oauth-jwt-bcp-01
- Added explicit typing. - Added explicit typing.
A.6. draft-sheffer-oauth-jwt-bcp-00 A.7. draft-sheffer-oauth-jwt-bcp-00
- Initial version. - Initial version.
Authors' Addresses Authors' Addresses
Yaron Sheffer Yaron Sheffer
Intuit Intuit
EMail: yaronf.ietf@gmail.com EMail: yaronf.ietf@gmail.com
 End of changes. 25 change blocks. 
42 lines changed or deleted 73 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/