< 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.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/