rfc9470.original.xml		rfc9470.xml
	<?xml version='1.0' encoding='utf-8'?>		<?xml version="1.0" encoding="UTF-8"?>
	<!DOCTYPE rfc [		<!DOCTYPE rfc [
	<!ENTITY nbsp "&#160;">		<!ENTITY nbsp "&#160;">
	<!ENTITY zwsp "&#8203;">		<!ENTITY zwsp "&#8203;">
	<!ENTITY nbhy "&#8209;">		<!ENTITY nbhy "&#8209;">
	<!ENTITY wj "&#8288;">		<!ENTITY wj "&#8288;">
	]>		]>
	<!-- name="GENERATOR" content="github.com/mmarkdown/mmark Mmark Markdown Process
	or - mmark.miek.nl" -->		<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" ipr="trust200902" do
	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" ipr="trust200902" do		cName="draft-ietf-oauth-step-up-authn-challenge-17" number="9470" submissionType
	cName="draft-ietf-oauth-step-up-authn-challenge-17" submissionType="IETF" catego		="IETF" category="std" consensus="true" tocInclude="true" symRefs="true" updates
	ry="std" xml:lang="en" consensus="true">		="" obsoletes="" xml:lang="en" sortRefs="true">
	<front>		<front>
	<title abbrev="OAuth Authn Challenge">OAuth 2.0 Step-up Authentication Challenge		<title abbrev="OAuth Auth Challenge">OAuth 2.0 Step Up Authentication Challeng
	Protocol</title><seriesInfo value="draft-ietf-oauth-step-up-authn-challenge-17"		e Protocol</title>
	stream="IETF" status="standard" name="Internet-Draft"/>		<seriesInfo name="RFC" value="9470"/>
	<author initials="V." surname="Bertocci" fullname="Vittorio Bertocci"><organizat		<author initials="V." surname="Bertocci" fullname="Vittorio Bertocci">
	ion>Auth0/Okta</organization><address><postal><street/>		<organization>Auth0/Okta</organization><address>
	</postal><email>vittorio@auth0.com</email>		<email>vittorio@auth0.com</email>
	</address></author>		</address></author>
	<author initials="B." surname="Campbell" fullname="Brian Campbell"><organization
	>Ping Identity</organization><address><postal><street/>		<author initials="B." surname="Campbell" fullname="Brian Campbell">
	</postal><email>bcampbell@pingidentity.com</email>		<organization>Ping Identity</organization><address>
	</address></author>		<email>bcampbell@pingidentity.com</email>
	<date/>		</address></author>
	<area>Security</area>		<date year="2023" month="August"/>
	<workgroup>Web Authorization Protocol</workgroup>
	<keyword>security</keyword>		<area>sec</area>
	<keyword>oauth2</keyword>		<workgroup>oauth</workgroup>
	<keyword>openid connect</keyword>
	<keyword>oauth</keyword>		<keyword>security</keyword>
	<keyword>step-up</keyword>		<keyword>oauth2</keyword>
			<keyword>openid connect</keyword>
			<keyword>oauth</keyword>
			<keyword>step up</keyword>
	<abstract>		<abstract>
	<t>It is not uncommon for resource servers to require different authentication s trengths or recentness according to the characteristics of a request. This docum ent introduces a mechanism for a resource server to signal to a client that the authentication event associated with the access token of the current request doe s not meet its authentication requirements and specify how to meet them.		<t>It is not uncommon for resource servers to require different authentication s trengths or recentness according to the characteristics of a request. This docum ent introduces a mechanism that resource servers can use to signal to a client t hat the authentication event associated with the access token of the current req uest does not meet its authentication requirements and, further, how to meet the m.
	This document also codifies a mechanism for a client to request that an authoriz ation server achieve a specific authentication strength or recentness when proce ssing an authorization request.</t>		This document also codifies a mechanism for a client to request that an authoriz ation server achieve a specific authentication strength or recentness when proce ssing an authorization request.</t>
	</abstract>		</abstract>
	<note title="Discussion Venues" removeInRFC="true">		<note title="Discussion Venues" removeInRFC="true">
	<t>Discussion of this document takes place on the		<t>Discussion of this document takes place on the
	Web Authorization Protocol Working Group mailing list (oauth@ietf.org),		Web Authorization Protocol Working Group mailing list (oauth@ietf.org),
	which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/ oauth/"/>.</t>		which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/ oauth/"/>.</t>
	<t>Source for this draft can be found at		<t>Source for this draft can be found at
	<eref target="https://github.com/oauth-wg/oauth-step-up-authn-challenge"/>.< /t>		<eref target="https://github.com/oauth-wg/oauth-step-up-authn-challenge"/>.< /t>
	</note>		</note>
	</front>		</front>
	<middle>		<middle>
	<section anchor="Introduction"><name>Introduction</name>		<section anchor="Introduction"><name>Introduction</name>
	<t>In simple API authorization scenarios, an authorization server will determine		<t>In simple API authorization scenarios, an authorization server will determine
	what authentication technique to use to handle a given request on the basis of		what authentication technique to use to handle a given request on the basis of
	aspects such as the scopes requested, the resource, the identity of the client a		aspects such as the scopes requested, the resource, the identity of the client,
	nd other characteristics known at provisioning time.		and other characteristics known at provisioning time.
	Although the approach is viable in many situations, it falls short in several im		Although that approach is viable in many situations, it falls short in several i
	portant circumstances. Consider, for instance, an eCommerce API requiring differ		mportant circumstances. Consider, for instance, an eCommerce API requiring diffe
	ent authentication strengths depending on whether the item being purchased excee		rent authentication strengths depending on whether the item being purchased exce
	ds a certain threshold, dynamically estimated by the API itself using a logic th		eds a certain threshold, dynamically estimated by the API itself using a logic t
	at is opaque to the authorization server.		hat is opaque to the authorization server.
	An API might also determine that a more recent user authentication is required based on its own risk evaluation of the API request.</t>		An API might also determine that a more recent user authentication is required based on its own risk evaluation of the API request.</t>
	<t>This document extends the error codes collection defined by <xref target="RFC		<t>This document extends the collection of error codes defined by <xref target="
	6750"/> with a new value, <tt>insufficient_user_authentication</tt>, which can b		RFC6750"/> with a new value, <tt>insufficient_user_authentication</tt>, which ca
	e used by resource servers to signal to the client that the authentication event		n be used by resource servers to signal to the client that the authentication ev
	associated with the access token presented with the request does not meet the a		ent associated with the access token presented with the request does not meet th
	uthentication requirements of the resource server.		e authentication requirements of the resource server.
	This document also introduces <tt>acr_values</tt> and <tt>max_age</tt> parameter		This document also introduces <tt>acr_values</tt> and <tt>max_age</tt> parameter
	s for the <tt>Bearer</tt> authentication scheme challenge defined by <xref targe		s for the <tt>Bearer</tt> authentication scheme challenge defined by <xref targe
	t="RFC6750"/>, which the resource server can use to explicitly communicate to th		t="RFC6750"/>. The resource server can use these parameters to explicitly commu
	e client the required authentication strength or recentness.</t>		nicate to the client the required authentication strength or recentness.</t>
	<t>The client can use that information to reach back to the authorization server		<t>The client can use that information to reach back to the authorization server
	with an authorization request specifying the authentication requirements indica		with an authorization request that specifies the authentication requirements in
	ted by protected resource, by including the <tt>acr_values</tt> or <tt>max_age</		dicated by the protected resource. This is accomplished by including the <tt>a
	tt> authorization request parameters as defined in <xref target="OIDC"/>.</t>		cr_values</tt> or <tt>max_age</tt> authorization request parameters as defined i
	<t>Those extensions will make it possible to implement interoperable step up aut		n <xref target="OIDC"/>.</t>
	hentication with minimal work from resource servers, clients and authorization s		<t>Those extensions will make it possible to implement interoperable step up aut
	ervers.</t>		hentication with minimal work from resource servers, clients, and authorization
			servers.</t>
	<section anchor="conventions-and-terminology"><name>Conventions and Terminology< /name>		<section anchor="conventions-and-terminology"><name>Conventions and Terminology< /name>
	<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",		<t>
	"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this		The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
	document are to be interpreted as described in BCP 14 <xref target="RFC2119"/> <		"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
	xref target="RFC8174"/>		NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
	when, and only when, they appear in all capitals, as shown here.</t>		"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
	<t>This specification uses the terms "access token", "authorization server", "au		"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
	thorization endpoint", "authorization request", "client", "protected resource",		to be interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/>
	and "resource server" defined by The OAuth 2.0 Authorization Framework <xref tar		<xref target="RFC8174"/> when, and only when, they appear in all capitals,
	get="RFC6749"/>.</t>		as shown here.
			</t>
			<t>This specification uses the terms "access token", "authorization server", "au
			thorization endpoint", "authorization request", "client", "protected resource",
			and "resource server" defined by "<xref target="RFC6749" format="title"/>" <xref
			target="RFC6749"/>.</t>
	</section>		</section>
	</section>		</section>
	<section anchor="protocol-overview"><name>Protocol Overview</name>		<section anchor="protocol-overview"><name>Protocol Overview</name>
	<t>The following is an end-to-end sequence of a typical step-up authentication s cenario implemented according to this specification.		<t>The following is an end-to-end sequence of a typical step up authentication s cenario implemented according to this specification.
	The scenario assumes that, before the sequence described below takes place, the client already obtained an access token for the protected resource.</t>		The scenario assumes that, before the sequence described below takes place, the client already obtained an access token for the protected resource.</t>
	<figure anchor="abstract-flow"><name>Abstract protocol flow </name>
	<artwork>+----------+ +--------------+		<figure anchor="abstract-flow"><name>Abstract Protocol Flow </name>
			<artwork name="" type="" align="left" alt=""><![CDATA[
			+----------+ +--------------+
	| | | |		| | | |
	| |-----------(1) request ------------------&gt;| |		| |-----------(1) request ------------------>| |
	| | | |		| | | |
	| |&lt;---------(2) challenge ------------------| Resource |		| |<---------(2) challenge ------------------| Resource |
	| | | Server |		| | | Server |
	| Client | | |		| Client | | |
	| |-----------(5) request ------------------&gt;| |		| |-----------(5) request ------------------>| |
	| | | |		| | | |
	| |&lt;-----(6) protected resource -------------| |		| |<-----(6) protected resource -------------| |
	| | +--------------+		| | +--------------+
	| |		| |
	| |		| |
	| | +-------+ +---------------+		| | +-------+ +---------------+
	| |-&gt;| | | |		| |->| | | |
	| | | |--(3) authorization request--&gt;| |		| | | |--(3) authorization request-->| |
	| | | User | | |		| | | User | | |
	| | | Agent |<-----------[...]------------&gt;| Authorization |		| | | Agent |<-----------[...]------------&gt;| Authorization |
	| | | | | Server |		| | | | | Server |
	| |&lt;-| | | |		| |<-| | | |
	| | +-------+ | |		| | +-------+ | |
	| | | |		| | | |
	| |&lt;-------- (4) access token --------------| |		| |<-------- (4) access token --------------| |
	| | | |		| | | |
	+----------+ +---------------+		+----------+ +---------------+
	</artwork>		]]></artwork>
	</figure>		</figure>
	<ol>		<ol spacing="normal">
	<li>The client requests a protected resource, presenting an access token.</li>		<li>The client requests a protected resource, presenting an access token.</li>
	<li>The resource server determines that the circumstances in which the presented access token was obtained offer insufficient authentication strength and/or rec entness, hence it denies the request and returns a challenge describing (using a combination of <tt>acr_values</tt> and <tt>max_age</tt>) what authentication re quirements must be met for the resource server to authorize a request.</li>		<li>The resource server determines that the circumstances in which the presented access token was obtained offer insufficient authentication strength and/or rec entness; hence, it denies the request and returns a challenge describing (using a combination of <tt>acr_values</tt> and <tt>max_age</tt>) what authentication r equirements must be met for the resource server to authorize a request.</li>
	<li>The client directs the user agent to the authorization server with an author ization request that includes the <tt>acr_values</tt> and/or <tt>max_age</tt> in dicated by the resource server in the previous step.</li>		<li>The client directs the user agent to the authorization server with an author ization request that includes the <tt>acr_values</tt> and/or <tt>max_age</tt> in dicated by the resource server in the previous step.</li>
	<li>After whatever sequence required by the grant of choice plays out, which wil l include the necessary steps to authenticate the user in accordance with the <t t>acr_values</tt> and/or <tt>max_age</tt> values of the authorization request, t he authorization server returns a new access token to the client. The access tok en contains or references information about the authentication event.</li>		<li>Whatever sequence required by the grant of choice plays out; this will inclu de the necessary steps to authenticate the user in accordance with the <tt>acr_v alues</tt> and/or <tt>max_age</tt> values of the authorization request. Then, t he authorization server returns a new access token to the client. The new access token contains or references information about the authentication event.</li>
	<li>The client repeats the request from step 1, presenting the newly obtained ac cess token.</li>		<li>The client repeats the request from step 1, presenting the newly obtained ac cess token.</li>
	<li>The resource server finds that the user authentication performed during the acquisition of the new access token complies with its requirements, and returns the representation of the requested protected resource.</li>		<li>The resource server finds that the user authentication performed during the acquisition of the new access token complies with its requirements and returns t he representation of the requested protected resource.</li>
	</ol>		</ol>
	<t>The validation operations mentioned in step 2 and 6 imply that the resource s		<t>The validation operations mentioned in steps 2 and 6 imply that the resource
	erver has a way of evaluating the authentication that occurred during the proces		server has a way of evaluating the authentication that occurred during the proce
	s by which the access token was obtained. In the context of this document, the a		ss by which the access token was obtained. In the context of this document, the
	ssessment by the resource server of the specific authentication method used to o		assessment by the resource server of the specific authentication method used to
	btain a token for the requested resource is called an "authentication level." Th		obtain a token for the requested resource is called an "authentication level". T
	is document will describe how the resource server can perform this assessment of		his document will describe how the resource server can perform this assessment o
	an "authentication level" when the access token is a JWT Access token <xref tar		f an authentication level when the access token is a JSON Web Token (JWT) <xref
	get="RFC9068"/> or is validated via introspection <xref target="RFC7662"/>. Othe		target="RFC9068"/> or is validated via introspection <xref target="RFC7662"/>. O
	r methods of determining the authentication level by which the access token was		ther methods of determining the authentication level by which the access token w
	obtained are possible, per agreement by the authorization server and the protect		as obtained are possible, per agreement by the authorization server and the prot
	ed resource, but are beyond the scope of this specification. Given an authentica		ected resource, but they are beyond the scope of this specification. Given an au
	tion level of a token, the resource server determines whether it meets the secur		thentication level of a token, the resource server determines whether it meets t
	ity criteria for the requested resource.</t>		he security criteria for the requested resource.</t>
	<t>"Authentication level" and "step-up" are metaphors in this specification. The		<t>The terms "authentication level" and "step up" are metaphors in this specific
	se metaphors do not suggest that there is an absolute hierarchy of authenticatio		ation. These metaphors do not suggest that there is an absolute hierarchy of aut
	n methods expressed in interoperable fashion. The notion of a level emerges from		hentication methods expressed in interoperable fashion. The notion of a level em
	the fact that the resource server may only want to accept certain authenticatio		erges from the fact that the resource server may only want to accept certain aut
	n methods. When presented with a token derived from a particular authentication		hentication methods. When presented with a token derived from a particular authe
	method (i.e., a given authentication level) that it does not want to accept (i.e		ntication method (i.e., a given authentication level) that it does not want to a
	., below the threshold or level it will accept), the resource server seeks to "s		ccept (i.e., below the threshold or level it will accept), the resource server s
	tep-up" (i.e., renegotiate) from the current authentication level to one that it		eeks to step up (i.e., renegotiate) from the current authentication level to one
	may accept. The "step-up" metaphor is intended to convey a shift from the origi		that it may accept. The "step up" metaphor is intended to convey a shift from t
	nal authentication level to one that is acceptable to the resource server.</t>		he original authentication level to one that is acceptable to the resource serve
	<t>Although the case in which the new access token supersedes old tokens by virt		r.</t>
	ue of a higher authentication level is common, in line with the intuition the te		<t>Although the case in which the new access token supersedes old tokens by
	rm "step-up authentication" suggests, it is important to keep in mind that this		virtue of a higher authentication level is common, in line with the connotation
	might not necessarily hold true in the general case. For example: a resource ser		of the term "step up authentication", it is important to keep in mind
	ver might require for a particular request a higher authentication level and a s		that this might not necessarily hold true in the general case. For example, for
	horter validity, resulting in a token suitable for one-off calls but leading to		a particular request, a
	frequent prompts, hence a suboptimal user experience, if reused for routine oper		resource server might require a higher authentication
	ations. In those scenarios, the client would be better served by keeping both th		level and a shorter validity, resulting in a token suitable for one-off calls
	e old tokens, associated with a lower authentication level, and the new one - se		but leading to frequent prompts: hence, offering a suboptimal user experience if
	lecting the appropriate token for each API call. This is not a new requirement f		the token is reused
	or clients, as incremental consent and least privilege principles will require s		for routine operations. In such a scenario, the client would be better served
	imilar heuristics for managing access tokens associated to different scopes and		by keeping both the old tokens, which are associated with a lower authentication
	permission levels. This document does not recommend any specific token caching s		level,
	trategy, as that will be dependent on the characteristics of every particular sc		and the new one: selecting the appropriate token for each API call. This is
	enario and remains application-dependent as in the core OAuth cases.		not a new requirement for clients, as incremental consent and least-privilege
	Also recall that OAuth 2.0 <xref target="RFC6749"/> assumes access tokens are tr		principles will require similar heuristics for managing access tokens
	eated as opaque by clients. The token format might be unreadable to the client o		associated with different scopes and permission levels. This document does not
	r might change at any time to become unreadable. So, during the course of any to		recommend any specific token-caching strategy: that choice will be dependent on
	ken caching strategy, a client must not attempt to inspect the content of the ac		the characteristics of every particular scenario and remains
	cess token to determine the associated authentication information or other detai		application-dependent as in the core OAuth cases. Also recall that OAuth 2.0
	ls (see Section 6 of <xref target="RFC9068"/> for a more detailed discussion).</		<xref target="RFC6749"/> assumes access tokens are treated as opaque by
	t>		clients. The token format might be unreadable to the client or might change at
			any time to become unreadable. So, during the course of any token-caching
			strategy, a client must not attempt to inspect the content of the access token
			to determine the associated authentication information or other details (see
			<xref target="RFC9068" sectionFormat="of" section="6"/> for a more detailed
			discussion).</t>
	</section>		</section>
	<section anchor="Challenge"><name>Authentication Requirements Challenge</name>		<section anchor="Challenge"><name>Authentication Requirements Challenge</name>
	<t>This specification introduces a new error code value for the <tt>error</tt> p arameter of the challenge of the <tt>Bearer</tt> authentication scheme from <xre f target="RFC6750"/> and other OAuth authentication schemes, such as <xref targe t="I-D.ietf-oauth-dpop"/>, which use the same <tt>error</tt> parameter:</t>
	<dl>		<t>This specification introduces a new error code value for the challenge of the
	<dt><tt>insufficient_user_authentication</tt></dt>		<tt>Bearer</tt> authentication scheme's <tt>error</tt> parameter (from <xref ta
			rget="RFC6750"/>) and other OAuth authentication schemes, such as those seen in
			<xref target="RFC9449"/>, which use the same <tt>error</tt> parameter:</t>
			<dl spacing="normal">
			<dt><tt>insufficient_user_authentication</tt>:</dt>
	<dd>The authentication event associated with the access token presented with the request does not meet the authentication requirements of the protected resource .</dd>		<dd>The authentication event associated with the access token presented with the request does not meet the authentication requirements of the protected resource .</dd>
	</dl>		</dl>
	<t>Note: the logic through which the resource server determines that the current
	request does not meet the authentication requirements of the protected resource		<t>Note: the logic through which the resource server determines that the current
	, and associated functionality (such as expressing, deploying and publishing suc		request does not meet the authentication requirements of the protected resource
	h requirements) is out of scope for this document.</t>		, and associated functionality (such as expressing, deploying and publishing suc
			h requirements), is out of scope for this document.</t>
	<t>Furthermore, this specification defines the following <tt>WWW-Authenticate</t t> auth-param values for those OAuth authentication schemes to convey the authen tication requirements back to the client.</t>		<t>Furthermore, this specification defines the following <tt>WWW-Authenticate</t t> auth-param values for those OAuth authentication schemes to convey the authen tication requirements back to the client.</t>
	<dl>		<dl spacing="normal">
	<dt><tt>acr_values</tt></dt>		<dt><tt>acr_values</tt>:</dt>
	<dd>A space-separated string listing the authentication context class reference
	values, in order of preference, one of which the protected resource requires for		<dd>A space-separated string listing the authentication context class reference
	the authentication event associated with the access token. The authentication c		values in order of preference. The protected resource requires one of these valu
	ontext, as defined in section 1.2 of <xref target="OIDC"/> conveys information a		es for the authentication event associated with the access token. As defined in
	bout how authentication takes place (e.g., what authentication method(s) or assu		Section 1.2 of <xref target="OIDC"/>, the authentication context conveys informa
	rance level to meet).</dd>		tion about how authentication takes place (e.g., what authentication method(s) o
	<dt><tt>max_age</tt></dt>		r assurance level to meet).</dd>
	<dd>Indicates the allowable elapsed time in seconds since the last active authen		<dt><tt>max_age</tt>:</dt>
	tication event associated with the access token. An active authentication event		<dd>This value indicates the allowable elapsed time in seconds since the last ac
	entails a user interacting with the authorization server in response to an authe		tive authentication event associated with the access token. An active authentica
	ntication prompt. Note that while the auth-param value can be conveyed as a toke		tion event entails a user interacting with the authorization server in response
	n or quoted-string (see section 11.2 of <xref target="RFC9110"/>), it has to rep		to an authentication prompt. Note that, while the auth-param value can be convey
	resent a non-negative integer.</dd>		ed as a token or quoted-string (see <xref target="RFC9110" sectionFormat="of" se
			ction="11.2"/>), it has to represent a non-negative integer.</dd>
	</dl>		</dl>
	<t><xref target="acr-challenge"/> below is an example of a <tt>Bearer</tt> authe		<t><xref target="acr-challenge"/> is an example of a <tt>Bearer</tt> authenticat
	ntication scheme challenge with the <tt>WWW-Authenticate</tt> header using the <		ion scheme challenge with the <tt>WWW-Authenticate</tt> header using:</t>
	tt>insufficient_user_authentication</tt> error code value to inform the client t		<ul><li>
	hat the access token presented is not sufficient to gain access to the protected		the <tt>insufficient_user_authentication</tt> error code value to inform the c
	resource, and the <tt>acr_values</tt> parameter to let the client know that the		lient that the access token presented is not sufficient to gain access to the pr
	expected authentication level corresponds to the authentication context class r		otected resource, and</li>
	eference identified by <tt>myACR</tt>.</t>		<li>the <tt>acr_values</tt> parameter to let the client know that the expected
			authentication level corresponds to the authentication context class reference
			identified by <tt>myACR</tt>.</li></ul>
	<t>Note that while this specification only defines usage of the above auth-param s with the <tt>insufficient_user_authentication</tt> error code, it does not pre clude future specifications or profiles from defining their usage with other err or codes.</t>		<t>Note that while this specification only defines usage of the above auth-param s with the <tt>insufficient_user_authentication</tt> error code, it does not pre clude future specifications or profiles from defining their usage with other err or codes.</t>
	<figure anchor="acr-challenge"><name>Authentication Requirements Challenge indic
	ating <tt>acr_values</tt> </name>		<figure anchor="acr-challenge">
	<artwork>HTTP/1.1 401 Unauthorized		<name>Authentication Requirements Challenge Indicating <tt>acr_values</tt> </nam
			e>
			<sourcecode type="http-message"><![CDATA[HTTP/1.1 401 Unauthorized
	WWW-Authenticate: Bearer error="insufficient_user_authentication",		WWW-Authenticate: Bearer error="insufficient_user_authentication",
	error_description="A different authentication level is required",		error_description="A different authentication level is required",
	acr_values="myACR"		acr_values="myACR"
	</artwork>		]]></sourcecode>
	</figure>		</figure>
	<t>The following example in <xref target="age-challenge"/> shows a challenge inf
	orming the client that last active authentication event associated with the pres		<t>The example in <xref target="age-challenge"/> shows a challenge informing the
	ented access token is too old and a more recent authentication is needed.</t>		client that the last active authentication event associated with the presented
	<figure anchor="age-challenge"><name>Authentication Requirements Challenge indic		access token is too old and a more recent authentication is needed.</t>
	ating <tt>max_age</tt> </name>
	<artwork>HTTP/1.1 401 Unauthorized		<figure anchor="age-challenge">
			<name>Authentication Requirements Challenge Indicating <tt>max_age</tt> </name>
			<sourcecode type="http-message"><![CDATA[HTTP/1.1 401 Unauthorized
	WWW-Authenticate: Bearer error="insufficient_user_authentication",		WWW-Authenticate: Bearer error="insufficient_user_authentication",
	error_description="More recent authentication is required",		error_description="More recent authentication is required",
	max_age="5"		max_age="5"
	</artwork>		]]></sourcecode>
	</figure>		</figure>
	<t>The auth-params <tt>max_age</tt> and <tt>acr_values</tt> MAY both occur in th
	e same challenge if the resource server needs to express requirements both about		<t>The auth-params <tt>max_age</tt> and <tt>acr_values</tt> <bcp14>MAY</bcp14> b
	recency and authentication levels.		oth occur in the same challenge if the resource server needs to express requirem
	If the resource server determines that the request is also lacking the scopes re		ents about both recency and authentication level.
	quired by the requested resource, it MAY include the <tt>scope</tt> attribute wi		If the resource server determines that the request is also lacking the scopes re
	th the scope necessary to access the protected resource, as described in section		quired by the requested resource, it <bcp14>MAY</bcp14> include the <tt>scope</t
	3.1 of <xref target="RFC6750"/>.</t>		t> attribute with the value necessary to access the protected resource, as descr
			ibed in <xref target="RFC6750" sectionFormat="of" section="3.1"/>.</t>
	</section>		</section>
	<section anchor="authorization-request"><name>Authorization Request</name>		<section anchor="authorization-request"><name>Authorization Request</name>
	<t>A client receiving a challenge from the resource server carrying the error co		<t>A client receiving a challenge from the resource server carrying the <tt>insu
	de <tt>insufficient_user_authentication</tt> SHOULD parse the <tt>WWW-Authentica		fficient_user_authentication</tt> error code <bcp14>SHOULD</bcp14> parse the <tt
	te</tt> header for <tt>acr_values</tt> and <tt>max_age</tt> and use them, if pr		>WWW-Authenticate</tt> header for <tt>acr_values</tt> and <tt>max_age</tt> and
	esent, in constructing an authorization request, which is then conveyed to the a		use them, if present, in constructing an authorization request. This request is
	uthorization server's authorization endpoint via the user agent in order to obta		then conveyed to the authorization server's authorization endpoint via the user
	in a new access token complying with the corresponding requirements.		agent in order to obtain a new access token complying with the corresponding req
	Both <tt>acr_values</tt> and <tt>max_age</tt> authorization request parameters a		uirements.
	re OPTIONAL parameters defined in Section 3.1.2.1. of <xref target="OIDC"/>. Thi		The <tt>acr_values</tt> and <tt>max_age</tt> authorization request parameters ar
	s document does not introduce any changes in the authorization server behavior d		e both <bcp14>OPTIONAL</bcp14> parameters defined in Section 3.1.2.1. of <xref t
	efined in <xref target="OIDC"/> for processing those parameters, hence any autho		arget="OIDC"/>. This document does not introduce any changes in the authorizatio
	rization server implementing OpenID Connect will be able to participate in the f		n server behavior defined in <xref target="OIDC"/> for processing those paramete
	low described here with little or no changes. See <xref target="AuthzResp"/> for		rs; hence, any authorization server implementing OpenID Connect will be able to
	more details.</t>		participate in the flow described here with little or no changes. See <xref targ
			et="AuthzResp"/> for more details.</t>
	<t>The example authorization request URI below, which might be used after receiv ing the challenge in <xref target="acr-challenge"/>, indicates to the authorizat ion server that the client would like the authentication to occur according to t he authentication context class reference identified by <tt>myACR</tt>.</t>		<t>The example authorization request URI below, which might be used after receiv ing the challenge in <xref target="acr-challenge"/>, indicates to the authorizat ion server that the client would like the authentication to occur according to t he authentication context class reference identified by <tt>myACR</tt>.</t>
	<figure><name>Authorization Request indicating <tt>acr_values</tt>		<figure><name>Authorization Request Indicating <tt>acr_values</tt>
	</name>		</name>
	<artwork>https://as.example.net/authorize?client_id=s6BhdRkqt3		<artwork><![CDATA[https://as.example.net/authorize?client_id=s6BhdRkqt3
	&amp;response_type=code&amp;scope=purchase&amp;acr_values=myACR		&response_type=code&scope=purchase&acr_values=myACR
	</artwork>		]]></artwork>
	</figure>		</figure>
	<t>After the challenge in <xref target="age-challenge"/>, a client might direct		<t>After the challenge in <xref target="age-challenge"/>, a client might direct
	the user agent to the following example authorization request URI where the <tt>		the user agent to the following example authorization request URI where the <tt>
	max_age</tt> parameter indicates to the authorization server that the user authe		max_age</tt> parameter indicates to the authorization server that the user-authe
	ntication event needs to have occurred no more than five seconds prior.</t>		ntication event needs to have occurred no more than five seconds prior.</t>
	<figure><name>Authorization Request indicating <tt>max_age</tt>		<figure><name>Authorization Request Indicating <tt>max_age</tt>
	</name>		</name>
	<artwork>https://as.example.net/authorize?client_id=s6BhdRkqt3		<artwork><![CDATA[https://as.example.net/authorize?client_id=s6BhdRkqt3
	&amp;response_type=code&amp;scope=purchase&amp;max_age=5		&response_type=code&scope=purchase&max_age=5
	</artwork>		]]></artwork>
	</figure>		</figure>
	</section>		</section>
	<section anchor="AuthzResp"><name>Authorization Response</name>		<section anchor="AuthzResp"><name>Authorization Response</name>
	<t>Section 5.5.1.1 of <xref target="OIDC"/> establishes that an authorization s
	erver receiving a request containing the <tt>acr_values</tt> parameter MAY attem		<t>Section 5.5.1.1 of <xref target="OIDC"/> establishes that an authorization s
	pt to authenticate the user in a manner that satisfies the requested Authenticat		erver receiving a request containing the <tt>acr_values</tt> parameter <bcp14>MA
	ion Context Class Reference, and include the corresponding value in the <tt>acr<		Y</bcp14> attempt to authenticate the user in a manner that satisfies the reques
	/tt> claim in the resulting ID Token. The same section also establishes that in		ted authentication context class reference and include the corresponding value i
	case the desired authentication level cannot be met, the authorization server SH		n the <tt>acr</tt> claim in the resulting ID Token. The same section also establ
	OULD include in the <tt>acr</tt> claim a value reflecting the authentication lev		ishes that, in case the desired authentication level cannot be met, the authoriz
	el of the current session (if any). Furthermore, Section 3.1.2.1 <xref target="O		ation server <bcp14>SHOULD</bcp14> include a value reflecting the authentication
	IDC"/> states that if a request includes the <tt>max_age</tt> parameter, the aut		level of the current session (if any) in the <tt>acr</tt> claim. Furthermore, S
	horization server MUST include the <tt>auth_time</tt> claim in the issued ID Tok		ection 3.1.2.1 <xref target="OIDC"/> states that if a request includes the <tt>m
	en.		ax_age</tt> parameter, the authorization server <bcp14>MUST</bcp14> include the
			<tt>auth_time</tt> claim in the issued ID Token.
	An authorization server complying with this specification will react to the pres ence of the <tt>acr_values</tt> and <tt>max_age</tt> parameters by including <tt >acr</tt> and <tt>auth_time</tt> in the access token (see <xref target="authn-in fo-in-at"/> for details).		An authorization server complying with this specification will react to the pres ence of the <tt>acr_values</tt> and <tt>max_age</tt> parameters by including <tt >acr</tt> and <tt>auth_time</tt> in the access token (see <xref target="authn-in fo-in-at"/> for details).
	Although <xref target="OIDC"/> leaves the authorization server free to decide ho		Although <xref target="OIDC"/> leaves the authorization server free to decide ho
	w to handle the inclusion of <tt>acr</tt> in the ID Token when requested via <tt		w to handle the inclusion of <tt>acr</tt> in the ID Token when requested via <tt
	>acr_values</tt>, when it comes to access tokens in this specification, the auth		>acr_values</tt>, when it comes to access tokens in this specification, the auth
	orization server SHOULD consider the requested acr value as necessary for succes		orization server <bcp14>SHOULD</bcp14> consider the requested acr value as neces
	sfully fulfilling the request. That is, the requested <tt>acr</tt> value is incl		sary for successfully fulfilling the request. That is, the requested <tt>acr</t
	uded in the access token if the authentication operation successfully met its re		t> value is included in the access token if the authentication operation success
	quirements, or that the authorization request fails in all other cases, returnin		fully met its requirements; otherwise,
	g <tt>unmet_authentication_requirements</tt> as defined in <xref target="OIDCUAR		the authorization request fails and returns an <tt>unmet_authentication_requirem
	"/>. The recommended behavior will help prevent clients getting stuck in a loop		ents</tt> error as defined in <xref target="OIDCUAR"/>. The recommended behavior
	where the authorization server keeps returning tokens that the resource server a		will help prevent clients getting stuck in a loop where the authorization serve
	lready identified as not meeting its requirements hence known to be rejected as		r keeps returning tokens that the resource server already identified as not meet
	well.</t>		ing its requirements.</t>
	</section>		</section>
	<section anchor="authn-info-in-at"><name>Authentication Information Conveyed via Access Token</name>		<section anchor="authn-info-in-at"><name>Authentication Information Conveyed via Access Token</name>
	<t>To evaluate whether an access token meets the protected resource's requiremen		<t>To evaluate whether an access token meets the protected resource's requiremen
	ts, the resource server needs a way of accessing information about the authentic		ts, the resource server needs a way of accessing information about the authentic
	ation event by which that access token was obtained. This specification provides		ation event by which that access token was obtained. This specification provides
	guidance on how to convey that information in conjunction with two common acces		guidance on how to convey that information in conjunction with two common acces
	s token validation methods: the one described in <xref target="RFC9068"/>, where		s-token-validation methods:</t>
	the access token is encoded in JWT format and verified via a set of validation		<ul>
	rules, and the one described in <xref target="RFC7662"/>, where the token is val		<li>the one described in <xref target="RFC9068"/>, where the access token is e
	idated and decoded by sending it to an introspection endpoint.		ncoded in JWT format and verified via a set of validation rules, and</li>
	Authorization servers and resource servers MAY elect to use other encoding and v		<li> the one described in <xref target="RFC7662"/>, where the token is validat
	alidation methods, however those are out of scope for this document.</t>		ed and decoded by sending it to an introspection endpoint.</li></ul>
			<t>Authorization servers and resource servers <bcp14>MAY</bcp14> elect to use ot
			her encoding and validation methods; however, those are out of scope for this do
			cument.</t>
	<section anchor="jwt-access-tokens"><name>JWT Access Tokens</name>		<section anchor="jwt-access-tokens"><name>JWT Access Tokens</name>
	<t>When access tokens are represented as JSON Web Tokens (JWT) <xref target="RFC
	7519"/>, the <tt>auth_time</tt> and <tt>acr</tt> claims (per Section 2.2.1 of <x		<t>When access tokens are represented as JSON Web Tokens (JWTs) <xref target="RF
	ref target="RFC9068"/>) are used to convey the time and context of the user auth		C7519"/>, the <tt>auth_time</tt> and <tt>acr</tt> claims (per <xref target="RFC9
	entication event that the authentication server performed during the course of o		068" sectionFormat="of" section="2.2.1"/>) are used to convey the time and conte
	btaining the access token. It is useful to bear in mind that the values of those		xt of the user-authentication event that the authentication server performed dur
	two parameters are established at user authentication time and will not change		ing the course of obtaining the access token. It is useful to bear in mind that
	in the event of access token renewals. See the aforementioned Section 2.2.1 of <		the values of those two parameters are established at user-authentication time a
	xref target="RFC9068"/> for details. The following is a conceptual example showi		nd will not change in the event of access token renewals. See the aforementioned
	ng the decoded content of such a JWT access token.</t>		<xref target="RFC9068" sectionFormat="of" section="2.2.1"/> for details. The fo
			llowing is a conceptual example showing the decoded content of such a JWT access
			token.</t>
	<figure>		<figure>
	<artwork>Header:		<name>Decoded JWT Access Token</name>
			<sourcecode type="json"><![CDATA[Header:
	{"typ":"at+JWT","alg":"ES256","kid":"LTacESbw"}		{"typ":"at+JWT","alg":"ES256","kid":"LTacESbw"}
	Claims:		Claims:
	{		{
	"iss": "https://as.example.net",		"iss": "https://as.example.net",
	"sub": "someone@example.net",		"sub": "someone@example.net",
	"aud": "https://rs.example.com",		"aud": "https://rs.example.com",
	"exp": 1646343000,		"exp": 1646343000,
	"iat": 1646340200,		"iat": 1646340200,
	"jti" : "e1j3V_bKic8-LAEB_lccD0G",		"jti" : "e1j3V_bKic8-LAEB_lccD0G",
	"client_id": "s6BhdRkqt3",		"client_id": "s6BhdRkqt3",
	"scope": "purchase",		"scope": "purchase",
	"auth_time": 1646340198,		"auth_time": 1646340198,
	"acr": "myACR"		"acr": "myACR"
	}		}
	</artwork>		]]></sourcecode>
	</figure>		</figure>
	</section>		</section>
	<section anchor="introspect"><name>OAuth 2.0 Token Introspection</name>		<section anchor="introspect"><name>OAuth 2.0 Token Introspection</name>
	<t>OAuth 2.0 Token Introspection <xref target="RFC7662"/> defines a method for a		<t>"<xref target="RFC7662" format="title"/>" <xref target="RFC7662"/> defines a
	protected resource to query an authorization server about the active state of a		method for a protected resource to query an authorization server about the activ
	n access token as well as to determine metainformation about the token.		e state of an access token as well as to determine metainformation about the tok
	The following two top-level introspection response members are defined to convey		en.
	information about the user authentication event that the authentication server		The following two top-level introspection response members are defined to convey
	performed during the course of obtaining the access token.</t>		information about the user-authentication event that the authentication server
			performed during the course of obtaining the access token.</t>
	<dl>		<dl spacing="normal">
	<dt><tt>acr</tt></dt>		<dt><tt>acr</tt>:</dt>
	<dd>Authentication Context Class Reference. String specifying an Authentication		<dd>String specifying an authentication context class reference value that ident
	Context Class Reference value that identifies the Authentication Context Class t		ifies the authentication context class that was satisfied by the user-authentica
	hat the user authentication performed satisfied.</dd>		tion event performed.</dd>
	<dt><tt>auth_time</tt></dt>		<dt><tt>auth_time</tt>:</dt>
	<dd>Time when the user authentication occurred. A JSON numeric value representin		<dd>Time when the user authentication occurred. A JSON numeric value representin
	g the number of seconds from 1970-01-01T00:00:00Z UTC until the time of date/tim		g the number of seconds from 1970-01-01T00:00:00Z UTC until the date/time of the
	e of the authentication event.</dd>		authentication event.</dd>
	</dl>		</dl>
	<t>The following example shows an introspection response with information about		<t>The following example shows an introspection response with information about
	the user authentication event by which the access token was obtained.</t>		the user-authentication event by which the access token was obtained.</t>
	<figure>		<figure>
	<artwork>HTTP/1.1 200 OK		<name>Introspection Response</name>
			<sourcecode type="http-message"><![CDATA[HTTP/1.1 200 OK
	Content-Type: application/json		Content-Type: application/json
	{		{
	"active": true,		"active": true,
	"client_id": "s6BhdRkqt3",		"client_id": "s6BhdRkqt3",
	"scope": "purchase",		"scope": "purchase",
	"sub": "someone@example.net",		"sub": "someone@example.net",
	"aud": "https://rs.example.com",		"aud": "https://rs.example.com",
	"iss": "https://as.example.net",		"iss": "https://as.example.net",
	"exp": 1639528912,		"exp": 1639528912,
	"iat": 1618354090,		"iat": 1618354090,
	"auth_time": 1646340198,		"auth_time": 1646340198,
	"acr": "myACR"		"acr": "myACR"
	}		}
	</artwork>		]]></sourcecode>
	</figure>		</figure>
	</section>		</section>
	</section>		</section>
	<section anchor="ASMetadata"><name>Authorization Server Metadata</name>		<section anchor="ASMetadata"><name>Authorization Server Metadata</name>
	<t>Authorization Servers can advertise their support of this specification by in cluding in their metadata document (as defined in <xref target="RFC8414"/>) the value <tt>acr_values_supported</tt> as defined in section 3 of <xref target="OID CDISC"/>. The presence of <tt>acr_values_supported</tt> in the authorization ser ver metadata document signals that the authorization server will understand and honor the <tt>acr_values</tt> and <tt>max_age</tt> parameters in incoming author ization requests.</t>		<t>Authorization servers can advertise their support of this specification by in cluding in their metadata document, as defined in <xref target="RFC8414"/>, the value <tt>acr_values_supported</tt>, as defined in Section 3 of <xref target="OI DCDISC"/>. The presence of <tt>acr_values_supported</tt> in the authorization se rver metadata document signals that the authorization server will understand and honor the <tt>acr_values</tt> and <tt>max_age</tt> parameters in incoming autho rization requests.</t>
	</section>		</section>
	<section anchor="Deployment"><name>Deployment Considerations</name>		<section anchor="Deployment"><name>Deployment Considerations</name>
	<t>This specification facilitates the communication of requirements from a resou
	rce server to a client, which in turn can enable a smooth step-up authentication		<t>This specification facilitates the communication of requirements from a resou
	experience. However, it is important to realize that the user experience achiev		rce server to a client, which, in turn, can enable a smooth step up authenticati
	able in every specific deployment is a function of the policies each resource se		on experience. However, it is important to realize that the user experience achi
	rver and authorization server pairs establish. Imposing constraints on those pol		evable in every specific deployment is a function of the policies each resource
	icies is out of scope for this specification, hence it is perfectly possible for		server and authorization server pair establishes. Imposing constraints on those
	resource servers and authorization servers to impose requirements that are impo		policies is out of scope for this specification; hence, it is perfectly possible
	ssible for users to comply with, or leading to an undesirable user experience ou		for resource servers and authorization servers to impose requirements that are
	tcome.		impossible for users to comply with or that lead to an undesirable user-experien
	The authentication prompts presented by the authorization server as a result of		ce outcome.
	the method of propagating authentication requirements described here might requi		The authentication prompts presented by the authorization server as a result of
	re the user to perform some specific actions such as using multiple devices, hav		the method of propagating authentication requirements described here might requi
	ing access to devices complying with specific security requirements, and so on.		re the user to perform some specific actions such as using multiple devices, hav
	Those extra requirements, concerning more about how to comply with a particular		ing access to devices complying with specific security requirements, and so on.
	requirement rather than indicating the identifier of the requirement itself, are		Those extra requirements, that are more concerned with how to comply with a part
	out of scope for this specification.</t>		icular requirement rather than indicating the identifier of the requirement itse
			lf, are out of scope for this specification.</t>
	</section>		</section>
	<section anchor="Security"><name>Security Considerations</name>		<section anchor="Security"><name>Security Considerations</name>
	<t>This specification adds to previously defined OAuth mechanisms. Their respec		<t>This specification adds to previously defined OAuth mechanisms. Their respec
	tive Security Considerations apply - OAuth 2.0 <xref target="RFC6749"/>, JWT acc		tive security considerations apply:</t>
	ess tokens <xref target="RFC9068"/>, Bearer WWW-Authentication <xref target="RFC
	6750"/>, token introspection <xref target="RFC7662"/>, and authorization server		<ul>
	metadata <xref target="RFC8414"/>.</t>		<li>OAuth 2.0 <xref target="RFC6749"/>,</li>
	<t>This document MUST NOT be used to position OAuth as an authentication protoco		<li>JWT access tokens <xref target="RFC9068"/>,</li>
	l. For the purposes of this specification, the way in which a user authenticated		<li>Bearer <tt>WWW-Authenticate</tt> <xref target="RFC6750"/>,</li>
	with the authorization server to obtain an access token is salient information,		<li>token introspection <xref target="RFC7662"/>, and</li>
	as a resource server might decide whether to grant access on the basis of how t		<li>authorization server metadata <xref target="RFC8414"/>.</li></ul>
	hat authentication operation was performed. Nonetheless, this specification does		<t>This document <bcp14>MUST NOT</bcp14> be used to position OAuth as an authent
	not attempt to define the mechanics by which authentication takes place, relyin		ication protocol. For the purposes of this specification, the way in which a use
	g on a separate authentication layer to take care of the details. In line with o		r authenticated with the authorization server to obtain an access token is salie
	ther specifications of the OAuth family, this document assumes the existence of		nt information, as a resource server might decide whether to grant access on the
	a session without going into the details of how it is established or maintained,		basis of how that authentication operation was performed. Nonetheless, this spe
	what protocols are used to implement that layer (e.g., OpenID Connect), and so		cification does not attempt to define the mechanics by which authentication take
	forth.		s place, relying on a separate authentication layer to take care of the details.
			In line with other specifications of the OAuth family, this document assumes th
			e existence of a session without going into the details of how it is established
			or maintained, what protocols are used to implement that layer (e.g., OpenID Co
			nnect), and so forth.
	Depending on the policies adopted by the resource server, the <tt>acr_values</tt > parameter introduced in <xref target="Challenge"/> might unintentionally discl ose information about the authenticated user, the resource itself, the authoriza tion server, and any other context-specific data that an attacker might use to g ain knowledge about their target.		Depending on the policies adopted by the resource server, the <tt>acr_values</tt > parameter introduced in <xref target="Challenge"/> might unintentionally discl ose information about the authenticated user, the resource itself, the authoriza tion server, and any other context-specific data that an attacker might use to g ain knowledge about their target.
	For example, a resource server requesting an acr value corresponding to a high l evel of assurance for some users but not others might identify possible high pri vilege users to target with spearhead phishing attacks.		For example, a resource server requesting an acr value corresponding to a high l evel of assurance for some users but not others might identify possible high-pri vilege users to target with spearhead phishing attacks.
	Implementers should use care in determining what to disclose in the challenge an d in what circumstances.		Implementers should use care in determining what to disclose in the challenge an d in what circumstances.
	The logic examining the incoming access token to determine whether a challenge s		The logic examining the incoming access token to determine whether or not a chal
	hould be returned can execute either before or after the conventional token vali		lenge should be returned can be executed either before or after the conventional
	dation logic, be it based on JWT token validation, introspection, or any other m		token-validation logic, be it based on JWT validation, introspection, or any ot
	ethod. The resource server MAY return a challenge without verifying the client p		her method. The resource server <bcp14>MAY</bcp14> return a challenge without ve
	resented a valid token. However, this approach will leak the required properties		rifying the client presented a valid token. However, this approach will leak the
	of an authorization token to an actor who has not proven they can obtain a toke		required properties of an authorization token to an actor who has not proven th
	n for this resource server.</t>		ey can obtain a token for this resource server.</t>
	<t>As this specification provides a mechanism for the resource server to trigger		<t>As this specification provides a mechanism for the resource server to trigger
	user interaction, it's important for the authorization server and clients to co		user interaction, it's important for the authorization server and clients to co
	nsider that a malicious resource server might abuse of that feature.</t>		nsider that a malicious resource server might abuse that feature.</t>
	</section>		</section>
	<section anchor="IANA"><name>IANA Considerations</name>		<section anchor="IANA"><name>IANA Considerations</name>
	<section anchor="oauth-extensions-error-registration"><name>OAuth Extensions Err or Registration</name>		<section anchor="oauth-extensions-error-registration"><name>OAuth Extensions Err or Registration</name>
	<t>This specification requests registration of the following error value in the "OAuth Extensions Error" registry <xref target="IANA.OAuth.Params"/> established by <xref target="RFC6749"/>.</t>		<t>This specification registers the following error value in the "OAuth Extensio ns Error Registry" <xref target="IANA.OAuth.Params"/> established by <xref targe t="RFC6749"/>.</t>
	<ul>		<dl spacing="compact" newline="false">
	<li>Name: <tt>insufficient_user_authentication</tt></li>		<dt>Name:</dt>
	<li>Usage Location: resource access error response</li>		<dd><tt>insufficient_user_authentication</tt></dd>
	<li>Protocol Extension: OAuth 2.0 Step-up Authentication Challenge Protocol</li>		<dt>Usage Location:</dt>
	<li>Change controller: IETF</li>		<dd>resource access error response</dd>
	<li>Specification document(s): <xref target="Challenge"/> of [[ this specificati		<dt>Protocol Extension:</dt>
	on ]]</li>		<dd>OAuth 2.0 Step Up Authentication Challenge Protocol</dd>
	</ul>		<dt>Change controller:</dt>
			<dd>IETF</dd>
			<dt>Specification document(s):</dt>
			<dd><xref target="Challenge"/> of RFC 9470</dd>
			</dl>
	</section>		</section>
	<section anchor="oauth-token-introspection-response-registration"><name>OAuth To ken Introspection Response Registration</name>		<section anchor="oauth-token-introspection-response-registration"><name>OAuth To ken Introspection Response Registration</name>
	<t>This specification requests registration of the following values in the "OAut h Token Introspection Response" registry <xref target="IANA.OAuth.Params"/> esta blished by <xref target="RFC7662"/>.</t>		<t>This specification registers the following values in the "OAuth Token Introsp ection Response" registry <xref target="IANA.OAuth.Params"/> established by <xre f target="RFC7662"/>.</t>
	<t>Authentication Context Class Reference:</t>		<t>Authentication Context Class Reference:</t>
	<ul>		<dl spacing="compact" newline="false">
	<li>Name: <tt>acr</tt></li>		<dt>Name:</dt>
	<li>Description: Authentication Context Class Reference</li>		<dd><tt>acr</tt></dd>
	<li>Change Controller: IETF</li>		<dt>Description:</dt>
	<li>Specification Document(s): <xref target="introspect"/> of [[ this specificat		<dd>Authentication Context Class Reference</dd>
	ion ]]</li>		<dt>Change Controller:</dt>
	</ul>		<dd>IETF</dd>
			<dt>Specification Document(s):</dt>
			<dd><xref target="introspect"/> of RFC 9470</dd>
			</dl>
	<t>Authentication Time:</t>		<t>Authentication Time:</t>
	<ul>		<dl spacing="compact" newline="false">
	<li>Name: <tt>auth_time</tt></li>		<dt>Name:</dt>
	<li>Description: Time when the user authentication occurred</li>		<dd><tt>auth_time</tt></dd>
	<li>Change Controller: IETF</li>		<dt>Description:</dt>
	<li>Specification Document(s): <xref target="introspect"/> of [[ this specificat		<dd>Time when the user authentication occurred</dd>
	ion ]]</li>		<dt>Change Controller:</dt>
	</ul>		<dd>IETF</dd>
			<dt>Specification Document(s):</dt>
			<dd><xref target="introspect"/> of RFC 9470</dd>
			</dl>
	</section>		</section>
	</section>		</section>
	</middle>		</middle>
	<back>		<back><references>
			<name>References</name>
	<references><name>Normative References</name>		<references><name>Normative References</name>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119. xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119. xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6749. xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6749. xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6750. xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6750. xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174. xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174. xml"/>
	</references>		</references>
	<references><name>Informative References</name>		<references><name>Informative References</name>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml-ids/reference.I-D.i
	etf-oauth-dpop.xml"/>		<!-- [I-D.ietf-oauth-dpop] in AUTH48 state as of 08/15/23; RFC 9449 -->
			<!--[rfced] Please note that we have updated the reference to
			draft-ietf-oauth-dpop-16 to instead point to its RFC-to-be number
			(as that document entered AUTH48 prior to this one). Note that
			if this document completes AUTH48 prior to
			draft-ietf-oauth-dpop-16, we can:
			1) revert the reference to point to the I-D, or
			2) hold publication until RFC 9449 completes AUTH48.
			Please let us know your preference.
			[rfced] Authors prefer to wait for 9449.
			-->
			<reference anchor="RFC9449" target="https://www.rfc-editor.org/info/rfc9449">
			<front>
			<title>OAuth 2.0 Demonstrating Proof of Possession at the Application Layer (DPo
			P)</title>
			<author initials='D' surname='Fett' fullname='Daniel Fett'>
			<organization />
			</author>
			<author initials='B' surname='Campbell' fullname='Brian Campbell'>
			<organization />
			</author>
			<author initials='J' surname='Bradley' fullname='John Bradley'>
			<organization />
			</author>
			<author initials='T' surname='Lodderstedt' fullname='Torsten Lodderstedt'>
			<organization />
			</author>
			<author initials='M' surname='Jones' fullname='Michael Jones'>
			<organization />
			</author>
			<author initials='D' surname='Waite' fullname='David Waite'>
			<organization />
			</author>
			<date year='2023' month='August'/>
			</front>
			<seriesInfo name="RFC" value="9449"/>
			<seriesInfo name="DOI" value="10.17487/RFC9449"/>
			</reference>
	<reference anchor="IANA.OAuth.Params" target="https://www.iana.org/assignments/o auth-parameters">		<reference anchor="IANA.OAuth.Params" target="https://www.iana.org/assignments/o auth-parameters">
	<front>		<front>
	<title>OAuth Parameters</title>		<title>OAuth Parameters</title>
	<author>		<author>
	<organization>IANA</organization>		<organization>IANA</organization>
	</author>		</author>
	<date/>		<date/>
	</front>		</front>
	</reference>		</reference>
	<reference anchor="OIDC" target="https://openid.net/specs/openid-connect-core-1_ 0.html">		<reference anchor="OIDC" target="https://openid.net/specs/openid-connect-core-1_ 0.html">
	<front>		<front>
	<title>OpenID Connect Core 1.0 incorporating errata set 1</title>		<title>OpenID Connect Core 1.0 incorporating errata set 1</title>
	<author fullname="Nat Sakimura" initials="N." surname="Sakimura">		<author fullname="Nat Sakimura" initials="N." surname="Sakimura">
	<organization>NRI</organization>		<organization>NRI</organization>
	</author>		</author>
	<author fullname="John Bradley" initials="J." surname="Bradley">		<author fullname="John Bradley" initials="J." surname="Bradley">
	<organization>Ping Identity</organization>		<organization>Ping Identity</organization>
	</author>		</author>
	<author fullname="Mike Jones" initials="M." surname="Jones">		<author fullname="Mike Jones" initials="M." surname="Jones">
	skipping to change at line 326 ¶		skipping to change at line 451 ¶
	</author>		</author>
	<author fullname="Breno de Medeiros" initials="B." surname="de Medeiros">		<author fullname="Breno de Medeiros" initials="B." surname="de Medeiros">
	<organization>Google</organization>		<organization>Google</organization>
	</author>		</author>
	<author fullname="Chuck Mortimore" initials="C." surname="Mortimore">		<author fullname="Chuck Mortimore" initials="C." surname="Mortimore">
	<organization>Salesforce</organization>		<organization>Salesforce</organization>
	</author>		</author>
	<date year="2014" month="Nov" day="8"/>		<date year="2014" month="Nov" day="8"/>
	</front>		</front>
	</reference>		</reference>
	<reference anchor="OIDCDISC" target="https://openid.net/specs/openid-connect-dis covery-1_0.html">		<reference anchor="OIDCDISC" target="https://openid.net/specs/openid-connect-dis covery-1_0.html">
	<front>		<front>
	<title>OpenID Connect Core 1.0 incorporating errata set 1</title>		<title>OpenID Connect Discovery 1.0 incorporating errata set 1</title>
	<author fullname="Nat Sakimura" initials="N." surname="Sakimura">		<author fullname="Nat Sakimura" initials="N." surname="Sakimura">
	<organization>NRI</organization>		<organization>NRI</organization>
	</author>		</author>
	<author fullname="John Bradley" initials="J." surname="Bradley">		<author fullname="John Bradley" initials="J." surname="Bradley">
	<organization>Ping Identity</organization>		<organization>Ping Identity</organization>
	</author>		</author>
	<author fullname="Mike Jones" initials="M." surname="Jones">		<author fullname="Mike Jones" initials="M." surname="Jones">
	<organization>Microsoft</organization>		<organization>Microsoft</organization>
	</author>		</author>
	<author fullname="Edmund Jay" initials="E." surname="Jay">		<author fullname="Edmund Jay" initials="E." surname="Jay">
	skipping to change at line 344 ¶		skipping to change at line 470 ¶
	</author>		</author>
	<author fullname="Mike Jones" initials="M." surname="Jones">		<author fullname="Mike Jones" initials="M." surname="Jones">
	<organization>Microsoft</organization>		<organization>Microsoft</organization>
	</author>		</author>
	<author fullname="Edmund Jay" initials="E." surname="Jay">		<author fullname="Edmund Jay" initials="E." surname="Jay">
	<organization>Illumila</organization>		<organization>Illumila</organization>
	</author>		</author>
	<date year="2014" month="Nov" day="8"/>		<date year="2014" month="Nov" day="8"/>
	</front>		</front>
	</reference>		</reference>
	<reference anchor="OIDCUAR" target="https://openid.net/specs/openid-connect-unme t-authentication-requirements-1_0.html">		<reference anchor="OIDCUAR" target="https://openid.net/specs/openid-connect-unme t-authentication-requirements-1_0.html">
	<front>		<front>
	<title>OpenID Connect Core Error Code unmet_authentication_requirements</tit le>		<title>OpenID Connect Core Error Code unmet_authentication_requirements</tit le>
	<author fullname="Torsten Lodderstedt" initials="T." surname="Lodderstedt">		<author fullname="Torsten Lodderstedt" initials="T." surname="Lodderstedt">
	<organization>YES</organization>		<organization>YES</organization>
	</author>		</author>
	<date year="2019" month="May" day="8"/>		<date year="2019" month="May" day="8"/>
	</front>		</front>
	</reference>		</reference>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7519. xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7519. xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7662. xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7662. xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8414. xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8414. xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9068. xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9068. xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9110. xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9110. xml"/>
	</references>		</references>
			</references>
	<section anchor="Acknowledgements"><name>Acknowledgements</name>		<section anchor="Acknowledgements" numbered="false"><name>Acknowledgements</name
	<t>I wanted to thank the Academy, the viewers at home, the shampoo manufacturers		>
	, etc..</t>		<t>I wanted to thank the Academy, the viewers at home, the shampoo manufacturers
	<t>This specification was developed within the OAuth Working Group under		, etc.</t>
	the chairpersonship of Rifaat Shekh-Yusef and Hannes Tschofenig with		<t>This specification was developed within the OAuth Working Group under the
	Paul Wouters, and Roman Danyliw serving as Security		chairpersonship of <contact fullname="Rifaat Shekh-Yusef"/> and <contact
	Area Directors. Additionally, the following individuals contributed		fullname="Hannes Tschofenig"/> with <contact fullname="Paul Wouters"/> and
	ideas, feedback, corrections, and wording that helped shape this specification:		<contact fullname="Roman Danyliw"/> serving as Security Area
	Caleb Baker,		Directors. Additionally, the following individuals contributed ideas,
	Ivan Kanakarakis,		feedback, corrections, and wording that helped shape this specification:
	Pieter Kasselman,		<contact fullname="Caleb Baker"/>, <contact fullname="Ivan Kanakarakis"/>,
	Aaron Parecki,		<contact fullname="Pieter Kasselman"/>, <contact fullname="Aaron Parecki"/>,
	Denis Pinkas,		<contact fullname="Denis Pinkas"/>, <contact fullname="Dima Postnikov"/>, and
	Dima Postnikov,		<contact fullname="Filip Skokan"/>.</t>
	and		<t>Some early discussion of the motivations and concepts that precipitated the
	Filip Skokan.</t>		initial draft version of this document occurred at the 2021 OAuth Security
	<t>Some early discussion of the motivations and concepts that precipitated the i		Workshop. The authors thank the organizers of the workshop (<contact
	nitial version		fullname="Guido Schmitz"/>, <contact fullname="Steinar Noem"/>, and <contact
	of this document occurred at the 2021 OAuth Security Workshop. The authors thank		fullname="Daniel Fett"/>) for hosting an event that is conducive to
	the organizers of the
	workshop (Guido Schmitz, Steinar Noem, and Daniel Fett) for hosting an event tha
	t is conducive to
	collaboration and community input.</t>		collaboration and community input.</t>
	</section>		</section>
	<section anchor="document-history"><name>Document History</name>
	<t>[[ To be removed from the final specification ]]</t>
	<t>-17</t>
	<ul>
	<li>Fix mistake in -16 update</li>
	</ul>
	<t>-16</t>
	<ul>
	<li>AD suggested editorial updates</li>
	</ul>
	<t>-15</t>
	<ul>
	<li>Editorial updates from IESG review/ballot</li>
	</ul>
	<t>-14</t>
	<ul>
	<li>Updates from Httpdir telechat review</li>
	</ul>
	<t>-13</t>
	<ul>
	<li>Make IETF the Change Controller for all registration requests per IANA sugge
	stion</li>
	<li>More updates from Genart review</li>
	<li>Updates from Artart review</li>
	<li>Updates from Secdir review</li>
	</ul>
	<t>-12</t>
	<ul>
	<li>Updates from Genart Last Call review</li>
	</ul>
	<t>-11</t>
	<ul>
	<li>Updates in the Protocol Overview section clarifying the nature of "authentic
	ation levels" and caching strategies, addressing AD review comments</li>
	</ul>
	<t>-10</t>
	<ul>
	<li>Fix two references where the section numbers got lost presumably due to tool
	ing issues</li>
	</ul>
	<t>-09</t>
	<ul>
	<li>Updates addressing AD review comments</li>
	</ul>
	<t>-07/-08</t>
	<ul>
	<li>Editorial updates addressing Shepherd Review comments</li>
	</ul>
	<t>-06</t>
	<ul>
	<li>Update examples/figures to be clear that the authorization request is sent b
	y the client via directing the user agent (not directly from client to AS)</li>
	</ul>
	<t>-05</t>
	<ul>
	<li>Forgotten Acknowledgements</li>
	<li>Minor updates to the updates in -04</li>
	</ul>
	<t>-04</t>
	<ul>
	<li>Editorial updates/notes from WGLC feedback</li>
	</ul>
	<t>-03</t>
	<ul>
	<li>Clarified that <tt>acr_values</tt> and <tt>max_age</tt> can co-occur in the
	challenge when necessary</li>
	<li>fleshed out deployment and security considerations</li>
	<li>fleshed out IANA considerations</li>
	<li>Attempt to clarify that while <tt>acr_values</tt> can request more than one
	value, only one of them is used and ends up in the token</li>
	</ul>
	<t>-02</t>
	<ul>
	<li>Fix typos introduced in -01</li>
	<li>Begin to fill out the Acknowledgements</li>
	</ul>
	<t>-01</t>
	<ul>
	<li>Added AS Metadata section with pointer to <tt>acr_values_supported</tt></li>
	<li>Mention that it's not necessarily the case that a new 'stepped-up' token alw
	ays supersedes older tokens</li>
	<li>Add examples with <tt>max_age</tt></li>
	</ul>
	<t>-00 (Working Group Draft)</t>
	<ul>
	<li>Initial WG revision (content unchanged from draft-bertocci-oauth-step-up-aut
	hn-challenge-01)</li>
	</ul>
	<t>-01 draft-bertocci-oauth-step-up-authn-challenge</t>
	<ul>
	<li>Fixed example</li>
	<li>Clarified/noted that scope can also be in the WWW-Authenticate/401</li>
	</ul>
	<t>-00 draft-bertocci-oauth-step-up-authn-challenge</t>
	<ul>
	<li>Initial Individual Draft (with all the authority thereby bestowed <eref targ
	et="https://datatracker.ietf.org/doc/html/draft-abr-twitter-reply">https://datat
	racker.ietf.org/doc/html/draft-abr-twitter-reply</eref>).</li>
	</ul>
	</section>
	</back>		</back>
	</rfc>		</rfc>
End of changes. 71 change blocks.
	473 lines changed or deleted		455 lines changed or added
This html diff was produced by rfcdiff 1.48.