rfc8725xml2.original.xml		rfc8725.xml
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version='1.0' encoding='utf-8'?>
	<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>		<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
	<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.12 -->		<rfc number="8725" consensus="true" xmlns:xi="http://www.w3.org/2001/XInclude"
			ipr="trust200902"
	<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [		docName="draft-ietf-oauth-jwt-bcp-07" category="bcp" updates="7519"
	]>		obsoletes="" submissionType="IETF" xml:lang="en" tocInclude="true"
			sortRefs="true" symRefs="true" version="3">
	<?rfc rfcedstyle="yes"?>		<!-- xml2rfc v2v3 conversion 2.37.1 -->
	<?rfc toc="yes"?>
	<?rfc tocindent="yes"?>
	<?rfc sortrefs="yes"?>
	<?rfc symrefs="yes"?>
	<?rfc strict="yes"?>
	<?rfc comments="yes"?>
	<?rfc inline="yes"?>
	<?rfc text-list-symbols="-o*+"?>
	<rfc ipr="trust200902" docName="draft-ietf-oauth-jwt-bcp-07" category="bcp" upda
	tes="RFC 7519">
	<front>		<front>
	<title abbrev="JWT BCP">JSON Web Token Best Current Practices</title>		<title abbrev="JWT BCP">JSON Web Token Best Current Practices</title>
			<seriesInfo name="RFC" value="8725"/>
			<seriesInfo name="BCP" value="225"/>
	<author initials="Y." surname="Sheffer" fullname="Yaron Sheffer">		<author initials="Y." surname="Sheffer" fullname="Yaron Sheffer">
	<organization>Intuit</organization>		<organization>Intuit</organization>
	<address>		<address>
	<email>yaronf.ietf@gmail.com</email>		<email>yaronf.ietf@gmail.com</email>
	</address>		</address>
	</author>		</author>
	<author initials="D." surname="Hardt" fullname="Dick Hardt">		<author initials="D." surname="Hardt" fullname="Dick Hardt">
	<organization></organization>		<organization/>
	<address>		<address>
	<email>dick.hardt@gmail.com</email>		<email>dick.hardt@gmail.com</email>
	</address>		</address>
	</author>		</author>
	<author initials="M.B." surname="Jones" fullname="Michael B. Jones">		<author initials="M." surname="Jones" fullname="Michael B. Jones">
	<organization>Microsoft</organization>		<organization>Microsoft</organization>
	<address>		<address>
	<email>mbj@microsoft.com</email>		<email>mbj@microsoft.com</email>
	<uri>http://self-issued.info/</uri>		<uri>https://self-issued.info/</uri>
	</address>		</address>
	</author>		</author>
			<date month="February" year="2020" />
	<date year="2019" month="October" day="13"/>
	<area>Security</area>		<area>Security</area>
	<workgroup>OAuth Working Group</workgroup>		<workgroup>OAuth Working Group</workgroup>
	<keyword>Internet-Draft</keyword>
	<abstract>
	<t>JSON Web Tokens, also known as JWTs, are URL-safe JSON-based security tokens		<keyword>JSON Web Token</keyword>
	that contain a set of claims that can be signed and/or encrypted.		<keyword>JWT</keyword>
	JWTs are being widely used and deployed as a simple security token format		<keyword>JSON Object Signing and Encryption</keyword>
	in numerous protocols and applications, both in the area of digital identity,		<keyword>JOSE</keyword>
	and in other application areas.		<keyword>JSON Web Signature</keyword>
	The goal of this Best Current Practices document is to provide actionable guidan		<keyword>JWS</keyword>
	ce		<keyword>JSON Web Encryption</keyword>
	leading to secure implementation and deployment of JWTs.</t>		<keyword>JWE</keyword>
			<keyword>attacks</keyword>
			<keyword>Claims</keyword>
			<keyword>Security</keyword>
			<keyword>Cryptography</keyword>
			<abstract>
			<t>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 encrypted.
			JWTs are being widely used and deployed as a simple security token
			format in numerous protocols and applications, both in the area of
			digital identity and in other application areas. This Best Current
			Practices document updates RFC 7519 to provide actionable guidance
			leading to secure implementation and deployment of JWTs.</t>
	</abstract>		</abstract>
	</front>		</front>
	<middle>		<middle>
			<section anchor="introduction" numbered="true" toc="default">
	<section anchor="introduction" title="Introduction">		<name>Introduction</name>
			<t>JSON Web Tokens, also known as JWTs <xref target="RFC7519"
	<t>JSON Web Tokens, also known as JWTs <xref target="RFC7519"/>, are URL-safe JS		format="default"/>, are URL-safe JSON-based security tokens
	ON-based security tokens
	that contain a set of claims that can be signed and/or encrypted.		that contain a set of claims that can be signed and/or encrypted.
	The JWT specification has seen rapid adoption because it encapsulates		The JWT specification has seen rapid adoption because it encapsulates
	security-relevant information in one easy-to-protect location, and because		security-relevant information in one easy-to-protect location, and because
	it is easy to implement using widely-available tools.		it is easy to implement using widely available tools.
	One application area in which JWTs are commonly used is representing digital ide ntity information,		One application area in which JWTs are commonly used is representing digital ide ntity information,
	such as OpenID Connect ID Tokens <xref target="OpenID.Core"/>		such as OpenID Connect ID Tokens <xref target="OpenID.Core" format="default"/>
	and OAuth 2.0 <xref target="RFC6749"/> access tokens and refresh tokens, the det		and OAuth 2.0 <xref target="RFC6749" format="default"/> access tokens and
	ails of which are deployment-specific.</t>		refresh tokens, the details of which are deployment-specific.</t>
			<t>Since the JWT specification was published, there have been several wide
	<t>Since the JWT specification was published, there have been several widely pub		ly published
	lished
	attacks on implementations and deployments.		attacks on implementations and deployments.
	Such attacks are the result of under-specified security mechanisms, as well as i ncomplete		Such attacks are the result of under-specified security mechanisms, as well as i ncomplete
	implementations and incorrect usage by applications.</t>		implementations and incorrect usage by applications.</t>
			<t>The goal of this document is to facilitate secure implementation and de
	<t>The goal of this document is to facilitate secure implementation and deployme		ployment of JWTs.
	nt of JWTs.
	Many of the recommendations in this document are about		Many of the recommendations in this document are about
	implementation and use of the cryptographic mechanisms underlying JWTs that are defined by		implementation and use of the cryptographic mechanisms underlying JWTs that are defined by
	JSON Web Signature (JWS) <xref target="RFC7515"/>,		JSON Web Signature (JWS) <xref target="RFC7515" format="default"/>,
	JSON Web Encryption (JWE) <xref target="RFC7516"/>, and		JSON Web Encryption (JWE) <xref target="RFC7516" format="default"/>, and
	JSON Web Algorithms (JWA) <xref target="RFC7518"/>.		JSON Web Algorithms (JWA) <xref target="RFC7518" format="default"/>.
	Others are about use of the JWT claims themselves.</t>		Others are about use of the JWT claims themselves.</t>
			<t>These are intended to be minimum recommendations for the use of JWTs
	<t>These are intended to be minimum recommendations for the use of JWTs
	in the vast majority of implementation		in the vast majority of implementation
	and deployment scenarios. Other specifications that reference this document can have		and deployment scenarios. Other specifications that reference this document can have
	stricter requirements related to one or more aspects of the format, based on the ir		stricter requirements related to one or more aspects of the format, based on the ir
	particular circumstances; when that is the case, implementers are advised to adh ere		particular circumstances; when that is the case, implementers are advised to adh ere
	to those stricter requirements. Furthermore, this document provides a floor, no t a ceiling,		to those stricter requirements. Furthermore, this document provides a floor, not a ceiling,
	so stronger options are always allowed (e.g., depending on differing evaluations of the		so stronger options are always allowed (e.g., depending on differing evaluations of the
	importance of cryptographic strength vs. computational load).</t>		importance of cryptographic strength vs. computational load).</t>
			<t>Community knowledge about the strength of various algorithms and feasib
	<t>Community knowledge about the strength of various algorithms and feasible att		le attacks can
	acks can
	change quickly, and experience shows that a Best Current Practice (BCP) document about		change quickly, and experience shows that a Best Current Practice (BCP) document about
	security is a point-in-time statement. Readers are advised to seek out any errat a or		security is a point-in-time statement. Readers are advised to seek out any errat a or
	updates that apply to this document.</t>		updates that apply to this document.</t>
			<section anchor="target-audience" numbered="true" toc="default">
	<section anchor="target-audience" title="Target Audience">		<name>Target Audience</name>
			<t>The intended audiences of this document are:</t>
	<t>The intended audience of this document is:</t>		<ul spacing="normal">
			<li>Implementers of JWT libraries (and the JWS and JWE libraries
	<t><list style="symbols">		used by those libraries),</li>
	<t>Implementers of JWT libraries (and the JWS and JWE libraries used by those		<li>Implementers of code that uses such libraries (to the extent that
	libraries),</t>		some mechanisms may
	<t>Implementers of code that uses such libraries (to the extent that some mech		not be provided by libraries, or until they are), and</li>
	anisms may		<li>Developers of specifications that rely on JWTs, both inside and
	not be provided by libraries, or until they are), and</t>		outside the IETF.</li>
	<t>Developers of specifications that rely on JWTs, both inside and outside the		</ul>
	IETF.</t>		</section>
	</list></t>		<section anchor="conventions-used-in-this-document" numbered="true" toc="d
			efault">
	</section>		<name>Conventions Used in this Document</name>
	<section anchor="conventions-used-in-this-document" title="Conventions used in t		<t>
	his document">		The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
			"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
	<t>The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL		NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
	NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”,		"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
	“MAY”, and “OPTIONAL” in this document are to be interpreted as		"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
	described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and		to be interpreted as
	only when, they		described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
	appear in all capitals, as shown here.</t>		when, and only when, they appear in all capitals, as shown here.
			</t>
	</section>		</section>
	</section>		</section>
	<section anchor="threats-and-vulnerabilities" title="Threats and Vulnerabilities		<section anchor="threats-and-vulnerabilities" numbered="true" toc="default">
	">		<name>Threats and Vulnerabilities</name>
			<t>This section lists some known and possible problems with JWT
	<t>This section lists some known and possible problems with JWT implementations		implementations and deployments.
	and deployments.
	Each problem description is followed by references to one or more mitigations to those problems.</t>		Each problem description is followed by references to one or more mitigations to those problems.</t>
			<section anchor="weak-signatures-and-insufficient-signature-validation"
	<section anchor="weak-signatures-and-insufficient-signature-validation" title="W		numbered="true" toc="default">
	eak Signatures and Insufficient Signature Validation">		<name>Weak Signatures and Insufficient Signature Validation</name>
			<t>Signed JSON Web Tokens carry an explicit indication of the signing al
	<t>Signed JSON Web Tokens carry an explicit indication of the signing algorithm,		gorithm,
	in the form of the “alg” header parameter, to facilitate cryptographic agility.		in the form of the "alg" Header Parameter, to facilitate cryptographic agility.
	This, in conjunction with design flaws in some libraries and applications, have		This, in conjunction with design flaws in some libraries and applications,
	led to several attacks:</t>		has led to several attacks:</t>
			<ul spacing="normal">
	<t><list style="symbols">		<li>The algorithm can be changed to "none" by an attacker, and some li
	<t>The algorithm can be changed to “none” by an attacker, and some libraries w		braries would trust
	ould trust		this value and "validate" the JWT without checking any signature.</li>
	this value and “validate” the JWT without checking any signature.</t>		<li>An "RS256" (RSA, 2048 bit) parameter value can be changed into
	<t>An “RS256” (RSA, 2048 bit) parameter value can be changed into		"HS256" (HMAC, SHA-256), and some libraries
	“HS256” (HMAC, SHA-256), and some libraries
	would try to validate the signature using HMAC-SHA256 and using the RSA public k ey as the		would try to validate the signature using HMAC-SHA256 and using the RSA public k ey as the
	HMAC shared secret (see <xref target="McLean"/> and CVE-2015-9235).</t>		HMAC shared secret (see <xref target="McLean" format="default"/> and
	</list></t>		<xref target="CVE-2015-9235"/>).</li>
			</ul>
	<t>For mitigations, see <xref target="algorithm-verification" /> and <xref targe		<t>For mitigations, see Sections <xref target="algorithm-verification"
	t="appropriate-algorithms" />.</t>		format="counter"/> and <xref target="appropriate-algorithms"
			format="counter"/>.</t>
	</section>		</section>
	<section anchor="weak-symmetric-keys" title="Weak Symmetric Keys">		<section anchor="weak-symmetric-keys" numbered="true" toc="default">
			<name>Weak Symmetric Keys</name>
	<t>In addition, some applications use a keyed MAC algorithm such as		<t>In addition, some applications use a keyed Message Authentication
	“HS256” to sign tokens, but supply a weak symmetric key with		Code (MAC) algorithm, such as
	insufficient entropy (such as a human memorable password). Such keys		"HS256", to sign tokens but supply a weak symmetric key with
			insufficient entropy (such as a human-memorable password). Such keys
	are vulnerable to offline brute-force or dictionary attacks once an		are vulnerable to offline brute-force or dictionary attacks once an
	attacker gets hold of such a token <xref target="Langkemper"></xref>.</t>		attacker gets hold of such a token <xref target="Langkemper" format="default"/>.
			</t>
	<t>For mitigations, see <xref target="key-entropy" />.</t>		<t>For mitigations, see <xref target="key-entropy" format="default"/>.</
			t>
	</section>		</section>
	<section anchor="incorrect-composition-of-encryption-and-signature" title="Incor		<section anchor="incorrect-composition-of-encryption-and-signature"
	rect Composition of Encryption and Signature">		numbered="true" toc="default">
			<name>Incorrect Composition of Encryption and Signature</name>
	<t>Some libraries that decrypt a JWE-encrypted JWT to obtain a JWS-signed object		<t>Some libraries that decrypt a JWE-encrypted JWT to obtain a JWS-signe
			d object
	do not always validate the internal signature.</t>		do not always validate the internal signature.</t>
			<t>For mitigations, see <xref target="validate-crypto" format="default"/
	<t>For mitigations, see <xref target="validate-crypto" />.</t>		>.</t>
			</section>
	</section>		<section
	<section anchor="plaintext-leakage-through-analysis-of-ciphertext-length" title=		anchor="plaintext-leakage-through-analysis-of-ciphertext-length"
	"Plaintext Leakage through Analysis of Ciphertext Length">		numbered="true" toc="default">
			<name>Plaintext Leakage through Analysis of Ciphertext Length</name>
	<t>Many encryption algorithms leak information about the length of the plaintext		<t>Many encryption algorithms leak information about the length of the
	, with a varying amount of		plaintext, with a varying amount of
	leakage depending on the algorithm and mode of operation. This problem is exacer bated		leakage depending on the algorithm and mode of operation. This problem is exacer bated
	when the plaintext is initially compressed, because the length of the compressed		when the plaintext is initially compressed, because the length of the
	plaintext and, thus,		compressed plaintext and, thus,
	the ciphertext		the ciphertext
	depend not only on the length of the original plaintext but also		depends not only on the length of the original plaintext but also
	on its content.		on its content.
	Compression attacks are particularly		Compression attacks are particularly
	powerful when there is attacker-controlled data in the same compression		powerful when there is attacker-controlled data in the same compression
	space as secret data, as is the case for some attacks on HTTPS.</t>		space as secret data, which is the case for some attacks on HTTPS.</t>
			<t>See <xref target="Kelsey" format="default"/> for general background
	<t>See <xref target="Kelsey"/> for general background		on compression and encryption and <xref target="Alawatugoda"
	on compression and encryption, and <xref target="Alawatugoda"/> for a specific e		format="default"/> for a specific example of attacks on HTTP cookies.</t>
	xample of attacks on HTTP cookies.</t>		<t>For mitigations, see <xref target="no-compression" format="default"/>
			.</t>
	<t>For mitigations, see <xref target="no-compression"/>.</t>		</section>
			<section anchor="insecure-use-of-elliptic-curve-encryption" numbered="true
	</section>		" toc="default">
	<section anchor="insecure-use-of-elliptic-curve-encryption" title="Insecure Use		<name>Insecure Use of Elliptic Curve Encryption</name>
	of Elliptic Curve Encryption">		<t>Per <xref target="Sanso" format="default"/>, several Javascript
			Object Signing and Encryption (JOSE) libraries
	<t>Per <xref target="Sanso"></xref>, several JOSE libraries fail to validate the		fail to validate their inputs correctly
	ir inputs correctly		when performing elliptic curve key agreement (the "ECDH-ES" algorithm).
	when performing elliptic curve key agreement (the “ECDH-ES” algorithm).
	An attacker that is able to send JWEs of its choosing that use invalid curve poi nts and		An attacker that is able to send JWEs of its choosing that use invalid curve poi nts and
	observe the cleartext outputs resulting from decryption with the invalid curve p oints		observe the cleartext outputs resulting from decryption with the invalid curve p oints
	can use this vulnerability to recover the recipient’s private key.</t>		can use this vulnerability to recover the recipient's private key.</t>
			<t>For mitigations, see <xref target="validate-inputs" format="default"/
	<t>For mitigations, see <xref target="validate-inputs" />.</t>		>.</t>
			</section>
	</section>		<section anchor="multiplicity-of-json-encodings" numbered="true" toc="defa
	<section anchor="multiplicity-of-json-encodings" title="Multiplicity of JSON Enc		ult">
	odings">		<name>Multiplicity of JSON Encodings</name>
			<t>Previous versions of the JSON format, such as the obsoleted <xref
	<t>Previous versions of the JSON format such as the obsoleted <xref target="RFC7		target="RFC7159" format="default"/>,
	159"/>
	allowed several different character		allowed several different character
	encodings: UTF-8, UTF-16 and UTF-32. This is not the case anymore, with the late		encodings: UTF-8, UTF-16, and UTF-32. This is not the case anymore, with the lat
	st		est
	standard <xref target="RFC8259"/> only allowing UTF-8 except for internal use wi		standard <xref target="RFC8259" format="default"/> only allowing UTF-8 except
	thin a “closed ecosystem”.		for internal use within a "closed ecosystem".
	This ambiguity where older implementations and those used within closed environm		This ambiguity, where older implementations and those used within closed environ
	ents may generate		ments may generate
	non-standard encodings, may result in the JWT being		non-standard encodings, may result in the JWT being
	misinterpreted by its recipient. This in turn could be used by a malicious sende		misinterpreted by its recipient. This, in turn, could be used by a malicious sen
	r to bypass		der to bypass
	the recipient’s validation checks.</t>		the recipient's validation checks.</t>
			<t>For mitigations, see <xref target="use-utf8" format="default"/>.</t>
	<t>For mitigations, see <xref target="use-utf8" />.</t>		</section>
			<section anchor="substitution" numbered="true" toc="default">
	</section>		<name>Substitution Attacks</name>
	<section anchor="substitution" title="Substitution Attacks">		<t>There are attacks in which one recipient will be given a JWT that was
			intended for it
	<t>There are attacks in which one recipient will be given a JWT that was intende
	d for it,
	and will attempt to use it at a different recipient for which that JWT was not i ntended.		and will attempt to use it at a different recipient for which that JWT was not i ntended.
	For instance, if an OAuth 2.0 <xref target="RFC6749"/> access token is legitimat		For instance, if an OAuth 2.0 <xref target="RFC6749" format="default"/> access
	ely presented to an		token is legitimately presented to an
	OAuth 2.0 protected resource for which it is intended, that protected resource m ight then present		OAuth 2.0 protected resource for which it is intended, that protected resource m ight then present
	that same access token to a different protected resource for which the access to ken is not intended,		that same access token to a different protected resource for which the access to ken is not intended,
	in an attempt to gain access. If such situations are not caught, this can resul t in		in an attempt to gain access. If such situations are not caught, this can result in
	the attacker gaining access to resources that it is not entitled to access.</t>		the attacker gaining access to resources that it is not entitled to access.</t>
			<t>For mitigations, see Sections <xref target="validate-iss-sub"
	<t>For mitigations, see <xref target="validate-iss-sub" /> and <xref target="use		format="counter"/> and <xref target="use-aud" format="counter"/>.</t>
	-aud" />.</t>		</section>
			<section anchor="cross-jwt-confusion" numbered="true" toc="default">
	</section>		<name>Cross-JWT Confusion</name>
	<section anchor="cross-jwt-confusion" title="Cross-JWT Confusion">		<t>As JWTs are being used by more different protocols in diverse
			application areas, it becomes increasingly
	<t>As JWTs are being used by more different protocols in diverse application are
	as, it becomes increasingly
	important to prevent cases of JWT tokens that have been issued for one purpose		important to prevent cases of JWT tokens that have been issued for one purpose
	being subverted and used for another.		being subverted and used for another.
	Note that this is a specific type of substitution attack.		Note that this is a specific type of substitution attack.
	If the JWT could be used in an application context in which it could be confused		If the JWT could be used in an application context in which it could be
	with other kinds of JWTs,		confused with other kinds of JWTs,
	then mitigations MUST be employed to prevent these substitution attacks.</t>		then mitigations <bcp14>MUST</bcp14> be employed to prevent these substitution a
			ttacks.</t>
	<t>For mitigations, see <xref target="validate-iss-sub" />, <xref target="use-au		<t>For mitigations, see Sections <xref target="validate-iss-sub"
	d" />,		format="counter"/>, <xref target="use-aud" format="counter"/>,
	<xref target="use-typ" />, and <xref target="preventing-confusion" />.</t>		<xref target="use-typ" format="counter"/>, and <xref
			target="preventing-confusion" format="counter"/>.</t>
	</section>		</section>
	<section anchor="indirect-attacks-on-the-server" title="Indirect Attacks on the		<section anchor="indirect-attacks-on-the-server" numbered="true" toc="defa
	Server">		ult">
			<name>Indirect Attacks on the Server</name>
	<t>Various JWT claims are used by the recipient to perform lookup operations,		<t>Various JWT claims are used by the recipient to perform lookup operat
	such as database and LDAP searches.		ions,
			such as database and Lightweight Directory Access Protocol (LDAP) searches.
	Others include URLs that are similarly looked up by the server. Any of these cla ims can be used by		Others include URLs that are similarly looked up by the server. Any of these cla ims can be used by
	an attacker as vectors for injection attacks or server-side request forgery (SSR F) attacks.</t>		an attacker as vectors for injection attacks or server-side request forgery (SSR F) attacks.</t>
			<t>For mitigations, see <xref target="do-not-trust-claims" format="defau
	<t>For mitigations, see <xref target="do-not-trust-claims"/>.</t>		lt"/>.</t>
			</section>
	</section>		</section>
	</section>		<section anchor="BP" numbered="true" toc="default">
	<section anchor="BP" title="Best Practices">		<name>Best Practices</name>
			<t>The best practices listed below should be applied by practitioners
	<t>The best practices listed below should be applied by practitioners
	to mitigate the threats listed in the preceding section.</t>		to mitigate the threats listed in the preceding section.</t>
			<section anchor="algorithm-verification" numbered="true" toc="default">
	<section anchor="algorithm-verification" title="Perform Algorithm Verification">		<name>Perform Algorithm Verification</name>
			<t>Libraries <bcp14>MUST</bcp14> enable the caller to specify a
	<t>Libraries MUST enable the caller to specify a supported set of algorithms and		supported set of algorithms and
	MUST NOT use any other algorithms when performing cryptographic operations.		<bcp14>MUST NOT</bcp14> use any other algorithms when performing cryptographic o
	The library MUST ensure that the “alg” or “enc” header specifies the same algori		perations.
	thm		The library <bcp14>MUST</bcp14> ensure that the "alg" or "enc" header specifies
			the same algorithm
	that is used for the cryptographic operation.		that is used for the cryptographic operation.
	Moreover, each key MUST be used with exactly one algorithm,		Moreover, each key <bcp14>MUST</bcp14> be used with exactly one algorithm,
	and this MUST be checked when the cryptographic operation is performed.</t>		and this <bcp14>MUST</bcp14> be checked when the cryptographic operation is perf
			ormed.</t>
	</section>		</section>
	<section anchor="appropriate-algorithms" title="Use Appropriate Algorithms">		<section anchor="appropriate-algorithms" numbered="true" toc="default">
			<name>Use Appropriate Algorithms</name>
	<t>As Section 5.2 of <xref target="RFC7515"/> says, “it is an application decisi		<t>As <xref target="RFC7515" sectionFormat="of" section="5.2"/> says,
	on which algorithms may		"it is an application decision which algorithms may
	be used in a given context. Even if a JWS can be successfully		be used in a given context. Even if a JWS can be successfully
	validated, unless the algorithm(s) used in the JWS are acceptable to		validated, unless the algorithm(s) used in the JWS are acceptable to
	the application, it SHOULD consider the JWS to be invalid.”</t>		the application, it <bcp14>SHOULD</bcp14> consider the JWS to be invalid."</t>
			<t>Therefore, applications <bcp14>MUST</bcp14> only allow the use of
	<t>Therefore, applications MUST only allow the use of cryptographically current		cryptographically current algorithms
	algorithms
	that meet the security requirements of the application.		that meet the security requirements of the application.
	This set will vary over time as new algorithms are introduced		This set will vary over time as new algorithms are introduced
	and existing algorithms are deprecated due to discovered cryptographic weaknesse s.		and existing algorithms are deprecated due to discovered cryptographic weaknesse s.
	Applications MUST therefore be designed to enable cryptographic agility.</t>		Applications <bcp14>MUST</bcp14> therefore be designed to enable cryptographic a
			gility.</t>
	<t>That said, if a JWT is cryptographically protected end-to-end by a transport		<t>That said, if a JWT is cryptographically protected end-to-end by a
	layer, such as TLS		transport layer, such as TLS
	using cryptographically current algorithms, there may be no need to apply anothe r layer of		using cryptographically current algorithms, there may be no need to apply anothe r layer of
	cryptographic protections to the JWT.		cryptographic protections to the JWT.
	In such cases, the use of the “none” algorithm can be perfectly acceptable.		In such cases, the use of the "none" algorithm can be perfectly acceptable.
	The “none” algorithm should only be used when the JWT is cryptographically prote		The "none" algorithm should only be used when the JWT is cryptographically prote
	cted by other means.		cted by other means.
	JWTs using “none” are often used in application contexts in which the content is		JWTs using "none" are often used in application contexts in which the content is
	optionally signed;		optionally signed;
	then the URL-safe claims representation and processing can be the same in both t		then, the URL-safe claims representation and processing can be the same in both
	he signed and unsigned cases.		the signed and unsigned cases.
	JWT libraries SHOULD NOT generate JWTs using “none” unless explicitly requested		JWT libraries <bcp14>SHOULD NOT</bcp14> generate JWTs using "none" unless
	to do by the caller.		explicitly requested to do so by the caller.
	Similarly, JWT libraries SHOULD NOT consume JWTs using “none” unless explicitly		Similarly, JWT libraries <bcp14>SHOULD NOT</bcp14> consume JWTs using "none"
	requested by the caller.</t>		unless explicitly requested by the caller.</t>
			<t>Applications <bcp14>SHOULD</bcp14> follow these algorithm-specific re
	<t>Applications SHOULD follow these algorithm-specific recommendations:</t>		commendations:</t>
			<ul spacing="normal">
			<li>Avoid all RSA-PKCS1 v1.5 encryption algorithms (<xref
			target="RFC8017" sectionFormat="comma" section="7.2"/>), preferring
			RSAES-OAEP
			(<xref target="RFC8017" sectionFormat="comma" section="7.1"/>).</li>
	<t><list style="symbols">		<li>Elliptic Curve Digital Signature Algorithm (ECDSA) signatures <xre
	<t>Avoid all RSA-PKCS1 v1.5 encryption algorithms (<xref target="RFC8017"/>, S		f target="ANSI-X962-2005"
	ec. 7.2}, preferring RSA-OAEP (<xref target="RFC8017"/>, Sec. 7.1).</t>		format="default"/> require a unique random value for every message
	<t>ECDSA signatures <xref target="ANSI-X962-2005"/> require a unique random va		that is signed.
	lue for every message that is signed.		If even just a few bits of the random value are predictable across multiple mess
	If even just a few bits of the random value are predictable across multiple mess		ages, then
	ages then
	the security of the signature scheme may be compromised. In the worst case,		the security of the signature scheme may be compromised. In the worst case,
	the private key may be recoverable by an attacker. To counter these attacks,		the private key may be recoverable by an attacker. To counter these attacks,
	JWT libraries SHOULD implement ECDSA using the deterministic approach defined in		JWT libraries <bcp14>SHOULD</bcp14> implement ECDSA using the deterministic
	<xref target="RFC6979"/>.		approach defined in <xref target="RFC6979" format="default"/>.
	This approach is completely compatible with existing ECDSA verifiers and so can be implemented		This approach is completely compatible with existing ECDSA verifiers and so can be implemented
	without new algorithm identifiers being required.</t>		without new algorithm identifiers being required.</li>
	</list></t>
	</section>
	<section anchor="validate-crypto" title="Validate All Cryptographic Operations">
	<t>All cryptographic operations used in the JWT MUST be validated and the entire		</ul>
	JWT MUST be rejected		</section>
			<section anchor="validate-crypto" numbered="true" toc="default">
			<name>Validate All Cryptographic Operations</name>
			<t>All cryptographic operations used in the JWT <bcp14>MUST</bcp14> be
			validated and the entire JWT <bcp14>MUST</bcp14> be rejected
	if any of them fail to validate.		if any of them fail to validate.
	This is true not only of JWTs with a single set of Header Parameters		This is true not only of JWTs with a single set of Header Parameters
	but also for Nested JWTs, in which both outer and inner operations MUST be valid ated		but also for Nested JWTs in which both outer and inner operations <bcp14>MUST</b cp14> be validated
	using the keys and algorithms supplied by the application.</t>		using the keys and algorithms supplied by the application.</t>
	<!-- See draft-ietf-oauth-jwsreq-13, sec. 6.1 and 6.2. -->		</section>
			<section anchor="validate-inputs" numbered="true" toc="default">
	</section>		<name>Validate Cryptographic Inputs</name>
	<section anchor="validate-inputs" title="Validate Cryptographic Inputs">		<t>Some cryptographic operations, such as Elliptic Curve Diffie-Hellman
			key agreement
	<t>Some cryptographic operations, such as Elliptic Curve Diffie-Hellman key agre		("ECDH-ES"), take inputs that may contain invalid values. This includes points n
	ement		ot on
	(“ECDH-ES”) take inputs that may contain invalid values, such as points not on t		the specified elliptic curve
	he specified elliptic curve		or other invalid points (e.g., <xref target="Valenta" format="default"/>, Sectio
	or other invalid points (see, e.g. <xref target="Valenta"/>, Sec. 7.1).		n 7.1).
	The JWS/JWE library itself must validate these inputs before using them		The JWS/JWE library itself must validate these inputs before using them,
	or it must use underlying cryptographic libraries that do so (or both!).</t>		or it must use underlying cryptographic libraries that do so (or both!).</t>
			<t>Elliptic Curve Diffie-Hellman Ephemeral Static (ECDH-ES) ephemeral
	<t>ECDH-ES ephemeral public key (epk) inputs should be validated according to th		public key (epk) inputs should be validated
	e recipient’s		according to the recipient's
	chosen elliptic curve. For the NIST prime-order curves P-256, P-384 and P-521, v		chosen elliptic curve. For the NIST prime-order curves P-256, P-384, and P-521,
	alidation MUST		validation <bcp14>MUST</bcp14>
	be performed according to Section 5.6.2.3.4 “ECC Partial Public-Key Validation R		be performed according to Section 5.6.2.3.4 (ECC Partial Public-Key Validation
	outine” of		Routine) of "Recommendation for Pair-Wise Key-Establishment Schemes Using Discre
	NIST Special Publication 800-56A revision 3 <xref target="nist-sp-800-56a-r3"></		te Logarithm Cryptography" <xref target="nist-sp-800-56a-r3" format="default"/>.
	xref>.		If the "X25519" or "X448" <xref target="RFC8037" format="default"/> algorithms a
	Likewise, if the “X25519” or “X448” <xref target="RFC8037"/> algorithms are used		re used,
	,		then the security considerations in <xref target="RFC8037" format="default"/> ap
	then the security considerations in <xref target="RFC8037"/> apply.</t>		ply.</t>
			</section>
	</section>		<section anchor="key-entropy" numbered="true" toc="default">
	<section anchor="key-entropy" title="Ensure Cryptographic Keys have Sufficient E		<name>Ensure Cryptographic Keys Have Sufficient Entropy</name>
	ntropy">		<t>The Key Entropy and Random Values advice in <xref
			target="RFC7515" section="10.1" sectionFormat="of"></xref> and the
	<t>The Key Entropy and Random Values advice in Section 10.1 of <xref target="RFC		Password Considerations in <xref target="RFC7518"
	7515"/> and		section="8.8" sectionFormat="of"></xref>
	the Password Considerations in Section 8.8 of <xref target="RFC7518"/>		<bcp14>MUST</bcp14> be followed.
	MUST be followed.		In particular, human-memorizable passwords <bcp14>MUST NOT</bcp14> be directly u
	In particular, human-memorizable passwords MUST NOT be directly used		sed
	as the key to a keyed-MAC algorithm such as “HS256”.		as the key to a keyed-MAC algorithm such as "HS256".
	In particular, passwords should only be used to perform key encryption, rather t		Moreover, passwords should only be used to perform key encryption, rather
	han content encryption,		than content encryption,
	as described in Section 4.8 of <xref target="RFC7518"/>.		as described in <xref target="RFC7518" sectionFormat="of" section="4.8"/>.
	Note that even when used for key encryption, password-based encryption is still		Note that even when used for key encryption, password-based encryption is
	subject to brute-force attacks.</t>		still subject to brute-force attacks.</t>
			</section>
	</section>		<section anchor="no-compression" numbered="true" toc="default">
	<section anchor="no-compression" title="Avoid Length-Dependent Encryption Inputs		<name>Avoid Compression of Encryption Inputs</name>
	">		<t>Compression of data <bcp14>SHOULD NOT</bcp14> be done before encrypti
			on, because
	<t>Compression of data SHOULD NOT be done before encryption, because
	such compressed data often reveals information about the plaintext.</t>		such compressed data often reveals information about the plaintext.</t>
			</section>
	</section>		<section anchor="use-utf8" numbered="true" toc="default">
	<section anchor="use-utf8" title="Use UTF-8">		<name>Use UTF-8</name>
			<t><xref target="RFC7515" format="default"/>, <xref target="RFC7516"
	<t><xref target="RFC7515"/>, <xref target="RFC7516"/>, and <xref target="RFC7519		format="default"/>, and <xref target="RFC7519" format="default"/> all
	"/> all specify that UTF-8 be used for encoding and decoding JSON		specify that UTF-8 be used for encoding and decoding JSON
	used in Header Parameters and JWT Claims Sets. This is also in line with the lat		used in Header Parameters and JWT Claims Sets. This is also in line with the
	est JSON specification <xref target="RFC8259"/>.		latest JSON specification <xref target="RFC8259" format="default"/>.
	Implementations and applications MUST do this, and not use or admit the use of		Implementations and applications <bcp14>MUST</bcp14> do this and not use or admi
			t the use of
	other Unicode encodings for these purposes.</t>		other Unicode encodings for these purposes.</t>
			</section>
	</section>		<section anchor="validate-iss-sub" numbered="true" toc="default">
	<section anchor="validate-iss-sub" title="Validate Issuer and Subject">		<name>Validate Issuer and Subject</name>
			<t>When a JWT contains an "iss" (issuer) claim, the application
	<t>When a JWT contains an “iss” (issuer) claim, the application MUST validate th		<bcp14>MUST</bcp14> validate that the cryptographic keys
	at the cryptographic keys
	used for the cryptographic operations in the JWT belong to the issuer.		used for the cryptographic operations in the JWT belong to the issuer.
	If they do not, the application MUST reject the JWT.</t>		If they do not, the application <bcp14>MUST</bcp14> reject the JWT.</t>
			<t>The means of determining the keys owned by an issuer is application-s
	<t>The means of determining the keys owned by an issuer is application-specific.		pecific.
	As one example, OpenID Connect <xref target="OpenID.Core"/> issuer values are “h		As one example, OpenID Connect <xref target="OpenID.Core" format="default"/>
	ttps” URLs		issuer values are "https" URLs
	that reference a JSON metadata document that contains a “jwks_uri” value that is		that reference a JSON metadata document that contains a "jwks_uri" value that is
	an “https” URL from which the issuer’s keys are retrieved as a JWK Set <xref tar		an "https" URL from which the issuer's keys are retrieved as a JWK Set <xref
	get="RFC7517"/>.		target="RFC7517" format="default"/>.
	This same mechanism is used by <xref target="RFC8414"/>.		This same mechanism is used by <xref target="RFC8414" format="default"/>.
	Other applications may use different means of binding keys to issuers.</t>		Other applications may use different means of binding keys to issuers.</t>
	<t>Similarly, when the JWT contains a “sub” (subject) claim, the application MUS		<t>Similarly, when the JWT contains a "sub" (subject) claim, the
	T validate that		application <bcp14>MUST</bcp14> validate that
	the subject value corresponds to a valid subject and/or issuer/subject pair at t		the subject value corresponds to a valid subject and/or issuer-subject pair at t
	he application.		he application.
	This may include confirming that the issuer is trusted by the application.		This may include confirming that the issuer is trusted by the application.
	If the issuer, subject, or the pair are invalid, the application MUST reject the		If the issuer, subject, or the pair are invalid, the application
	JWT.</t>		<bcp14>MUST</bcp14> reject the JWT.</t>
			</section>
	</section>		<section anchor="use-aud" numbered="true" toc="default">
	<section anchor="use-aud" title="Use and Validate Audience">		<name>Use and Validate Audience</name>
			<t>If the same issuer can issue JWTs that are intended for use by more
	<t>If the same issuer can issue JWTs that are intended for use by more than one		than one relying party or application,
	relying party or application,		the JWT <bcp14>MUST</bcp14> contain an "aud" (audience) claim that can be used
	the JWT MUST contain an “aud” (audience) claim that can be used to determine whe		to determine whether the JWT
	ther the JWT
	is being used by an intended party or was substituted by an attacker at an unint ended party.</t>		is being used by an intended party or was substituted by an attacker at an unint ended party.</t>
			<t>In such cases, the relying party or application <bcp14>MUST</bcp14>
	<t>In such cases, the relying party or application MUST validate the audience va		validate the audience value,
	lue
	and if the audience value is not present or not associated with the recipient,		and if the audience value is not present or not associated with the recipient,
	it MUST reject the JWT.</t>		it <bcp14>MUST</bcp14> reject the JWT.</t>
			</section>
	</section>		<section anchor="do-not-trust-claims" numbered="true" toc="default">
	<section anchor="do-not-trust-claims" title="Do Not Trust Received Claims">		<name>Do Not Trust Received Claims</name>
			<t>The "kid" (key ID) header is used by the relying application to
	<t>The “kid” (key ID) header is used by the relying application to perform key l		perform key lookup. Applications
	ookup. Applications		should ensure that this does not create SQL or LDAP injection vulnerabilities by
	should ensure that this does not create SQL or LDAP injection vulnerabilities, b		validating
	y validating
	and/or sanitizing the received value.</t>		and/or sanitizing the received value.</t>
			<t>Similarly, blindly following a "jku" (JWK set URL) or "x5u" (X.509 UR
	<t>Similarly, blindly following a “jku” (JWK set URL) or “x5u” (X.509 URL) heade		L) header,
	r,
	which may contain an arbitrary URL,		which may contain an arbitrary URL,
	could result in server-side request forgery (SSRF) attacks. Applications SHOULD		could result in server-side request forgery (SSRF) attacks. Applications
	protect against such		<bcp14>SHOULD</bcp14> protect against such
	attacks, e.g., by matching the URL to a whitelist of allowed locations,		attacks, e.g., by matching the URL to a whitelist of allowed locations
	and ensuring no cookies are sent in the GET request.</t>		and ensuring no cookies are sent in the GET request.</t>
			</section>
	</section>		<section anchor="use-typ" numbered="true" toc="default">
	<section anchor="use-typ" title="Use Explicit Typing">		<name>Use Explicit Typing</name>
			<t>Sometimes, one kind of JWT can be confused for another. If a particul
	<t>Sometimes, one kind of JWT can be confused for another. If a particular		ar
	kind of JWT is subject to such confusion, that JWT can include an explicit		kind of JWT is subject to such confusion, that JWT can include an explicit
	JWT type value, and the validation rules can specify checking the type.		JWT type value, and the validation rules can specify checking the type.
	This mechanism can prevent such confusion.		This mechanism can prevent such confusion.
	Explicit JWT typing is accomplished by using the “typ” header parameter.		Explicit JWT typing is accomplished by using the "typ" Header Parameter.
	For instance, the <xref target="RFC8417"/> specification uses the “application/s		For instance, the <xref target="RFC8417" format="default"/> specification uses
	ecevent+jwt” media type		the "application/secevent+jwt" media type
	to perform explicit typing of Security Event Tokens (SETs).</t>		to perform explicit typing of Security Event Tokens (SETs).</t>
			<t>Per the definition of "typ" in <xref
	<t>Per the definition of “typ” in Section 4.1.9 of <xref target="RFC7515"/>,		target="RFC7515" sectionFormat="of" section="4.1.9"/>,
	it is RECOMMENDED that the “application/” prefix be omitted from the “typ” value		it is <bcp14>RECOMMENDED</bcp14> that the "application/" prefix be omitted from
	.		the "typ" value.
	Therefore, for example, the “typ” value used to explicitly include a type for a		Therefore, for example, the "typ" value used to explicitly include a type for a
	SET		SET
	SHOULD be “secevent+jwt”.		<bcp14>SHOULD</bcp14> be "secevent+jwt".
	When explicit typing is employed for a JWT, it is RECOMMENDED that a media type		When explicit typing is employed for a JWT, it is <bcp14>RECOMMENDED</bcp14>
	name of the format		that a media type name of the format
	“application/example+jwt” be used, where “example” is replaced by the identifier		"application/example+jwt" be used, where "example" is replaced by the
	for the specific kind of JWT.</t>		identifier for the specific kind of JWT.</t>
			<t>When applying explicit typing to a Nested JWT, the "typ" Header
	<t>When applying explicit typing to a Nested JWT, the “typ” header parameter con		Parameter containing the explicit type value
	taining the explicit type value		<bcp14>MUST</bcp14> be present in the inner JWT of the Nested JWT (the JWT
	MUST be present in the inner JWT of the Nested JWT (the JWT whose payload is the		whose payload is the JWT Claims Set).
	JWT Claims Set).		In some cases, the same "typ" Header Parameter value will be present in the oute
	In some cases the same “typ” header parameter value will be present in the outer		r JWT as well,
	JWT as well,
	to explicitly type the entire Nested JWT.</t>		to explicitly type the entire Nested JWT.</t>
			<t>Note that the use of explicit typing may not achieve disambiguation
	<t>Note that the use of explicit typing may not achieve disambiguation from exis		from existing kinds of JWTs,
	ting kinds of JWTs,		as the validation rules for existing kinds of JWTs often do not use the "typ" He
	as the validation rules for existing kinds JWTs often do not use the “typ” heade		ader Parameter value.
	r parameter value.		Explicit typing is <bcp14>RECOMMENDED</bcp14> for new uses of JWTs.</t>
	Explicit typing is RECOMMENDED for new uses of JWTs.</t>		</section>
			<section anchor="preventing-confusion" numbered="true" toc="default">
	</section>		<name>Use Mutually Exclusive Validation Rules for Different Kinds of JWT
	<section anchor="preventing-confusion" title="Use Mutually Exclusive Validation		s</name>
	Rules for Different Kinds of JWTs">		<t>Each application of JWTs defines a profile specifying the required
			and optional JWT claims
	<t>Each application of JWTs defines a profile specifying the required and option
	al JWT claims
	and the validation rules associated with them.		and the validation rules associated with them.
	If more than one kind of JWT can be issued by the same issuer,		If more than one kind of JWT can be issued by the same issuer,
	the validation rules for those JWTs MUST be written such that they are mutually		the validation rules for those JWTs <bcp14>MUST</bcp14> be written such that
	exclusive,		they are mutually exclusive,
	rejecting JWTs of the wrong kind.		rejecting JWTs of the wrong kind.
	To prevent substitution of JWTs from one context into another,		To prevent substitution of JWTs from one context into another,
	application developers may employ a number of strategies:</t>		application developers may employ a number of strategies:</t>
			<ul spacing="normal">
	<t><list style="symbols">		<li>Use explicit typing for different kinds of JWTs.
	<t>Use explicit typing for different kinds of JWTs.		Then the distinct "typ" values can be used to differentiate between the
	Then the distinct “typ” values can be used to differentiate between the differen		different kinds of JWTs.</li>
	t kinds of JWTs.</t>		<li>Use different sets of required claims or different required claim
	<t>Use different sets of required claims or different required claim values.		values.
	Then the validation rules for one kind of JWT will reject those with different c		Then the validation rules for one kind of JWT will reject those with different
	laims or values.</t>		claims or values.</li>
	<t>Use different sets of required header parameters or different required head		<li>Use different sets of required Header Parameters or different
	er parameter values.		required Header Parameter values.
	Then the validation rules for one kind of JWT will reject those with different h		Then the validation rules for one kind of JWT will reject those with different
	eader parameters or values.</t>		Header Parameters or values.</li>
	<t>Use different keys for different kinds of JWTs.		<li>Use different keys for different kinds of JWTs.
	Then the keys used to validate one kind of JWT will fail to validate other kinds		Then the keys used to validate one kind of JWT will fail to validate other kinds
	of JWTs.</t>		of JWTs.</li>
	<t>Use different “aud” values for different uses of JWTs from the same issuer.		<li>Use different "aud" values for different uses of JWTs from the sam
	Then audience validation will reject JWTs substituted into inappropriate context		e issuer.
	s.</t>		Then audience validation will reject JWTs substituted into inappropriate context
	<t>Use different issuers for different kinds of JWTs.		s.</li>
	Then the distinct “iss” values can be used to segregate the different kinds of J		<li>Use different issuers for different kinds of JWTs.
	WTs.</t>		Then the distinct "iss" values can be used to segregate the different kinds of J
	</list></t>		WTs.</li>
			</ul>
	<t>Given the broad diversity of JWT usage and applications,		<t>Given the broad diversity of JWT usage and applications,
	the best combination of types, required claims, values, header parameters, key u		the best combination of types, required claims, values, Header Parameters, key u
	sages, and issuers		sages, and issuers
	to differentiate among different kinds of JWTs		to differentiate among different kinds of JWTs
	will, in general, be application specific.		will, in general, be application-specific.
	As discussed in <xref target="use-typ"/>, for new JWT applications, the use of e		As discussed in <xref target="use-typ" format="default"/>, for new JWT
	xplicit typing is RECOMMENDED.</t>		applications, the use of explicit typing is
			<bcp14>RECOMMENDED</bcp14>.</t>
	</section>		</section>
	</section>		</section>
	<section anchor="security-considerations" title="Security Considerations">		<section anchor="security-considerations" numbered="true" toc="default">
			<name>Security Considerations</name>
	<t>This entire document is about security considerations when implementing and d		<t>This entire document is about security considerations when
	eploying JSON Web Tokens.</t>		implementing and deploying JSON Web Tokens.</t>
			</section>
	</section>		<section anchor="iana-considerations" numbered="true" toc="default">
	<section anchor="iana-considerations" title="IANA Considerations">		<name>IANA Considerations</name>
			<t>This document has no IANA actions.</t>
	<t>This document requires no IANA actions.</t>		</section>
	</section>
	<section anchor="acknowledgements" title="Acknowledgements">
	<t>Thanks to Antonio Sanso for bringing the “ECDH-ES” invalid point attack to th
	e attention
	of JWE and JWT implementers. Tim McLean <xref target="McLean"/> published the RS
	A/HMAC confusion attack.
	Thanks to Nat Sakimura for advocating the use of explicit typing. Thanks to Neil
	Madden for his
	numerous comments, and to
	Carsten Bormann,
	Brian Campbell,
	Brian Carpenter,
	Alissa Cooper,
	Roman Danyliw,
	Ben Kaduk,
	Mirja Kuehlewind,
	Barry Leiba,
	Eric Rescorla,
	Adam Roach,
	Martin Vigoureux,
	and Eric Vyncke
	for their reviews.</t>
	</section>
	</middle>		</middle>
	<back>		<back>
			<references>
			<name>References</name>
			<references>
			<name>Normative References</name>
			<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
			ence.RFC.2119.xml"/>
			<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
			ence.RFC.6979.xml"/>
			<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
			ence.RFC.8259.xml"/>
			<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
			ence.RFC.7515.xml"/>
			<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
			ence.RFC.7516.xml"/>
			<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
			ence.RFC.7518.xml"/>
			<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
			ence.RFC.7519.xml"/>
			<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
			ence.RFC.8017.xml"/>
			<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
			ence.RFC.8037.xml"/>
			<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
			ence.RFC.8174.xml"/>
			<reference anchor="nist-sp-800-56a-r3" target="https://doi.org/10.6028/N
			IST.SP.800-56Ar3">
			<front>
			<title>Recommendation for Pair-Wise Key-Establishment Schemes
			Using Discrete Logarithm Cryptography</title>
			<author initials="E." surname="Barker" fullname="Elaine Barker">
			<organization/>
			</author>
			<author initials="L." surname="Chen" fullname="Lily Chen">
			<organization/>
			</author>
			<author initials="A." surname="Roginsky" fullname="Allen Roginsky">
			<organization/>
			</author>
			<author initials="A." surname="Vassilev" fullname="Apostol Vassilev"
			>
			<organization/>
			</author>
			<author initials="R." surname="Davis" fullname="Richard Davis">
			<organization/>
			</author>
			<date year="2018" month="April"/>
			</front>
			<seriesInfo name="NIST Special Publication" value="800-56A Revision 3"
			/>
			<seriesInfo name="DOI" value="10.6028/NIST.SP.800-56Ar3"/>
			</reference>
			</references>
			<references>
			<name>Informative References</name>
			<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
			ence.RFC.6749.xml"/>
			<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
			ence.RFC.7159.xml"/>
			<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
			ence.RFC.7517.xml"/>
			<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
			ence.RFC.8414.xml"/>
			<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
			ence.RFC.8417.xml"/>
			<reference anchor="ANSI-X962-2005">
			<front>
			<title>Public Key Cryptography for the Financial Services
			Industry: the Elliptic Curve Digital Signature Algorithm (ECDSA)</tit
			le>
			<author>
			<organization>American National Standards Institute</organization>
			</author>
			<date year="2005" month="November"/>
			</front>
			<seriesInfo name="ANSI" value="X9.62-2005"/>
			</reference>
	<references title='Normative References'>		<reference anchor="Alawatugoda">
			<front>
	<reference anchor="RFC2119" target='https://www.rfc-editor.org/info/rfc2119'>		<title>Protecting Encrypted Cookies from Compression Side-Channel At
	<front>		tacks</title>
	<title>Key words for use in RFCs to Indicate Requirement Levels</title>		<author initials="J." surname="Alawatugoda" fullname="Janaka Alawatu
	<author initials='S.' surname='Bradner' fullname='S. Bradner'><organization /></		goda">
	author>		<organization/>
	<date year='1997' month='March' />		</author>
	<abstract><t>In many standards track documents several words are used to signify		<author initials="D." surname="Stebila" fullname="Douglas Stebila">
	the requirements in the specification. These words are often capitalized. This		<organization/>
	document defines these words as they should be interpreted in IETF documents.		</author>
	This document specifies an Internet Best Current Practices for the Internet Comm		<author initials="C." surname="Boyd" fullname="Colin Boyd">
	unity, and requests discussion and suggestions for improvements.</t></abstract>		<organization/>
	</front>		</author>
	<seriesInfo name='BCP' value='14'/>		<date month="July" year="2015"/>
	<seriesInfo name='RFC' value='2119'/>		</front>
	<seriesInfo name='DOI' value='10.17487/RFC2119'/>		<refcontent>Financial Cryptography and Data Security, pp. 86-106</refc
	</reference>		ontent>
			<seriesInfo name="DOI" value="10.1007/978-3-662-47854-7_6"/>
	<reference anchor="RFC6979" target='https://www.rfc-editor.org/info/rfc6979'>		</reference>
	<front>
	<title>Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic
	Curve Digital Signature Algorithm (ECDSA)</title>
	<author initials='T.' surname='Pornin' fullname='T. Pornin'><organization /></au
	thor>
	<date year='2013' month='August' />
	<abstract><t>This document defines a deterministic digital signature generation
	procedure. Such signatures are compatible with standard Digital Signature Algor
	ithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA) digital signat
	ures and can be processed with unmodified verifiers, which need not be aware of
	the procedure described therein. Deterministic signatures retain the cryptograp
	hic security features associated with digital signatures but can be more easily
	implemented in various environments, since they do not need access to a source o
	f high-quality randomness.</t></abstract>
	</front>
	<seriesInfo name='RFC' value='6979'/>
	<seriesInfo name='DOI' value='10.17487/RFC6979'/>
	</reference>
	<reference anchor="RFC8259" target='https://www.rfc-editor.org/info/rfc8259'>
	<front>
	<title>The JavaScript Object Notation (JSON) Data Interchange Format</title>
	<author initials='T.' surname='Bray' fullname='T. Bray' role='editor'><organizat
	ion /></author>
	<date year='2017' month='December' />
	<abstract><t>JavaScript Object Notation (JSON) is a lightweight, text-based, lan
	guage-independent data interchange format. It was derived from the ECMAScript P
	rogramming Language Standard. JSON defines a small set of formatting rules for
	the portable representation of structured data.</t><t>This document removes inco
	nsistencies with other specifications of JSON, repairs specification errors, and
	offers experience-based interoperability guidance.</t></abstract>
	</front>
	<seriesInfo name='STD' value='90'/>
	<seriesInfo name='RFC' value='8259'/>
	<seriesInfo name='DOI' value='10.17487/RFC8259'/>
	</reference>
	<reference anchor="RFC7515" target='https://www.rfc-editor.org/info/rfc7515'>
	<front>
	<title>JSON Web Signature (JWS)</title>
	<author initials='M.' surname='Jones' fullname='M. Jones'><organization /></auth
	or>
	<author initials='J.' surname='Bradley' fullname='J. Bradley'><organization /></
	author>
	<author initials='N.' surname='Sakimura' fullname='N. Sakimura'><organization />
	</author>
	<date year='2015' month='May' />
	<abstract><t>JSON Web Signature (JWS) represents content secured with digital si
	gnatures or Message Authentication Codes (MACs) using JSON-based data structures
	. Cryptographic algorithms and identifiers for use with this specification are
	described in the separate JSON Web Algorithms (JWA) specification and an IANA re
	gistry defined by that specification. Related encryption capabilities are descr
	ibed in the separate JSON Web Encryption (JWE) specification.</t></abstract>
	</front>
	<seriesInfo name='RFC' value='7515'/>
	<seriesInfo name='DOI' value='10.17487/RFC7515'/>
	</reference>
	<reference anchor="RFC7516" target='https://www.rfc-editor.org/info/rfc7516'>
	<front>
	<title>JSON Web Encryption (JWE)</title>
	<author initials='M.' surname='Jones' fullname='M. Jones'><organization /></auth
	or>
	<author initials='J.' surname='Hildebrand' fullname='J. Hildebrand'><organizatio
	n /></author>
	<date year='2015' month='May' />
	<abstract><t>JSON Web Encryption (JWE) represents encrypted content using JSON-b
	ased data structures. Cryptographic algorithms and identifiers for use with thi
	s specification are described in the separate JSON Web Algorithms (JWA) specific
	ation and IANA registries defined by that specification. Related digital signat
	ure and Message Authentication Code (MAC) capabilities are described in the sepa
	rate JSON Web Signature (JWS) specification.</t></abstract>
	</front>
	<seriesInfo name='RFC' value='7516'/>
	<seriesInfo name='DOI' value='10.17487/RFC7516'/>
	</reference>
	<reference anchor="RFC7518" target='https://www.rfc-editor.org/info/rfc7518'>
	<front>
	<title>JSON Web Algorithms (JWA)</title>
	<author initials='M.' surname='Jones' fullname='M. Jones'><organization /></auth
	or>
	<date year='2015' month='May' />
	<abstract><t>This specification registers cryptographic algorithms and identifie
	rs to be used with the JSON Web Signature (JWS), JSON Web Encryption (JWE), and
	JSON Web Key (JWK) specifications. It defines several IANA registries for these
	identifiers.</t></abstract>
	</front>
	<seriesInfo name='RFC' value='7518'/>
	<seriesInfo name='DOI' value='10.17487/RFC7518'/>
	</reference>
	<reference anchor="RFC7519" target='https://www.rfc-editor.org/info/rfc7519'>
	<front>
	<title>JSON Web Token (JWT)</title>
	<author initials='M.' surname='Jones' fullname='M. Jones'><organization /></auth
	or>
	<author initials='J.' surname='Bradley' fullname='J. Bradley'><organization /></
	author>
	<author initials='N.' surname='Sakimura' fullname='N. Sakimura'><organization />
	</author>
	<date year='2015' month='May' />
	<abstract><t>JSON Web Token (JWT) is a compact, URL-safe means of representing c
	laims to be transferred between two parties. The claims in a JWT are encoded as
	a JSON object that is used as the payload of a JSON Web Signature (JWS) structu
	re or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the cl
	aims to be digitally signed or integrity protected with a Message Authentication
	Code (MAC) and/or encrypted.</t></abstract>
	</front>
	<seriesInfo name='RFC' value='7519'/>
	<seriesInfo name='DOI' value='10.17487/RFC7519'/>
	</reference>
	<reference anchor="RFC8017" target='https://www.rfc-editor.org/info/rfc8017'>
	<front>
	<title>PKCS #1: RSA Cryptography Specifications Version 2.2</title>
	<author initials='K.' surname='Moriarty' fullname='K. Moriarty' role='editor'><o
	rganization /></author>
	<author initials='B.' surname='Kaliski' fullname='B. Kaliski'><organization /></
	author>
	<author initials='J.' surname='Jonsson' fullname='J. Jonsson'><organization /></
	author>
	<author initials='A.' surname='Rusch' fullname='A. Rusch'><organization /></auth
	or>
	<date year='2016' month='November' />
	<abstract><t>This document provides recommendations for the implementation of pu
	blic-key cryptography based on the RSA algorithm, covering cryptographic primiti
	ves, encryption schemes, signature schemes with appendix, and ASN.1 syntax for r
	epresenting keys and for identifying the schemes.</t><t>This document represents
	a republication of PKCS #1 v2.2 from RSA Laboratories' Public-Key Cryptography
	Standards (PKCS) series. By publishing this RFC, change control is transferred
	to the IETF.</t><t>This document also obsoletes RFC 3447.</t></abstract>
	</front>
	<seriesInfo name='RFC' value='8017'/>
	<seriesInfo name='DOI' value='10.17487/RFC8017'/>
	</reference>
	<reference anchor="RFC8037" target='https://www.rfc-editor.org/info/rfc8037'>
	<front>
	<title>CFRG Elliptic Curve Diffie-Hellman (ECDH) and Signatures in JSON Object S
	igning and Encryption (JOSE)</title>
	<author initials='I.' surname='Liusvaara' fullname='I. Liusvaara'><organization
	/></author>
	<date year='2017' month='January' />
	<abstract><t>This document defines how to use the Diffie-Hellman algorithms &quo
	t;X25519&quot; and &quot;X448&quot; as well as the signature algorithms &quot;Ed
	25519&quot; and &quot;Ed448&quot; from the IRTF CFRG elliptic curves work in JSO
	N Object Signing and Encryption (JOSE).</t></abstract>
	</front>
	<seriesInfo name='RFC' value='8037'/>
	<seriesInfo name='DOI' value='10.17487/RFC8037'/>
	</reference>
	<reference anchor="RFC8174" target='https://www.rfc-editor.org/info/rfc8174'>
	<front>
	<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
	<author initials='B.' surname='Leiba' fullname='B. Leiba'><organization /></auth
	or>
	<date year='2017' month='May' />
	<abstract><t>RFC 2119 specifies common key words that may be used in protocol s
	pecifications. This document aims to reduce the ambiguity by clarifying that on
	ly UPPERCASE usage of the key words have the defined special meanings.</t></abs
	tract>
	</front>
	<seriesInfo name='BCP' value='14'/>
	<seriesInfo name='RFC' value='8174'/>
	<seriesInfo name='DOI' value='10.17487/RFC8174'/>
	</reference>
	<reference anchor="nist-sp-800-56a-r3" target="https://doi.org/10.6028/NIST.SP.8
	00-56Ar3">
	<front>
	<title>Recommendation for Pair-Wise Key Establishment Schemes Using Discrete
	Logarithm Cryptography, Draft NIST Special Publication 800-56A Revision 3</titl
	e>
	<author initials="E." surname="Barker" fullname="Elaine Barker">
	<organization></organization>
	</author>
	<author initials="L." surname="Chen" fullname="Lily Chen">
	<organization></organization>
	</author>
	<author initials="S." surname="Keller" fullname="Sharon Keller">
	<organization></organization>
	</author>
	<author initials="A." surname="Roginsky" fullname="Allen Roginsky">
	<organization></organization>
	</author>
	<author initials="A." surname="Vassilev" fullname="Apostol Vassilev">
	<organization></organization>
	</author>
	<author initials="R." surname="Davis" fullname="Richard Davis">
	<organization></organization>
	</author>
	<date year="2018" month="April"/>
	</front>
	</reference>
	</references>
	<references title='Informative References'>
	<reference anchor="RFC6749" target='https://www.rfc-editor.org/info/rfc6749'>
	<front>
	<title>The OAuth 2.0 Authorization Framework</title>
	<author initials='D.' surname='Hardt' fullname='D. Hardt' role='editor'><organiz
	ation /></author>
	<date year='2012' month='October' />
	<abstract><t>The OAuth 2.0 authorization framework enables a third-party applica
	tion to obtain limited access to an HTTP service, either on behalf of a resource
	owner by orchestrating an approval interaction between the resource owner and t
	he HTTP service, or by allowing the third-party application to obtain access on
	its own behalf. This specification replaces and obsoletes the OAuth 1.0 protoco
	l described in RFC 5849. [STANDARDS-TRACK]</t></abstract>
	</front>
	<seriesInfo name='RFC' value='6749'/>
	<seriesInfo name='DOI' value='10.17487/RFC6749'/>
	</reference>
	<reference anchor="RFC7159" target='https://www.rfc-editor.org/info/rfc7159'>
	<front>
	<title>The JavaScript Object Notation (JSON) Data Interchange Format</title>
	<author initials='T.' surname='Bray' fullname='T. Bray' role='editor'><organizat
	ion /></author>
	<date year='2014' month='March' />
	<abstract><t>JavaScript Object Notation (JSON) is a lightweight, text-based, lan
	guage-independent data interchange format. It was derived from the ECMAScript P
	rogramming Language Standard. JSON defines a small set of formatting rules for
	the portable representation of structured data.</t><t>This document removes inco
	nsistencies with other specifications of JSON, repairs specification errors, and
	offers experience-based interoperability guidance.</t></abstract>
	</front>
	<seriesInfo name='RFC' value='7159'/>
	<seriesInfo name='DOI' value='10.17487/RFC7159'/>
	</reference>
	<reference anchor="RFC7517" target='https://www.rfc-editor.org/info/rfc7517'>		<reference anchor="CVE-2015-9235" target="https://nvd.nist.gov/vuln/detai
	<front>		l/CVE-2015-9235">
	<title>JSON Web Key (JWK)</title>		<front>
	<author initials='M.' surname='Jones' fullname='M. Jones'><organization /></auth		<title>CVE-2015-9235 Detail</title>
	or>		<author>
	<date year='2015' month='May' />		<organization>NIST</organization>
	<abstract><t>A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data st		</author>
	ructure that represents a cryptographic key. This specification also defines a
	JWK Set JSON data structure that represents a set of JWKs. Cryptographic algori
	thms and identifiers for use with this specification are described in the separa
	te JSON Web Algorithms (JWA) specification and IANA registries established by th
	at specification.</t></abstract>
	</front>
	<seriesInfo name='RFC' value='7517'/>
	<seriesInfo name='DOI' value='10.17487/RFC7517'/>
	</reference>
	<reference anchor="RFC8414" target='https://www.rfc-editor.org/info/rfc8414'>		<date month="May" year="2018"/>
	<front>		</front>
	<title>OAuth 2.0 Authorization Server Metadata</title>		<refcontent>National Vulnerability Database</refcontent>
	<author initials='M.' surname='Jones' fullname='M. Jones'><organization /></auth		</reference>
	or>
	<author initials='N.' surname='Sakimura' fullname='N. Sakimura'><organization />
	</author>
	<author initials='J.' surname='Bradley' fullname='J. Bradley'><organization /></
	author>
	<date year='2018' month='June' />
	<abstract><t>This specification defines a metadata format that an OAuth 2.0 clie
	nt can use to obtain the information needed to interact with an OAuth 2.0 author
	ization server, including its endpoint locations and authorization server capabi
	lities.</t></abstract>
	</front>
	<seriesInfo name='RFC' value='8414'/>
	<seriesInfo name='DOI' value='10.17487/RFC8414'/>
	</reference>
	<reference anchor="RFC8417" target='https://www.rfc-editor.org/info/rfc8417'>		<reference anchor="Kelsey">
	<front>		<front>
	<title>Security Event Token (SET)</title>		<title>Compression and Information Leakage of Plaintext</title>
	<author initials='P.' surname='Hunt' fullname='P. Hunt' role='editor'><organizat		<author initials="J." surname="Kelsey" fullname="John Kelsey">
	ion /></author>		<organization/>
	<author initials='M.' surname='Jones' fullname='M. Jones'><organization /></auth		</author>
	or>		<date month="July" year="2002"/>
	<author initials='W.' surname='Denniss' fullname='W. Denniss'><organization /></		</front>
	author>		<refcontent>Fast Software Encryption, pp. 263-276</refcontent>
	<author initials='M.' surname='Ansari' fullname='M. Ansari'><organization /></au		<seriesInfo name="DOI" value="10.1007/3-540-45661-9_21"/>
	thor>		</reference>
	<date year='2018' month='July' />
	<abstract><t>This specification defines the Security Event Token (SET) data stru
	cture. A SET describes statements of fact from the perspective of an issuer abo
	ut a subject. These statements of fact represent an event that occurred directl
	y to or about a security subject, for example, a statement about the issuance or
	revocation of a token on behalf of a subject. This specification is intended t
	o enable representing security- and identity-related events. A SET is a JSON We
	b Token (JWT), which can be optionally signed and/or encrypted. SETs can be dist
	ributed via protocols such as HTTP.</t></abstract>
	</front>
	<seriesInfo name='RFC' value='8417'/>
	<seriesInfo name='DOI' value='10.17487/RFC8417'/>
	</reference>
	<reference anchor="ANSI-X962-2005" >		<reference anchor="Langkemper"
	<front>		target="https://www.sjoerdlangkemper.nl/2016/09/28/attacking-j
	<title>American National Standard X9.62: The Elliptic Curve Digital Signatur		wt-authentication/">
	e Algorithm (ECDSA)</title>		<front>
	<author >		<title>Attacking JWT authentication</title>
	<organization></organization>		<author initials="S." surname="Langkemper" fullname="Sjoerd Langkemp
	</author>		er">
	<date year="2005" month="November"/>		<organization/>
	</front>		</author>
	</reference>		<date month="September" year="2016"/>
			</front>
			</reference>
	<reference anchor="Alawatugoda" >		<reference anchor="McLean"
	<front>		target="https://auth0.com/blog/critical-vulnerabilities-in-jso
	<title>Protecting Encrypted Cookies from Compression Side-Channel Attacks</t		n-web-token-libraries/">
	itle>		<front>
	<author initials="J." surname="Alawatugoda" fullname="Janaka Alawatugoda">		<title>Critical vulnerabilities in JSON Web Token libraries</title>
	<organization></organization>		<author initials="T." surname="McLean" fullname="Tim McLean">
	</author>		<organization/>
	<author initials="D." surname="Stebila" fullname="Douglas Stebila">		</author>
	<organization></organization>		<date month="March" year="2015"/>
	</author>		</front>
	<author initials="C." surname="Boyd" fullname="Colin Boyd">		</reference>
	<organization></organization>
	</author>
	<date year="2015"/>
	</front>
	<seriesInfo name="Financial Cryptography and Data Security" value="pp. 86-106"
	/>
	<seriesInfo name="DOI" value="10.1007/978-3-662-47854-7_6"/>
	</reference>
	<reference anchor="Kelsey" >		<reference anchor="Valenta" target="https://ia.cr/2018/298">
	<front>		<front>
	<title>Compression and Information Leakage of Plaintext</title>		<title>In search of CurveSwap: Measuring elliptic curve implementati
	<author initials="J." surname="Kelsey" fullname="John Kelsey">		ons in the wild</title>
	<organization></organization>		<author initials="L." surname="Valenta" fullname="Luke Valenta">
	</author>		<organization/>
	<date year="2002"/>		</author>
	</front>		<author initials="N." surname="Sullivan" fullname="Nick Sullivan">
	<seriesInfo name="Fast Software Encryption" value="pp. 263-276"/>		<organization/>
	<seriesInfo name="DOI" value="10.1007/3-540-45661-9_21"/>		</author>
	</reference>		<author initials="A." surname="Sanso" fullname="Antonio Sanso">
			<organization/>
			</author>
			<author initials="N." surname="Heninger" fullname="Nadia Heninger">
			<organization/>
			</author>
			<date month="March" year="2018"/>
			</front>
			</reference>
	<reference anchor="Langkemper" target="https://www.sjoerdlangkemper.nl/2016/09/2		<reference anchor="Sanso"
	8/attacking-jwt-authentication/">		target="https://blogs.adobe.com/security/2017/03/critical-vuln
	<front>		erability-uncovered-in-json-encryption.html">
	<title>Attacking JWT Authentication</title>		<front>
	<author initials="S." surname="Langkemper" fullname="Sjoerd Langkemper">		<title>Critical Vulnerability Uncovered in JSON Encryption</title>
	<organization></organization>		<author initials="A." surname="Sanso" fullname="Antonio Sanso">
	</author>		<organization/>
	<date year="2016" month="September"/>		</author>
	</front>		<date month="March" year="2017"/>
	</reference>		</front>
	<reference anchor="McLean" target="https://auth0.com/blog/critical-vulnerabiliti		</reference>
	es-in-json-web-token-libraries//">
	<front>
	<title>Critical vulnerabilities in JSON Web Token libraries</title>
	<author initials="T." surname="McLean" fullname="Tim McLean">
	<organization></organization>
	</author>
	<date year="2015" month="March"/>
	</front>
	</reference>
	<reference anchor="Valenta" target="https://ia.cr/2018/298">
	<front>
	<title>In search of CurveSwap: Measuring elliptic curve implementations in t
	he wild</title>
	<author initials="L." surname="Valenta" fullname="Luke Valenta">
	<organization></organization>
	</author>
	<author initials="N." surname="Sullivan" fullname="Nick Sullivan">
	<organization></organization>
	</author>
	<author initials="A." surname="Sanso" fullname="Antonio Sanso">
	<organization></organization>
	</author>
	<author initials="N." surname="Heninger" fullname="Nadia Heninger">
	<organization></organization>
	</author>
	<date year="2018" month="March"/>
	</front>
	</reference>
	<reference anchor="Sanso" target="https://blogs.adobe.com/security/2017/03/criti
	cal-vulnerability-uncovered-in-json-encryption.html">
	<front>
	<title>Critical Vulnerability Uncovered in JSON Encryption</title>
	<author initials="A." surname="Sanso" fullname="Antonio Sanso">
	<organization></organization>
	</author>
	<date year="2017" month="March"/>
	</front>
	</reference>
	<reference anchor="OpenID.Core" target="http://openid.net/specs/openid-connect-c
	ore-1_0.html">
	<front>
	<title>OpenID Connect Core 1.0</title>
	<author initials="N." surname="Sakimura" fullname="Nat Sakimura">
	<organization></organization>
	</author>
	<author initials="J." surname="Bradley" fullname="John Bradley">
	<organization></organization>
	</author>
	<author initials="M.B." surname="Jones" fullname="Michael B. Jones">
	<organization></organization>
	</author>
	<author initials="B.d." surname="Medeiros" fullname="Breno de Medeiros">
	<organization></organization>
	</author>
	<author initials="C." surname="Mortimore" fullname="Chuck Mortimore">
	<organization></organization>
	</author>
	<date year="2014" month="November"/>
	</front>
	</reference>
			<reference anchor="OpenID.Core" target="https://openid.net/specs/openid-
			connect-core-1_0.html">
			<front>
			<title>OpenID Connect Core 1.0 incorporating errata set 1</title>
			<author initials="N." surname="Sakimura" fullname="Nat Sakimura">
			<organization/>
			</author>
			<author initials="J." surname="Bradley" fullname="John Bradley">
			<organization/>
			</author>
			<author initials="M." surname="Jones" fullname="Michael B. Jones">
			<organization/>
			</author>
			<author initials="B." surname="de Medeiros" fullname="Breno de Medei
			ros">
			<organization/>
			</author>
			<author initials="C." surname="Mortimore" fullname="Chuck Mortimore"
			>
			<organization/>
			</author>
			<date month="November" year="2014"/>
			</front>
			</reference>
			</references>
	</references>		</references>
			<section anchor="acknowledgements" numbered="false" toc="default">
	<section anchor="document-history" title="Document History">		<name>Acknowledgements</name>
			<t>Thanks to <contact fullname="Antonio Sanso"/> for bringing the
	<t>[[ to be removed by the RFC editor before publication as an RFC ]]</t>		"ECDH-ES" invalid point attack to the attention
			of JWE and JWT implementers. <contact fullname="Tim McLean"/> published the
	<section anchor="draft-ietf-oauth-jwt-bcp-07" title="draft-ietf-oauth-jwt-bcp-07		RSA/HMAC confusion attack <xref target="McLean"
	">		format="default"/>.
			Thanks to <contact fullname="Nat Sakimura"/> for advocating the use of
	<t><list style="symbols">		explicit typing. Thanks to <contact fullname="Neil Madden"/> for his
	<t>IESG review comments.</t>		numerous comments, and to
	</list></t>		<contact fullname="Carsten Bormann"/>,
			<contact fullname="Brian Campbell"/>,
	</section>		<contact fullname="Brian Carpenter"/>,
	<section anchor="draft-ietf-oauth-jwt-bcp-06" title="draft-ietf-oauth-jwt-bcp-06		<contact fullname="Alissa Cooper"/>,
	">		<contact fullname="Roman Danyliw"/>,
			<contact fullname="Ben Kaduk"/>,
	<t><list style="symbols">		<contact fullname="Mirja Kühlewind"/>,
	<t>Second AD review.</t>		<contact fullname="Barry Leiba"/>,
	<t>Removed unworkable recommendation to pad encrypted passwords.</t>		<contact fullname="Eric Rescorla"/>,
	</list></t>		<contact fullname="Adam Roach"/>,
			<contact fullname="Martin Vigoureux"/>,
	</section>		and <contact fullname="Éric Vyncke"/>
	<section anchor="draft-ietf-oauth-jwt-bcp-05" title="draft-ietf-oauth-jwt-bcp-05		for their reviews.</t>
	">		</section>
	<t><list style="symbols">
	<t>Genart review comments.</t>
	</list></t>
	</section>
	<section anchor="draft-ietf-oauth-jwt-bcp-04" title="draft-ietf-oauth-jwt-bcp-04
	">
	<t><list style="symbols">
	<t>AD review comments.</t>
	</list></t>
	</section>
	<section anchor="draft-ietf-oauth-jwt-bcp-03" title="draft-ietf-oauth-jwt-bcp-03
	">
	<t><list style="symbols">
	<t>Acknowledgements.</t>
	</list></t>
	</section>
	<section anchor="draft-ietf-oauth-jwt-bcp-02" title="draft-ietf-oauth-jwt-bcp-02
	">
	<t><list style="symbols">
	<t>Implemented WGLC feedback.</t>
	</list></t>
	</section>
	<section anchor="draft-ietf-oauth-jwt-bcp-01" title="draft-ietf-oauth-jwt-bcp-01
	">
	<t><list style="symbols">
	<t>Feedback from Brian Campbell.</t>
	</list></t>
	</section>
	<section anchor="draft-ietf-oauth-jwt-bcp-00" title="draft-ietf-oauth-jwt-bcp-00
	">
	<t><list style="symbols">
	<t>Initial WG draft. No change from the latest individual version.</t>
	</list></t>
	</section>
	<section anchor="draft-sheffer-oauth-jwt-bcp-01" title="draft-sheffer-oauth-jwt-
	bcp-01">
	<t><list style="symbols">
	<t>Added explicit typing.</t>
	</list></t>
	</section>
	<section anchor="draft-sheffer-oauth-jwt-bcp-00" title="draft-sheffer-oauth-jwt-
	bcp-00">
	<t><list style="symbols">
	<t>Initial version.</t>
	</list></t>
	</section>
	</section>
	</back>		</back>
	<!-- ##markdown-source:
	H4sIAGAoo10AA71c63LbuJL+z6fAUX5sfI4oX+Jr9lLr2J6JZ+LEaznJnJqa
	mqJESGJMkVqCtKKTyrvss+yT7dfdAAhK8mSytbVVMxVZAoFGoy9fX8A4jqM6
	q3P9Uv00fPdWfdQjdV8+6EK90qZWF01V6aJWt1UyrrOxNlEyGlX6EaM/3qtX
	F7dRWo6LZI7H0yqZ1HGm60lcJk09iz8t63g0XsR7J9E4qfW0rFYvFb6ImkWK
	v81LdffDhTo52j+LypEpc03fRVG2qF6qumpMfbC3d7Z3ECWVTl6qoR43VVav
	omVZPUyrslm8VO/OsY76iC+yYqp+pC+jB73CiPSlui5qXRW6ji+JsCgydVKk
	vyd5WYDYFXayyF5GSlWTsU5Nvcrtt0rV5Tj4mBUpGOC+MGVVV3pi/N+reefP
	usrGfvC4nM/xrP81K/KsaJfRn+s4z0wdY5JRmWNYXP71b1FEzCsroi3G//QY
	fvr7QA1nejLRFX8nLP97UpVF5/uymiZF9o+kzsqCWdBkNf+g50mWv1S9FT0y
	GdAx/fuUvhuAyl53rcuBep1UaR2sdJmNH4Iv3Wwpvh7M6OsnJ7sZvBqon8B0
	E0x3k41nic5V56cu7RhSlaacdBecjz79+9z94lZTCpKBH2d1vXi5u2t0Pokz
	YxqdDrJiUu72oqgoqzkmftTEVojdwf7+mf14fHbiPp4eHLmPEMuj9uNx+/G0
	/egf29s/8R9f+I/7J4cQZ2yZz3gRn+7txUfHSVy9eMlEt+fsGObYc5UnEBT1
	Kqke7Ll2f3+T5St1MdPFlt+GMxaKn3Web332HN8X6q6c4nQeVtsGLEpTl7n6
	kBiT5fpxy5A7Or4qVZfJYyZnZ01I706L0Kd8impSVuo2yar4Y2Y0aFqpK6jh
	CFI/I81Qw/FMz7VR7w0p8GVmxhWsgHpTThPo+myuLqrVoi6nVbKYrfqKNVm9
	vR7eq+FCj7MkV7cNZhvLasLgc3WnQRZ98UKkg6wN7avKcnWwt38qFCfVVENV
	SWgMpCYtswEkcHd/b3C8d3C6S6sMhrcDO2n1ApYJwtQVo+OTQy8w+6HseCE4
	3D9sP56wPJy/HV7Hv5wdH8QwcEcvO/w7n2tYkKRQb3lL2OCQzBYx+5ezwfHB
	S3U/05CPPFvAHJN5ftTg2zSraWg2LZK6qTQOGdaWGfj86uJyeL4TMuJt+ajn
	I10pWp4JypMlnpuWKezs5bvrAXiwv7d3snt2chq/iI9B6eHJ6dFhfPL7MY2H
	bBm96g59ER8d7sWHR8fH+/HZ7wf7GIb/3iTF9EHPF7r6lsgPP5Uam2wf6LKl
	rpMxG3lyO2T1IT322MOtDfWitns77dNZH2896+VyOTC8YO7XGxT5Lj2wu3e2
	i+NP3IrsxpLOirvEhJvxG50U39rWfTa3Izv7ucDhYLJcPTZ5oatklOX4AoqQ
	FetuOM9GFZRBm3CfN0k1nqkX+7zHo617JJr2yELujvJyuju2K8ZrK8ZZEX8y
	ZREv9SiuacXYr7jLG/2QwGDUybd2+qZ50G7slp/fkgMZNhDcx2Sb2Tov6rLI
	SjVMClNuez5Js0S91gWOZE04rgtlNDOknIhGDJcJ0MGNTgwcA4RGO30Zs75k
	80Wuyf7waTLTcbxqmeXpJpMPzvpPG40sGYwrEpvT3YOzU+IW0/8tXm1udkMw
	PgTHtFLvizGUttKpF5CrYkymcU3+heT9F0zyyVaSSRrMIEnLkWbpMBZX0S5O
	dvdebJeUVdw4ErzEaE/CYFbPc9r9u4Uuri8HF2Wlv8UDGDjs/yGbN9U2efmp
	nAGCVkma621OaiuA6A55BeBaqlRDDlKdATFsGXMxayCWNwB12Rw0d45C9qIu
	yqLQYyBh/K72B3tbLakYm8MNhoPfJabJ0gGA6K6BzzL2i3gs8+LfSsf7v+9Z
	HsZxrJIRcCTwdhR1bYHpqyQ3pXooymWhEkPGkL4DYe/v3sQmmWgWjniUGIiK
	O1nFam2iegaWY9ka4EIl+LkmhRkDa8yNkh/heEZaGfgRPA+/swv/bY8ZYCqi
	9Xi5kSa1WmapBhBpjAwGrxd5uaI/DM3ParZGhRIPCleqiga+rmyMWlQlcDYA
	ME+SLBbOoWNvoxIA3+onxQFEcWrdXUbAHDP3I3oOgzAWZxFMwI+YQUQ+c1ri
	ETxdzzLzRGyjEMs0jEswpC6JsEcsouhn+OIRdjNtsjQpxjrKNQwSeIBhvMN1
	qxIwhGfEysS9gZzwPEsh2FH0jCB6VaYNr/Cnzlt9+WLR59ev/59nTzwk50tC
	nE0cg2egymicKxBahsfSkg0CZhonkAuV1TRHsjBNTiFf5OiKKw1omRCrHajC
	U3SGwL04sxV8UUyCQaqXl7Jan5lqp44yPiYaS4fguQ9xbGUzTh4RN/DJ1SUk
	bBC9w/zrEkLrLmewKMoLOKHYsnDCjXUqvai0IYHD5OsSGG6iH5kGM4EvawYE
	H+VUcYKBnfz6lcVXQtmDwZ6cLwHLr18heRBLYw+Rd49oE3TM7Fd9VoxU41ih
	PjhR2QbtoJW92B0ZhG+YQXj5oc2zXILmRcPgXKc8M6aZJY+k7pp8LMw/Nm21
	3o+MBCph+WLDs3aVAOwfMm/sA0QmkYINNTkLZINgu3L0hmI817D3CKTmpBNG
	LeHR6V/spqQla4jDlqXpZ+j4mIQimWIfq455AT82LMOaCZgkY3J/kN3vVPOb
	pFjJpLS/MCiyeCNcixiRjMqmjrbMTmpkJxq30RDATMsT4Vu+sgDZarRIwSQj
	fR6tWtvShgnPf/o43PEG5QgGpR3VAgwadtUOO2a7U6TtUB9tGBp63g49/foV
	GkeCZNo9hhsiIfRGSM8RuT9qeyyGDT54VYNx2AEOA+ZpnhVADPMNllKgSRPa
	uYkJkXUbjwls/Tz5VLIg4ccuj6O1EzRjXQD9lmYAOMMOpaMllrdQQ2iH6FJ4
	kmRFSWUiyQTh6Ur/Z5NVvB5ZETKDvBkydCCaYAckGUvUxnFFbAmcH5vykreR
	VdEiAUwZw5BWapxVWJAyWrAP/wyt14XQlRkRFDzZbzfq+Z8iMJblk5TUO8In
	ADQwbSu9YMEPTUVMIDL7a3u17pF8/SQvy6qvihJSp8YaKlNMYQhLmrYkwK7E
	L1gy8mWywsc8L5eg5rkeTAd9OgOcJ4kwdpxmlNJi7P6Y5I1lvfCHlASIjfbO
	TqyjFFhQF1OY0kdQT8ahqV0knZdJugPhuoDkNAUJAznWXKdTJ5nEOj8Bpn4k
	QWiIUi/gJC0TOJ2MfIozZDj1iHQRE4F544d8Ja5Kf0ZgmbGYmFm5dHq5HX6o
	568ubncCo8AGwVvAjPi8KKEPBMCBV4lUCBONHag7wJEtpwzX/KBoZ2SNdFUl
	NRBU5RKwlhxYRHahndMFn549U/eMZRFwp7wLsZdeJRP79Tbj+TKK/qquQwEU
	tWzjWfWcWCRWYMjsgpkJfmbPC4st8um/3+lvmXhcplp2g6eASMjLBAvx5oAr
	PtdEHI8zJRgYWNB5sopIfGFjrFzz4n6SPilrA2+f01QrYvSOmMG/qkt4xhyw
	XmjZbi7AYoi1AHYLag1jS+wbB8Sficbrq/sfhPfADY8EL2gSQSFrbkNO4wHE
	UMLbqN7N++F9ry//qrfv+PPd1X+8v767uqTPw9fnb974D5EdMXz97v2by/ZT
	++TFu5ubq7eX8jC+VZ2vot7N+d97Iui9d7f31+/enr/pbXduYrxJcKoFZfgo
	RIhgOhBrjmRnkP3//q/9Q7iOv9j0LOCP/EGJVPxBRk5WY2Amf9JZRJBgxP80
	C0wKlHFB4EyAAqkdLDJMHZgKuH0/A96rRY0/dDMhxM6M0CxjcUWZeSNiYvE3
	HlmURjQfMoJ/IDdLmAWW629Cn6sEQmmfU7J3ca8ZuS9rCyFy3rWYdTcxB51T
	J1bOcDtKRGg+6uShdfBCxXVhmgkEMuOMq3f+H5I8E/dJsJBR/1r4AVZWFUS9
	IEMG1ESIGxbawkXrrChgIDvtbWTfOV5yY25UDz/3cA5kpRQcGaJvyEJ/DWJ1
	TXky5czDgM+lT8eLAOZTU8j5MOPBRiwP95MsGVbxcbWKvxlPMpzNnXEUQGut
	OFss0ii/ExcTiWnnZ3oFDqTHQLKwD9I2aKG1tZdlk6dSx4pYIciPib73HoX1
	mMiBINoN2enxTEuekwy2cWc1AGXnBVRyeHB03FPP74bnlHA4PFWjrN5p+WnX
	WCMbaldGvdf22dc35xd9BQsQ4++dbaRHjnT2Co5Wf9giPRJl0WQx5sJUFqty
	TIyRIFFChDFbqIRxSUTjoZNJJdgepkA9h4+CokuSlEIeTHPx4SqmxGZ8dvDi
	iFz2D6QCrfT3ybGpf/kMVbHpln/t+VOLcare/vZ2/41nXBu7gNYsqgzbilvf
	jrGhEq2ALwkUUdkCxuEa552mmcShzLBQshh4JrRV7Iw22QqRDQf9CZDkkdC6
	CG6EYzcNO+EEgQ2WNn5pNu6YBSoV6LCmnMFiBdbZSDNRs2aOQ59r2AmOdheJ
	MeQVdgDhOOZ6oE2QKXZZPQ6JoZ4TqkmqUdWAF9DYMZsbKDmDJtJ+H92NSXoj
	J/QKnDRqVkJSyOkxJTbH82ubxf/tzx0eqIvtrvwpXPvgDYANhjdzVieITOho
	vUWDGeuqILveVPNoEAd4EfuEBmsdMWBkUyIAIbFNfpSjT1g2SksBtIJWO3rA
	nowwZaCif2afbpJYLJ3f6y0V/KggrKAFDxSq1rOqbKYzqH2Sr0zGyOIiW8CT
	2WGEUSMJM3XAkBap5iRKYXalxbi5R7j018It3hejmhDu5VgymZcNB7WU7mKy
	OiC97hhLOos54TBMS2CIFx0odqrO7VHC5nMy1tWIwqDIxi0BCTQCIV6dwZOv
	GL/DixlKR7iM0ib97ahgHlBD6KAx/YjHtKyLZA98towk7E66k2JT04xOuJ2S
	FJXycRH5bMg+pdMYKV9YApjJQW6jDdjyVbSAf68mTe6CNUquEKa36kT5YMh/
	Tr4pJZhunaiBZfc7JF9tFgkponH2kwYz1AlCPw6HxUa1uZnX9/e3Q0oBsb2V
	Gh7sLQ2d6oI94QhjqbUCqLYswlUlmvFiJl7jy5egcGhnSjz8pYPmBDAYukYF
	Zi4fMg70t+rMly9FGQerUxZBLILNwbyXKH+tDNrahSi6hYH6lcsrv/W9o//p
	3TAMMCYJgfmuh8sIRiJmpNNl44OT4wODQJMmbakmsXubVlqyj88Z7VxdXL6O
	r4a9Vj3gxc5bxOCDdWeHjZb4h/WchWtWltaZSlQDuphQuypHgoxwqHlG01d8
	+lBUEXPoOu9Dkms006Qq584cegQl1mxz5ohAhOgbYZdONQr0Uv7lUVcuvZUt
	yDH9Eyl69kisBFO+0yIK271FvCGiBXRy0sYVvUoyPnDHt5V+5NgcVJggOSAD
	xeg51ysKbVuMUpud2j86o9Srxd1ORCTvwJkcoJSEMiKRdqu+VO/vf4hP+/zP
	viAe+vjiwJo5/EdWxashjLMkTjyrOQteSy8SFfWZFmo7gf6wMWKC6LR4KSjR
	WMN5kWp5n0OnQhOy2+qN85IsH87DrEyt5z3By7Ddo2zaEPeWbGvgqHFe26IU
	iSM4xLTTujmLx6wqC0ldIUC2dqLWiJSL2O/B86fPg2w219ovcrNcLYrmmQkD
	QEDojMXTCo9jIR5rKjI+hEFH2qcBEkxO4kBnTtpCwoeockVIJ1oXw0cf2wii
	ftLUdIURa8VNPTn1UjhsRqbO6oZnOrdW7MszE3z9lcPwSrKVztD5ggKFb54w
	qjDntKdphsieMce96PeSc9k2rcKHXUtVi5/ArABTNe3X1lQ4i9TKarsCPSsr
	87wcWiQilW7+AXMCgJIzaIirJhTLfLv+QNKd6yk4CNXiCoAURGw+sYjaKWzh
	RlO5wpQNgcqWsMw6eaGmL4RueWKeTWesS4VbSapY7BE7hNHyATf+cHXGLGu7
	CrnD0avEdo7nUwaI/AzQ9LUFu8CjLi1JJ09zAKCAZJsmJfvpVYEFtEXOmJDh
	laPDE2oxq7CIpuT6ko1XLQnfaVaNiSGu2+MgkvekSb24X1QlhpPQXJTFpGG8
	EZ0btVb3dSrJSYku36WOm1EClwzzZq2NAnnKssG9c7vLmL7DpPCzLq1bS+1V
	P0pCnRJ6Nndo62DMo7YwJa1+fMakboumQrSgI6EVe38k4Je6WooMTAouFg+i
	t2VtM4e1teABhKlXCy3RTWAG5BgH0XVQwugYKytAwcYZKX6uW7OQ1e0zY2a1
	Nb62hv2QFanbtSDYopP94QwfnoWISsU94FjNtZMtJP/vRaf/pNz0o81fwDV+
	ZlPeLInUVTV2AhbEe2nG4d55ixaJwUMCN1UUfbDJ+KBmlFQ6SBOHlpb4IYhN
	5QCbzaINSUxboSXsPBJHnao3l+e3tpGIoKktW0FC8yblIntQVjPZPGNYz7OD
	ACxgaWAsVg0QuLn6n9GOXpuYsSRHQQqJqHnE5svKWGf/yeYhPXau7NQx54qp
	TENVBAyeaoTpz4fDux92vnXSX76kZQzRjzkvFQtZAq+lKNH2QjyDn3t1K94N
	RBvSb/cb5UZpCxpYhVKsVpJZ5OU0ZCytDCZSlcmSIii1tllYO4+FCpCOsebY
	0uZgbWxsz7HtafwQJHjUMyJ0e/IHxL/xaJ9VRksXhwA0apBl7M3qTgiD0jAl
	GwvbINEt/EQusS7ZHjpg6ThpR63HCt2MZiuD0k8hscjK0WaaytsilzLFKfYA
	sHzu1NXGTRsd+uUjF1V4M7dZNG4j8+gG5ptAfF/pRDJE3q609ojC9ZqDZB2m
	eAU3Zq0lYphFD7mQ/olliTzLH4IidMAUzZ23GbmwnCyHuzVb95U909BqydHg
	gM4rKGWDNytIfU986ZpBRhQkHcK2X6JdkepAoSG3WM1acPj/K/qTMBOXrVzX
	TMO+GeE9/JgzoMA2TZGzhw8TJc/NTlDPsdWvSlDJorYBoQCGlmL2mrY+A1rI
	BFT+aVdd4YUHPQtIJxx5dJKUfFhtmBFWzDvHJckXW59smSPyNdfaVkpdabJT
	4rZhWLDuwBVWLACm7JKS6JGqmARP9bKjalL3574o6i/hSipMRafMYFyXC6wG
	19TThiPpNDOuV7IrgpRaLShNBOU73+BK7VhGrJSygrhVazKeKE1gawxJs7Tv
	hOKe5G2TnS0qBc6k7iaK+DmuqaukMGR3EB2uSB2de7p/M4wko/5nTsd17FAM
	NiJACrZa4CjJZYE8sgjl9LpbsvS1xSWGNgPKezM9DMT6ociwkZJ6yEbJhFSc
	syeBWIvN23jC+g8WS296nBX5E+wcOTM81wkZVgarwja3FoW/E+D7Vq03wVkQ
	tElSkZN7tLi0LvCqIhb/LICMhvneO+vhfZtY278DSsk28DEKc7zlxopcC3al
	FYdSC/sH85x3FKSt2iqtj8fV5p6t5XGFu3zlEIOIRFo6vCJ+cBANHaTpqyfX
	I8vTzL93ubWFuspnZ5cCqEVLrTf3SHyt3+dlFMXq/LGklkNYlLvheXz788Vw
	Xz3uD46eyIc/l1zL3v4JNTDBcQzUyeAAHxdcceVmE5ro3fnV7fbB+zsDLMsX
	KtrEP7XzdW90wPdYiwjlbooMfFBQ8bSc2/oceWbKN1FbmzGS7RfHLefOsQUh
	ZfUJKI3aa2AfR1lrXDuzcaYZ5i4bi/NI6HYUHJkk0LRbg72QBKLecAclXKnq
	Gb6P40wIp2DLOTWTDADPeewSCFWiMkmsBwk/95jNDTIx3ULpQN2XFPhQGsid
	tQDW/nYhb7s6hettfTGleid1gxnKxDJEIBDj+t2gWZLHODs5I3wrKTE3iiyK
	7Ru0VQaIFZFrIY/1NbKmIEpuruFSqdPitrsqjVz5tuPIbHuoPCvRqJULC3w+
	uMTzOWT4omON33mkKBhorXBE4IdaHZ5Al2v44t6jNA9NlOu9IQqr7qBKf2LL
	GnFmyEnJfCNfbrlKdYeq0UE9RcJWV0zi6F47RP1aYOytK1mbyJVVWC3eismQ
	PhlvkNlIgr+Etbmts+COMr/dje1FraBQ4VMaAVpTwOXWrDVNHbAS/ctf4lhR
	lWTLjVaDE4zpfoUhk3A82OepjwcHAxXH/9Y91e6JXktZoXuakvT+aiuXTx1n
	iwg2Ln5NIF3xa53nVP7tVCKi574KsYMA/EG7woaAuGTl28Fd+p/NSbCYLTHI
	uYqh8I253RpIRKkX9sFuLvssFfcRXgymA6ijvRy0ZlClr3y42zZ/cWJY5xOY
	MJiasDpj/CZGgtX8Mc8jTprKI4RPgo7YLlvXy8MlqfRzPE1C9hdqNrBsU3pB
	xpCqAkEjw3O9eNhxVLShb6BY43FZuasBa3npaEyp9mKNewP1gw3V+GYjLOpc
	x5gD7OTfjbqlXo0+/nlxesgCdxsfHez3wzQ3qUBkgRfHVl1C2jiJZPXF4JBq
	VBekhnV7izKmC5ptW5C6g8pl5N0BFr956bLyly7Vr5s3Xn8bIBR/0MvMSMaZ
	seMvB0dH+2cS4/5yeHjas+WQvRcnlHvuIn0yaf0WeHkf5qKhtre6MwlBX7G2
	VxJfd7WSejsklThs+yuubH/Fl2dBX4LNhPAdVvs7ncSduOIPrDvcejlmXOcY
	Tvcj1yNTSiXQHm5tkwZlW9f24B4/HZyGT59+/Ro5Y+d6xhiit6XmvvSCxNwL
	kv2j0w1iLSVBOYpyMilwMmsjWyYjGed8OreyxFtbWZRtZdlYuV1nG6gPcnK0
	SlhOxs5nUhUtPPIOfifiOt2Cjj2HG+wJM7oMoTiU8AmR9YUdxfbaTIAcCY3V
	FK6ahttBOMoOumTaTBtkS6CoNGXEl9xfIILkp7Pm/8uztdJ21OkeoNtNVPwP
	MDcdFCVfrMULiXc3YSQ+a7sgeAoJeCjhmnBGflsfiO9tGNDNNZeLkcojOypX
	EAOZ4S2BjbsA4aUkRuQup8bnIBM6MZjIvSIuGdouSfsHlW4jB102gIJtEb5X
	FxJqDTU1qDsIwggio7bNQq+XW6Um3L3sEhReIcZbqqKbiZNUWqRlw+QVOQ4G
	JEnnWR0ExpG4wvdFxm3JvjzqMnLG1yjMGg68pkqGYJyhlbo1vCApeRzHx5mv
	IFo/zkmuHkb01HMuiVQ7EpX21zGObCdwrDbj2HWU3DH2ZzKJRnVqvXnZ+j6h
	w9VKVkpaqp4gSHBnm3lge8tBPeuFA/whriuXha0O2zJQpQTnu5mDu0/nRi6X
	SVtKf/161tqlLDfdozXsUD1+vwS4S6WAaO0WSCIyBklNWPt893N48Y5qS71P
	ywfzO1xXz4ZvNvSjYkCwgDRrtOkIoeafjIWzFcGKGijm0d22/Onjz6QRXhFP
	fNTDmQbf6e7Tw2Ca6MDh/qG/ptOVegKJJNJtic+fxiiTLjAmh67fMX2Gb5j5
	PEInixPygKpK1L3IIv4dUirRq9UM2+tKbTpmUVK9jP2W4E83yN5jFPJ23beL
	JKuUFfrNRCVt25V9qEyVSSrfq0kraFxFeSKMsOVBGdx3BPE1Aja9TELl07Z/
	Viesjeb+dR8+unsY3mYnTQobYUmQVJMQPXaKsnZPrNN8QGfuyrvskqWLQdA0
	+fsVm70gOx11Ak1/zxQiTWVC9dzdFLFnrcIbpw4bOAXXJDcWDvCkUebCZ98L
	UrQEe3qoz8FXPf24tsBGwkDpmM6Dg2hbgvOP9rohlrq9B8MiKbeRJ1t+cUV9
	myKkibnB1JhynHHw4B2XDxr6dM/1SVG4LBXgjronOVR3eqwzMgjWQX55tq3Y
	J2a195DRuRAcur7cccWlzKyVU4UN4e7XQJwUVwcqzOlFFvx1C1p8JUQLA6jo
	D94N/+MN8YALr23Bc+0FFX2ixgU6xTSyGm0S6hL9h/MGlds7M7prhhCrFClw
	qABm3hDM8EPTo9uKP3NiAhZ3h8OQz0f09S+Do70z+VI404/EFIdhMwlXNcpq
	jlgxth9JSb/tf/qOeq3alhR1958Tahgx0s7mbttKVM3MAawbzxwjyHewHQTB
	taYCq9Qxpc3N3aQ2UsHjE6Ini9L1ZEp5mzPfYrt/vLp3xLfm58rdB7lfLeh5
	b3jq1cJmM6i2Q7emoM/UzeBaONzdBNf0EDZjcHNNEkQUUfhkZkIobjGvbSLo
	t+1ObOGs9Q5urnB+kfs5WEL6PgEWxNBVk2sp0jv46q9jcNUaTzsX4d0pjXad
	F12aBpHnkl2bJiJ4MubkI1+epvNrc1U9ap3YuCWz3rBFI53rphi3C2z5ApzU
	j1uRord8MI1/+7SseyCfXqZC+4kCffaXfCyp4Lt76RpXPWt3Lej58OreUKbk
	1hppzrr6/nzZRSdK2x+crQXBfXt/P7hSFpa+A9J7nKDPPpPYlEDaZCcZHbUc
	s0oflD05yHBIb22g9zhBtcJLjMiItDJjm5FVRazd6/BwIAh8nWfU4O56cmQS
	nH1fPbHXJDgJfiNJ9wZw1OGD3Y6coPWbfdvc2bM/9uyrCvJk3JrxNg3tkbyv
	qwQKNnBBBaVMuM95bW9sVtoEbf8PRNYZSSfY4VTOTbo8hvOG1t5Icpc0xvKi
	XVGaq7mnUa6+JSu60+s637ux4Y6ULjmvmpiwX+IJkkU2XIvmGlWSfKYV7NsH
	+lFXgHhjQUK9pRp8DZvMfPl0nb3kWxgOwJhDzqiQLT289lVqJPK+NLHWIGaT
	Nxu2TNSg8wzjPkkO2Asu7lbFH/ElMGatpIfyTCtR9aNp2/VM6y9umrrhAurV
	Z+iZgafu5Bk9rZc+0vg53KD4l23dY3A2fK8yhCjuIakF8bXpqpxkuRP7VQsa
	pBojl0ptlTfoL4ue9BFbINucIX8XM29xfLZZ0TWLtdBcMPTWE5QGbd6TU5pl
	RYbQIlcnWXwrWc0dr7XjdT8S7OhfD2E1a0l385lI2M4ycGNB66BjJosf7ant
	ZeSuX/bc/ajbXOOvQ5NMiz3EKRQNvyuJ+ilrqlpPMy2XLklC1rVhwrfQnDR0
	xJ0NvahlyqINRBCYd7MRWLhpuLtopOul9o8/sYDQ1P5stBRfvcTYcn+HyO6P
	lpiA2K1nuy4mbH881C9tq394L8Gv7Bb4JrHrKv0U3dtV//9+C1vpeWo3nGH4
	c9LAQ92p+whtK3kbd3+29N1u0iLRrJWyLk2h3WvhSaDfls4wInSsDBnGz4dh
	LOtZVgRNcL5jZZNAm4b5bu3hrOF27TF6WmnfufnkpNGP3CdHY0YVOWVpAHe3
	dz7e21fwbFzJZrPH/aVAxSNs1F8uh0dFALGmcn1fptyQoj5HpLyMTdJadkQb
	RiCZl/wap62bieg8uPps78X1fXOrtXCdpCI1nDXGuKYDFwV97XufyLChcw39
	D2BA169yZ65H4d06kX1hgQUc4YuLJMP/VImM03K+e6HNwpOZdmn44C0ATML1
	+dvz7cv7de1BUYQvw+W1afL8+di/a4XbBLlxrnjgnF3nbYjMtBEFpT4o8pfp
	OsVlGzq7TDPd1+CXZUR8ile+WhC+BGcQvI8zvHPu32XFU90Nz3f5orpHGb7n
	vyU6fH2hIP30kYNrS/X206V6hZ9BwwTdJGkqb8VTYGbk34nnXh1t49Qyukgq
	Qw7/FUUGRdGPXsEWFOoCsH/EcNT9XS14r/3oHFsyCQ6NXHE/uiupReAyKVZ5
	tsRwzPVzkjYP/egmqz4l6udGz3K9hCLgR37vwxudjZJ+dEUX0e+0GZdVjj/P
	02Su7qiNBk9SpF6oD9m0bCrdfJasAj/wYVWMH7SKbMSRVVwg1kv3Bjy6akqC
	cenE5zWMUVmtoujXX21Da6Xn5WOLlehl4YiWapIPqYUtgjJ0wuUPGvPbbww7
	/+h15FGsrq+GP1qSPLMH33jwmB6EMpbY5PmlfZpawu4spU1BLyfnkmu3YY3T
	Zknavk+vLZV+a9EjWvRHeidV/b30HnKX3OX3PvaCH1tT2G89dMBMbVui1Mcf
	31yoidbpiDXnj5/ep6d/sIPFfXbl+1sT7PHycnEcS8vIgXpb2rdgtC7ZlgSp
	fvGYpQ29g1dukIZLGHml+lYyz1PKHq8r9rcf7pDo1/wfMr6WaIBfAAA=
	</rfc>		</rfc>
End of changes. 77 change blocks.
	1201 lines changed or deleted		658 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/