rfc9767.original.xml		rfc9767.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;">
	]>		]>
	<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>		<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
	<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.5 (Ruby 3.3.0		-ietf-gnap-resource-servers-09" number="9767" updates="" obsoletes="" submission
	) -->		Type="IETF" category="std" consensus="true" tocInclude="true" sortRefs="true" sy
	<?rfc tocindent="yes"?>		mRefs="true" version="3" xml:lang="en">
	<?rfc strict="yes"?>
	<?rfc compact="yes"?>
	<?rfc comments="yes"?>
	<?rfc inline="yes"?>
	<?rfc docmapping="yes"?>
	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
	-ietf-gnap-resource-servers-09" category="std" consensus="true" tocInclude="true
	" sortRefs="true" symRefs="true" version="3">
	<!-- xml2rfc v2v3 conversion 3.20.1 -->
	<front>		<front>
	<title>Grant Negotiation and Authorization Protocol Resource Server Connecti		<title abbrev="GNAP RS Connections">Grant Negotiation and Authorization Prot
	ons</title>		ocol Resource Server Connections</title>
	<seriesInfo name="Internet-Draft" value="draft-ietf-gnap-resource-servers-09		<seriesInfo name="RFC" value="9767"/>
	"/>
	<author initials="J." surname="Richer" fullname="Justin Richer" role="editor ">		<author initials="J." surname="Richer" fullname="Justin Richer" role="editor ">
	<organization>Bespoke Engineering</organization>		<organization>Bespoke Engineering</organization>
	<address>		<address>
	<email>ietf@justin.richer.org</email>		<email>ietf@justin.richer.org</email>
	<uri>https://bspk.io/</uri>		<uri>https://bspk.io/</uri>
	</address>		</address>
	</author>		</author>
	<author initials="F." surname="Imbault" fullname="Fabien Imbault">		<author initials="F." surname="Imbault" fullname="Fabien Imbault">
	<organization>acert.io</organization>		<organization>acert.io</organization>
	<address>		<address>
	<email>fabien.imbault@acert.io</email>		<email>fabien.imbault@acert.io</email>
	<uri>https://acert.io/</uri>		<uri>https://acert.io/</uri>
	</address>		</address>
	</author>		</author>
	<date year="2024" month="September" day="23"/>		<date year="2025" month="April"/>
	<area>Security</area>		<area>SEC</area>
	<workgroup>GNAP</workgroup>		<workgroup>gnap</workgroup>
	<keyword>Internet-Draft</keyword>
	<abstract>
	<?line 63?>
	<t>GNAP defines a mechanism for delegating authorization to a piece of		<abstract>
	software (the client), and conveying the results and artifacts of that delegatio		<t>The Grant Negotiation and Authorization Protocol (GNAP) defines a mechanism f
	n		or delegating authorization to a piece of
	to the software.		software (the client) and conveying the results and artifacts of that delegation
	This extension defines methods for resource servers (RS) to connect		to the software. This extension defines methods for resource servers (RSs) to co
	with authorization servers (AS) in an interoperable fashion.</t>		nnect with authorization servers (ASs) in an interoperable fashion.</t>
	</abstract>		</abstract>
	</front>		</front>
	<middle>		<middle>
	<?line 71?>
	<section anchor="introduction">		<section anchor="introduction">
	<name>Introduction</name>		<name>Introduction</name>
	<t>The core GNAP specification (<xref target="GNAP"/>) defines distinct ro les for the authorization		<t>The core GNAP specification <xref target="RFC9635"/> defines distinct r oles for the authorization
	server (AS) and the resource server (RS). However, the core specification		server (AS) and the resource server (RS). However, the core specification
	does not define how the RS gets answers to important questions, such as whether		does not define how the RS gets answers to important questions, such as whether
	a given access token is still valid or what set of access rights the access		a given access token is still valid or what set of access rights the access
	token is approved for.</t>		token is approved for.</t>
	<t>While it's possible for the AS and RS to be tightly coupled, such as a single		<t>While it's possible for the AS and RS to be tightly coupled, such as a single
	deployed server with a shared storage system, GNAP does not presume or require		deployed server with a shared storage system, GNAP does not presume or require
	such a tight coupling. It is increasingly common for the AS and RS to be run		such a tight coupling. It is increasingly common for the AS and RS to be run
	and managed separately, particularly in cases where a single AS protects multipl e		and managed separately, particularly in cases where a single AS protects multipl e
	RS's simultaneously.</t>		RSs simultaneously.</t>
	<t>This specification defines a set of RS-facing APIs that an AS can make		<t>This specification defines a set of RS-facing APIs that an AS can make
	available for advanced loosely-coupled deployments. Additionally, this document		available for advanced loosely coupled deployments. Additionally, this document
	defines a general-purpose model for access tokens, which can be used in		defines a general-purpose model for access tokens, which can be used in
	structured, formatted access tokens or in token introspection responses.		structured, formatted access tokens or in token introspection responses.
	This specification also defines a method		This specification also defines a method
	for an RS to derive a downstream token for calling another chained RS.</t>		for an RS to derive a downstream token for calling another chained RS.</t>
	<t>The means of the authorization server issuing		<t>The means for the authorization server to issue the
	the access token to the client instance and the means of the client instance		access token to the client instance and the means for the client instance
	presenting the access token to the resource server are the subject of the		to present the access token to the resource server are subjects of the
	core GNAP specification <xref target="GNAP"/>.</t>		core GNAP specification <xref target="RFC9635"/>.</t>
	<section anchor="terminology">		<section anchor="terminology">
	<name>Terminology</name>		<name>Terminology</name>
	<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp 14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL		<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp 14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
	NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",		NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
	"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i nterpreted as		"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i nterpreted as
	described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they		described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
	appear in all capitals, as shown here.</t>		appear in all capitals, as shown here.</t>
	<?line -18?>		<?line -18?>
	<t>This document contains non-normative examples of partial and complete HTTP me		<t>This document contains non-normative examples of partial and complete
	ssages, JSON structures, URLs, query components, keys, and other elements. Some		HTTP messages, JSON structures, URLs, query components, keys, and other elements
	examples use a single trailing backslash <tt>\</tt> to indicate line wrapping fo		. Some examples use a single trailing backslash <tt>\</tt> to indicate line wrap
	r long values, as per <xref target="RFC8792"/>. The <tt>\</tt> character and lea		ping for long values, as per <xref target="RFC8792"/>. The <tt>\</tt> character
	ding spaces on wrapped lines are not part of the value.</t>		and leading spaces on wrapped lines are not part of the value.</t>
	<t>Terminology specific to GNAP is defined in the terminology section of
	the core specification <xref target="GNAP"/>, and provides definitions for the		<t>Terminology specific to GNAP is defined in the terminology
	protocol roles: authorization server (AS), client, resource server (RS), resourc		section of the core specification; see <xref
	e owner (RO), end user; as well as the protocol elements: attribute, access toke		target="RFC9635" sectionFormat="of" section="1.1"/>. The following proto
	n, grant, privilege, protected resource, right, subject, subject information. Th		col roles are defined:
	e same definitions are used in this document.</t>		authorization server, client, end user, resource owner, and resource ser
			ver. The following protocol
			elements are defined: access token, attribute, grant,
			privilege, protected resource, right, subject, and subject
			information. The same definitions are used in this
			document.</t>
	</section>		</section>
	</section>		</section>
	<section anchor="structure">		<section anchor="structure">
	<name>Access Tokens</name>		<name>Access Tokens</name>
	<t>Access tokens are a mechanism for an AS to provide a client instance li		<t>Access tokens are used as a mechanism for an AS to provide a
	mited access to an RS.		client instance limited access to an RS. These access tokens
	These access tokens are artifacts representing a particular set of access rights		are artifacts representing a particular set of access rights
	granted to		granted to the client instance to act on behalf of the RO. While
	the client instance to act on behalf of the RO. While the format of access token		the format of access tokens varies in different systems (see
	s varies in		discussion in <xref target="token-format"/>), the concept of an
	different systems (see discussion in <xref target="token-format"/>), the concept		access token is consistent across all GNAP systems.</t>
	of an access token is
	consistent across all GNAP systems.</t>
	<section anchor="general-purpose-access-token-model">		<section anchor="general-purpose-access-token-model">
	<name>General-purpose Access Token Model</name>		<name>General-Purpose Access Token Model</name>
	<t>The core GNAP specification <xref target="GNAP"/> focuses on the rela		<t>The core GNAP specification <xref target="RFC9635"/>
	tionship between the client and the AS. Since the access token		focuses on the relationship between the client and the
	is opaque to the client, the core specification does not define a token model. H		AS. Since the access token is opaque to the client, the core
	owever, the AS will need to create		specification does not define a token model. However, the AS
	tokens and the RS will need to understand tokens. To facilitate a level of struc		will need to create tokens, and the RS will need to understand
	tural interoperability, a common		tokens. To facilitate a level of structural interoperability,
	access token model is presented here.		a common access token model is presented here. Access tokens
	Access tokens represent a common set of aspects across different GNAP deployment		represent a common set of aspects across different GNAP
	s. This list is not intended to be		deployments. This list is not intended to be universal or
	universal or comprehensive, but rather serves as guidance to implementers in dev		comprehensive but rather serves as guidance to implementers in
	eloping		developing data structures and associated systems across a
	data structures and associated systems across a GNAP deployment. These data stru		GNAP deployment. These data structures are communicated
	ctures are communicated		between the AS and RS by using either a structured token or an
	between the AS and RS either by using a structured token or an API-like mechanis		API-like mechanism such as token introspection (see <xref
	m like token introspection (see <xref target="introspection"/>).</t>		target="introspection"/>).</t>
	<t>This general-purpose data model does not assume either approach, and		<t>This general-purpose data model does not assume either
	in fact both can be used together		approach; in fact, both approaches can be used together to
	to convey different pieces of information. Where possible, mappings to the <xref		convey different pieces of information. Where possible,
	target="JWT"/> standard format		mappings to the JSON Web Token (JWT) <xref target="RFC7519"/>
	are provided for each item in the model.</t>		standard format are provided for each item in the model.</t>
	<section anchor="value">		<section anchor="value">
	<name>Value</name>		<name>Value</name>
	<t>All access tokens have a <em>value</em>, which is the string that i s passed on the wire between parties.		<t>All access tokens have a <em>value</em>, which is the string that i s passed on the wire between parties.
	In order for different access tokens to be differentiated at runtime, the value of a token needs to be unique		In order for different access tokens to be differentiated at runtime, the value of a token needs to be unique
	within a security domain (such as all systems controlled by an AS). Otherwise, t		within a security domain (such as all systems controlled by an AS). Otherwise, t
	wo separate tokens would be		wo separate tokens would be confused for each other, which would lead to securit
	confused for each other which would lead to security issues.		y issues.
	The AS chooses the value, which can be structured as in <xref target="token-form		The AS chooses the value, which can be structured (see <xref target="token-forma
	at"/> or unstructured. When the token is		t"/>) or unstructured. When the token is
	structured, the token value also has a <em>format</em> known to the AS and RS, a nd the other items		structured, the token value also has a <em>format</em> known to the AS and RS, a nd the other items
	in this token model are contained within the token's value in some fashion.		in this token model are contained within the token's value in some fashion.
	When the token is unstructured, the values are usually retrieved by the RS using a service		When the token is unstructured, the values are usually retrieved by the RS using a service
	like token introspection described in <xref target="introspection"/>.</t>		such as token introspection described in <xref target="introspection"/>
	<t>The access token value is conveyed the <tt>value</tt> field of an <		.</t>
	tt>access_token</tt> response from <xref section="3.2" sectionFormat="of" target
	="GNAP"/>.</t>		<t>The access token value is conveyed in the <tt>value</tt> field of a
			n <tt>access_token</tt> response; see <xref section="3.2" sectionFormat="of" tar
			get="RFC9635"/>.</t>
	<t>The format and content of the access token value is opaque to the c lient software.		<t>The format and content of the access token value is opaque to the c lient software.
	While the client software needs to be able to carry and present the access token		While the client software needs to be able to carry and present the access token
	value, the client software is never expected nor intended to be able to understa nd		value, the client software is never expected nor intended to be able to understa nd
	the token value itself.</t>		the token value itself.</t>
	<t>If structured tokens like <xref target="JWT"/> are used, the value of the token might not be stored by the AS. Instead,		<t>If structured tokens like those in <xref target="RFC7519"/> are use d, the value of the token might not be stored by the AS. Instead,
	a token identifier can be used along with protection by an AS-generated signatur e to validate and		a token identifier can be used along with protection by an AS-generated signatur e to validate and
	identify an individual token.</t>		identify an individual token.</t>
	</section>		</section>
	<section anchor="issuer">		<section anchor="issuer">
	<name>Issuer</name>		<name>Issuer</name>
	<t>The access token is issued by the AS as defined by <xref target="GN AP"/>. The AS will		<t>The access token is issued by the AS as defined in <xref target="RF C9635"/>. The AS will
	need to identify itself in order to allow an RS to recognize tokens that the AS has issued, particularly		need to identify itself in order to allow an RS to recognize tokens that the AS has issued, particularly
	in cases where tokens from multiple different AS's could be presented to the sam		in cases where tokens from multiple different ASs could be presented to the same
	e RS.</t>		RS.</t>
	<t>This information is not usually conveyed directly to the client ins		<t>This information is not usually conveyed directly to the client instance, sin
	tance, since the client		ce the client instance should know this information based on where it receives t
	instance should know this information based on where it receives the token from.		he token from.</t>
	</t>
	<t>In a <xref target="JWT"/> formatted token or a token introspection		<t>In the payload of a JSON Web Token <xref target="RFC7519"/> or a to
	response, this corresponds to the <tt>iss</tt> claim.</t>		ken introspection response, this corresponds to the <tt>iss</tt> claim.</t>
	</section>		</section>
	<section anchor="audience">		<section anchor="audience">
	<name>Audience</name>		<name>Audience</name>
	<t>The access token is intended for use at one or more RS's. The AS ca		<t>The access token is intended for use at one or more RSs. The AS can
	n list a token's intended RS's		list a token's intended RSs to allow each RS to ensure that the RS is not recei
	to allow each RS to ensure that the RS is not receiving a token intended for som		ving a token intended for someone else.
	eone else.
	The AS and RS have to agree on the nature of any audience identifiers represente d by the token,		The AS and RS have to agree on the nature of any audience identifiers represente d by the token,
	but the URIs of the RS are a common pattern.</t>		but the URIs of the RS are a common pattern.</t>
	<t>In a <xref target="JWT"/> formatted token or token introspection re sponse, this corresponds to the <tt>aud</tt> claim.</t>		<t>In the payload of a JSON Web Token <xref target="RFC7519"/> or toke n introspection response, this corresponds to the <tt>aud</tt> claim.</t>
	<t>In cases where more complex access is required, the <tt>location</t t> field of objects in the <tt>access</tt>		<t>In cases where more complex access is required, the <tt>location</t t> field of objects in the <tt>access</tt>
	array can also convey audience information.		array can also convey audience information.
	In such cases, the client instance might need to know the audience information i n order to differentiate between		In such cases, the client instance might need to know the audience information i n order to differentiate between
	possible RS's to present the token to.</t>		possible RSs to present the token to.</t>
	</section>		</section>
	<section anchor="key-binding">		<section anchor="key-binding">
	<name>Key Binding</name>		<name>Key Binding</name>
	<t>Access tokens in GNAP are bound to the client instance's registered or presented key, except in		<t>Access tokens in GNAP are bound to the client instance's registered or presented key, except in
	cases where the access token is a bearer token. For all tokens bound to a key, t he AS and RS need to		cases where the access token is a bearer token. For all tokens bound to a key, t he AS and RS need to
	be able to identify which key the token is bound to, otherwise an attacker could substitute their		be able to identify which key the token is bound to; otherwise, an attacker coul d substitute their
	own key during presentation of the token. In the case of an asymmetric algorithm , the		own key during presentation of the token. In the case of an asymmetric algorithm , the
	AS and RS needs to know only the public key, while the client instance will also need to know the private		AS and RS need to know only the public key, while the client instance will also need to know the private
	key in order to present the token. In the case of a symmetric algorithm, all par ties		key in order to present the token. In the case of a symmetric algorithm, all par ties
	will need to either know or be able to derive the shared key.</t>		will need to either know or be able to derive the shared key.</t>
	<t>The source of this key information can vary depending on deployment decisions. For example, an AS		<t>The source of this key information can vary depending on deployment decisions. For example, an AS
	could decide that all tokens issued to a client instance are always bound to tha t client instance's current key.		could decide that all tokens issued to a client instance are always bound to tha t client instance's current key.
	When the key needs to be dereferenced, the AS looks up the client instance to wh ich the token was issued		When the key needs to be dereferenced, the AS looks up the client instance to wh ich the token was issued
	and finds the key information there.		and finds the key information there. Alternatively, the AS could bind each token
	The AS could alternatively bind each token to a specific key that is managed sep		to a specific key that is managed separately from client instance
	arately from client instance
	information. In such a case, the AS determines the key information directly. Thi s approach allows the client		information. In such a case, the AS determines the key information directly. Thi s approach allows the client
	instance to use a different key for each request, or allows the AS to issue a ke y for the client instance		instance to use a different key for each request or allows the AS to issue a key for the client instance
	to use with the particular token.</t>		to use with the particular token.</t>
	<t>In all cases, the key binding also includes a proofing mechanism, a long with any parameters needed for that		<t>In all cases, the key binding also includes a proofing mechanism, a long with any parameters needed for that
	mechanism such as a signing or digest algorithm. If such information is not incl uded with the proofing key, an attacker could		mechanism such as a signing or digest algorithm. If such information is not incl uded with the proofing key, an attacker could
	present a token with a seemingly-valid key using an insecure and incorrect proof		present a token with a seemingly valid key using an insecure and incorrect proof
	ing mechanism.</t>		ing mechanism.</t>
	<t>This value is conveyed to the client instance in the <tt>key</tt> f		<t>This value is conveyed to the client instance in the <tt>key</tt> f
	ield of the <tt>access_token</tt> response in <xref section="3.2" sectionFormat=		ield of the <tt>access_token</tt> response in <xref section="3.2" sectionFormat=
	"of" target="GNAP"/>.		"of" target="RFC9635"/>.
	Since the common case is that the token is bound to the client instance's regist ered key, this field can be omitted in this case		Since the common case is that the token is bound to the client instance's regist ered key, this field can be omitted in this case
	since the client will be aware of its own key.</t>		since the client will be aware of its own key.</t>
	<t>In a <xref target="JWT"/> formatted token, this corresponds to the		<t>In the payload of a JSON Web Token <xref target="RFC7519"/>, this c
	<tt>cnf</tt> (confirmation) claim. In a token introspection response, this corre		orresponds to the <tt>cnf</tt> (confirmation) claim. In a token introspection re
	sponds to the <tt>key</tt> claim.</t>		sponse, this corresponds to the <tt>key</tt> claim.</t>
	<t>In the case of a bearer token, all parties need to know that a toke		<t>In the case of a bearer token, all parties need to know that a toke
	n has no key bound to it, and will therefore		n has no key bound to it and will therefore reject any attempts to use the beare
	reject any attempts to use the bearer token with a key in an undefined way.</t>		r token with a key in an undefined way.</t>
	</section>		</section>
	<section anchor="flags">		<section anchor="flags">
	<name>Flags</name>		<name>Flags</name>
	<t>GNAP access tokens can have multiple data flags associated with the
	m that indicate special		<t>GNAP access tokens can have multiple associated data
	processing or considerations for the token. For example, whether the token is a		flags that indicate special processing or considerations for
	bearer token,		a token. For example, the data flags can indicate whether
	or should be expected to be durable across grant updates.</t>		a token is a bearer token or should be expected to be
	<t>The client can request a set of flags using the <tt>flags</tt> fiel		durable across grant updates.</t>
	d of the <tt>access_token</tt> grant request parameter in <xref section="2.1.1"		<t>The client can request a set of flags using the <tt>flags</tt> fiel
	sectionFormat="of" target="GNAP"/>.</t>		d of the <tt>access_token</tt> grant request parameter in <xref section="2.1.1"
	<t>These flags are conveyed from the AS to the client in the <tt>flags		sectionFormat="of" target="RFC9635"/>.</t>
	</tt> field of the <tt>access_token</tt> section of the grant response in <xref		<t>These flags are conveyed from the AS to the client in the <tt>flags
	section="3.2" sectionFormat="of" target="GNAP"/>.</t>		</tt> field of the <tt>access_token</tt> section of the grant response in <xref
			section="3.2" sectionFormat="of" target="RFC9635"/>.</t>
	<t>For token introspection, flags are returned in the <tt>flags</tt> f ield of the response.</t>		<t>For token introspection, flags are returned in the <tt>flags</tt> f ield of the response.</t>
	</section>		</section>
	<section anchor="access-rights">		<section anchor="access-rights">
	<name>Access Rights</name>		<name>Access Rights</name>
	<t>Access tokens are tied to a limited set of access rights. These rig hts specify in some detail what the token		<t>Access tokens are tied to a limited set of access rights. These rig hts specify in some detail what the token
	can be used for, how, and where. The internal structure of access rights are det ailed in <xref section="8" sectionFormat="of" target="GNAP"/>.</t>		can be used for, how it can be used, and where it can be used. The internal stru cture of access rights is detailed in <xref section="8" sectionFormat="of" targe t="RFC9635"/>.</t>
	<t>The access rights associated with an access token are calculated fr om the rights available to the client		<t>The access rights associated with an access token are calculated fr om the rights available to the client
	instance making the request, the rights available to be approved by the RO, the rights actually approved		instance making the request, the rights available to be approved by the RO, the rights actually approved
	by the RO, and the rights corresponding to the RS in question. The rights for a specific access token		by the RO, and the rights corresponding to the RS in question. The rights for a specific access token
	are a subset of the overall rights in a grant request.</t>		are a subset of the overall rights in a grant request.</t>
	<t>These rights are requested by the client instance in the <tt>access		<t>These rights are requested by the client instance in the <tt>access
	</tt> field of the <tt>access_token</tt> request in <xref section="2.1" sectionF		</tt> field of the <tt>access_token</tt> request; see <xref section="2.1" sectio
	ormat="of" target="GNAP"/>.</t>		nFormat="of" target="RFC9635"/>.</t>
	<t>The rights associated with an issued access token are conveyed to t		<t>The rights associated with an issued access token are conveyed to t
	he client instance in the <tt>access</tt> field of the <tt>access_token</tt> res		he client instance in the <tt>access</tt> field of the <tt>access_token</tt> res
	ponse in <xref section="3.2" sectionFormat="of" target="GNAP"/>.</t>		ponse in <xref section="3.2" sectionFormat="of" target="RFC9635"/>.</t>
	<t>In token introspection responses, this corresponds to the <tt>acces		<t>In token introspection responses, access rights correspond to the <
	s</tt> claim.</t>		tt>access</tt> claim.</t>
	</section>		</section>
	<section anchor="time-validity-window">		<section anchor="time-validity-window">
	<name>Time Validity Window</name>		<name>Time Validity Window</name>
	<t>The access token can be limited to a certain time window outside of which it is no longer		<t>The access token can be limited to a certain time window outside of which it is no longer
	valid for use at an RS. This window can be explicitly bounded by an expiration t ime and a		valid for use at an RS. This window can be explicitly bounded by an expiration t ime and a
	not-before time, or it could be calculated based on the issuance time of the tok en. For example,		not-before time, or it could be calculated based on the issuance time of the tok en. For example,
	an RS could decide that it will accept tokens for most calls within an hour of a token's		an RS could decide that it will accept tokens for most calls within an hour of a token's
	issuance, but only within five minutes of the token's issuance for certain high- value calls.</t>		issuance, but only within five minutes of the token's issuance for certain high- value calls.</t>
	<t>Since access tokens could be revoked at any time for any reason out side of a client instance's control,		<t>Since access tokens could be revoked at any time for any reason out side of a client instance's control,
	the client instance often does not know or concern itself with the validity time window of		the client instance often does not know or concern itself with the validity time window of
	an access token. However, this information can be made available to it using the		an access token. However, this information can be made available to it by using
	<tt>expires_in</tt> field		the <tt>expires_in</tt> field
	of an access token response in <xref section="3.2" sectionFormat="of" target="GN		of an access token response; see <xref section="3.2" sectionFormat="of" target="
	AP"/>.</t>		RFC9635"/>.</t>
	<t>The issuance time of the token is conveyed in the <tt>iat</tt> clai		<t>The issuance time of the token is conveyed in the <tt>iat</tt> clai
	m of a <xref target="JWT"/> formatted token or a token introspection response.</		m in the payload of a JSON Web Token <xref target="RFC7519"/> or a token introsp
	t>		ection response.</t>
	<t>The expiration time of a token, after which it is to be rejected, i		<t>The expiration time of a token, after which it is to be rejected, i
	s conveyed in the <tt>exp</tt> claim of a <xref target="JWT"/> formatted token o		s conveyed in the <tt>exp</tt> claim in the payload of a JSON Web Token <xref ta
	r a token introspection response.</t>		rget="RFC7519"/> or a token introspection response.</t>
	<t>The starting time of a token's validity window, before which it is		<t>The starting time of a token's validity window, before which it is
	to be rejected, is conveyed in the <tt>nbf</tt> claim of a <xref target="JWT"/>		to be rejected, is conveyed in the <tt>nbf</tt> claim in the payload of a JSON W
	formatted token or a token introspection response.</t>		eb Token <xref target="RFC7519"/> or a token introspection response.</t>
	</section>		</section>
	<section anchor="token-identifier">		<section anchor="token-identifier">
	<name>Token Identifier</name>		<name>Token Identifier</name>
	<t>Individual access tokens often need a unique internal identifier to allow the AS to differentiate		<t>Individual access tokens often need a unique internal identifier to allow the AS to differentiate
	between multiple separate tokens. This value of the token can often be used as t he		between multiple separate tokens. This value of the token can often be used as t he
	identifier, but in some cases a separate identifier is used.</t>		identifier, but in some cases, a separate identifier is used.</t>
	<t>This separate identifier can be conveyed in the <tt>jti</tt> claim		<t>This separate identifier can be conveyed in the <tt>jti</tt> claim
	of a <xref target="JWT"/> formatted token or a token introspection response.</t>		in the payload of a JSON Web Token <xref target="RFC7519"/> or a token introspec
	<t>This identifier is not usually exposed to the client instance using		tion response.</t>
	the token, since the client		<t>This identifier is not usually exposed to the client instance using
			the token, because the client
	instance only needs to use the token by value.</t>		instance only needs to use the token by value.</t>
	</section>		</section>
	<section anchor="authorizing-resource-owner">		<section anchor="authorizing-resource-owner">
	<name>Authorizing Resource Owner</name>		<name>Authorizing Resource Owner</name>
	<t>Access tokens are approved on behalf of a resource owner (RO). The identity of this RO can be used by		<t>Access tokens are approved on behalf of a resource owner (RO). The identity of this RO can be used by
	the RS to determine exactly which resource to access, or which kinds of access t o allow. For example,		the RS to determine exactly which resource to access or which kinds of access to allow. For example,
	an access token used to access identity information can hold a user identifier t o allow the RS to		an access token used to access identity information can hold a user identifier t o allow the RS to
	determine which profile information to return. The nature of this information is subject to agreement		determine which profile information to return. The nature of this information is subject to agreement
	by the AS and RS.</t>		by the AS and RS.</t>
	<t>This corresponds to the <tt>sub</tt> claim of a <xref target="JWT"/ > formatted token or a token introspection response.</t>		<t>This corresponds to the <tt>sub</tt> claim in the payload of a JSON Web Token <xref target="RFC7519"/> or a token introspection response.</t>
	<t>Detailed RO information is not returned to the client instance		<t>Detailed RO information is not returned to the client instance
	when an access token is requested alone, and in many cases returning		when an access token is requested alone, and in many cases, returning
	this information to the client instance would be a privacy violation on the part of the AS. Since the		this information to the client instance would be a privacy violation on the part of the AS. Since the
	access token represents a specific delegated access, the client instance needs o nly to use the token		access token represents a specific delegated access, the client instance needs o nly to use the token
	at its target RS. Following the profile example, the client instance does not ne ed to know		at its target RS. Following the profile example, the client instance does not ne ed to know
	the account identifier to get specific attributes about the account represented by the token.</t>		the account identifier to get specific attributes about the account represented by the token.</t>
	<t>GNAP does allow for the return of subject information separately fr om the access token, in the form		<t>GNAP does allow for the return of subject information separately fr om the access token, in the form
	of identifiers and assertions. These values are returned directly to the client separately from any		of identifiers and assertions. These values are returned directly to the client separately from any
	access tokens that are requested, though it's common that they represent the sam e party.</t>		access tokens that are requested, though it's common that they represent the sam e party.</t>
	</section>		</section>
	<section anchor="end-user">		<section anchor="end-user">
	<name>End User</name>		<name>End User</name>
	skipping to change at line 255 ¶		skipping to change at line 262 ¶
	The token model should be able to reflect these kinds of situations by represent ing the end user		The token model should be able to reflect these kinds of situations by represent ing the end user
	and RO separately.		and RO separately.
	For example, an end user can request a financial payment, but the RO is the hold er of the account		For example, an end user can request a financial payment, but the RO is the hold er of the account
	that the payment would be withdrawn from. The RO would be consulted for approval by the AS outside		that the payment would be withdrawn from. The RO would be consulted for approval by the AS outside
	of the flow of the GNAP request. A token in such circumstances would need to sho w both the		of the flow of the GNAP request. A token in such circumstances would need to sho w both the
	RO and end user as separate entities.</t>		RO and end user as separate entities.</t>
	</section>		</section>
	<section anchor="client-instance">		<section anchor="client-instance">
	<name>Client Instance</name>		<name>Client Instance</name>
	<t>Access tokens are issued to a specific client instance by the AS. T he identity of this instance can		<t>Access tokens are issued to a specific client instance by the AS. T he identity of this instance can
	be used by the RS to allow specific kinds of access, or other attributes about t he access token.		be used by the RS to allow specific kinds of access or other attributes about th e access token.
	For example, an AS that binds all access tokens issued to a particular client in stance to that		For example, an AS that binds all access tokens issued to a particular client in stance to that
	client instance's most recent key rotation would need to be able to look up the client instance		client instance's most recent key rotation would need to be able to look up the client instance
	in order to find the key binding detail.</t>		in order to find the key binding detail.</t>
	<t>This corresponds to the <tt>client_id</tt> claim of a <xref target= "JWT"/> formatted token or the <tt>instance_id</tt> field of a token introspecti on response.</t>		<t>This corresponds to the <tt>client_id</tt> claim in the payload of a JSON Web Token <xref target="RFC7519"/> or the <tt>instance_id</tt> field of a token introspection response.</t>
	<t>The client is not normally informed of this information separately, since a client instance can		<t>The client is not normally informed of this information separately, since a client instance can
	usually correctly assume that it is the client instance to which a token that		usually correctly assume that it is the client instance to which a token that
	it receives was issued.</t>		it receives was issued.</t>
	</section>		</section>
	<section anchor="label">		<section anchor="label">
	<name>Label</name>		<name>Label</name>
	<t>When multiple access tokens are requested or a client instance uses token labels, the parties		<t>When multiple access tokens are requested or a client instance uses token labels, the parties
	will need to keep track of which labels were applied to each individual token. S ince labels can		will need to keep track of which labels were applied to each individual token. S ince labels can
	be re-used across different grant requests, the token label alone is not suffici ent to		be reused across different grant requests, the token label alone is not sufficie nt to
	uniquely identify a given access token in a system. However, within the context of a grant		uniquely identify a given access token in a system. However, within the context of a grant
	request, these labels are required to be unique.</t>		request, these labels are required to be unique.</t>
	<t>A client instance can request a specific label using the <tt>label<		<t>A client instance can request a specific label using the <tt>label<
	/tt> field of an <tt>access_token</tt> request in <xref section="2.1" sectionFor		/tt> field of an <tt>access_token</tt> request; see <xref section="2.1" sectionF
	mat="of" target="GNAP"/>.</t>		ormat="of" target="RFC9635"/>.</t>
	<t>The AS can inform the client instance of a token's label using the		<t>The AS can inform the client instance of a token's label using the
	<tt>label</tt> field of an <tt>access_token</tt> response in <xref section="3.2"		<tt>label</tt> field of an <tt>access_token</tt> response; see <xref section="3.
	sectionFormat="of" target="GNAP"/>.</t>		2" sectionFormat="of" target="RFC9635"/>.</t>
	<t>This corresponds to the <tt>label</tt> field of a token introspecti on response.</t>		<t>This corresponds to the <tt>label</tt> field of a token introspecti on response.</t>
	</section>		</section>
	<section anchor="parent-grant-request">		<section anchor="parent-grant-request">
	<name>Parent Grant Request</name>		<name>Parent Grant Request</name>
	<t>All access tokens are issued in the context of a specific grant req uest from a client instance. The		<t>All access tokens are issued in the context of a specific grant req uest from a client instance. The
	grant request itself represents a unique tuple of:</t>		grant request itself represents a unique tuple of:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>		<li>
	<t>The AS processing the grant request</t>		<t>The AS processing the grant request</t>
	</li>		</li>
	<li>		<li>
	<t>The client instance making the grant request</t>		<t>The client instance making the grant request</t>
	</li>		</li>
	<li>		<li>
	<t>The RO (or set of RO's) approving the grant request (or needing to approve it)</t>		<t>The RO (or set of ROs) approving the grant request (or needing to approve it)</t>
	</li>		</li>
	<li>		<li>
	<t>The access rights granted by the RO</t>		<t>The access rights granted by the RO</t>
	</li>		</li>
	<li>		<li>
	<t>The current state of the grant request, as defined in <xref sec tion="1.5" sectionFormat="of" target="GNAP"/></t>		<t>The current state of the grant request, as defined in <xref sec tion="1.5" sectionFormat="of" target="RFC9635"/></t>
	</li>		</li>
	</ul>		</ul>
	<t>The AS can use this information to tie common information to a spec ific token. For instance,		<t>The AS can use this information to tie common information to a spec ific token. For instance,
	instead of specifying a client instance for every issued access token for a gran t, the AS		instead of specifying a client instance for every issued access token for a gran t, the AS
	can store the client information in the grant itself and look it up by reference from the		can store the client information in the grant itself and look it up by reference from the
	access token.</t>		access token.</t>
	<t>The AS can also use this information when a grant request is update d. For example, if the client		<t>The AS can also use this information when a grant request is update d. For example, if the client
	instance asks for a new access token from an existing grant, the AS can use this link to revoke		instance asks for a new access token from an existing grant, the AS can use this link to revoke
	older non-durable access tokens that had been previously issued under the grant. </t>		older non-durable access tokens that had been previously issued under the grant. </t>
	<t>A client instance will have its own model of an ongoing grant reque st, especially if that		<t>A client instance will have its own model of an ongoing grant reque st, especially if that
	grant request can be continued using the API defined in <xref section="5" sectio nFormat="of" target="GNAP"/> where several		grant request can be continued using the API defined in <xref section="5" sectio nFormat="of" target="RFC9635"/> where several
	pieces of statefulness need to be kept in hand. The client instance might need t o keep an		pieces of statefulness need to be kept in hand. The client instance might need t o keep an
	association with the grant request that issued the token in case the access toke n expires or		association with the grant request that issued the token in case the access toke n expires or
	does not have sufficient access rights, so that the client instance can get a ne w access		does not have sufficient access rights, so that the client instance can get a ne w access
	token without having to restart the grant request process from scratch.</t>		token without having to restart the grant request process from scratch.</t>
	<t>Since the grant itself does not need to be identified in any of the protocol messages, GNAP		<t>Since the grant itself does not need to be identified in any of the protocol messages, GNAP
	does not define a specific grant identifier to be conveyed between any parties i n the protocol.		does not define a specific grant identifier to be conveyed between any parties i n the protocol.
	Only the AS needs to keep an explicit connection between an issued access token and the		Only the AS needs to keep an explicit connection between an issued access token and the
	parent grant that issued it.</t>		parent grant that issued it.</t>
	</section>		</section>
	<section anchor="as-specific-access-tokens">		<section anchor="as-specific-access-tokens">
	<name>AS-Specific Access Tokens</name>		<name>AS-Specific Access Tokens</name>
	<t>When an access token is used for the grant continuation API defined
	in <xref section="5" sectionFormat="of" target="GNAP"/> (the continuation acces		<t>When an access token is used for the grant continuation API defined
	s token)		in <xref section="5" sectionFormat="of" target="RFC9635"/> (the continuation ac
	the token management API defined in <xref section="6" sectionFormat="of" target=		cess token),
	"GNAP"/> (the token management access token),		the token management API defined in <xref section="6" sectionFormat="of" target=
			"RFC9635"/> (the token management access token),
	or the RS-facing API defined in <xref target="rs-facing-api"/> (the resource ser ver management access token),		or the RS-facing API defined in <xref target="rs-facing-api"/> (the resource ser ver management access token),
	the AS <bcp14>MUST</bcp14> separate these access tokens from others usable at RS 's. The AS can		the AS <bcp14>MUST</bcp14> separate these access tokens from other access tokens used at one or more RSs. The AS can
	do this through the use of a flag on the access token data structure, by using a special internal		do this through the use of a flag on the access token data structure, by using a special internal
	access right, or any other means at its disposal. Just like other access tokens in GNAP,		access right, or any other means at its disposal. Just like other access tokens in GNAP,
	the contents of these AS-specific access tokens are opaque to the software prese nting the token.		the contents of these AS-specific access tokens are opaque to the software prese nting the token.
	Unlike other access tokens, the contents of these AS-specific access tokens are		Unlike other access tokens, the contents of these AS-specific access to
	also opaque to the RS.</t>		kens are also opaque to the RS.</t>
	<t>The client instance is given continuation access tokens only as par t of the <tt>continue</tt> field		<t>The client instance is given continuation access tokens only as par t of the <tt>continue</tt> field
	of the grant response in <xref section="3.1" sectionFormat="of" target="GNAP"/>.		of the grant response in <xref section="3.1" sectionFormat="of" target="RFC9635" />.
	The client instance is given token management access tokens only as part of the <tt>manage</tt> field		The client instance is given token management access tokens only as part of the <tt>manage</tt> field
	of the grant response in <xref section="3.1.2" sectionFormat="of" target="GNAP"/ >.		of the grant response in <xref section="3.2.1" sectionFormat="of" target="RFC963 5"/>.
	The means by which the RS is given resource server management access tokens is o ut of		The means by which the RS is given resource server management access tokens is o ut of
	scope of this specification, but methods could include pre-configuration of the		scope of this specification, but methods could include preconfiguration of the t
	token value with		oken value with
	the RS software or granting the access token through a standard GNAP process.</t		the RS software or granting the access token through a standard GNAP pr
	>		ocess.</t>
	<t>For continuation access tokens and token management access tokens,		<t>For continuation access tokens and token management access tokens,
	a client instance <bcp14>MUST</bcp14> take steps to differentiate these special- purpose access tokens from		a client instance <bcp14>MUST</bcp14> take steps to differentiate these special- purpose access tokens from
	access tokens used at RS's.		access tokens used at one or more RSs.
	To facilitate this, a client instance can store AS-specific access tokens separa tely from		To facilitate this, a client instance can store AS-specific access tokens separa tely from
	other access tokens in order to keep them from being confused with each other an d used at the		other access tokens in order to keep them from being confused with each other an d used at the
	wrong endpoints.</t>		wrong endpoints.</t>
	<t>An RS should never see an AS-specific access token presented, so an y attempts to process one <bcp14>MUST</bcp14>		<t>An RS should never see an AS-specific access token presented, so an y attempts to process one <bcp14>MUST</bcp14>
	fail. When introspection is used, the AS <bcp14>MUST NOT</bcp14> return an <tt>a ctive</tt> value of <tt>true</tt> for		fail. When introspection is used, the AS <bcp14>MUST NOT</bcp14> return an <tt>a ctive</tt> value of <tt>true</tt> for
	AS-specific access tokens to the RS. If an AS implements its protected endpoints in such a way		AS-specific access tokens to the RS. If an AS implements its protected endpoints in such a way
	as it uses token introspection internally, the AS <bcp14>MUST</bcp14> differenti ate these AS-specific access tokens		that it uses token introspection internally, the AS <bcp14>MUST</bcp14> differen tiate these AS-specific access tokens
	from those issued for use at an external RS.</t>		from those issued for use at an external RS.</t>
	</section>		</section>
	</section>		</section>
	<section anchor="token-format">		<section anchor="token-format">
	<name>Access Token Formats</name>		<name>Access Token Formats</name>
	<t>When the AS issues an access token for use at an RS, the RS		<t>When the AS issues an access token for use at an RS, the RS
	needs to have some means of understanding what the access token is for		needs to have some means of understanding what the access token is for
	in order to determine how to respond to the request. The core GNAP		in order to determine how to respond to the request. The core GNAP
	protocol makes neither assumptions nor demands on the format or contents		protocol makes neither assumptions nor demands on the format or contents
	of the access token, and in fact, the token format and contents are opaque		of the access token, and in fact, the token format and contents are opaque
	skipping to change at line 363 ¶		skipping to change at line 373 ¶
	<t>Self-contained structured token formats allow for the conveyance		<t>Self-contained structured token formats allow for the conveyance
	of information between the AS and RS without requiring the RS to		of information between the AS and RS without requiring the RS to
	call the AS at runtime as described in <xref target="introspection"/>. Structure d tokens		call the AS at runtime as described in <xref target="introspection"/>. Structure d tokens
	can also be used in combination with introspection, allowing the token itself		can also be used in combination with introspection, allowing the token itself
	to carry one class of information and the introspection response to carry		to carry one class of information and the introspection response to carry
	another.</t>		another.</t>
	<t>Some token formats, such as Macaroons <xref target="MACAROON"/> and B iscuits <xref target="BISCUIT"/>, allow for		<t>Some token formats, such as Macaroons <xref target="MACAROON"/> and B iscuits <xref target="BISCUIT"/>, allow for
	the RS to derive sub-tokens without having to call the AS		the RS to derive sub-tokens without having to call the AS
	as described in <xref target="token-chaining"/>.</t>		as described in <xref target="token-chaining"/>.</t>
	<t>The supported token formats can be communicated dynamically at runtim e		<t>The supported token formats can be communicated dynamically at runtim e
	between the AS and RS in several places.</t>		between the AS and RS in several places:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>		<li>
	<t>The AS can declare its supported token formats as part of RS-faci ng discovery <xref target="discovery"/></t>		<t>The AS can declare its supported token formats as part of RS-faci ng discovery (<xref target="discovery"/>).</t>
	</li>		</li>
	<li>		<li>
	<t>The RS can require a specific token format be used to access a re gistered resource set <xref target="rs-register-resource-handle"/></t>		<t>The RS can require a specific token format be used to access a re gistered resource set (<xref target="rs-register-resource-handle"/>).</t>
	</li>		</li>
	<li>		<li>
	<t>The AS can return the token's format in an introspection response <xref target="introspection"/></t>		<t>The AS can return the token's format in an introspection response (<xref target="introspection"/>).</t>
	</li>		</li>
	</ul>		</ul>
	<t>In all places where the token format is listed explicitly, it <bcp14> MUST</bcp14> be one of the registered		<t>In all places where the token format is listed explicitly, it <bcp14> MUST</bcp14> be one of the registered
	values in the GNAP Token Formats Registry <xref target="IANA-token-format"/>.</t >		values in the "GNAP Token Formats" registry <xref target="IANA-token-format"/>.< /t>
	</section>		</section>
	</section>		</section>
	<section anchor="rs-facing-api">		<section anchor="rs-facing-api">
	<name>Resource-Server-Facing API</name>		<name>Resource-Server-Facing API</name>
	<t>To facilitate runtime and dynamic connections with an RS, the AS can of fer an		<t>To facilitate runtime and dynamic connections with an RS, the AS can of fer an
	RS-Facing API consisting of one or more of the following optional		RS-facing API consisting of one or more of the following optional
	pieces.</t>		pieces:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>		<li>
	<t>Discovery</t>		<t>Discovery</t>
	</li>		</li>
	<li>		<li>
	<t>Introspection</t>		<t>Introspection</t>
	</li>		</li>
	<li>		<li>
	<t>Token chaining</t>		<t>Token chaining</t>
	</li>		</li>
	<li>		<li>
	<t>Resource reference registration</t>		<t>Resource reference registration</t>
	</li>		</li>
	</ul>		</ul>
	<section anchor="discovery">		<section anchor="discovery">
	<name>RS-facing AS Discovery</name>		<name>RS-Facing AS Discovery</name>
	<t>A GNAP AS offering RS-facing services can publish its features		<t>A GNAP AS offering RS-facing services can publish its features
	on a well-known discovery document at the URL with the same		on a well-known discovery document at the URL with the same
	schema and authority as the grant request endpoint URL, at		schema and authority as the grant request endpoint URL, at
	the path <tt>/.well-known/gnap-as-rs</tt>.</t>		the path <tt>/.well-known/gnap-as-rs</tt>.</t>
	<t>The discovery response is a JSON document <xref target="RFC8259"/> co nsisting of a single JSON		<t>The discovery response is a JSON document <xref target="RFC8259"/> co nsisting of a single JSON
	object with the following fields:</t>		object with the following fields:</t>
	<dl>
			<dl spacing="normal" newline="false">
	<dt>grant_request_endpoint (string):</dt>		<dt>grant_request_endpoint (string):</dt>
	<dd>		<dd>
	<t>The location of the AS's grant request endpoint defined by <xref		<t>The location of the AS's grant request endpoint defined by <xref
	section="9" sectionFormat="of" target="GNAP"/>.		section="9" sectionFormat="of" target="RFC9635"/>.
	This URL <bcp14>MUST</bcp14> be the same URL used by client instances in suppo rt of GNAP requests.		This URL <bcp14>MUST</bcp14> be the same URL used by client instances in suppo rt of GNAP requests.
	The RS can use this to derive downstream access tokens, if supported by the AS .		The RS can use this to derive downstream access tokens, if supported by the AS .
	The location <bcp14>MUST</bcp14> be a URL <xref target="RFC3986"/>		The location <bcp14>MUST</bcp14> be a URL <xref target="RFC3986"/>
	with a scheme component that <bcp14>MUST</bcp14> be https, a host component, a		with a scheme component that <bcp14>MUST</bcp14> be https, a host component, a
	nd optionally,		nd (optionally)
	port, path and query components and no fragment components.		port, path, and query components and no fragment components.
	<bcp14>REQUIRED</bcp14>.		<bcp14>REQUIRED</bcp14>.
	See <xref target="token-chaining"/>.</t>		See <xref target="token-chaining"/>.</t>
	</dd>		</dd>
	<dt>introspection_endpoint (string):</dt>		<dt>introspection_endpoint (string):</dt>
	<dd>		<dd>
	<t>The URL of the endpoint offering introspection.		<t>The URL of the endpoint offering introspection.
	The location <bcp14>MUST</bcp14> be a URL <xref target="RFC3986"/>		The location <bcp14>MUST</bcp14> be a URL <xref target="RFC3986"/>
	with a scheme component that <bcp14>MUST</bcp14> be https, a host component, a		with a scheme component that <bcp14>MUST</bcp14> be https, a host component, a
	nd optionally,		nd (optionally)
	port, path and query components and no fragment components.		port, path, and query components and no fragment components.
	<bcp14>REQUIRED</bcp14> if the AS supports introspection. An absent value indi cates that the AS does not support introspection.		<bcp14>REQUIRED</bcp14> if the AS supports introspection. An absent value indi cates that the AS does not support introspection.
	See <xref target="introspection"/>.</t>		See <xref target="introspection"/>.</t>
	</dd>		</dd>
	<dt>token_formats_supported (array of strings):</dt>		<dt>token_formats_supported (array of strings):</dt>
	<dd>		<dd>
	<t>A list of token formats supported by this AS. The values in this list		<t>A list of token formats supported by this AS. The values in this list
	<bcp14>MUST</bcp14> be registered in the GNAP Token Format Registry in <xref t arget="IANA-token-format"/>.		<bcp14>MUST</bcp14> be registered in the "GNAP Token Formats" registry per <xr ef target="IANA-token-format"/>.
	<bcp14>OPTIONAL</bcp14>.</t>		<bcp14>OPTIONAL</bcp14>.</t>
	</dd>		</dd>
	<dt>resource_registration_endpoint (string):</dt>		<dt>resource_registration_endpoint (string):</dt>
	<dd>		<dd>
	<t>The URL of the endpoint offering resource registration.		<t>The URL of the endpoint offering resource registration.
	The location <bcp14>MUST</bcp14> be a URL <xref target="RFC3986"/>		The location <bcp14>MUST</bcp14> be a URL <xref target="RFC3986"/>
	with a scheme component that <bcp14>MUST</bcp14> be https, a host component, a		with a scheme component that <bcp14>MUST</bcp14> be https, a host component, a
	nd optionally,		nd (optionally)
	port, path and query components and no fragment components.		port, path, and query components and no fragment components.
	<bcp14>REQUIRED</bcp14> if the AS supports dynamic resource registration. An a bsent value indicates that the AS does not support this feature.		<bcp14>REQUIRED</bcp14> if the AS supports dynamic resource registration. An a bsent value indicates that the AS does not support this feature.
	See <xref target="rs-register-resource-handle"/>.</t>		See <xref target="rs-register-resource-handle"/>.</t>
	</dd>		</dd>
	<dt>key_proofs_supported (array of strings)</dt>		<dt>key_proofs_supported (array of strings):</dt>
	<dd>		<dd>
	<t>A list of the AS's supported key		<t>A list of the AS's supported key
	proofing mechanisms. The values of this list correspond to possible		proofing mechanisms. The values of this list correspond to possible
	values of the <tt>proof</tt> field of the key section of the request.		values of the <tt>proof</tt> field of the key section of the request.
	Values <bcp14>MUST</bcp14> be in the GNAP Key Proofing Methods registry establ ished by <xref target="GNAP"/>.		Values <bcp14>MUST</bcp14> be registered in the "GNAP Key Proofing Methods" re gistry established by <xref target="RFC9635"/>.
	<bcp14>OPTIONAL</bcp14>.</t>		<bcp14>OPTIONAL</bcp14>.</t>
	</dd>		</dd>
	</dl>		</dl>
	<t>Additional fields are defined in the GNAP RS-Facing Discovery Documen t Fields registry <xref target="IANA-rs-discovery"/>.</t>		<t>Additional fields are defined in the "GNAP RS-Facing Discovery Docume nt Fields" registry; see <xref target="IANA-rs-discovery"/>.</t>
	</section>		</section>
	<section anchor="authentication">		<section anchor="authentication">
	<name>Protecting RS requests to the AS</name>		<name>Protecting RS Requests to the AS</name>
	<t>Unless otherwise specified, the RS <bcp14>MUST</bcp14> protect its ca lls to the AS using any of the signature		<t>Unless otherwise specified, the RS <bcp14>MUST</bcp14> protect its ca lls to the AS using any of the signature
	methods defined by <xref section="7" sectionFormat="of" target="GNAP"/>.</t>		methods defined in <xref section="7" sectionFormat="of" target="RFC9635"/>.</t>
	<t>The RS <bcp14>MAY</bcp14> present its keys by reference or by value i n		<t>The RS <bcp14>MAY</bcp14> present its keys by reference or by value i n
	a similar fashion to a client instance calling the AS in the core protocol		a similar fashion to a client instance calling the AS in the core protocol
	of GNAP, described in <xref section="7.1" sectionFormat="of" target="GNAP"/>. In		of GNAP, as described in <xref section="7.1" sectionFormat="of" target="RFC9635"
	the protocols defined here,		/>. In the protocols defined here,
	this takes the form of the resource server identifying itself using a <tt>key</t		this takes the form of the resource server identifying itself by using a <tt>key
	t> field or		</tt> field or
	by passing an instance identifier directly.</t>		by passing an instance identifier directly.</t>
	<sourcecode type="http-message"><![CDATA[		<sourcecode type="http-message"><![CDATA[
	POST /continue HTTP/1.1		POST /continue HTTP/1.1
	Host: server.example.com		Host: server.example.com
	Authorization: GNAP 80UPRY5NM33OMUKMKSKU		Authorization: GNAP 80UPRY5NM33OMUKMKSKU
	Signature-Input: sig1=...		Signature-Input: sig1=...
	Signature: sig1=...		Signature: sig1=...
	Content-Type: application/json		Content-Type: application/json
	"resource_server": {		"resource_server": {
	skipping to change at line 496 ¶		skipping to change at line 507 ¶
	Host: server.example.com		Host: server.example.com
	Signature-Input: sig1=...		Signature-Input: sig1=...
	Signature: sig1=...		Signature: sig1=...
	Content-Type: application/json		Content-Type: application/json
	{		{
	"resource_server": "7C7C4AZ9KHRS6X63AJAO"		"resource_server": "7C7C4AZ9KHRS6X63AJAO"
	}		}
	]]></sourcecode>		]]></sourcecode>
	<t>The means by which an RS's keys are made known to the AS are out		<t>The means by which an RS's keys are made known to the AS are out
	of scope of this specification.		of the scope of this specification.
	The AS <bcp14>MAY</bcp14> require an RS to pre-register its keys		The AS <bcp14>MAY</bcp14> require an RS to preregister its keys,
	or could allow calls from arbitrary keys in a trust-on-first-use		or it could allow calls from arbitrary keys in a trust-on-first-use
	model.</t>		model.</t>
	<t>The AS <bcp14>MAY</bcp14> issue access tokens to the RS for protectin		<t>The AS <bcp14>MAY</bcp14> issue access tokens, called "resource serve
	g the RS-facing		r management access tokens", to the RS to protect the RS-facing API endpoints.
	API endpoints, called a resource server management access token.
	If such tokens are issued, the RS <bcp14>MUST</bcp14> present them		If such tokens are issued, the RS <bcp14>MUST</bcp14> present them
	to the RS-facing API endpoints along with the RS authentication.</t>		to the RS-facing API endpoints along with the RS authentication.</t>
	<sourcecode type="http-message"><![CDATA[		<sourcecode type="http-message"><![CDATA[
	POST /continue HTTP/1.1		POST /continue HTTP/1.1
	Host: server.example.com		Host: server.example.com
	Authorization: GNAP 80UPRY5NM33OMUKMKSKU		Authorization: GNAP 80UPRY5NM33OMUKMKSKU
	Signature-Input: sig1=...		Signature-Input: sig1=...
	Signature: sig1=...		Signature: sig1=...
	Content-Type: application/json		Content-Type: application/json
	skipping to change at line 596 ¶		skipping to change at line 606 ¶
	</artset>		</artset>
	<ol spacing="normal" type="1"><li>		<ol spacing="normal" type="1"><li>
	<t>The client instance calls the RS with its access token.</t>		<t>The client instance calls the RS with its access token.</t>
	</li>		</li>
	<li>		<li>
	<t>The RS introspects the access token value at the AS.		<t>The RS introspects the access token value at the AS.
	The RS signs the request with its own key (not the client instance's		The RS signs the request with its own key (not the client instance's
	key or the token's key).</t>		key or the token's key).</t>
	</li>		</li>
	<li>		<li>
	<t>The AS validates the access token value and the Resource Server's request		<t>The AS validates the access token value and the RS's request
	and returns the introspection response for the token.</t>		and returns the introspection response for the token.</t>
	</li>		</li>
	<li>		<li>
	<t>The RS fulfills the request from the client instance.</t>		<t>The RS fulfills the request from the client instance.</t>
	</li>		</li>
	</ol>		</ol>
	<t>The RS signs the request with its own key and sends the value of the access		<t>The RS signs the request with its own key and sends the value of the access
	token as the body of the request as a JSON object with the following members:</t		token in the body of the request as a JSON object with the following members:</t
	>		>
	<dl>		<dl newline="false" spacing="normal">
	<dt>access_token (string):</dt>		<dt>access_token (string):</dt>
	<dd>		<dd>
	<t><bcp14>REQUIRED</bcp14>. The access token value presented to the RS by the client instance.</t>		<t>The access token value presented to the RS by the client instance . <bcp14>REQUIRED</bcp14>.</t>
	</dd>		</dd>
	<dt>proof (string):</dt>		<dt>proof (string):</dt>
	<dd>		<dd>
	<t><bcp14>RECOMMENDED</bcp14>. The proofing method used by the clien		<t>The proofing method used by the client instance to bind the token
	t instance to bind the token to the RS request.		to the RS request.
	The value <bcp14>MUST</bcp14> be in the GNAP Key Proofing Methods registry.</t		The value <bcp14>MUST</bcp14> be registered in the "GNAP Key Proofing Methods"
	>		registry. <bcp14>RECOMMENDED</bcp14>.</t>
	</dd>		</dd>
	<dt>resource_server (string or object):</dt>		<dt>resource_server (object/string):</dt>
	<dd>		<dd>
	<t><bcp14>REQUIRED</bcp14>. The identification used to authenticate		<t>The identification used to authenticate the resource server makin
	the resource server making this call, either		g this call, either
	by value or by reference as described in <xref target="authentication"/>.</t>		by value or by reference as described in <xref target="authentication"/>. <bcp
			14>REQUIRED</bcp14>.</t>
	</dd>		</dd>
	<dt>access (array of strings/objects):</dt>		<dt>access (array of strings/objects):</dt>
	<dd>		<dd>
	<t><bcp14>OPTIONAL</bcp14>. The minimum access rights required to fu		<t>The minimum access rights required to fulfill the request. This <
	lfill the request. This <bcp14>MUST</bcp14> be in the		bcp14>MUST</bcp14> be in the
	format described in <xref section="8" sectionFormat="of" target="GNAP"/>.</t>		format described in <xref section="8" sectionFormat="of" target="RFC9635"/>. <
			bcp14>OPTIONAL</bcp14>. </t>
	</dd>		</dd>
	</dl>		</dl>
	<t>Additional fields are defined in the GNAP Token Introspection Request		<t>Additional fields are defined in the "GNAP Token Introspection Reques
	registry <xref target="IANA-token-introspection-request"/>.</t>		t" registry (<xref target="IANA-token-introspection-request"/>).</t>
	<sourcecode type="http-message"><![CDATA[		<sourcecode type="http-message"><![CDATA[
	POST /introspect HTTP/1.1		POST /introspect HTTP/1.1
	Host: server.example.com		Host: server.example.com
	Content-Type: application/json		Content-Type: application/json
	Signature-Input: sig1=...		Signature-Input: sig1=...
	Signature: sig1=...		Signature: sig1=...
	Digest: sha256=...		Digest: sha256=...
	{		{
	"access_token": "OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0",		"access_token": "OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0",
	skipping to change at line 671 ¶		skipping to change at line 683 ¶
	<t>is appropriate for presentation at the identified RS, and</t>		<t>is appropriate for presentation at the identified RS, and</t>
	</li>		</li>
	<li>		<li>
	<t>is appropriate for the <tt>access</tt> indicated (if present).</t >		<t>is appropriate for the <tt>access</tt> indicated (if present).</t >
	</li>		</li>
	</ul>		</ul>
	<t>The AS responds with a data structure describing the token's		<t>The AS responds with a data structure describing the token's
	current state and any information the RS would need to validate the		current state and any information the RS would need to validate the
	token's presentation, such as its intended proofing mechanism and key		token's presentation, such as its intended proofing mechanism and key
	material.</t>		material.</t>
	<dl>		<dl newline="false" spacing="normal">
	<dt>active (boolean):</dt>		<dt>active (boolean):</dt>
	<dd>		<dd>
	<t><bcp14>REQUIRED</bcp14>. If <tt>true</tt>, the access token prese nted is active,		<t>If <tt>true</tt>, the access token presented is active,
	as defined above. If any of the criteria for an active token		as defined above. If any of the criteria for an active token
	are not true, or if the AS is unable to make a		are not true, or if the AS is unable to make a
	determination (such as the token is not found), the value is		determination (such as the token is not found), the value is
	set to <tt>false</tt> and other fields are omitted.</t>		set to <tt>false</tt> and other fields are omitted. <bcp14>REQUIRED</bcp14>.</ t>
	</dd>		</dd>
	</dl>		</dl>
	<t>If the access token is active, additional fields from the single acce ss token		<t>If the access token is active, additional fields from the single acce ss token
	response structure defined in <xref section="3.2.1" sectionFormat="of" target="G NAP"/> are included. In		response structure defined in <xref section="3.2.1" sectionFormat="of" target="R FC9635"/> are included. In
	particular, these include the following:</t>		particular, these include the following:</t>
	<dl>		<dl newline="false" spacing="normal">
	<dt>access (array of strings/objects):</dt>		<dt>access (array of strings/objects):</dt>
	<dd>		<dd>
	<t><bcp14>REQUIRED</bcp14>. The access rights associated with this a		<t>The access rights associated with this access token. This <bcp14>
	ccess token. This <bcp14>MUST</bcp14> be in the		MUST</bcp14> be in the
	format described in the <xref section="8" sectionFormat="of" target="GNAP"/>.		format described in <xref section="8" sectionFormat="of" target="RFC9635"/>.
	This array <bcp14>MAY</bcp14> be filtered or otherwise limited for consumption by the identified RS, including		This array <bcp14>MAY</bcp14> be filtered or otherwise limited for consumption by the identified RS, including
	being an empty array, indicating that the token has no explicit access rights		being an empty array, which indicates that the token has no explicit access ri
	that		ghts that
	can be disclosed to the RS.</t>		can be disclosed to the RS. <bcp14>REQUIRED</bcp14>.</t>
	</dd>		</dd>
	<dt>key (object/string):</dt>		<dt>key (object/string):</dt>
	<dd>		<dd>
	<t><bcp14>REQUIRED</bcp14> if the token is bound. The key bound to t he access token, to allow the RS		<t>if the token is bound. The key bound to the access token, to allo w the RS
	to validate the signature of the request from the client instance. If the acce ss		to validate the signature of the request from the client instance. If the acce ss
	token is a bearer token, this <bcp14>MUST NOT</bcp14> be included.</t>		token is a bearer token, this <bcp14>MUST NOT</bcp14> be included. <bcp14>REQU IRED</bcp14></t>
	</dd>		</dd>
	<dt>flags (array of strings):</dt>		<dt>flags (array of strings):</dt>
	<dd>		<dd>
	<t><bcp14>OPTIONAL</bcp14>. The set of flags associated with the acc ess token.</t>		<t>The set of flags associated with the access token. <bcp14>OPTIONA L</bcp14>.</t>
	</dd>		</dd>
	<dt>exp (integer):</dt>		<dt>exp (integer):</dt>
	<dd>		<dd>
	<t><bcp14>OPTIONAL</bcp14>. The timestamp after which this token is		<t>The timestamp after which this token is no longer valid.
	no longer valid.		Expressed as integer seconds from UNIX Epoch. <bcp14>OPTIONAL</bcp14>.</t>
	Expressed as integer seconds from UNIX Epoch.</t>
	</dd>		</dd>
	<dt>iat (integer):</dt>		<dt>iat (integer):</dt>
	<dd>		<dd>
	<t><bcp14>OPTIONAL</bcp14>. The timestamp at which this token was is		<t>The timestamp at which this token was issued by the AS.
	sued by the AS.		Expressed as integer seconds from UNIX Epoch. <bcp14>OPTIONAL</bcp14>.</t>
	Expressed as integer seconds from UNIX Epoch.</t>
	</dd>		</dd>
	<dt>nbf (integer):</dt>		<dt>nbf (integer):</dt>
	<dd>		<dd>
	<t><bcp14>OPTIONAL</bcp14>. The timestamp before which this token is		<t>The timestamp before which this token is not valid.
	not valid.		Expressed as integer seconds from UNIX Epoch. <bcp14>OPTIONAL</bcp14>.</t>
	Expressed as integer seconds from UNIX Epoch.</t>
	</dd>		</dd>
	<dt>aud (string or array of strings):</dt>		<dt>aud (string or array of strings):</dt>
	<dd>		<dd>
	<t><bcp14>OPTIONAL</bcp14>. Identifiers for the resource servers thi s token can be accepted at.</t>		<t>Identifiers for the resource servers this token can be accepted a t. <bcp14>OPTIONAL</bcp14>.</t>
	</dd>		</dd>
	<dt>sub (string):</dt>		<dt>sub (string):</dt>
	<dd>		<dd>
	<t><bcp14>OPTIONAL</bcp14>. Identifier of the resource owner who aut horized this token.</t>		<t>Identifier of the resource owner who authorized this token. <bcp1 4>OPTIONAL</bcp14>.</t>
	</dd>		</dd>
	<dt>iss (string):</dt>		<dt>iss (string):</dt>
	<dd>		<dd>
	<t><bcp14>REQUIRED</bcp14>. Grant endpoint URL of the AS that issued this token.</t>		<t>Grant endpoint URL of the AS that issued this token. <bcp14>REQUI RED</bcp14>.</t>
	</dd>		</dd>
	<dt>instance_id (string):</dt>		<dt>instance_id (string):</dt>
	<dd>		<dd>
	<t><bcp14>OPTIONAL</bcp14>. The instance identifier of the client in stance that the token was issued to.</t>		<t>The instance identifier of the client instance that the token was issued to. <bcp14>OPTIONAL</bcp14>.</t>
	</dd>		</dd>
	</dl>		</dl>
	<t>Additional fields are defined in the GNAP Token Introspection Respons e registry <xref target="IANA-token-introspection"/>.</t>		<t>Additional fields are defined in the "GNAP Token Introspection Respon se" registry (<xref target="IANA-token-introspection"/>).</t>
	<t>The response <bcp14>MAY</bcp14> include any additional fields defined in an access		<t>The response <bcp14>MAY</bcp14> include any additional fields defined in an access
	token response and <bcp14>MUST NOT</bcp14> include the access token <tt>value</t t> itself.</t>		token response and <bcp14>MUST NOT</bcp14> include the access token <tt>value</t t> itself.</t>
	<sourcecode type="http-message"><![CDATA[		<sourcecode type="http-message"><![CDATA[
	HTTP/1.1 200 OK		HTTP/1.1 200 OK
	Content-Type: application/json		Content-Type: application/json
	Cache-Control: no-store		Cache-Control: no-store
	{		{
	"active": true,		"active": true,
	"access": [		"access": [
	skipping to change at line 768 ¶		skipping to change at line 780 ¶
	}		}
	]]></sourcecode>		]]></sourcecode>
	<t>When processing the results of the introspection response, the RS <bc p14>MUST</bcp14> determine the		<t>When processing the results of the introspection response, the RS <bc p14>MUST</bcp14> determine the
	appropriate course of action. For instance, if the RS determines that the access token's		appropriate course of action. For instance, if the RS determines that the access token's
	access rights are not sufficient for the request to which the token was attached , the RS		access rights are not sufficient for the request to which the token was attached , the RS
	can return an error or a public resource, as appropriate for the RS.		can return an error or a public resource, as appropriate for the RS.
	In all cases, the final determination of the response is at the discretion of th e RS.</t>		In all cases, the final determination of the response is at the discretion of th e RS.</t>
	</section>		</section>
	<section anchor="rs-register-resource-handle">		<section anchor="rs-register-resource-handle">
	<name>Registering a Resource Set</name>		<name>Registering a Resource Set</name>
	<t>If the RS needs to, it can post a set of resources as described in th		<t>If the RS needs to, it can post a set of resources, as described in S
	e Resource Access Rights section of		ection <xref target="RFC9635" sectionFormat="bare" section="8"/> ("Resource Acce
	<xref target="GNAP"/> to the AS's resource registration endpoint along with info		ss Rights") of <xref target="RFC9635"/>, to the AS's resource registration endpo
	rmation about		int along with information about
	what the RS will need to validate the request.</t>		what the RS will need to validate the request.</t>
	<dl>		<dl newline="false" spacing="normal">
	<dt>access (array of objects/strings):</dt>		<dt>access (array of objects/strings):</dt>
	<dd>		<dd>
	<t><bcp14>REQUIRED</bcp14>. The list of access rights associated wit		<t>The list of access rights associated with the request in the form
	h the request in the format described		at described
	in the "Resource Access Rights" section of <xref target="GNAP"/>.</t>		in Section <xref target="RFC9635" sectionFormat="bare" section="8"/> ("Resourc
			e Access Rights") of <xref target="RFC9635"/>. <bcp14>REQUIRED</bcp14>. </t>
	</dd>		</dd>
	<dt>resource_server (string or object):</dt>		<dt>resource_server (object/string):</dt>
	<dd>		<dd>
	<t><bcp14>REQUIRED</bcp14>. The identification used to authenticate		<t> The identification used to authenticate the resource server maki
	the resource server making this call, either		ng this call, either
	by value or by reference as described in <xref target="authentication"/>.</t>		by value or by reference as described in <xref target="authentication"/>. <bcp
			14>REQUIRED</bcp14>.</t>
	</dd>		</dd>
	<dt>token_formats_supported (array of strings):</dt>		<dt>token_formats_supported (array of strings):</dt>
	<dd>		<dd>
	<t><bcp14>OPTIONAL</bcp14>. The token formats the RS is able to proc		<t>The list of token formats that the RS is able to process.
	ess for accessing the resource.		The values in this array <bcp14>MUST</bcp14> be registered in the "GNAP Token
	The values in this array <bcp14>MUST</bcp14> be registered in the GNAP Token F		Formats" registry per <xref target="IANA-token-format"/>.
	ormats Registry in <xref target="IANA-token-format"/>.
	If the field is omitted, the token format is at the discretion of the AS.		If the field is omitted, the token format is at the discretion of the AS.
	If the AS does not support any of the requested		If the AS does not support any of the requested
	token formats, the AS <bcp14>MUST</bcp14> return an error to the RS.</t>		token formats, the AS <bcp14>MUST</bcp14> return an error to the RS. <bcp14>OP TIONAL</bcp14>.</t>
	</dd>		</dd>
	<dt>token_introspection_required (boolean):</dt>		<dt>token_introspection_required (boolean):</dt>
	<dd>		<dd>
	<t><bcp14>OPTIONAL</bcp14>. If present and set to <tt>true</tt>, the RS expects to make a token introspection request as		<t> If present and set to <tt>true</tt>, the RS expects to make a to ken introspection request as
	described in <xref target="introspection"/>. If absent or set to <tt>false</tt >, the RS does not anticipate needing		described in <xref target="introspection"/>. If absent or set to <tt>false</tt >, the RS does not anticipate needing
	to make an introspection request for tokens relating to this resource set. If the AS does not		to make an introspection request for tokens relating to this resource set. If the AS does not
	support token introspection for this RS, the AS <bcp14>MUST</bcp14> return an error to the RS.</t>		support token introspection for this RS, the AS <bcp14>MUST</bcp14> return an error to the RS. <bcp14>OPTIONAL</bcp14>.</t>
	</dd>		</dd>
	</dl>		</dl>
	<t>Additional fields are defined in the GNAP Resource Set Registration R equest registry <xref target="IANA-resource-registration-request"/>.</t>		<t>Additional fields are defined in the "GNAP Resource Set Registration Request Parameters" registry (<xref target="IANA-resource-registration-request"/ >).</t>
	<t>The RS <bcp14>MUST</bcp14> identify itself with its own key and sign the		<t>The RS <bcp14>MUST</bcp14> identify itself with its own key and sign the
	request.</t>		request.</t>
	<sourcecode type="http-message"><![CDATA[		<sourcecode type="http-message"><![CDATA[
	POST /resource HTTP/1.1		POST /resource HTTP/1.1
	Host: server.example.com		Host: server.example.com
	Content-Type: application/json		Content-Type: application/json
	Signature-Input: sig1=...		Signature-Input: sig1=...
	Signature: sig1=...		Signature: sig1=...
	Digest: ...		Digest: ...
	skipping to change at line 835 ¶		skipping to change at line 846 ¶
	},		},
	"dolphin-metadata"		"dolphin-metadata"
	],		],
	"resource_server": "7C7C4AZ9KHRS6X63AJAO"		"resource_server": "7C7C4AZ9KHRS6X63AJAO"
	}		}
	]]></sourcecode>		]]></sourcecode>
	<t>The AS responds with a reference appropriate to represent the		<t>The AS responds with a reference appropriate to represent the
	resources list that the RS presented in its request as well as		resources list that the RS presented in its request as well as
	any additional information the RS might need in future requests.</t>		any additional information the RS might need in future requests.</t>
	<dl>		<dl newline="false" spacing="normal">
	<dt>resource_reference (string):</dt>		<dt>resource_reference (string):</dt>
	<dd>		<dd>
	<t><bcp14>REQUIRED</bcp14>. A single string representing the list of resources registered in the request.		<t>A single string representing the list of resources registered in the request.
	The RS <bcp14>MAY</bcp14> make this handle available to a client instance as p art of a		The RS <bcp14>MAY</bcp14> make this handle available to a client instance as p art of a
	discovery response as described in <xref section="9.1" sectionFormat="of" targ		discovery response as described in <xref section="9.1" sectionFormat="of" targ
	et="GNAP"/> or as		et="RFC9635"/> or as
	documentation to client software developers.</t>		documentation to client software developers. <bcp14>REQUIRED</bcp14>.</t>
	</dd>		</dd>
	<dt>instance_id (string):</dt>		<dt>instance_id (string):</dt>
	<dd>		<dd>
	<t><bcp14>OPTIONAL</bcp14>. An instance identifier that the RS can u		<t>An instance identifier that the RS can use to refer to itself in
	se to refer to itself in future calls to		future calls to
	the AS, in lieu of sending its key by value. See <xref target="authentication"		the AS, in lieu of sending its key by value. See <xref target="authentication"
	/>.</t>		/>. <bcp14>OPTIONAL</bcp14>.</t>
	</dd>		</dd>
	<dt>introspection_endpoint (string):</dt>		<dt>introspection_endpoint (string):</dt>
	<dd>		<dd>
	<t><bcp14>OPTIONAL</bcp14>. The introspection endpoint of this AS, u		<t>The introspection endpoint of this AS that is used to allow the R
	sed to allow the RS to perform		S to perform token introspection. See <xref target="introspection"/>. <bcp14>OPT
	token introspection. See <xref target="introspection"/>.</t>		IONAL</bcp14>.</t>
	</dd>		</dd>
	</dl>		</dl>
	<t>Additional fields are defined in the GNAP Resource Set Registration R esponse Registry <xref target="IANA-resource-registration-response"/>.</t>		<t>Additional fields are defined in the "GNAP Resource Set Registration Response Parameters" registry (<xref target="IANA-resource-registration-response "/>).</t>
	<sourcecode type="http-message"><![CDATA[		<sourcecode type="http-message"><![CDATA[
	HTTP/1.1 200 OK		HTTP/1.1 200 OK
	Content-Type: application/json		Content-Type: application/json
	Cache-Control: no-store		Cache-Control: no-store
	{		{
	"resource_reference": "FWWIKYBQ6U56NL1"		"resource_reference": "FWWIKYBQ6U56NL1"
	}		}
	]]></sourcecode>		]]></sourcecode>
	<t>If a resource was previously registered, the AS <bcp14>MAY</bcp14> re turn the same resource reference		<t>If a resource was previously registered, the AS <bcp14>MAY</bcp14> re turn the same resource reference
	value as in previous responses.</t>		value as in previous responses.</t>
	<t>If the registration fails, the AS returns an HTTP 400 Bad Request err
	or to the		<t>If the registration fails, the AS returns HTTP status code 400 (Bad R
	RS indicating that the registration was not successful.</t>		equest) to the
			RS, indicating that the registration was not successful.</t>
	<t>The client instance can then use the <tt>resource_reference</tt> valu e as a string-type access		<t>The client instance can then use the <tt>resource_reference</tt> valu e as a string-type access
	reference as defined in <xref section="8.1" sectionFormat="of" target="GNAP"/>. This value <bcp14>MAY</bcp14> be combined with any other		reference as defined in <xref section="8.1" sectionFormat="of" target="RFC9635"/ >. This value <bcp14>MAY</bcp14> be combined with any other
	additional access rights requested by the client instance.</t>		additional access rights requested by the client instance.</t>
	<sourcecode type="json"><![CDATA[		<sourcecode type="json"><![CDATA[
	{		{
	"access_token": {		"access_token": {
	"access": [		"access": [
	"FWWIKYBQ6U56NL1",		"FWWIKYBQ6U56NL1",
	{		{
	"type": "photo-api",		"type": "photo-api",
	"actions": [		"actions": [
	"read",		"read",
	skipping to change at line 901 ¶		skipping to change at line 912 ¶
	},		},
	"dolphin-metadata"		"dolphin-metadata"
	]		]
	},		},
	"client": "client-12351.bdxqf"		"client": "client-12351.bdxqf"
	}		}
	]]></sourcecode>		]]></sourcecode>
	</section>		</section>
	<section anchor="response-error">		<section anchor="response-error">
	<name>Error Responses</name>		<name>Error Responses</name>
	<t>In the case of an error from the RS-facing API, the AS responds to th		<t>In the case of an error from the RS-facing API, the AS responds to th
	e RS with an HTTP 400 (Bad Request)		e RS with HTTP status code 400 (Bad Request) and a JSON object consisting of a s
	status code and a JSON object consisting of a single <tt>error</tt> field, which		ingle <tt>error</tt> field, which is either an object or a string.</t>
	is either an object or a string.</t>
	<t>When returned as a string, the error value is the error code:</t>		<t>When returned as a string, the error value is the error code:</t>
	<sourcecode type="json"><![CDATA[		<sourcecode type="json"><![CDATA[
	{		{
	error: "invalid_access"		error: "invalid_access"
	}		}
	]]></sourcecode>		]]></sourcecode>
	<t>When returned as an object, the error object contains the following f ields:</t>		<t>When returned as an object, the error object contains the following f ields:</t>
	<dl>		<dl newline="false" spacing="normal">
	<dt><tt>code</tt> (string):</dt>		<dt><tt>code</tt> (string):</dt>
	<dd>		<dd>
	<t>A single ASCII error code defining the error.		<t>A single ASCII error code defining the error.
	<bcp14>REQUIRED</bcp14>.</t>		<bcp14>REQUIRED</bcp14>.</t>
	</dd>		</dd>
	<dt><tt>description</tt> (string):</dt>		<dt><tt>description</tt> (string):</dt>
	<dd>		<dd>
	<t>A human-readable string description of the error intended for the		<t>A human-readable string description of the error intended for the
	developer of the client.		developer of the client.
	<bcp14>OPTIONAL</bcp14>.</t>		<bcp14>OPTIONAL</bcp14>.</t>
	skipping to change at line 932 ¶		skipping to change at line 942 ¶
	</dl>		</dl>
	<sourcecode type="json"><![CDATA[		<sourcecode type="json"><![CDATA[
	{		{
	"error": {		"error": {
	"code": "invalid_access",		"code": "invalid_access",
	"description": "Access to 'foo' is not permitted for this RS."		"description": "Access to 'foo' is not permitted for this RS."
	}		}
	}		}
	]]></sourcecode>		]]></sourcecode>
	<t>This specification defines the following error code values:</t>		<t>This specification defines the following error code values:</t>
	<dl>		<dl newline="false" spacing="normal">
	<dt><tt>"invalid_request"</tt>:</dt>		<dt><tt>"invalid_request"</tt>:</dt>
	<dd>		<dd>
	<t>The request is missing a required parameter, includes an		<t>The request is missing a required parameter, includes an
	invalid parameter value or is otherwise malformed.</t>		invalid parameter value, or is otherwise malformed.</t>
	</dd>		</dd>
	<dt><tt>"invalid_resource_server"</tt>:</dt>		<dt><tt>"invalid_resource_server"</tt>:</dt>
	<dd>		<dd>
	<t>The request was made from an RS that was not recognized		<t>The request was made from an RS that was not recognized
	or allowed by the AS, or the RS's signature validation failed.</t>		or allowed by the AS, or the RS's signature validation failed.</t>
	</dd>		</dd>
	<dt><tt>"invalid_access"</tt></dt>		<dt><tt>"invalid_access"</tt></dt>
	<dd>		<dd>
	<t>The RS is not permitted to register or introspect for the request ed "access" value.</t>		<t>The RS is not permitted to register or introspect for the request ed "access" value.</t>
	</dd>		</dd>
	</dl>		</dl>
	<t>Additional error codes can be defined in the <xref target="IANA-error -code">GNAP RS-Facing Error Codes Registry</xref>.</t>		<t>Additional error codes can be defined in the "GNAP RS-Facing Error Co des" registry (<xref target="IANA-error-code"/>).</t>
	</section>		</section>
	</section>		</section>
	<section anchor="token-chaining">		<section anchor="token-chaining">
	<name>Deriving a downstream token</name>		<name>Deriving a Downstream Token</name>
	<t>Some architectures require an RS to act as a client instance and use a derived access		<t>Some architectures require an RS to act as a client instance and use a derived access
	token for a secondary RS. Since the RS is not the same entity that made the init ial grant		token for a secondary RS. Since the RS is not the same entity that made the init ial grant
	request, the RS is not capable of referencing or modifying the existing grant. A s such,		request, the RS is not capable of referencing or modifying the existing grant. A s such,
	the RS needs to request or generate a new token access token for its use at the secondary RS.		the RS needs to request or generate a new access token for its use at the second ary RS.
	This internal secondary token is issued in the context of the incoming access to ken.</t>		This internal secondary token is issued in the context of the incoming access to ken.</t>
	<t>While it is possible to use a <xref target="structure">token format</xr ef> that allows for the		<t>While it is possible to use a <xref target="structure">token format</xr ef> that allows for the
	RS to generate its own secondary token,		RS to generate its own secondary token,
	the AS can allow the RS to request this secondary access token using the same		the AS can allow the RS to request this secondary access token using the same
	process used by the original client instance to request the primary access token . Since the		process used by the original client instance to request the primary access token . Since the
	RS is acting as its own client instance from the perspective of GNAP, this proce ss		RS is acting as its own client instance from the perspective of GNAP, this proce ss
	uses the same grant endpoint, request structure, and response structure as a cli ent		uses the same grant endpoint, request structure, and response structure as a cli ent
	instance's request.</t>		instance's request.</t>
	<artset>		<artset>
	<artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1.1 " height="192" width="464" viewBox="0 0 464 192" class="diagram" text-anchor="mi ddle" font-family="monospace" font-size="13px" stroke-linecap="round">		<artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1.1 " height="192" width="464" viewBox="0 0 464 192" class="diagram" text-anchor="mi ddle" font-family="monospace" font-size="13px" stroke-linecap="round">
	skipping to change at line 1054 ¶		skipping to change at line 1064 ¶
	</li>		</li>
	<li>		<li>
	<t>RS2 fulfills the call from RS1.</t>		<t>RS2 fulfills the call from RS1.</t>
	</li>		</li>
	<li>		<li>
	<t>RS1 fulfills the call from the original client instance.</t>		<t>RS1 fulfills the call from the original client instance.</t>
	</li>		</li>
	</ol>		</ol>
	<t>If the RS needs to derive a token from one presented to it, it can		<t>If the RS needs to derive a token from one presented to it, it can
	request one from the AS by making a token request as described in		request one from the AS by making a token request as described in
	<xref target="GNAP"/> and presenting the existing access token's		<xref target="RFC9635"/> and presenting the existing access token's
	value in the "existing_access_token" field.</t>		value in the "existing_access_token" field.</t>
	<t>Since the RS is acting as a client instance,		<t>Since the RS is acting as a client instance,
	the RS <bcp14>MUST</bcp14> identify itself with its own key in the <tt>client</t t> field and sign the		the RS <bcp14>MUST</bcp14> identify itself with its own key in the <tt>client</t t> field and sign the
	request just as any client instance would, as described in <xref target="authent ication"/>.		request just as any client instance would, as described in <xref target="authent ication"/>.
	The AS <bcp14>MUST</bcp14> determine that the token being presented is appropria te for use		The AS <bcp14>MUST</bcp14> determine that the token being presented is appropria te for use
	at the RS making the token chaining request.</t>		at the RS making the token chaining request.</t>
	<artwork><![CDATA[
			<sourcecode type="http-message"><![CDATA[
	POST /tx HTTP/1.1		POST /tx HTTP/1.1
	Host: server.example.com		Host: server.example.com
	Content-Type: application/json		Content-Type: application/json
	Detached-JWS: ejy0...		Detached-JWS: ejy0...
	{		{
	"access_token": {		"access_token": {
	"access": [		"access": [
	{		{
	"actions": [		"actions": [
	"read",		"read",
	"write",		"write",
	"dolphin"		"dolphin"
	],		],
	"locations": [		"locations": [
	"https://server.example.net/",		"https://server.example.net/",
	"https://resource.local/other"		"https://resource.local/other"
	],		],
	"datatypes": [		"datatypes": [
	"metadata",		"metadata",
	"images"		"images"
	]		]
	},		},
	"dolphin-metadata"		"dolphin-metadata"
	]		]
	},		},
	"client": "7C7C4AZ9KHRS6X63AJAO",		"client": "7C7C4AZ9KHRS6X63AJAO",
	"existing_access_token": "OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0"		"existing_access_token": "OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0"
	}		}
	]]></artwork>		]]></sourcecode>
	<t>The AS responds with a token for the downstream RS2 as described in		<t>The AS responds with a token for the downstream RS2 as described in
	<xref target="GNAP"/>. The downstream RS2 could		<xref target="RFC9635"/>. The downstream RS2 could
	repeat this process as necessary for calling further RS's.</t>		repeat this process as necessary for calling further RSs.</t>
	</section>		</section>
	<section anchor="IANA">		<section anchor="IANA">
	<name>IANA Considerations</name>		<name>IANA Considerations</name>
	<t>IANA is requested to add values to existing registries and to create 5 registries in the Grant Negotiation and Authorization Protocol registry.</t>		<t>IANA has added values to existing registries and created five registrie s under the "Grant Negotiation and Authorization Protocol (GNAP)" registry group .</t>
	<section anchor="IANA-well-known">		<section anchor="IANA-well-known">
	<name>Well-Known URI</name>		<name>Well-Known URIs</name>
	<t>The "gnap-as-rs" URI suffix is registered into the Well-Known URIs Re		<t>The "gnap-as-rs" URI suffix is registered in the "Well-Known URIs" re
	gistry to support RS-facing discovery of the AS.</t>		gistry to support RS-facing discovery of the AS.</t>
	<dl>		<dl newline="false" spacing="compact">
	<dt>URI Suffix:</dt>		<dt>URI Suffix:</dt>
	<dd>		<dd>gnap-as-rs</dd>
	<t>gnap-as-rs</t>
	</dd>
	<dt>Change Controller:</dt>		<dt>Change Controller:</dt>
	<dd>		<dd>IETF</dd>
	<t>IETF</t>
	</dd>
	<dt>Specification Document:</dt>		<dt>Specification Document:</dt>
	<dd>		<dd><xref target="discovery"/> of RFC 9767</dd>
	<t><xref target="discovery"/> of RFC xxxx</t>
	</dd>
	<dt>Status:</dt>		<dt>Status:</dt>
	<dd>		<dd>Permanent</dd>
	<t>Permanent</t>
	</dd>
	</dl>		</dl>
	</section>		</section>
	<section anchor="IANA-grant-request">		<section anchor="IANA-grant-request">
	<name>GNAP Grant Request Parameters</name>		<name>GNAP Grant Request Parameters</name>
	<t>The following parameter is registered into the GNAP Grant Request Par		<t>The following parameter is registered in the "GNAP Grant Request Para
	ameters registry:</t>		meters" registry:</t>
	<dl>		<dl newline="false" spacing="compact">
	<dt>Name:</dt>		<dt>Name:</dt>
	<dd>		<dd>
	<t><tt>existing_access_token</tt></t>		<tt>existing_access_token</tt>
	</dd>		</dd>
	<dt>Type:</dt>		<dt>Type:</dt>
	<dd>		<dd>
	<t>string</t>		string
	</dd>		</dd>
	<dt>Reference:</dt>		<dt>Reference:</dt>
	<dd>		<dd>
	<t><xref target="token-chaining"/> of RFC xxxx</t>		<xref target="token-chaining"/> of RFC 9767
	</dd>		</dd>
	</dl>		</dl>
	</section>		</section>
	<section anchor="IANA-token-format">		<section anchor="IANA-token-format">
	<name>GNAP Token Formats</name>		<name>GNAP Token Formats</name>
	<t>This document defines a GNAP token format, for which IANA is asked to		<t>This document defines a GNAP token format, for which IANA has created
	create and maintain a new registry titled "GNAP Token Formats". Initial values		and maintains a new registry titled "GNAP Token Formats". Initial values for th
	for this registry are given in <xref target="IANA-token-format-contents"/>. Futu		is registry are given in <xref target="IANA-token-format-contents"/>. Future ass
	re assignments and modifications to existing assignment are to be made through t		ignments and modifications to existing assignment are to be made through the Spe
	he Specification Required registration policy <xref target="RFC8126"/>.</t>		cification Required registration policy <xref target="RFC8126"/>.</t>
	<t>The Designated Expert (DE) is expected to ensure that:</t>		<t>The designated expert (DE) is expected to ensure that:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>		<li>
	<t>all registrations follow the template presented in <xref target=" IANA-token-format-template"/>.</t>		<t>all registrations follow the template presented in <xref target=" IANA-token-format-template"/>.</t>
	</li>		</li>
	<li>		<li>
	<t>the format's definition is sufficiently unique from other formats provided by existing parameters.</t>		<t>the format's definition is sufficiently unique from other formats provided by existing parameters.</t>
	</li>		</li>
	<li>		<li>
	<t>the format's definition specifies the format of the access token in sufficient detail to allow for the AS and RS to be able to communicate the to ken information.</t>		<t>the format's definition specifies the format of the access token in sufficient detail to allow for the AS and RS to be able to communicate the to ken information.</t>
	</li>		</li>
	</ul>		</ul>
	<section anchor="IANA-token-format-template">		<section anchor="IANA-token-format-template">
	<name>Registry Template</name>		<name>Registry Template</name>
	<dl>		<dl newline="false" spacing="compact">
	<dt>Name</dt>		<dt>Name:</dt>
	<dd>		<dd>
	<t>The name of the format.</t>		The name of the format.
	</dd>		</dd>
	<dt>Status</dt>		<dt>Status:</dt>
	<dd>		<dd>
	<t>Whether or not the format is in active use. Possible values are Active and Deprecated.</t>		Whether or not the format is in active use. Possible values are Ac tive and Deprecated.
	</dd>		</dd>
	<dt>Description</dt>		<dt>Description:</dt>
	<dd>		<dd>
	<t>Human-readable description of the access token format.</t>		The human-readable description of the access token format.
	</dd>		</dd>
	<dt>Reference</dt>		<dt>Reference:</dt>
	<dd>		<dd>
	<t>The specification that defines the token format.</t>		The specification that defines the token format.
	</dd>		</dd>
	</dl>		</dl>
	</section>		</section>
	<section anchor="IANA-token-format-contents">		<section anchor="IANA-token-format-contents">
	<name>Initial Registry Contents</name>		<name>Initial Registry Contents</name>
	<table>		<table>
	<name>Initial contents of the GNAP Token Formats Registry.</name>		<name>Initial Contents of the GNAP Token Formats Registry</name>
	<thead>		<thead>
	<tr>		<tr>
	<th align="left">Name</th>		<th align="left">Name</th>
	<th align="left">Status</th>		<th align="left">Status</th>
	<th align="left">Description</th>		<th align="left">Description</th>
	<th align="left">Reference</th>		<th align="left">Reference</th>
	</tr>		</tr>
	</thead>		</thead>
	<tbody>		<tbody>
	<tr>		<tr>
	<td align="left">		<td align="left">
	<tt>jwt-signed</tt></td>		<tt>jwt-signed</tt></td>
	<td align="left">Active</td>		<td align="left">Active</td>
	<td align="left">JSON Web Token, signed with JWS</td>		<td align="left">JSON Web Token, signed with JWS</td>
	<td align="left">		<td align="left">
	<xref target="JWT"/></td>		<xref target="RFC7519"/></td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">		<td align="left">
	<tt>jwt-encrypted</tt></td>		<tt>jwt-encrypted</tt></td>
	<td align="left">Active</td>		<td align="left">Active</td>
	<td align="left">JSON Web Token, encrypted with JWE</td>		<td align="left">JSON Web Token, encrypted with JWE</td>
	<td align="left">		<td align="left">
	<xref target="JWT"/></td>		<xref target="RFC7519"/></td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">		<td align="left">
	<tt>macaroon</tt></td>		<tt>macaroon</tt></td>
	<td align="left">Active</td>		<td align="left">Active</td>
	<td align="left">Macaroon</td>		<td align="left">Macaroon</td>
	<td align="left">		<td align="left">
	<xref target="MACAROON"/></td>		<xref target="MACAROON"/></td>
	</tr>		</tr>
	<tr>		<tr>
	skipping to change at line 1234 ¶		skipping to change at line 1237 ¶
	<td align="left">ZCAP</td>		<td align="left">ZCAP</td>
	<td align="left">		<td align="left">
	<xref target="ZCAPLD"/></td>		<xref target="ZCAPLD"/></td>
	</tr>		</tr>
	</tbody>		</tbody>
	</table>		</table>
	</section>		</section>
	</section>		</section>
	<section anchor="IANA-token-introspection-request">		<section anchor="IANA-token-introspection-request">
	<name>GNAP Token Introspection Request</name>		<name>GNAP Token Introspection Request</name>
	<t>This document defines GNAP token introspection, for which IANA is ask		<t>This document defines GNAP token introspection, for which IANA has cr
	ed to create and maintain a new registry titled "GNAP Token Introspection Reques		eated and maintains a new registry titled "GNAP Token Introspection Request". In
	t". Initial values for this registry are given in <xref target="IANA-token-intro		itial values for this registry are given in <xref target="IANA-token-introspecti
	spection-request-contents"/>. Future assignments and modifications to existing a		on-request-contents"/>. Future assignments and modifications to existing assignm
	ssignment are to be made through the Specification Required registration policy		ent are to be made through the Specification Required registration policy <xref
	<xref target="RFC8126"/>.</t>		target="RFC8126"/>.</t>
	<t>The Designated Expert (DE) is expected to ensure that:</t>		<t>The DE is expected to ensure that:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>		<li>
	<t>all registrations follow the template presented in <xref target=" IANA-token-introspection-request-template"/>.</t>		<t>all registrations follow the template presented in <xref target=" IANA-token-introspection-request-template"/>.</t>
	</li>		</li>
	<li>		<li>
	<t>the claim's definition is sufficiently orthogonal to other claims defined in the registry so as avoid overlapping functionality.</t>		<t>the claim's definition is sufficiently orthogonal to other claims defined in the registry so as avoid overlapping functionality.</t>
	</li>		</li>
	<li>		<li>
	<t>the claim's definition specifies the syntax and semantics of the claim in sufficient detail to allow for the AS and RS to be able to communicate the token values.</t>		<t>the claim's definition specifies the syntax and semantics of the claim in sufficient detail to allow for the AS and RS to be able to communicate the token values.</t>
	</li>		</li>
	</ul>		</ul>
	<section anchor="IANA-token-introspection-request-template">		<section anchor="IANA-token-introspection-request-template">
	<name>Registry Template</name>		<name>Registry Template</name>
	<dl>		<dl newline="false" spacing="compact">
	<dt>Name</dt>		<dt>Name:</dt>
	<dd>		<dd>
	<t>The name of the claim.</t>		The name of the claim.
	</dd>		</dd>
	<dt>Type</dt>		<dt>Type:</dt>
	<dd>		<dd>
	<t>The JSON data type of the claim value.</t>		The JSON data type of the claim value.
	</dd>		</dd>
	<dt>Reference</dt>		<dt>Reference:</dt>
	<dd>		<dd>
	<t>The specification that defines the claim.</t>		The specification that defines the claim.
	</dd>		</dd>
	</dl>		</dl>
	</section>		</section>
	<section anchor="IANA-token-introspection-request-contents">		<section anchor="IANA-token-introspection-request-contents">
	<name>Initial Registry Contents</name>		<name>Initial Registry Contents</name>
	<t>The table below contains the initial contents of the GNAP Token Int rospection Registry.</t>		<t>The table below contains the initial contents of the "GNAP Token In trospection Request" registry.</t>
	<table>		<table>
	<name>Initial contents of the GNAP Token Introspection Request Regis try.</name>		<name>Initial Contents of the GNAP Token Introspection Request Regis try</name>
	<thead>		<thead>
	<tr>		<tr>
	<th align="left">Name</th>		<th align="left">Name</th>
	<th align="left">Type</th>		<th align="left">Type</th>
	<th align="left">Reference</th>		<th align="left">Reference</th>
	</tr>		</tr>
	</thead>		</thead>
	<tbody>		<tbody>
	<tr>		<tr>
	<td align="left">access_token</td>		<td align="left">access_token</td>
	<td align="left">string</td>		<td align="left">string</td>
	<td align="left">		<td align="left">
	<xref target="introspection"/> of RFC xxxx</td>		<xref target="introspection"/> of RFC 9767</td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">proof</td>		<td align="left">proof</td>
	<td align="left">string</td>		<td align="left">string</td>
	<td align="left">		<td align="left">
	<xref target="introspection"/> of RFC xxxx</td>		<xref target="introspection"/> of RFC 9767</td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">resource_server</td>		<td align="left">resource_server</td>
	<td align="left">object/string</td>		<td align="left">object/string</td>
	<td align="left">		<td align="left">
	<xref target="introspection"/> of RFC xxxx</td>		<xref target="introspection"/> of RFC 9767</td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">access</td>		<td align="left">access</td>
	<td align="left">array of strings/objects</td>		<td align="left">array of strings/objects</td>
	<td align="left">		<td align="left">
	<xref target="introspection"/> of RFC xxxx</td>		<xref target="introspection"/> of RFC 9767</td>
	</tr>		</tr>
	</tbody>		</tbody>
	</table>		</table>
	</section>		</section>
	</section>		</section>
	<section anchor="IANA-token-introspection">		<section anchor="IANA-token-introspection">
	<name>GNAP Token Introspection Response</name>		<name>GNAP Token Introspection Response</name>
	<t>This document defines GNAP token introspection, for which IANA is ask		<t>This document defines GNAP token introspection, for which IANA has cr
	ed to create and maintain a new registry titled "GNAP Token Introspection Respon		eated and maintains a new registry titled "GNAP Token Introspection Response". I
	se". Initial values for this registry are given in <xref target="IANA-token-intr		nitial values for this registry are given in <xref target="IANA-token-introspect
	ospection-contents"/>. Future assignments and modifications to existing assignme		ion-contents"/>. Future assignments and modifications to existing assignment are
	nt are to be made through the Specification Required registration policy <xref t		to be made through the Specification Required registration policy <xref target=
	arget="RFC8126"/>.</t>		"RFC8126"/>.</t>
	<t>The Designated Expert (DE) is expected to ensure that:</t>		<t>The DE is expected to ensure that:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>		<li>
	<t>all registrations follow the template presented in <xref target=" IANA-token-introspection-template"/>.</t>		<t>all registrations follow the template presented in <xref target=" IANA-token-introspection-template"/>.</t>
	</li>		</li>
	<li>		<li>
	<t>the claim's definition is sufficiently orthogonal to other claims defined in the registry so as avoid overlapping functionality.</t>		<t>the claim's definition is sufficiently orthogonal to other claims defined in the registry so as avoid overlapping functionality.</t>
	</li>		</li>
	<li>		<li>
	<t>the claim's definition specifies the syntax and semantics of the claim in sufficient detail to allow for the AS and RS to be able to communicate the token values.</t>		<t>the claim's definition specifies the syntax and semantics of the claim in sufficient detail to allow for the AS and RS to be able to communicate the token values.</t>
	</li>		</li>
	</ul>		</ul>
	<section anchor="IANA-token-introspection-template">		<section anchor="IANA-token-introspection-template">
	<name>Registry Template</name>		<name>Registry Template</name>
	<dl>		<dl newline="false" spacing="compact">
	<dt>Name</dt>		<dt>Name:</dt>
	<dd>		<dd>
	<t>The name of the claim.</t>		The name of the claim.
	</dd>		</dd>
	<dt>Type</dt>		<dt>Type:</dt>
	<dd>		<dd>
	<t>The JSON data type of the claim value.</t>		The JSON data type of the claim value.
	</dd>		</dd>
	<dt>Reference</dt>		<dt>Reference:</dt>
	<dd>		<dd>
	<t>The specification that defines the claim.</t>		The specification that defines the claim.
	</dd>		</dd>
	</dl>		</dl>
	</section>		</section>
	<section anchor="IANA-token-introspection-contents">		<section anchor="IANA-token-introspection-contents">
	<name>Initial Registry Contents</name>		<name>Initial Registry Contents</name>
	<t>The table below contains the initial contents of the GNAP Token Int rospection Registry.</t>		<t>The table below contains the initial contents of the "GNAP Token In trospection Response" registry.</t>
	<table>		<table>
	<name>Initial contents of the GNAP Token Introspection Response Regi stry.</name>		<name>Initial Contents of the GNAP Token Introspection Response Regi stry</name>
	<thead>		<thead>
	<tr>		<tr>
	<th align="left">Name</th>		<th align="left">Name</th>
	<th align="left">Type</th>		<th align="left">Type</th>
	<th align="left">Reference</th>		<th align="left">Reference</th>
	</tr>		</tr>
	</thead>		</thead>
	<tbody>		<tbody>
	<tr>		<tr>
	<td align="left">active</td>		<td align="left">active</td>
	<td align="left">boolean</td>		<td align="left">boolean</td>
	<td align="left">		<td align="left">
	<xref target="introspection"/> of RFC xxxx</td>		<xref target="introspection"/> of RFC 9767</td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">access</td>		<td align="left">access</td>
	<td align="left">array of strings/objects</td>		<td align="left">array of strings/objects</td>
	<td align="left">		<td align="left">
	<xref target="introspection"/> of RFC xxxx</td>		<xref target="introspection"/> of RFC 9767</td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">key</td>		<td align="left">key</td>
	<td align="left">object/string</td>		<td align="left">object/string</td>
	<td align="left">		<td align="left">
	<xref target="introspection"/> of RFC xxxx</td>		<xref target="introspection"/> of RFC 9767</td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">flags</td>		<td align="left">flags</td>
	<td align="left">array of strings</td>		<td align="left">array of strings</td>
	<td align="left">		<td align="left">
	<xref target="introspection"/> of RFC xxxx</td>		<xref target="introspection"/> of RFC 9767</td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">exp</td>		<td align="left">exp</td>
	<td align="left">integer</td>		<td align="left">integer</td>
	<td align="left">		<td align="left">
	<xref target="introspection"/> of RFC xxxx</td>		<xref target="introspection"/> of RFC 9767</td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">iat</td>		<td align="left">iat</td>
	<td align="left">integer</td>		<td align="left">integer</td>
	<td align="left">		<td align="left">
	<xref target="introspection"/> of RFC xxxx</td>		<xref target="introspection"/> of RFC 9767</td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">nbf</td>		<td align="left">nbf</td>
	<td align="left">integer</td>		<td align="left">integer</td>
	<td align="left">		<td align="left">
	<xref target="introspection"/> of RFC xxxx</td>		<xref target="introspection"/> of RFC 9767</td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">aud</td>		<td align="left">aud</td>
	<td align="left">string or array of strings</td>		<td align="left">string or array of strings</td>
	<td align="left">		<td align="left">
	<xref target="introspection"/> of RFC xxxx</td>		<xref target="introspection"/> of RFC 9767</td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">sub</td>		<td align="left">sub</td>
	<td align="left">string</td>		<td align="left">string</td>
	<td align="left">		<td align="left">
	<xref target="introspection"/> of RFC xxxx</td>		<xref target="introspection"/> of RFC 9767</td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">iss</td>		<td align="left">iss</td>
	<td align="left">string</td>		<td align="left">string</td>
	<td align="left">		<td align="left">
	<xref target="introspection"/> of RFC xxxx</td>		<xref target="introspection"/> of RFC 9767</td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">instance_id</td>		<td align="left">instance_id</td>
	<td align="left">string</td>		<td align="left">string</td>
	<td align="left">		<td align="left">
	<xref target="introspection"/> of RFC xxxx</td>		<xref target="introspection"/> of RFC 9767</td>
	</tr>		</tr>
	</tbody>		</tbody>
	</table>		</table>
	</section>		</section>
	</section>		</section>
	<section anchor="IANA-resource-registration-request">		<section anchor="IANA-resource-registration-request">
	<name>GNAP Resource Set Registration Request Parameters</name>		<name>GNAP Resource Set Registration Request Parameters</name>
	<t>This document defines a means to register a resource set for a GNAP A		<t>This document defines a means to register a resource set for a GNAP A
	S, for which IANA is asked to create and maintain a new registry titled "GNAP Re		S, for which IANA has created and maintains a new registry titled "GNAP Resource
	source Set Registration Request Parameters". Initial values for this registry ar		Set Registration Request Parameters". Initial values for this registry are give
	e given in <xref target="IANA-resource-registration-request-contents"/>. Future		n in <xref target="IANA-resource-registration-request-contents"/>. Future assign
	assignments and modifications to existing assignment are to be made through the		ments and modifications to existing assignment are to be made through the Expert
	Expert Review registration policy <xref target="RFC8126"/>.</t>		Review registration policy <xref target="RFC8126"/>.</t>
	<t>The Designated Expert (DE) is expected to ensure that:</t>		<t>The DE is expected to ensure that:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>		<li>
	<t>all registrations follow the template presented in <xref target=" IANA-resource-registration-request-template"/>.</t>		<t>all registrations follow the template presented in <xref target=" IANA-resource-registration-request-template"/>.</t>
	</li>		</li>
	<li>		<li>
	<t>the parameter's definition is sufficiently orthogonal to other pa rameters defined in the registry so as avoid overlapping functionality.</t>		<t>the parameter's definition is sufficiently orthogonal to other pa rameters defined in the registry so as avoid overlapping functionality.</t>
	</li>		</li>
	<li>		<li>
	<t>the parameter's definition specifies the syntax and semantics of the parameter in sufficient detail to allow for the AS and RS to be able to comm unicate the resource set.</t>		<t>the parameter's definition specifies the syntax and semantics of the parameter in sufficient detail to allow for the AS and RS to be able to comm unicate the resource set.</t>
	</li>		</li>
	</ul>		</ul>
	<section anchor="IANA-resource-registration-request-template">		<section anchor="IANA-resource-registration-request-template">
	<name>Registry Template</name>		<name>Registry Template</name>
	<dl>		<dl newline="false" spacing="compact">
	<dt>Name</dt>		<dt>Name:</dt>
	<dd>		<dd>
	<t>The name of the parameter.</t>		The name of the parameter.
	</dd>		</dd>
	<dt>Type</dt>		<dt>Type:</dt>
	<dd>		<dd>
	<t>The JSON data type of the parameter value.</t>		The JSON data type of the parameter value.
	</dd>		</dd>
	<dt>Reference</dt>		<dt>Reference:</dt>
	<dd>		<dd>
	<t>The specification that defines the token.</t>		The specification that defines the token.
	</dd>		</dd>
	</dl>		</dl>
	</section>		</section>
	<section anchor="IANA-resource-registration-request-contents">		<section anchor="IANA-resource-registration-request-contents">
	<name>Initial Registry Contents</name>		<name>Initial Registry Contents</name>
	<t>The table below contains the initial contents of the GNAP Resource Set Registration Request Parameters Registry.</t>		<t>The table below contains the initial contents of the "GNAP Resource Set Registration Request Parameters" registry.</t>
	<table>		<table>
	<name>Initial contents of the GNAP Resource Set Registration Request Parameters Registry.</name>		<name>Initial Contents of the GNAP Resource Set Registration Request Parameters Registry</name>
	<thead>		<thead>
	<tr>		<tr>
	<th align="left">Name</th>		<th align="left">Name</th>
	<th align="left">Type</th>		<th align="left">Type</th>
	<th align="left">Reference</th>		<th align="left">Reference</th>
	</tr>		</tr>
	</thead>		</thead>
	<tbody>		<tbody>
	<tr>		<tr>
	<td align="left">access</td>		<td align="left">access</td>
	<td align="left">array of strings/objects</td>		<td align="left">array of strings/objects</td>
	<td align="left">		<td align="left">
	<xref target="rs-register-resource-handle"/> of RFC xxxx</td>		<xref target="rs-register-resource-handle"/> of RFC 9767</td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">resource_server</td>		<td align="left">resource_server</td>
	<td align="left">string or object</td>		<td align="left">object/string</td>
	<td align="left">		<td align="left">
	<xref target="rs-register-resource-handle"/> of RFC xxxx</td>		<xref target="rs-register-resource-handle"/> of RFC 9767</td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">token_formats_supported</td>		<td align="left">token_formats_supported</td>
	<td align="left">string</td>		<td align="left">array of strings</td>
	<td align="left">		<td align="left">
	<xref target="rs-register-resource-handle"/> of RFC xxxx</td>		<xref target="rs-register-resource-handle"/> of RFC 9767</td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">token_introspection_required</td>		<td align="left">token_introspection_required</td>
	<td align="left">boolean</td>		<td align="left">boolean</td>
	<td align="left">		<td align="left">
	<xref target="rs-register-resource-handle"/> of RFC xxxx</td>		<xref target="rs-register-resource-handle"/> of RFC 9767</td>
	</tr>		</tr>
	</tbody>		</tbody>
	</table>		</table>
	</section>		</section>
	</section>		</section>
	<section anchor="IANA-resource-registration-response">		<section anchor="IANA-resource-registration-response">
	<name>GNAP Resource Set Registration Response Parameters</name>		<name>GNAP Resource Set Registration Response Parameters</name>
	<t>This document defines a means to register a resource set for a GNAP A		<t>This document defines a means to register a resource set for a GNAP A
	S, for which IANA is asked to create and maintain a new registry titled "GNAP Re		S, for which IANA has created and maintains a new registry titled "GNAP Resource
	source Set Registration Response Parameters". Initial values for this registry a		Set Registration Response Parameters". Initial values for this registry are giv
	re given in <xref target="IANA-resource-registration-response-contents"/>. Futur		en in <xref target="IANA-resource-registration-response-contents"/>. Future assi
	e assignments and modifications to existing assignment are to be made through th		gnments and modifications to existing assignment are to be made through the Expe
	e Expert Review registration policy <xref target="RFC8126"/>.</t>		rt Review registration policy <xref target="RFC8126"/>.</t>
	<t>The Designated Expert (DE) is expected to ensure that:</t>		<t>The DE is expected to ensure that:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>		<li>
	<t>all registrations follow the template presented in <xref target=" IANA-resource-registration-response-template"/>.</t>		<t>all registrations follow the template presented in <xref target=" IANA-resource-registration-response-template"/>.</t>
	</li>		</li>
	<li>		<li>
	<t>the parameter's definition is sufficiently orthogonal to other cl aims defined in the registry so as avoid overlapping functionality.</t>		<t>the parameter's definition is sufficiently orthogonal to other cl aims defined in the registry so as avoid overlapping functionality.</t>
	</li>		</li>
	<li>		<li>
	<t>the parameter's definition specifies the syntax and semantics of the claim in sufficient detail to allow for the AS and RS to be able to communic ate the resource set.</t>		<t>the parameter's definition specifies the syntax and semantics of the claim in sufficient detail to allow for the AS and RS to be able to communic ate the resource set.</t>
	</li>		</li>
	</ul>		</ul>
	<section anchor="IANA-resource-registration-response-template">		<section anchor="IANA-resource-registration-response-template">
	<name>Registry Template</name>		<name>Registry Template</name>
	<dl>		<dl newline="false" spacing="compact">
	<dt>Name</dt>		<dt>Name:</dt>
	<dd>		<dd>
	<t>The name of the parameter.</t>		The name of the parameter.
	</dd>		</dd>
	<dt>Type</dt>		<dt>Type:</dt>
	<dd>		<dd>
	<t>The JSON data type of the parameter value.</t>		The JSON data type of the parameter value.
	</dd>		</dd>
	<dt>Reference</dt>		<dt>Reference:</dt>
	<dd>		<dd>
	<t>The specification that defines the parameter.</t>		The specification that defines the parameter.
	</dd>		</dd>
	</dl>		</dl>
	</section>		</section>
	<section anchor="IANA-resource-registration-response-contents">		<section anchor="IANA-resource-registration-response-contents">
	<name>Initial Registry Contents</name>		<name>Initial Registry Contents</name>
	<t>The table below contains the initial contents of the GNAP Resource Set Registration Response Parameters Registry.</t>		<t>The table below contains the initial contents of the "GNAP Resource Set Registration Response Parameters" registry.</t>
	<table>		<table>
	<name>Initial contents of the GNAP Resource Set Registration Respons e Parameters Registry.</name>		<name>Initial Contents of the GNAP Resource Set Registration Respons e Parameters Registry</name>
	<thead>		<thead>
	<tr>		<tr>
	<th align="left">Name</th>		<th align="left">Name</th>
	<th align="left">Type</th>		<th align="left">Type</th>
	<th align="left">Reference</th>		<th align="left">Reference</th>
	</tr>		</tr>
	</thead>		</thead>
	<tbody>		<tbody>
	<tr>		<tr>
	<td align="left">resource_reference</td>		<td align="left">resource_reference</td>
	<td align="left">string</td>		<td align="left">string</td>
	<td align="left">		<td align="left">
	<xref target="rs-register-resource-handle"/> of RFC xxxx</td>		<xref target="rs-register-resource-handle"/> of RFC 9767</td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">instance_id</td>		<td align="left">instance_id</td>
	<td align="left">string</td>		<td align="left">string</td>
	<td align="left">		<td align="left">
	<xref target="rs-register-resource-handle"/> of RFC xxxx</td>		<xref target="rs-register-resource-handle"/> of RFC 9767</td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">introspection_endpoint</td>		<td align="left">introspection_endpoint</td>
	<td align="left">string</td>		<td align="left">string</td>
	<td align="left">		<td align="left">
	<xref target="rs-register-resource-handle"/> of RFC xxxx</td>		<xref target="rs-register-resource-handle"/> of RFC 9767</td>
	</tr>		</tr>
	</tbody>		</tbody>
	</table>		</table>
	</section>		</section>
	</section>		</section>
	<section anchor="IANA-rs-discovery">		<section anchor="IANA-rs-discovery">
	<name>GNAP RS-Facing Discovery Document Fields</name>		<name>GNAP RS-Facing Discovery Document Fields</name>
	<t>This document defines a means to for a GNAP AS to be discovered by a		<t>This document defines a means to for a GNAP AS to be discovered by a
	GNAP RS, for which IANA is asked to create and maintain a new registry titled "G		GNAP RS, for which IANA has created and maintains a new registry titled "GNAP RS
	NAP RS-Facing Discovery Document Fields". Initial values for this registry are g		-Facing Discovery Document Fields". Initial values for this registry are given i
	iven in <xref target="IANA-rs-discovery-contents"/>. Future assignments and modi		n <xref target="IANA-rs-discovery-contents"/>. Future assignments and modificati
	fications to existing assignment are to be made through the Expert Review regist		ons to existing assignment are to be made through the Expert Review registration
	ration policy <xref target="RFC8126"/>.</t>		policy <xref target="RFC8126"/>.</t>
	<t>The Designated Expert (DE) is expected to ensure that:</t>		<t>The DE is expected to ensure that:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>		<li>
	<t>all registrations follow the template presented in <xref target=" IANA-rs-discovery-template"/>.</t>		<t>all registrations follow the template presented in <xref target=" IANA-rs-discovery-template"/>.</t>
	</li>		</li>
	<li>		<li>
	<t>the field's definition is sufficiently orthogonal to other fields defined in the registry so as avoid overlapping functionality.</t>		<t>the field's definition is sufficiently orthogonal to other fields defined in the registry so as avoid overlapping functionality.</t>
	</li>		</li>
	<li>		<li>
	<t>the field's definition specifies the syntax and semantics of the fields in sufficient detail to allow for RS to be able to communicate with the A S.</t>		<t>the field's definition specifies the syntax and semantics of the fields in sufficient detail to allow for the RS to be able to communicate with t he AS.</t>
	</li>		</li>
	</ul>		</ul>
	<section anchor="IANA-rs-discovery-template">		<section anchor="IANA-rs-discovery-template">
	<name>Registry Template</name>		<name>Registry Template</name>
	<dl>		<dl newline="false" spacing="compact">
	<dt>Name</dt>		<dt>Name:</dt>
	<dd>		<dd>
	<t>The name of the field.</t>		The name of the field.
	</dd>		</dd>
	<dt>Type</dt>		<dt>Type:</dt>
	<dd>		<dd>
	<t>The JSON data type of the field value.</t>		The JSON data type of the field value.
	</dd>		</dd>
	<dt>Reference</dt>		<dt>Reference:</dt>
	<dd>		<dd>
	<t>The specification that defines the field.</t>		The specification that defines the field.
	</dd>		</dd>
	</dl>		</dl>
	</section>		</section>
	<section anchor="IANA-rs-discovery-contents">		<section anchor="IANA-rs-discovery-contents">
	<name>Initial Registry Contents</name>		<name>Initial Registry Contents</name>
	<t>The table below contains the initial contents of the GNAP RS-Facing Discovery Registry.</t>		<t>The table below contains the initial contents of the "GNAP RS-Facin g Discovery Document Fields" registry.</t>
	<table>		<table>
	<name>Initial contents of the GNAP RS-Facing Discovery Document Fiel ds Registry.</name>		<name>Initial Contents of the GNAP RS-Facing Discovery Document Fiel ds Registry</name>
	<thead>		<thead>
	<tr>		<tr>
	<th align="left">Name</th>		<th align="left">Name</th>
	<th align="left">Type</th>		<th align="left">Type</th>
	<th align="left">Reference</th>		<th align="left">Reference</th>
	</tr>		</tr>
	</thead>		</thead>
	<tbody>		<tbody>
	<tr>		<tr>
	<td align="left">introspection_endpoint</td>		<td align="left">introspection_endpoint</td>
	<td align="left">string</td>		<td align="left">string</td>
	<td align="left">		<td align="left">
	<xref target="discovery"/> of RFC xxxx</td>		<xref target="discovery"/> of RFC 9767</td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">token_formats_supported</td>		<td align="left">token_formats_supported</td>
	<td align="left">array of strings</td>		<td align="left">array of strings</td>
	<td align="left">		<td align="left">
	<xref target="discovery"/> of RFC xxxx</td>		<xref target="discovery"/> of RFC 9767</td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">resource_registration_endpoint</td>		<td align="left">resource_registration_endpoint</td>
	<td align="left">string</td>		<td align="left">string</td>
	<td align="left">		<td align="left">
	<xref target="discovery"/> of RFC xxxx</td>		<xref target="discovery"/> of RFC 9767</td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">grant_request_endpoint</td>		<td align="left">grant_request_endpoint</td>
	<td align="left">string</td>		<td align="left">string</td>
	<td align="left">		<td align="left">
	<xref target="discovery"/> of RFC xxxx</td>		<xref target="discovery"/> of RFC 9767</td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">key_proofs_supported</td>		<td align="left">key_proofs_supported</td>
	<td align="left">array of strings</td>		<td align="left">array of strings</td>
	<td align="left">		<td align="left">
	<xref target="discovery"/> of RFC xxxx</td>		<xref target="discovery"/> of RFC 9767</td>
	</tr>		</tr>
	</tbody>		</tbody>
	</table>		</table>
	</section>		</section>
	</section>		</section>
	<section anchor="IANA-error-code">		<section anchor="IANA-error-code">
	<name>GNAP RS-Facing Error Codes</name>		<name>GNAP RS-Facing Error Codes</name>
	<t>This document defines a set of errors that the AS can return to the R S, for which IANA is asked to create and maintain a new registry titled "GNAP RS -Facing Error Codes". Initial values for this registry are given in <xref target ="IANA-error-code-contents"/>. Future assignments and modifications to existing assignment are to be made through the Specification Required registration policy <xref target="RFC8126"/>.</t>		<t>This document defines a set of errors that the AS can return to the R S, for which IANA has created and maintains a new registry titled "GNAP RS-Facin g Error Codes". Initial values for this registry are given in <xref target="IANA -error-code-contents"/>. Future assignments and modifications to existing assign ments are to be made through the Specification Required registration policy <xre f target="RFC8126"/>.</t>
	<t>The DE is expected to ensure that:</t>		<t>The DE is expected to ensure that:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>		<li>
	<t>all registrations follow the template presented in <xref target=" IANA-error-code-template"/>.</t>		<t>all registrations follow the template presented in <xref target=" IANA-error-code-template"/>.</t>
	</li>		</li>
	<li>		<li>
	<t>the error response is sufficiently unique from other errors to pr ovide actionable information to the client instance.</t>		<t>the error response is sufficiently unique from other errors to pr ovide actionable information to the client instance.</t>
	</li>		</li>
	<li>		<li>
	<t>the definition of the error response specifies all conditions in which the error response is returned, and what the client instance's expected ac tion is.</t>		<t>the definition of the error response specifies all conditions in which the error response is returned and what the client instance's expected act ion is.</t>
	</li>		</li>
	</ul>		</ul>
	<section anchor="IANA-error-code-template">		<section anchor="IANA-error-code-template">
	<name>Registration Template</name>		<name>Registration Template</name>
	<dl newline="true">		<dl newline="false" spacing="compact">
	<dt>Error:</dt>		<dt>Error:</dt>
	<dd>		<dd>
	<t>A unique string code for the error.</t>		A unique string code for the error.
	</dd>		</dd>
	<dt>Specification document(s):</dt>		<dt>Reference:</dt>
	<dd>		<dd>
	<t>Reference to the document(s) that specify the		Reference to the document(s) that specifies the
	value, preferably including a URI that can be used		value, preferably including a URI that can be used
	to retrieve a copy of the document(s). An indication of the		to retrieve a copy of the document(s). An indication of the
	relevant sections may also be included but is not required.</t>		relevant sections may also be included but is not required.
	</dd>		</dd>
	</dl>		</dl>
	</section>		</section>
	<section anchor="IANA-error-code-contents">		<section anchor="IANA-error-code-contents">
	<name>Initial Contents</name>		<name>Initial Contents</name>
	<table>		<table>
	<name>Initial contents of the GNAP RS-Facing Error Codes Registry.</ name>		<name>Initial Contents of the GNAP RS-Facing Error Codes Registry</n ame>
	<thead>		<thead>
	<tr>		<tr>
	<th align="left">Error</th>		<th align="left">Error</th>
	<th align="left">Specification document(s)</th>		<th align="left">Reference</th>
	</tr>		</tr>
	</thead>		</thead>
	<tbody>		<tbody>
	<tr>		<tr>
	<td align="left">invalid_request</td>		<td align="left">invalid_request</td>
	<td align="left">		<td align="left">
	<xref target="response-error"/> of RFC xxxx</td>		<xref target="response-error"/> of RFC 9767</td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">invalid_resource_server</td>		<td align="left">invalid_resource_server</td>
	<td align="left">		<td align="left">
	<xref target="response-error"/> of RFC xxxx</td>		<xref target="response-error"/> of RFC 9767</td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">invalid_access</td>		<td align="left">invalid_access</td>
	<td align="left">		<td align="left">
	<xref target="response-error"/> of RFC xxxx</td>		<xref target="response-error"/> of RFC 9767</td>
	</tr>		</tr>
	</tbody>		</tbody>
	</table>		</table>
	</section>		</section>
	</section>		</section>
	</section>		</section>
	<section anchor="Security">		<section anchor="Security">
	<name>Security Considerations</name>		<name>Security Considerations</name>
	<t>In addition to the normative requirements in this document and in <xref		<t>In addition to the normative requirements in this document and in <xref
	target="GNAP"/>, implementers are		target="RFC9635"/>, implementers are
	strongly encouraged to consider these additional security considerations in impl		strongly encouraged to consider the following additional security considerations
	ementations		in implementations
	and deployments of GNAP.</t>		and deployments of GNAP.</t>
	<section anchor="security-tls">		<section anchor="security-tls">
	<name>TLS Protection in Transit</name>		<name>TLS Protection in Transit</name>
	<t>All requests in GNAP made over untrusted network connections have to be made over TLS as outlined in <xref target="BCP195"/>		<t>All requests in GNAP made over untrusted network connections have to be made over TLS as outlined in <xref target="BCP195"/>
	to protect the contents of the request and response from manipulation and interc eption by an attacker.		to protect the contents of the request and response from manipulation and interc eption by an attacker.
	This includes all requests from a client instance to the RS and all requests fro m the RS to an AS.</t>		This includes all requests from a client instance to the RS and all requests fro m the RS to an AS.</t>
	</section>		</section>
	<section anchor="security-token-validation">		<section anchor="security-token-validation">
	<name>Token Validation</name>		<name>Token Validation</name>
	<t>The RS has a responsibility to validate the incoming access token in a manner consistent with its deployment.		<t>The RS has a responsibility to validate the incoming access token in a manner consistent with its deployment.
	For self-contained stateless tokens such as those described in <xref target="tok en-format"/>, this consists of actions such		For self-contained stateless tokens such as those described in <xref target="tok en-format"/>, this consists of actions such
	as validating the token's signature and ensuring the relevant fields and results are appropriate for the		as validating the token's signature and ensuring the relevant fields and results are appropriate for the
	request being made. For reference-style tokens or tokens that are otherwise opaq ue to the RS, the token introspection		request being made. For reference-style tokens or tokens that are otherwise opaq ue to the RS, the token introspection
	RS-facing API can be used to provide updated information about the state of the token, as described in <xref target="introspection"/>.</t>		RS-facing API can be used to provide updated information about the state of the token, as described in <xref target="introspection"/>.</t>
	<t>The RS needs to validate that a token:</t>		<t>The RS needs to validate that a token:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>		<li>
	<t>Is intended for this RS (audience restriction)</t>		<t>is intended for this RS (audience restriction)</t>
	</li>		</li>
	<li>		<li>
	<t>Is presented using the appropriate key for the token (see also <x ref target="security-key-proof"/>)</t>		<t>is presented using the appropriate key for the token (see also <x ref target="security-key-proof"/>)</t>
	</li>		</li>
	<li>		<li>
	<t>Identifies an appropriate subject to access the resource (usually this is the resource owner who authorized the token's issuance)</t>		<t>identifies an appropriate subject to access the resource (usually this is the resource owner who authorized the token's issuance)</t>
	</li>		</li>
	<li>		<li>
	<t>Is issued by a trusted AS for this resource</t>		<t>is issued by a trusted AS for this resource</t>
	</li>		</li>
	</ul>		</ul>
	<t>Even though key proofing mechanisms have to cover the value of the to ken, validating the key proofing alone		<t>Even though key proofing mechanisms have to cover the value of the to ken, validating the key proofing alone
	is not sufficient to protect a request to an RS.		is not sufficient to protect a request to an RS.
	If an RS validates only the presentation method as described in <xref target="se curity-key-proof"/> without validating the		If an RS validates only the presentation method as described in <xref target="se curity-key-proof"/> without validating the
	token itself, an attacker could use a compromised key or a confused deputy to ma ke arbitrary calls to the RS		token itself, an attacker could use a compromised key or a confused deputy to ma ke arbitrary calls to the RS
	beyond what has been authorized by the RO.</t>		beyond what has been authorized by the RO.</t>
	</section>		</section>
	<section anchor="security-token-cache">		<section anchor="security-token-cache">
	<name>Caching Token Validation Result</name>		<name>Caching Token Validation Result</name>
	<t>Since token validation can be an expensive process, requiring either cryptographic operations or network calls to an introspection		<t>Since token validation can be an expensive process, requiring either cryptographic operations or network calls to an introspection
	service as described in <xref target="introspection"/>, an RS could cache the re sults of token validation for a particular token.		service as described in <xref target="introspection"/>, an RS could cache the re sults of token validation for a particular token.
	The trade offs of using a cached validation for a token present an important dec ision space for implementers: relying on a cached validation result		The trade-off for using a cached validation for a token presents an important de cision space for implementers: relying on a cached validation result
	increases performance and lowers processing overhead, but it comes at the expens e of the liveness and accuracy of the information		increases performance and lowers processing overhead, but it comes at the expens e of the liveness and accuracy of the information
	in the cache. While a cached value is in use at the RS, an attacker could presen t a revoked token and have it accepted by the RS.</t>		in the cache. While a cached value is in use at the RS, an attacker could presen t a revoked token and have it accepted by the RS.</t>
	<t>As with any cache, the consistency of this cache can be managed in a variety of ways. One of the most simple		<t>As with any cache, the consistency of this cache can be managed in a variety of ways. One of the most simple
	methods is managing the lifetime of the cache in order to balance the performanc e and security properties.		methods is managing the lifetime of the cache in order to balance the performanc e and security properties.
	Too long of a cache, and an attacker has a larger window in which to use a revok		If the cache is too long, an attacker has a larger window in which to use a revo
	ed token. Too short of a window and		ked token. If the window is too short, the benefits of using the cache are dimin
	the benefits of using the cache are diminished.		ished.
	It is also possible that an AS could send a proactive signal to the RS to invali date revoked access tokens, though such a mechanism		It is also possible that an AS could send a proactive signal to the RS to invali date revoked access tokens, though such a mechanism
	is outside the scope of this specification.</t>		is outside the scope of this specification.</t>
	</section>		</section>
	<section anchor="security-key-proof">		<section anchor="security-key-proof">
	<name>Key Proof Validation</name>		<name>Key Proof Validation</name>
	<t>For key-bound access tokens, the proofing method needs to be validate		<t>For key-bound access tokens, the proofing method needs to be validate
	d alongside the value of the token itself as described in <xref target="security		d alongside the value of the token itself, as described in <xref target="securit
	-token-validation"/>.		y-token-validation"/>.
	The process of validation is defined by the key proofing method, as described in		The process of validation is defined by the key proofing method, as described in
	<xref section="7.3" sectionFormat="of" target="GNAP"/>.</t>		<xref section="7.3" sectionFormat="of" target="RFC9635"/>.</t>
	<t>If the proofing method is not validated, an attacker could use a comp romised token without access to the token's bound key.</t>		<t>If the proofing method is not validated, an attacker could use a comp romised token without access to the token's bound key.</t>
	<t>The RS also needs to ensure that the proofing method is appropriate f		<t>The RS also needs to ensure that the proofing method is appropriate f
	or the key associated with the token, including any choice of		or the key associated with the token, including any choice of algorithm or ident
	algorithm or identifiers.</t>		ifiers.</t>
	<t>The proofing should be validated independently on each request to the RS, particularly as aspects of the call could vary.		<t>The proofing should be validated independently on each request to the RS, particularly as aspects of the call could vary.
	As such, the RS should never cache the results of a proof validation from one me ssage and apply it to a subsequent message.</t>		As such, the RS should never cache the results of a proof validation from one me ssage and apply it to a subsequent message.</t>
	</section>		</section>
	<section anchor="token-exfiltration">		<section anchor="token-exfiltration">
	<name>Token Exfiltration</name>		<name>Token Exfiltration</name>
	<t>Since the RS sees the token value, it is possible for a compromised R S to leak that value to an attacker.		<t>Since the RS sees the token value, it is possible for a compromised R S to leak that value to an attacker.
	As such, the RS needs to protect token values as sensitive information and prote ct them from exfiltration.</t>		As such, the RS needs to protect token values as sensitive information and prote ct them from exfiltration.</t>
	<t>This is especially problematic with bearer tokens and tokens bound to a shared key, since an RS has access		<t>This is especially problematic with bearer tokens and tokens bound to a shared key, since an RS has access
	to all information necessary to create a new, valid request using the token in q uestion.</t>		to all information necessary to create a new, valid request using the token in q uestion.</t>
	</section>		</section>
	<section anchor="security-token-reuse-by-rs">		<section anchor="security-token-reuse-by-rs">
	<name>Token Re-Use by an RS</name>		<name>Token Reuse by an RS</name>
	<t>If the access token is a bearer token, or the RS has access to the ke y material needed to present the token,		<t>If the access token is a bearer token, or the RS has access to the ke y material needed to present the token,
	the RS could be tricked into re-using an access token presented to it by a clien t. While it is possible to build		the RS could be tricked into reusing an access token presented to it by a client . While it is possible to build
	a system that makes use of this artifact as a feature, it is safer to exchange t he incoming access token for		a system that makes use of this artifact as a feature, it is safer to exchange t he incoming access token for
	another contextual token for use by the RS, as described in <xref target="token- chaining"/>. This access token can be bound		another contextual token for use by the RS, as described in <xref target="token- chaining"/>. This access token can be bound
	to the RS's own keys and limited to access needed by the RS, instead of the full set of rights associated with		to the RS's own keys and limited to access needed by the RS, instead of the full set of rights associated with
	the token issued to the client instance.</t>		the token issued to the client instance.</t>
	</section>		</section>
	<section anchor="token-format-considerations">		<section anchor="token-format-considerations">
	<name>Token Format Considerations</name>		<name>Token Format Considerations</name>
	<t>With formatted tokens, the format of the token is likely to have its own considerations, and the RS needs		<t>With formatted tokens, the format of the token is likely to have its own considerations, and the RS needs
	to follow any such considerations during the token validation process. The appli cation and scope of		to follow any such considerations during the token validation process. The appli cation and scope of
	these considerations is specific to the format and outside the scope of this spe cification.</t>		these considerations is specific to the format and outside the scope of this spe cification.</t>
	</section>		</section>
	<section anchor="over-sharing-token-contents">		<section anchor="over-sharing-token-contents">
	<name>Over-sharing Token Contents</name>		<name>Oversharing Token Contents</name>
	<t>The contents of the access token model divulge to the RS information
	about the access token's context and rights.		<t>The contents of the access token model divulge information about the
			access token's context and rights to the RS.
	This is true whether the contents are parsed from the token itself or sent in an introspection response.</t>		This is true whether the contents are parsed from the token itself or sent in an introspection response.</t>
	<t>It's likely that every RS does not need to know all details of the to ken model, especially in systems where		<t>It's likely that every RS does not need to know all details of the to ken model, especially in systems where
	a single access token is usable across multiple RS's. An attacker could use this to gain information about		a single access token is usable across multiple RSs. An attacker could use this to gain information about
	the larger system by compromising only one RS. By limiting the information avail able to only		the larger system by compromising only one RS. By limiting the information avail able to only
	that which is relevant to a specific RS, such as using a limited introspection r eply as defined in <xref target="introspection"/>,		that which is relevant to a specific RS, such as using a limited introspection r eply as defined in <xref target="introspection"/>,
	a system can follow the principle of least disclosure to each RS.</t>		a system can follow the principle of least disclosure to each RS.</t>
	</section>		</section>
	<section anchor="resource-references">		<section anchor="resource-references">
	<name>Resource References</name>		<name>Resource References</name>
	<t>Resource references, as returned by the protocol in <xref target="rs- register-resource-handle"/>, are intended to be opaque to		<t>Resource references, as returned by the protocol in <xref target="rs- register-resource-handle"/>, are intended to be opaque to
	both the RS and the client. However, since they are under the control of the AS, the AS can put whatever content		both the RS and the client. However, since they are under the control of the AS, the AS can put whatever content
	it wants into the reference value. This value could unintentionally disclose sys tem structure or other internal		it wants into the reference value. This value could unintentionally disclose sys tem structure or other internal
	details if it processed by an unintended party. Furthermore, such patterns could lead to the client software and		details if it was processed by an unintended party. Furthermore, such patterns c ould lead to the client software and
	RS depending on certain structures being present in the reference value, which d iminishes the separation of concerns		RS depending on certain structures being present in the reference value, which d iminishes the separation of concerns
	of the different roles in a GNAP system.</t>		of the different roles in a GNAP system.</t>
	<t>To mitigate this, the AS should only use fully random or encrypted va lues for resource references.</t>		<t>To mitigate this, the AS should only use fully random or encrypted va lues for resource references.</t>
	</section>		</section>
	<section anchor="token-re-issuance-from-an-untrusted-as">		<section anchor="token-re-issuance-from-an-untrusted-as">
	<name>Token Re-Issuance From an Untrusted AS</name>		<name>Token Reissuance from an Untrusted AS</name>
	<t>It is possible for an attacker's client instance to issue its own tok ens to another client instance, acting as		<t>It is possible for an attacker's client instance to issue its own tok ens to another client instance, acting as
	an AS that the second client instance has chosen to trust. If the token is a bea rer token or the re-issuance		an AS that the second client instance has chosen to trust. If the token is a bea rer token or the reissuance
	is bound using an AS-provided key, the target client instance will not be able t o tell that the token was originally		is bound using an AS-provided key, the target client instance will not be able t o tell that the token was originally
	issued by the valid AS. This process allows an attacker to insert their own sess ion and rights into an unsuspecting		issued by the valid AS. This process allows an attacker to insert their own sess ion and rights into an unsuspecting
	client instance, in the guise of a token valid for the attacker that appears to have been issued to the target		client instance in the guise of a valid token for the attacker that appears to h ave been issued to the target
	client instance on behalf of its own RO.</t>		client instance on behalf of its own RO.</t>
	<t>This attack is predicated on a misconfiguration with the targeted cli ent, as it has been configured to get tokens		<t>This attack is predicated on a misconfiguration with the targeted cli ent, as it has been configured to get tokens
	from the attacker's AS and use those tokens with the target RS, which has no ass ociation with the attacker's AS.		from the attacker's AS and use those tokens with the target RS, which has no ass ociation with the attacker's AS.
	However, since the token is ultimately coming from the trusted AS, and is being presented with a valid key,		However, since the token is ultimately coming from the trusted AS and is being p resented with a valid key,
	the RS has no way of telling that the token was passed through an intermediary.< /t>		the RS has no way of telling that the token was passed through an intermediary.< /t>
	<t>To mitigate this, the RS can publish its association with the trusted AS through either discovery or documentation.		<t>To mitigate this, the RS can publish its association with the trusted AS through either discovery or documentation.
	Therefore, a client properly following this association would only go directly t		Therefore, a client properly following this association would only go directly t
	o the trusted RS directly for		o the trusted RS for
	access tokens for the RS.</t>		access tokens for the RS.</t>
	<t>Furthermore, limiting the use of bearer tokens and AS-provided keys t
	o only highly trusted AS's and limited circumstances		<t>Furthermore, limiting the use of bearer tokens and AS-provided keys t
	prevents the attacker from being able to willingly exfiltrate their token to an		o only highly trusted ASs in certain circumstances prevents the attacker from be
	unsuspecting client instance.</t>		ing able to willingly exfiltrate their token to an unsuspecting client instance.
			</t>
	</section>		</section>
	<section anchor="introspection-of-token-keys">		<section anchor="introspection-of-token-keys">
	<name>Introspection of Token Keys</name>		<name>Introspection of Token Keys</name>
	<t>The introspection response defined in <xref target="introspection"/>		<t>The introspection response defined in <xref target="introspection"/>
	provides a means for the AS to tell the RS the key		provides a means for the AS to tell the RS what key material is needed to valida
	material needed to validate the key proof of the request. Capture of the introsp		te the key proof of the request. Capture of the introspection response can expos
	ection response can expose		e
	these security keys to an attacker. In the case of asymmetric cryptography, only the public key is exposed,		these security keys to an attacker. In the case of asymmetric cryptography, only the public key is exposed,
	and the token cannot be re-used by the attacker based on this result alone. This could potentially divulge		and the token cannot be reused by the attacker based on this result alone. This could potentially divulge
	information about the client instance that was unknown otherwise.</t>		information about the client instance that was unknown otherwise.</t>
	<t>If an access token is bound to a symmetric key, the RS will need acce ss to the full key value in order to validate		<t>If an access token is bound to a symmetric key, the RS will need acce ss to the full key value in order to validate
	the key proof of the request, as described in <xref target="security-key-proof"/ >. However, divulging the key		the key proof of the request, as described in <xref target="security-key-proof"/ >. However, divulging the key
	material to the RS also gives the RS the ability to create a new request with th e token.		material to the RS also gives the RS the ability to create a new request with th e token.
	In this circumstance, the RS is under similar risk of token exfiltration and		In this circumstance, the RS is under similar risk of token exfiltration and
	re-use as a bearer token, as described in <xref target="security-token-reuse-by- rs"/>. Consequently, symmetric		reuse as a bearer token, as described in <xref target="security-token-reuse-by-r s"/>. Consequently, symmetric
	keys should only be used in systems where the RS can be fully trusted to not cre ate a new request with		keys should only be used in systems where the RS can be fully trusted to not cre ate a new request with
	tokens presented to it.</t>		tokens presented to it.</t>
	</section>		</section>
	<section anchor="security-rs-registration">		<section anchor="security-rs-registration">
	<name>RS Registration and Management</name>		<name>RS Registration and Management</name>
	<t>Most functions of the RS-facing API in <xref target="rs-facing-api"/> are protected by requiring the RS to		<t>Most functions of the RS-facing API in <xref target="rs-facing-api"/> are protected by requiring the RS to
	present proof of a signing key along with the request, in order to identify the RS making the		present proof of a signing key along with the request, in order to identify the RS making the
	call, potentially coupled with an AS-specific access token.		call, potentially coupled with an AS-specific access token.
	This practice allows the AS to differentially respond to API calls to different RS's, such as		This practice allows the AS to differentially respond to API calls to different RSs, such as
	answering introspection calls with only the access rights relevant to a given RS instead of		answering introspection calls with only the access rights relevant to a given RS instead of
	all access rights an access token could be good for.</t>		all access rights an access token could be good for.</t>
	<t>While the means by which an RS and its keys become known to the AS is out of scope for this		<t>While the means by which an RS and its keys become known to the AS is out of scope for this
	specification, it is anticipated that common practice will be to statically regi ster an		specification, it is anticipated that common practice will be to statically regi ster an
	RS, allowing it to protect specific resources or certain classes of resources.		RS, allowing it to protect specific resources or certain classes of resources.
	Fundamentally, the RS can only offer the resources that it serves. However, a ro gue AS could		Fundamentally, the RS can only offer the resources that it serves. However, a ro gue AS could
	attempt to register a set of resources that mimics a different RS in order to so licit an access		attempt to register a set of resources that mimics a different RS in order to so licit an access
	token usable at the target RS. If the access token is a bearer token or is bound to a symmetric		token that is usable at the target RS. If the access token is a bearer token or is bound to a symmetric
	key that is known to the RS, then the attacker's RS gains the ability and knowle dge needed		key that is known to the RS, then the attacker's RS gains the ability and knowle dge needed
	to use that token elsewhere.</t>		to use that token elsewhere.</t>
	<t>In some ecosystems, dynamic registration of an RS and its associated resources is feasible.		<t>In some ecosystems, dynamic registration of an RS and its associated resources is feasible.
	In such systems, the identity of the RS could be conveyed by a URI passed in the <tt>location</tt> field		In such systems, the identity of the RS could be conveyed by a URI passed in the <tt>location</tt> field
	of an access rights request, thereby allowing the AS to limit the view the RS ha s into the		of an access rights request, thereby allowing the AS to limit the view the RS ha s into the
	larger system.</t>		larger system.</t>
	</section>		</section>
	</section>		</section>
	<section anchor="Privacy">		<section anchor="Privacy">
	<name>Privacy Considerations</name>		<name>Privacy Considerations</name>
	<section anchor="token-contents">		<section anchor="token-contents">
	<name>Token Contents</name>		<name>Token Contents</name>
	<t>The contents of the access token could potentially contain personal i nformation about the end-user, RO, or other parties.		<t>The contents of the access token could potentially contain personal i nformation about the end user, RO, or other parties.
	This is true whether the contents are parsed from the token itself or sent in an introspection response.</t>		This is true whether the contents are parsed from the token itself or sent in an introspection response.</t>
	<t>While an RS will sometimes need this information for processing, it's often the case that an RS is exposed to these		<t>While an RS will sometimes need this information for processing, it's often the case that an RS is exposed to these
	details only in passing, and not intentionally. For example, consider a client t hat is issued an access token that is		details only in passing, and not intentionally. For example, consider a client t hat has been issued an access token that is
	usable for both medical and non-medical APIs. If this access token contains a me dical record number to facilitate the		usable for both medical and non-medical APIs. If this access token contains a me dical record number to facilitate the
	RS serving the medical API, then any RS for a non-medical API would also learn t he user's medical record number		RS serving the medical API, then any RS for a non-medical API would also learn t he user's medical record number
	in the process, even though that API has no need to make such a correlation.</t>		in the process, even though that API has no need to make such a correlation.</t>
	<t>To mitigate this, a formatted token could contain separate sections t argeted to different RS's to segregate data.		<t>To mitigate this, a formatted token could contain separate sections t argeted to different RSs to segregate data.
	Alternatively, token introspection can be used to limit the data returned to eac h RS, as defined in <xref target="introspection"/>.</t>		Alternatively, token introspection can be used to limit the data returned to eac h RS, as defined in <xref target="introspection"/>.</t>
	</section>		</section>
	<section anchor="token-use-disclosure-through-introspection">		<section anchor="token-use-disclosure-through-introspection">
	<name>Token Use Disclosure through Introspection</name>		<name>Token Use Disclosure through Introspection</name>
	<t>When introspection is used by an RS, the AS is made aware of a partic ular token being used at a particular RS.		<t>When introspection is used by an RS, the AS is made aware of a partic ular token being used at a particular RS.
	When the RS is a separate system, the AS would not otherwise have insight into t his action. This can potentially		When the RS is a separate system, the AS would not otherwise have insight into t his action. This can potentially
	lead to the AS learning about patterns and actions of particular end users by wa tching which RS's are accessed		lead to the AS learning about patterns and actions of particular end users by wa tching which RSs are accessed
	and when.</t>		and when.</t>
	</section>		</section>
	<section anchor="mapping-a-user-to-an-as">		<section anchor="mapping-a-user-to-an-as">
	<name>Mapping a User to an AS</name>		<name>Mapping a User to an AS</name>
	<t>When the client instance receives information about the protecting AS from an RS, this can be used to		<t>When the client instance receives information about the protecting AS from an RS, it can be used to
	derive information about the resources being protected without releasing the res ources themselves. For example,		derive information about the resources being protected without releasing the res ources themselves. For example,
	if a medical record is protected by a personal AS, an untrusted client could cal l an RS to discover the location		if a medical record is protected by a personal AS, an untrusted client could cal l an RS to discover the location
	of the AS protecting the record. Since the AS is tied strongly to a single RO, t he untrusted and unauthorized client		of the AS protecting the record. Since the AS is tied strongly to a single RO, t he untrusted and unauthorized client
	software can gain information about the resource being protected without accessi ng the record itself.</t>		software can gain information about the resource being protected without accessi ng the record itself.</t>
	</section>		</section>
	</section>		</section>
	<section anchor="Acknowledgements">
	<name>Acknowledgements</name>
	<t>The editors would like to thank the feedback of the following individua
	ls for their reviews,
	implementations, and contributions:
	Aaron Parecki,
	Adrian Gropper,
	Andrii Deinega,
	Annabelle Backman,
	Dmitry Barinov,
	Fabien Imbault,
	Florian Helmschmidt,
	George Fletcher,
	Justin Richer,
	Kathleen Moriarty,
	Leif Johansson,
	Mike Varley,
	Nat Sakimura,
	Takahiko Kawasaki,
	Yaron Sheffer.</t>
	<t>Finally, the editors want to acknowledge the immense contributions of A
	aron Parecki to the content
	of this document. We thank him for his insight, input, and hard work, without wh
	ich GNAP would
	not have grown to what it is.</t>
	</section>
	</middle>		</middle>
	<back>		<back>
			<displayreference target="RFC9635" to="GNAP"/>
			<displayreference target="RFC7519" to="JWT"/>
	<references>		<references>
	<name>References</name>		<name>References</name>
	<references anchor="sec-normative-references">		<references anchor="sec-normative-references">
	<name>Normative References</name>		<name>Normative References</name>
	<reference anchor="BCP195" target="https://www.rfc-editor.org/info/bcp19
	5">
	<front>
	<title>Recommendations for Secure Use of Transport Layer Security (T
	LS) and Datagram Transport Layer Security (DTLS)</title>
	<author initials="Y." surname="Sheffer">
	<organization/>
	</author>
	<author initials="R." surname="Holz">
	<organization/>
	</author>
	<author initials="P." surname="Saint-Andre">
	<organization/>
	</author>
	<date year="2015" month="May"/>
	</front>
	</reference>
	<reference anchor="RFC2119">
	<front>
	<title>Key words for use in RFCs to Indicate Requirement Levels</tit
	le>
	<author fullname="S. Bradner" initials="S." surname="Bradner"/>
	<date month="March" year="1997"/>
	<abstract>
	<t>In many standards track documents several words are used to sig
	nify the requirements in the specification. These words are often capitalized. T
	his document defines these words as they should be interpreted in IETF documents
	. This document specifies an Internet Best Current Practices for the Internet Co
	mmunity, and requests discussion and suggestions for improvements.</t>
	</abstract>
	</front>
	<seriesInfo name="BCP" value="14"/>
	<seriesInfo name="RFC" value="2119"/>
	<seriesInfo name="DOI" value="10.17487/RFC2119"/>
	</reference>
	<reference anchor="RFC3986">
	<front>
	<title>Uniform Resource Identifier (URI): Generic Syntax</title>
	<author fullname="T. Berners-Lee" initials="T." surname="Berners-Lee
	"/>
	<author fullname="R. Fielding" initials="R." surname="Fielding"/>
	<author fullname="L. Masinter" initials="L." surname="Masinter"/>
	<date month="January" year="2005"/>
	<abstract>
	<t>A Uniform Resource Identifier (URI) is a compact sequence of ch
	aracters that identifies an abstract or physical resource. This specification de
	fines the generic URI syntax and a process for resolving URI references that mig
	ht be in relative form, along with guidelines and security considerations for th
	e use of URIs on the Internet. The URI syntax defines a grammar that is a supers
	et of all valid URIs, allowing an implementation to parse the common components
	of a URI reference without knowing the scheme-specific requirements of every pos
	sible identifier. This specification does not define a generative grammar for UR
	Is; that task is performed by the individual specifications of each URI scheme.
	[STANDARDS-TRACK]</t>
	</abstract>
	</front>
	<seriesInfo name="STD" value="66"/>
	<seriesInfo name="RFC" value="3986"/>
	<seriesInfo name="DOI" value="10.17487/RFC3986"/>
	</reference>
	<reference anchor="JWT">
	<front>
	<title>JSON Web Token (JWT)</title>
	<author fullname="M. Jones" initials="M." surname="Jones"/>
	<author fullname="J. Bradley" initials="J." surname="Bradley"/>
	<author fullname="N. Sakimura" initials="N." surname="Sakimura"/>
	<date month="May" year="2015"/>
	<abstract>
	<t>JSON Web Token (JWT) is a compact, URL-safe means of representi
	ng claims 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) stru
	cture or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the
	claims to be digitally signed or integrity protected with a Message Authenticat
	ion Code (MAC) and/or encrypted.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="7519"/>
	<seriesInfo name="DOI" value="10.17487/RFC7519"/>
	</reference>
	<reference anchor="RFC8174">
	<front>
	<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
	tle>
	<author fullname="B. Leiba" initials="B." surname="Leiba"/>
	<date month="May" year="2017"/>
	<abstract>
	<t>RFC 2119 specifies common key words that may be used in protoco
	l specifications. This document aims to reduce the ambiguity by clarifying that
	only UPPERCASE usage of the key words have the defined special meanings.</t>
	</abstract>
	</front>
	<seriesInfo name="BCP" value="14"/>
	<seriesInfo name="RFC" value="8174"/>
	<seriesInfo name="DOI" value="10.17487/RFC8174"/>
	</reference>
	<reference anchor="RFC8259">
	<front>
	<title>The JavaScript Object Notation (JSON) Data Interchange Format
	</title>
	<author fullname="T. Bray" initials="T." role="editor" surname="Bray
	"/>
	<date month="December" year="2017"/>
	<abstract>
	<t>JavaScript Object Notation (JSON) is a lightweight, text-based,
	language-independent data interchange format. It was derived from the ECMAScrip
	t Programming Language Standard. JSON defines a small set of formatting rules fo
	r the portable representation of structured data.</t>
	<t>This document removes inconsistencies with other specifications
	of JSON, repairs specification errors, and offers experience-based interoperabi
	lity guidance.</t>
	</abstract>
	</front>
	<seriesInfo name="STD" value="90"/>
	<seriesInfo name="RFC" value="8259"/>
	<seriesInfo name="DOI" value="10.17487/RFC8259"/>
	</reference>
	<reference anchor="GNAP">
	<front>
	<title>Grant Negotiation and Authorization Protocol</title>
	<author fullname="Justin Richer" initials="J." surname="Richer">
	<organization>Bespoke Engineering</organization>
	</author>
	<author fullname="Fabien Imbault" initials="F." surname="Imbault">
	<organization>acert.io</organization>
	</author>
	<date day="19" month="March" year="2024"/>
	<abstract>
	<t> GNAP defines a mechanism for delegating authorization to a p
	iece of
	software, and conveying the results and artifacts of that delegation
	to the software. This delegation can include access to a set of APIs
	as well as subject information passed directly to the software.
	</t>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml9/reference.BCP.
	</abstract>		0195.xml"/>
	</front>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
	<seriesInfo name="Internet-Draft" value="draft-ietf-gnap-core-protocol		119.xml"/>
	-20"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
	</reference>		986.xml"/>
	<reference anchor="RFC8792">		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
	<front>		519.xml"/>
	<title>Handling Long Lines in Content of Internet-Drafts and RFCs</t		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	itle>		174.xml"/>
	<author fullname="K. Watsen" initials="K." surname="Watsen"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	<author fullname="E. Auerswald" initials="E." surname="Auerswald"/>		259.xml"/>
	<author fullname="A. Farrel" initials="A." surname="Farrel"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
	<author fullname="Q. Wu" initials="Q." surname="Wu"/>		635.xml"/>
	<date month="June" year="2020"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	<abstract>		792.xml"/>
	<t>This document defines two strategies for handling long lines in
	width-bounded text content. One strategy, called the "single backslash" strateg
	y, is based on the historical use of a single backslash ('\') character to indic
	ate where line-folding has occurred, with the continuation occurring with the fi
	rst character that is not a space character (' ') on the next line. The second s
	trategy, called the "double backslash" strategy, extends the first strategy by a
	dding a second backslash character to identify where the continuation begins and
	is thereby able to handle cases not supported by the first strategy. Both strat
	egies use a self-describing header enabling automated reconstitution of the orig
	inal content.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="8792"/>
	<seriesInfo name="DOI" value="10.17487/RFC8792"/>
	</reference>
	</references>		</references>
	<references anchor="sec-informative-references">		<references anchor="sec-informative-references">
	<name>Informative References</name>		<name>Informative References</name>
	<reference anchor="MACAROON" target="https://research.google/pubs/pub418		<reference anchor="MACAROON" target="https://www.ndss-symposium.org/ndss
	92/">		2014/
			ndss-2014-programme/macaroons-cookies-contextual-caveats-
			decentralized-authorization-cloud/">
	<front>		<front>
	<title>Macaroons: Cookies with Contextual Caveats for Decentralized Authorization in the Cloud</title>		<title>Macaroons: Cookies with Contextual Caveats for Decentralized Authorization in the Cloud</title>
	<author>		<author fullname="Arnar Birgisson"/>
	<organization/>		<author fullname="Joe Gibbs Politz"/>
	</author>		<author fullname="Ulfar Erlingsson"/>
	<date year="2014"/>		<author fullname="Ankur Taly"/>
			<author fullname="Michael Vrable"/>
			<author fullname="Mark Lentczner"/>
			<date month="February" year="2014"/>
	</front>		</front>
			<refcontent>NDSS Symposium 2014</refcontent>
			<seriesInfo name="DOI" value="10.14722/ndss.2014.23212"/>
	</reference>		</reference>
	<reference anchor="BISCUIT" target="https://www.biscuitsec.org/">		<reference anchor="BISCUIT" target="https://www.biscuitsec.org/">
	<front>		<front>
	<title>Biscuit Authorization</title>		<title>Biscuit Authorization</title>
	<author>		<author>
	<organization/>		<organization>Biscuit</organization>
	</author>		</author>
	<date>n.d.</date>
	</front>		</front>
	</reference>		</reference>
	<reference anchor="ZCAPLD" target="https://w3c-ccg.github.io/zcap-spec/" >		<reference anchor="ZCAPLD" target="https://w3c-ccg.github.io/zcap-spec/" >
	<front>		<front>
	<title>Authorization Capabilities for Linked Data</title>		<title>Authorization Capabilities for Linked Data v0.3</title>
	<author>		<author fullname="Christine Lemmer-Webber" role="editor"/>
	<organization/>		<author fullname="Manu Sporny" role="editor"/>
	</author>		<date month="January" year="2023"/>
	<date year="2023"/>
	</front>
	</reference>
	<reference anchor="RFC8126">
	<front>
	<title>Guidelines for Writing an IANA Considerations Section in RFCs
	</title>
	<author fullname="M. Cotton" initials="M." surname="Cotton"/>
	<author fullname="B. Leiba" initials="B." surname="Leiba"/>
	<author fullname="T. Narten" initials="T." surname="Narten"/>
	<date month="June" year="2017"/>
	<abstract>
	<t>Many protocols make use of points of extensibility that use con
	stants to identify various protocol parameters. To ensure that the values in the
	se fields do not have conflicting uses and to promote interoperability, their al
	locations are often coordinated by a central record keeper. For IETF protocols,
	that role is filled by the Internet Assigned Numbers Authority (IANA).</t>
	<t>To make assignments in a given registry prudently, guidance des
	cribing the conditions under which new values should be assigned, as well as whe
	n and how modifications to existing values can be made, is needed. This document
	defines a framework for the documentation of these guidelines by specification
	authors, in order to assure that the provided guidance for the IANA Consideratio
	ns is clear and addresses the various issues that are likely in the operation of
	a registry.</t>
	<t>This is the third edition of this document; it obsoletes RFC 52
	26.</t>
	</abstract>
	</front>		</front>
	<seriesInfo name="BCP" value="26"/>		<refcontent>W3C Draft Community Group Report</refcontent>
	<seriesInfo name="RFC" value="8126"/>
	<seriesInfo name="DOI" value="10.17487/RFC8126"/>
	</reference>		</reference>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 126.xml"/>
	</references>		</references>
	</references>		</references>
	<?line 1517?>		<section anchor="Acknowledgements" numbered='false'>
			<name>Acknowledgements</name>
	<section anchor="history">		<t>The editors would like to thank the following
	<name>Document History</name>		individuals for their reviews, feedback, implementations, and contribution
	<ul spacing="normal">		s:
	<li>		<contact fullname="Aaron Parecki"/>, <contact fullname="Adrian
	<t>-09		Gropper"/>, <contact fullname="Andrii Deinega"/>, <contact
	</t>		fullname="Annabelle Backman"/>, <contact fullname="Dmitry Barinov"/>,
	<ul spacing="normal">		<contact fullname="Fabien Imbault"/>, <contact fullname="Florian
	<li>		Helmschmidt"/>, <contact fullname="George Fletcher"/>, <contact
	<t>Updated description of well-known discovery endpoint.</t>		fullname="Justin Richer"/>, <contact fullname="Kathleen Moriarty"/>,
	</li>		<contact fullname="Leif Johansson"/>, <contact fullname="Mike Varley"/>,
	</ul>		<contact fullname="Nat Sakimura"/>, <contact fullname="Takahiko
	</li>		Kawasaki"/>, and <contact fullname="Yaron Sheffer"/>.</t>
	<li>		<t>Additionally, the editors want to acknowledge the immense contributions
	<t>-08		of
	</t>		<contact fullname="Aaron Parecki"/> to the content of this document. We
	<ul spacing="normal">		thank him for his insight, input, and hard work, without which GNAP
	<li>		would not have grown to what it is.</t>
	<t>Editorial and IANA updates based on review feedback.</t>
	</li>
	</ul>
	</li>
	<li>
	<t>-07
	</t>
	<ul spacing="normal">
	<li>
	<t>Editorial updates based on review feedback.</t>
	</li>
	</ul>
	</li>
	<li>
	<t>-06
	</t>
	<ul spacing="normal">
	<li>
	<t>Editorial updates based on review feedback.</t>
	</li>
	</ul>
	</li>
	<li>
	<t>-05
	</t>
	<ul spacing="normal">
	<li>
	<t>Added discussion of access tokens used to call the RS-facing AS
	APIs.</t>
	</li>
	<li>
	<t>Updated IANA sections to align with core (and each other).</t>
	</li>
	<li>
	<t>Added IANA section on introspection requests.</t>
	</li>
	<li>
	<t>Added error responses.</t>
	</li>
	<li>
	<t>Added extended discussion on resource server registration pract
	ices.</t>
	</li>
	</ul>
	</li>
	<li>
	<t>-04
	</t>
	<ul spacing="normal">
	<li>
	<t>Editorial cleanup.</t>
	</li>
	<li>
	<t>Updated IANA requirements, including "specification required" r
	egistration.</t>
	</li>
	<li>
	<t>Added privacy and security considerations.</t>
	</li>
	<li>
	<t>Clarified and expanded token introspection request and response
	.</t>
	</li>
	<li>
	<t>Clarified and expanded resource set registration request and re
	sponse, include example of use of resource reference.</t>
	</li>
	<li>
	<t>Updated discovery.</t>
	</li>
	<li>
	<t>Allow optional tokens on RS-facing API requests.</t>
	</li>
	<li>
	<t>Tighter controls over derived tokens.</t>
	</li>
	</ul>
	</li>
	<li>
	<t>-03
	</t>
	<ul spacing="normal">
	<li>
	<t>Added token model.</t>
	</li>
	<li>
	<t>Added IANA sections.</t>
	</li>
	</ul>
	</li>
	<li>
	<t>-02
	</t>
	<ul spacing="normal">
	<li>
	<t>Editorial and formatting fixes.</t>
	</li>
	</ul>
	</li>
	<li>
	<t>-01
	</t>
	<ul spacing="normal">
	<li>
	<t>Better described RS authentication.</t>
	</li>
	<li>
	<t>Added access token format registry.</t>
	</li>
	<li>
	<t>Filled out introspection protocol.</t>
	</li>
	<li>
	<t>Filled out resource registration protocol.</t>
	</li>
	<li>
	<t>Expanded RS-facing discovery mechanisms.</t>
	</li>
	<li>
	<t>Moved client-facing RS response back to GNAP core document.</t>
	</li>
	</ul>
	</li>
	<li>
	<t>-00
	</t>
	<ul spacing="normal">
	<li>
	<t>Extracted resource server section.</t>
	</li>
	</ul>
	</li>
	</ul>
	</section>		</section>
	</back>		</back>
	<!-- ##markdown-source:
	H4sIAAAAAAAAA+1963bbVpbmfzwFRl5rbE+T9C1OYk13dcu3ihLbcklyuZOa
	WjZIHpKIQIANgJJZtvtZ5lnmyWZfzw2gRDmu7q5elR9VFgGc6z57f/t6hsNh
	0uZtYfbTm7+vs7JNX5l51eZZm1dlmpXT9GDdLqo6/wv/8rqu2mpSFemxaap1
	PTHpianPTZ0+qcrSTPCd5mYyrSZltoQ2p3U2a4e5aWfDeZmthrV8NWzoq2Z4
	91EyyVrost7sp007TZJ8Ve+nbb1u2vt37z66ez/JapPtQzeTdZ23m+Siqs/m
	dbVe7ae/f3XwOjkzG/hpup8elq2pS9MOn2KnSdK0MPx3WVGVMJCNaZJVvp/+
	CUY/SOF/8nJqynaQNlXd1mbWwL82S/lHW+cTeDSplqtM/rGEl+FRXhZ5aQYp
	THCZrVZ5Of9zkmS0QvtJmg7hhWY//XGUHueThanhpzTllfgRJpSX/u9VPc9K
	Wdf99LFpVtWZSZ+Vc+jB1NA0vWWWWV7sp7iE//IrtTGqqY0RfE9vwLLsp4u2
	XTX7d+6Mm9XZKK/u0JO6wn0107yt6sQN7/koPVyOs3XReuN7no1zUwYPwgFm
	E1O30LQ/qhl9NMr5o38JXgmGpU/uJElZ1Uto8tzs02uPn7y+9+gh/ztN26ye
	mxZoUT+8uLgY1bPJkCeBc76Tl7Pqzniygs9u6mdMwceGd2pKQ27SWVUz3Zj0
	TWPSapaeAonDOtdt+iLbmNpSVXrr9MXJbaL3p1mbzetsecm7T/Fl6Rr6gp5f
	Zpv0/t17D+VHRxH839D+K+Ut+HmUnizMbCak0PvO8Sj9oSr+sv2F19BIlpft
	8KCc1oaeHj9/cv/evUf7+seDR99/y3/8+PZ0H3/57uG9R/r0+3vffWNf/f7+
	Q/kOjxUcp+HTkTu4k6o2w5Uc/iSB0wArwa+fPHvxfD/dgybSD/DfHhxh2KFg
	k18ePDk4Pjp65VZEN1r3GRiDyerJYjSvqnlh7qzW4wb/55t73z+6f8d9xhu9
	9zKbZHVV4So8qaqz3DTpRd4ukAu15kO7zor0SXZuspaJ4KmZwIjrrMj/YmKO
	BoeyXZj0SVGtp3u2I95W2NJvmEoPT568OTzdPn6k03HeTNZ525gJ0Wk86Mf8
	OOyeXvrlycHrF08vafzBZDiZzEdzmOJ6jMfoLxPYk2ZlJt2lCWf3JFvBGS3y
	FpcIl+JFXp4ZpvLubO8/SJLhcJhmY+CBwPqSBGkhnZoZ8KQmzdKlmSyAJzRL
	amtqCjOHfsq5ULz22lbw7iqHVYdDlzTVrL0ALp7ewoWeFMAy2tsDOmyTqjw3
	G2wAHwERABtp6ElWt/kMhtDgsW0XWWt7g0WD9vF9bXiUnC7yJoWNN2WD/euA
	lwZGNeWJq+hJRfSkt47hxENLE5ZcCRFQOA/76gG8mqM8hP8FKVOtTJ2NCwMM
	sFnAiyNetmU+nRYmSW6gLKqr6ZrkYQKjg2nDAaKTleK25bN8wl3c+vgRf/38
	+bYd9TRHNj9piX/z4HG2wdASHhqPDNdL1s+fIs0QmciFgb8G9AoNIxgBCGvo
	pKxa6T9dVBf06vFJClSIu9Fc4CLAUuVL5IeIEv5tbRpisiAu1xNYNziAC1ht
	YGhZOoeDD4s1mZgGPzuDP2B74P2iSM/hEE5BtMDrsKeNaXF/5dU6ny+gQ5os
	/ZLYj0HY1tU5EC6sBqz220UOq5+3N5t0VTVNTnsh63RwQgsCw4cRjw0cDGi1
	2MDU16vCTN2As7QByoMNm5pVUW2gcVk3poS0WQBtwY8geLI5rNqmac1ywJto
	F22FRLs0KVHYv61zYMTcPvfLvUI3IHNbnAhsLOAZ6nhDwAJoYNvI63WZ4A/L
	rIQB4PBWWQ1HtdgM0hUekMm6yGpoB0hzkjWG9gD2VyeGDSLPNniMlnC0cliA
	5PgEVq3J8e+sNNW6KTajhE9QSJru2Ms2HZ8M4UjiaT14fdjwqYQjAb1M4P+W
	2ZlJsnMABpluRzY9z8oJjLyoqgaGPZQ9SHnFCVSN0oMpCHfoMCtwYi0OBPDV
	Gp8mbgxzU8KhK4ardQ1bbtJlBQyBe/EIDejxYgH4iEYES7huoLccjgsgykkL
	SAD2n4VTCw+CL3ELURgwyeEBxuWglagRnJWwwKO+dcqKpgp4JDKdhEZWymZO
	AdCd48ZMq4sSxmIAX3BH+NoEZk5MFAgKNjAFHgttISGMmHksTVYKIzS9LAoo
	q1kjZHRnR9oXVslcF3FDiztiWUbQcvRSgrSNkl7Yc1+7MctBNk+seT3+FRZP
	Wk62cT9lfjDPGzfSU1Mv87IqqvmG5w3YPkVw34DEf3Nyujfg/09fHdG/j5/9
	4c3h8bOn+O+THw5evLD/SOSNkx+O3rx46v7lvnxy9PLls1dP+WP4NQ1+SvZe
	Hvy8xzJq7+j16eHRq4MXe4wVPPLk6dJZJbkAC0Zk1QDdNpM6HxPxIcb9f//3
	3jcw2/8hAO3zZ/kDIRj8Aee25N6qEs4z/wkLt0mA8QEwIuED3BPEft4CvQ2Q
	fzXAqcsUTzws3//6E67Mn/fTf0Ro/M3v5AeccPCjrlnwI61Z95fOx7yIPT/1
	dGNXM/g9WulwvAc/B3/runs//uM/o/6VDu99/8+/S4Rp2c0AQd7CwUG+XA6t
	mgGwIFuuUJACLRLXBHDI2AN/bk36w+npazgITQNMFlb2x5OjV6nlF/DDm+MX
	8L8g8Wri2MAJWBkE6mxk0+jYAj4RjnZSLb1+gQc5lgy4KqfDPs4mZ00B+CF9
	/3/ek3Atp3gsTEpTvKhZvyQGATrsHCXn2vDOA/xQ+vnu0X04PimeFmwHWAcC
	NzyJMK7CZFNsowE9Fheg5GaRITOzAvIlIQbLokyAukG+4w6jPbQ4TDrFuOzE
	8KaKn1v/dWGbylY6mMOee14+FO351EibuVPe8GtVOhgN7fezP4RBA+Ffg14c
	5P0Kp4Z+PIIfQVnE/an/NyEYA0csa8JudVeh57aFI71uQf/3WeEgnaPhBEQy
	8HiAJXMzUKkLy6O9DhjdDJQz2n+kVlsCHEn72IBCHiwFbpMIspD/INtMD3gs
	pyzEPt6wpPs5SQ4CAZcRNggxPMtv2FfZBHghlhVFvswDaclyDWWhaUwkRKkP
	i91r48mQzAMt/ciPFhJ6aqukT2hhzyhTULIvsmKmBHZ8NEoZEeJfvJpe4zKy
	86xGJQjAwDRHzRubZkwHAL8xBnH3ZN00ohR+/EjfDbk5wOcKoGEkK26+g3FB
	zoECAk2iaJgAgGiIa7Pg465Y0v0+AjP+HqYvEdlcrjXo+YHJwpD5aLM4Ltj2
	schXsEjthTGlL9pV7B+cAJPKaU0jwZ4AeVWrDLhdCB22qQ9prD5kshqEzyLt
	AyjtApWA0tAmpwiFW5Mo6cjgjqO31iXAJ7LmyVbCMalSRKKg1yLDzIDRnQMY
	hD1R4gce72lq+CJAy0wAdxJsGwNJmLaQKnTKMjU8PJaUbTOWhgknNrrjjrpE
	efagLgmsAigE+8NFw0HC9KaMIpJ1maPCCaNHWAiypjYL1GnPgX8A50kB/aOk
	Ib7WIKuar/Opno0cxQ12hNpajvgdFqVCIZKAgp95Mo017KapJnmG89VjoDQb
	j5z4EpBpp5na0FrAsFFyTROf5Jw2Y3Ia9XgDXIwZgYPjsgnCiV4fDov8zHg8
	iv7sw+R0ZD9+DH6EU6qqTKwu0NB5qy3Fwgqg6ibDIxUzmyxYJsH6IQtLxyDb
	A2Wireas57Lp4BwgqttxsnkQ0gi4+ltSy1RTHaRiO270iH38+OPbUzjNRORZ
	PRUehqZv5cv0W2pgfKD2mqWKXT5lyFNupH9EyQ08H4VYQLqLjHSPdyTa36mG
	lLOgQ2s3AfyMiHIFi2Kmyk8uQJ+1fIS4N+pAh7hfcCbZCGQnH3bKsNg+ZUKD
	PkCpbfOlGTiwQWdI9hjPvH4LVAVsiOwyCH8RVrABdlotAecBBagiDzNWEkYQ
	CEgBlUygN5Jut0fpEe7YRd5gtxeVVaR1rBfVupji+YOvZ7TLdrEZ2vGK8WsI
	qnCEdjioe7FqSEQ/WaCy27j5RSqpR/tZ0ydp8DCsS/ca0Y+gLBU0vj7rHvBy
	kj66IAPHO27zXXpWoq4g5GZP5sDyXJ4mUlaTKMrw2SOfdMLXMG7ZEtvxzUa6
	hh8bxL7WLtYZeTAzjwgU5azRCgDMFqjSnPMmikywvAOYXw7a6VbOEOheHQ4h
	KnUgAmTwjRxow2vynn5+n85yA9vOAv89f/eOvntvDQPprK6W0NeJDOHB6D5+
	YJXbU4dLxOxJGEE1+t6x9Elhz+TpAE/0KDhDZIpBTpXV9UbANkuxjuAXWu1r
	EYUVSnHQaVYMa0sylviyy3blxHUSUyYax4sZrMfhrCMCGmb1ygoV80Z8wrW4
	JPMasnE6U1XtiAXRzSGQGRzUQaKcJUd/H8AWtK947Dwj3YosfgLacf+UdQxZ
	jJCMzOdlhuPFOZIVk6AHzFJa3rB5eApKwBQdENStsOZDZBF1D+WhRRCfeWNH
	rqDKFfxoTSTpqUNQiWIj2zcvLVI8s2bEykVRXTgbVG0m1bzM/2K5HrF86RPZ
	BQ8kNC0mkWlRPiVyV4uiJwIO0LY4EW7qASo12KNmI1YtsoVaGal4SBmAPYhT
	kEATNN/2G7IGqFdP/HOQWHWhWdBAkPUxQ/P7G2ci5nheeYvrY/JzYdxinINp
	IrWi9FHCdNZDh1wuNRqKSROgM/8ytWL/Paw4qOxFli+FTg7WU5gDMLd+StED
	h9KJrAqoDJHteYnAHC27lkyQyAlpZpZH2+/xxcRSCMk5phHYW6JwpQz4VTaG
	V4c5sJ2tGw1yfRyKKRpjJaHAP4If2Nu8BsgmyELOEnFVODkyb++UeojbnQ5W
	uBOEwvjnm+NDa7yEjli/FXC+wk2qyx227ws3D8bsNu8wPCa0HWxg+qDbmDfq
	IRCm9r6oWIfyRExFNoFG4Z2Im/eABOtsQ3tK0l2Ap1s2D23iWAgZ0YAGfadG
	macwETkhpre9gKUEcE6BYWJdMORaIFuCkzFqLhYK/wmG/Ri5JGglkYYFHZHe
	gds4rtbldMuZv4kLOUc1G3k+bKAjkzMDap75QBo6KPoB5+o5UBlMAXoTEhil
	z/EwF4UOyA4i44ZDrUZWL/FEn+XGDPjQfB1gH21wwHgLASlZEdo2m5yhYCKG
	1azHTZu365YGndcJQjdsa7omqC7TzXwbm0zgULT9rDFqoWg2yyWiqQnMbF4B
	YF0saSZJOJPGEgJZoMkEth4X8BlN/SJGG5aUSFUnouyQExrEUL/HsftU1CGP
	7sDT3mHj3ogWkgQmAlHhePy1j0bE80LSh/15MBpBZGoPnPEh52E6wsfTdp4B
	bAJF2BDFpoQuVSuGf05yNBc1TDli8B0wdEh4M/GdqXBUj7RE6BNtdXwzyMaK
	i2zT+McAvu+eA9BASO7SnCzWxon4IBDWwNCxnSjrgb0vquoM0Piqd1PhOyZh
	R74XFiGQTxLwybSxvfnL1rL1RMUQrUJWIC8mezwQ1xi+ZaljfUmZszHzqWFt
	tOv5ZOgRe6oCbVv5X0bkZCc8NWyjNv3DVqAhRhq1BrCMbHoBBoJdsu07AISt
	Wt0R2b1p2kHKbEWbYXsrrSVzFmvrjqclHRA6pQPl7KeKLg/VMWR5PTY4Zg7L
	5xIAUrGekm8S5lTN8IE1sAx8BIyiGBd6aciGhDQk8h03JHFWGd+FDpgSTwZa
	AuYG8YaeV9iJGb/ZA/RkUFNvcjo2Yjgdtpg485sQpHjpjVmSN33IoQU4fVEV
	UXY1HP/FJh0S45O2ZxkUkvZogv0OVBXQ0J0nvj2Z3VERSRndoiA6W6ygF2KE
	uYfROzLkaskoMgu+4fGJ2lMtc8I/quZjV0mMopmtIx8lBRANWhiKw4LoCkx1
	CWaalLP36S20suRCD7cFQqXU4hdCMdoED4qFosSX8YEMiSVW5ogL9aGy4rOk
	C563bC+hpSEuBxM3SW3IjUMwFhZhuWob5Qw4Dr93pVkRiLAfqCyzqgf8XiDS
	8yKbNxJ6FdrUcAcJTTvVC82aM/zAt+fqmVoKI1XPIvHYrICjVGGzcm7JaTFF
	NTdwvHmYyEo2ifEJKTJa4QTVgYXqgNZiIKJozYFTYmkmhw8IIdSlG5HKQoA4
	V2GgLgKFZ8rHm3aefrj8AHIf2pRlb+F5vD+6N7oXm2zQrsNLy9YvZggkgBwf
	D47hzoOKXKQ6xh1YRfK8X2UZeGOtDShXnnO2d0Tam6qeTGnH5Inr8xzCiRHA
	og7BPh+eugrEo8dSfWMNgyCEs7zg4C9LRIlvkAHyG2AMmpw1AhOk05I/p8wK
	ZznqOhBxnNyFWv90Fb/v2OOiL6PTEzv3iASyAoVv6xOBfm7jngKScFhhmZ25
	MEeBBdu+R7ar8W5q/zwKX5+0bCfR9xLvPRsOyO86hkkDqKxiX9ooPl5geZ+8
	wg6OBTZC1rBRQTHWegnd18hU5XMy1Qdnzh4mb5PkkZvgNvkqCvAVIpbPdnyi
	O1u+fa8Fj3e3fEcYsNswdzneh1eEoF1mkZBB+Bal0xxO3R8RGaGr4i2Iguqi
	x7okJ1BPNuslpkZ7f4ruGlgo/DKt1i3KChyxeJHElUkxKqZOGIR5BiqOFWBQ
	LY1IZyAaQL/M0bhHMta6bOBBXosygX2TtzIB1Dgck8hN2YGEJujWWRu902mN
	e7gsuLUM17GtUF/2hVvCltKu2pYLGsIFW7XWBEpWt6al6L1GXSIooEGr9Fxa
	N5tER8A+XI7w4tdnqJsCfAVdvwmGdrNx46YQQdmLBVDwkEEq9Qu7zNgxAgq6
	KLU5r87Y8YYAhZaAwz7QyZI1KILclnZ00ZvWoTbojcioZq3xQgBU/6YgibpU
	o7SF+OdKhwFJzZKI2QZRA5HdVmhnmWGois8089bHBURCpnmXq3Et6QnY2O1A
	nl5KQ4GuoNwAeIucQl7VL7YdS/fxgXDUBdx+1loHJR9GCR4mWIoKf98IocWv
	OkKgh5oDRcPxsWeQN533Gw4BH+LrDrkcz77akIkz0iuH1uCMrNc6b6LIYCJz
	0hYycUs7OOI5lqxJ3cHDwGJq4yMsfo880cIne9xdSPc8DOu5ImtC4rpn9qJI
	i22fmevBG2dOQYlTG/bd84qcs84u/NrmX5Fw8HAHw/J9QECjVbNd9LrTLidh
	uyeIWK61iKlmxqMDkaMhj+yB4fBCbNvmOB5hxGBvNJ3CtCAmLeuLNRQQO+XU
	KWt0PD4K3JHjTSLwjGyXYrFCGUVOMD4ztnUKiMMxDTijgozOZJjzo9+YJrvC
	LuCFEttinRU6zpj3LqqCDkGD+7WF8mn0iRs9DwxWakZZG76tsBJdhVfHOYU6
	fB/JVAIm1ZVECQKe27Scer7FPnwEDXw12n2qWgZsYI95y2pg/cSbYIR3TwCh
	h4spcdXGIi1RYPOR5qY52D9apC0nRcNbyACYn2cTIPm8KsSBUFrTonKcIDow
	iUSmmOEaX0eQ1CwLoPudTnwA2b0QncKEYFYjmW8EGJ9XSE96xJV4rCWirwOL
	Q3y7jqZEAMJsI4rFrpyeo9G9MDOAozZAgr7b5oocaYYc9swHQM0nvE0Uk9gN
	9O0YtGPv1EAZLn6C2MV3jEr0HkBCdj6wduWF0Vjq2+I9j3sH4kpCicfGMF9R
	wyWv1vMFZ12JmVLNkxsvPJJcLejoR5JSm9YzGPKbRkMgNOpaY9DozZRiNW22
	SRzwkp727DhyJC8QtPXaTkhAA9vM1botfCLwZ1oe5X960/G/QTrnkMsg7DwI
	W0/EmEKpi5qsGIYaTM62HE3W9+hw609yeOIlciuqEeqhjPEwc4AAGLdj0Btn
	E4qwma0LOE8SJefFL5pK7XziMkX2RmAM50eoY1NOFnVVSuLYqRWkHCjmLH8K
	zGszK4htE5Va8dTk7VosjmOPfHT77TYSWz/ySHaUxM42u1ahzXCWl7CgmO6x
	yshhxwDJzQr/hfLM1F4kFp73xJrd5UvHQpGSpnV2IcEhRJXQmn3uVorULMIH
	MAInpkTdSqTHWUEqEP2bWIkaTdIDK4LEnZ/Xk/VSiEQ6VEaHqUAcqoocG8aD
	q2aXJfMgHpE1RXHSuXzC9HiocqkH4/iuSsst44PoRV71whz/xCYO7Di4INzT
	eQFDGEMAh4MUtzFqpz52CAShOO7omBrNOgGy/hQ9H1uPV5T8YF0lmQwBNWWZ
	k3G/rsQ9H26TdyrQ/brF+5r4HAr9rB23Hps4L4M63OS7fLor4GG9VUZA37mw
	x10UQJ2DCGDsoCgUPpppL6bz81kZvHed4UgvLiisFnEmkdtqnsmbvnV0Xmyd
	Ae2eH+rlnNpyHl5kY8y9IFe6VdK6GS4OphFW7KomRgFTgQ0KT+8NXTgzZoVZ
	YSAjrFGNP0ovDKsYhVjeOfo7jjAUqCbfyPmqzZCVxDgnIbDMNn7wMDXAsFO3
	sVnP4CzS3ADQs+KLm2oDHntTvSlWm8KxPaHkhQxPuEgDkxaNJ/FN4o2di650
	Xtvjw2OAzTroxQKew0gZCU/LMw3RD1dE9e5oT5YwO6bpXhIMLCFfNJTdTFRb
	2ECng6uOMh2C1xmnrxCpHPNi9OUVeNKhb2vtFoQeOEacHSSEciMJ3xTzYaBz
	iPWlxTxy6GY/SYYa8eh5NX2fGg9/2IsfPa9M3+sgSG9VNlft+Ohmc1tEeu9X
	9DKea3G0iHUA5nFbGuxPd7O+Gx2lRPU0BGojF6EclCzIwHSkcW/00JFGQKWs
	cPVojLmNOoieZH7ip7WX29Bbsq9gMgSiOfbzcXxovMoUEHOO6bN9bhb2N0kO
	JYMIcghSTHd4qIKgRLcoQieU8YpiFU3BK0aVEvZklawkBAr++lCsTO8isbIe
	7TXa0MhvPY185LmfTO9sUFlzpr610lxES8BKGLRBpT/m4WqEu1fk5RnDarTs
	JwxfMePZudY7itwiQ2yKKTzwVU7IXbeCovXdWvZyVpJXFHegQSCM9ZljVeW8
	smN2BGok2AC7YqUoOt3OwghTpqHYo3vw+rCfuj3aFh2lMeR+TFzmFZ0a0G9K
	XAUPeZ1xUChMpJz2a5NRVCwKZpCm6i0kSlA9MpyKhKsxiHSeAQnjifFpKs4J
	wA6u+AotrydvA06BZcqsrt0r+NCU4RNW4uJNECJD68KToF801fdMQtgnE2Mz
	AWA2WVj3UuewdWwtY898POXolo3yLptM7bLsqXZbN3c0khmhvca3R6slXULW
	Wk7tDXobJUcaynrgB7nyvlr3oxYAIlXdttrvEWYsnqwyD0v5m5+3akY+GZ7o
	VIIEbcGWPaY/m3fm1lrOBtPeTofilkph+5nfzW0vI4dDK0m53dryt3HLnU+D
	1in0hzU6r1BM2HTdyKNhtsq12Thhf3sHsplU2sL5Tnry0ImKSWHElWXG2HYy
	JIACmau2i5qMW9j+WgPHMGpG7aPBboV5sIMgs5W5nnUPJf5B5khQPBekyXLx
	FTF9TnMAYU1WjKhUICdDicLbFyUv/lhOJFPfMWaSnwx7QzcYrYU5ZTa/K7K9
	iHB8U24bhE2Fv1bnJGDDEdgKN524ikZUi620LJZkrIbhma7fqzjx3L4+q+tH
	0wGyv3Q4lx6ALUPit683oBDg45CYWMYbLzCbs3N4YDseIUpDQYmAddkm1co5
	W4KsfraUafk0jiaQiF0kliFFcM7XdTcHQXyXKHjUk2XJDIifpt1fUEhOYOay
	oMkeJmJJAt8uIQdbH2Dr3DEZMN5Z4iRtdoYubLNqOi5boWw51jadvMtsIgM6
	a9/CcZKwXgGu96Df1iGod/tBikz3yRYWYe1HbF7AUFDiiGODi2/TnAnPeHnO
	GZsMaeQo6C5qjA035XQFEK/FTTigIBmx8nJSKCbic7Zk75hdeg7BmDhOVmEH
	mh1wM5IZmrY45TlUU0VGWlis9Y3U1cLaM+YYvHce9PfApfHsAdbavqiOG2HI
	OhsMbTWFhtizq+hiV8NaZjMM3k3QlNT6pp9o9CIQik04gT5q2zrSRPSYqrGa
	dxhqhTUQKSqBOOuNsDoM6ilLrIn58QY1pxnniUsdwYlTOnsHocQhXQNZssQC
	K4aw6HmwVcVcLjB5YRTBxtAHd6ffLUPFCCvhk9abam3kxKu1RkriYCacZ8T+
	UtgBjYUrdjWUVLYSGMTU1kzRejG1FWjKo0OHnFcVwjebddO6fVGrpSo71g5r
	GCMK8puyPhruYwU0gGhEPd5Nf5ENROqAy4cuSb9TY0ObD/2UjKjJ7hyWrUj7
	i3moSsGGOWXl7PKfZBwZT6/bUg9sq7g0Jz89ibPBE6uSuyp+aKYY56WnikUR
	0JnvMhbqInUlsSnwyGYmRdbERTps1Gy/aSzVBhIp0ofrjaQeLK2rLWkL1MJk
	tfotZrVDJ1IHFp9IWVmqg6WbEsR/UO5asx4PhVF19TlvyZPuOvMxp3qC8L61
	WzbrFRby7FCGVcldSZd0uimzZT7haGO7p1sqvSBHZIU8XRVYc2zk2eew9amB
	xa/ZkLBtFB5+cooEFmeqyIb08aP99+fPaqg7sebfvDYdw5UeUlfDRc925ifM
	eBiqZVVFH7rC5Wg9KIzt+EA7Jglkye5mo13aqrF9RNU5CDafi1fP88MG85Ai
	QiiMbAztAKUPSRTM8Smt3dDNL5EIAVGTCV2FcuGY3qU1Pjx4dTAMpAQVabQx
	UUOu+z587vS8jzdC5S6JYI9lB6WlKk/3bmwstsoWWdsK5SMaYoAYvN6k1Bbl
	sMyCNHj1rNoAkmrF5UXFSEQ0+VRpCP596G8CbixH3MmpgR9sIJgzKPKyMgAm
	QevpvCeudVgUR61oW6NVRzcwzoqCzOx3UtiEjyEl3zYLOigzQ3FRIJfQDIlV
	6oZcz8UdCleRUjPjXzhjFcYOANoHEJhx7AjHMrhQgtAQpAAHGwHG1Cbsu4LG
	3t8Zud7vUGHwDA5J8174ihuPU2zwjFFJRTvEjx+l3DgwxHAXbZVE/CDhXHg3
	DbehpEk1+wlbFN/JwN/Zgd/ioka395N9OqWaaO8CnG422yYdlN5QjeyRr41h
	xWzyuOAi64nTdaYf1bsdSX1BjMT1tEHritN2LTOzFl8nCbzqsZE+ns88duqc
	8bZNuwI63owGSluBReKB9eCrmlOJtGJcsUu2cemnVJYc9ZcFhb/rS1IKc2VL
	+VKLOKQBUw8+jqto0o8lsIk6m0sRT33Eg9d6pfzXCdX86pFqAR/dTgg4Z6EB
	+449iUEb/42WTj0SwHWERpporiloddmYore0jhNnDIZFYqy5Vmm4Z8VO+qqy
	wQbRnkk5quado9VbXNmCS/dhTTTaqwMuXYJbFUCDiMbhcGjEiS/bRDzy1QOy
	8p6Y3yb/nPgj7NQrAbFJrUsLs1JY8M4XB19IfrUTMq6t/+ZkqDCgf+5fSpac
	88xC06fKSwEd7OaZ2byj1PDLCTSkTxUn7gtohheuk2XeBLSqljdqynnvySgi
	FVWoHf91k76nZqNMMwwOilJKbfIdNvFHbkL33z8BWJDltY70pVj8aj0J6C0i
	IGLCYlTxQXA13EU4SypmUCOY+nMozoGkpwoNnvO3dYRDYeM8zM+GjddSrYsg
	lJWiaiEAsvh4A3EOGlb44AD8elMWZGpqtfiKqAlqVDoWm4wYewh8cXqXa1Zr
	C1jnli0Mlqi9tBdCfNeJHsHeDn621VCwMywpHTquq9pmKMAyJoiQljkGp0mJ
	vbS3hIhWlFeTjkZn1M47lshwBrHOaAccmMW1Qot+7maJKsqAY9FbsruoUcVL
	NA5M0xo+RDKXvYnqPQnKKdQY3I/1KF0xB7HGO6+grdqRJP/+7/9OjG0oTsbk
	9RFs5R11CFCZ7zv3RveSH4Dp7ctgRuK2HwHXSoKrU/h6qfT7u29eH//88NXL
	Bw+OXr756eVPJz+9SU50y4eH5WqNjeXze/80Go3cE++3J2wWGp5uVvAzxXMx
	Rd75tUHlYc9KER7T3n76kc7XHqyG/YN+oLMPP+0RB8/newP37NeLs+BlbqHF
	FvaePfHepAeT+hwfANNY3X/47dm9+PlZPsXn9+/evze8+93w7ren9+/u37+/
	f/fBL/GrH/DF4Y+Pjn48/OXXb8pltfpl/IdX351+/+H8QTM2Jw+Hs3fnj1+d
	bN49+6F8/Msk/p5G2Pxanzy8t3rRrh+8/ubFm9M/nm8ODj8cz57+8d3Y3D/+
	eXX48N1s+POv+fmFu7eGRd7n5DNufpLwWbFnZ/9r0MTX3WrZ1+6G73335Lsn
	3xz88uinH45Pvv3Xbx8c/HhwtKcT6/H/kJ58UzgG8lrKiOyU+UR1eN3iWb/E
	22OL9SA7sjYUrRuI/h4Vm5ZJJZVWq2LDFXNJjmOpxzlIcODeNDYKB6T73IYV
	IKm8hn+AapNo5VqvaymJ02+aJ4PlyjH9wM+coEXAGuYHNBxK1tvRLTZKtFRN
	J7Qtlgw2yWGZ2LH53m7nHvAK60gToUD6W+ZZX0jILu0yMIh9vBEqDJYq1BfR
	X4lb68ESEItzkCR0JmmdBblTLjGslqiGpshap/VmuxU1bRVQKR3TDYal8ESs
	JUPRV3GlT3iWS36s2m009I9srEMpQ9Py55LLzV9RbOGqJqfRzIZdRCE41CIM
	2nPwEFaS6OfIxUMWRFwIa1MOFiKxKouD3pJEpf4urwghkXaWNefz5B+G8t8/
	CNv+h/4/k0+ajgC/3Lp3e/i7TymON/0kL8L/H+CfySfNV/CeSEu37vN39Gui
	z9PoxfjP7S/+4/DWg9t2rFe36E0mdU184zexdT34jNzblupEOHRh1AlDvDgK
	Z7w/UguS27qm63KTOtG6jYHpCeFs42sQrjOtQ3gLSbLHq3WzoYbwFb+GEEsp
	rMz+wJ43PTrbB6eXAYT3jN60KZLUFb7FtvfmMudNWNIoSb6xyyR5UOGEbUZe
	N1tr90XCoQGTkiJ5QUZ3EKInJthxNd1EqhsXWCPb6XZT6NIsx6ZGW6gfOB5Y
	HqwJzQ9B9te6U6cXZthflgVWgCBo1L69z4e78BRfVIiCZJ+eHI2xprhIIEjl
	GJWnwlrF+fparG+o0SthpOw9ZhXR2vaslPJSsbtYz5ET4qZXv7FB5TlrjwMp
	T0nTsMpcBFZ7nKSR+opqo2xexyZxR+rG0iysWk6zWOZlvlwvQ6kYpFXIGYg9
	63lsL6Dxiwdqi84YVlna3SjQBwok8aBjDGCTXHDShzJs6nULpnIf7ICqroA/
	18NST6ku4j7WHwVVi35S/OSfWQRPRyePXt5//fKHn94cf/vN6ePvX337+O13
	R788/v7J0+dHr17fv/fo+PW9F6d3RYXapg9+kYKhASkeqtnKmV2ARh7VQuEA
	HNYovFKSEWfzLhuSjBHvDkTMdMKu+sYwSNwVNl7sFrlM9aIMr1vY9MomcVMY
	v7RMtoctQz+0dkq6rkAz9jRQyY/ts9Hu6ven+hVB0Iu8Tk60qEyUFxjlzwhD
	mmzJPjfCzI0Qo7D4351QGj1dJDtc1hvNryg6vlECqC4LTrm0l0pzcDLYAkT9
	3zmknX6yNSq9RCexWYo80Mnp6zGWDQocC0rxgK3cW7EdB9tlth2lt2Czpdnb
	Tum0+VJiNQ/jepXJBQElgHHC9BxyqJadEriE0oLkT/9cJQqM/Kk6Kspbr1h7
	14xMfaKVGbozMPWCJAORw61xVRUmKyNxdqiBcIPuqXbS354B5iJeilE2roDu
	ODjOwhRYG+pe7xGTIXBBB2pArpfDnrlcV//JWtIRpk+UscjluLogwTnFJmdI
	Ybf9yyFyBp8NqSPp+1lWNOa9dzufJ4GkAirfQ9FZD7cKadYRYBYaiqM6qI5n
	8aZPQj1h9Q9GQTIhGxukHi4aWhOXg6wZkRp8Gx/enQBBLwDcUguPUEtYjOs6
	UADHtwUOMIjD1mmsaPDBQgR5Yeu4O7u81qGbSXlSid9T9hQxA14cNAMRwjJi
	L8YQ0w33NlBWYK86chQlpV5tOki4PpS4hM1KbBT6IQq/LBGF3pFWxEt+pwd5
	d0QNMUjejqDEbEfcpVFhHRpKxEy8q0kiMbtVkUkDwpdGlfijgrmt3X4UTGOP
	VJOES472+3BDGBoUcO0pVRtrsrAdwLSBLc1N3dMc2kdgLstVUP/Mu7bIL0rI
	q8UU+OwD8jupnyXto+uMxACt15tXh/+aPltVlP0Eg9xxGG13DF25qrr2NUdR
	jme7jSIorRavRvsb1iFbT32d6YoNP/SK1bh6ONH9697w5GxxgUUy1EGXzXoc
	qJl9zXdcTFxv62JR2YItlJKXO8LKkV32asec7+xHPzkHbxqm+PntuZoJW4ZL
	umSP70rFaKwRh+zJIyK6ROO3KlUionbQqlzZVP2IjPQiiSiOvzMWbxzWuiiG
	DtsKymQP6DrBFohhvX3L3hnV0etUjUvv372bHv10ldL2JJsszPAJl7Pch/Mw
	pFwLTxdDoQ+qEsEVXz+D3/7k/GzTqlgt8hKG0WYIGPECaYp6Z5yBZQ7m7KL6
	8+ArufG4FXblHZ8cRA40eooD3zv4w8HjvofizPuw+cswdvTxNIs5Nw36ad9z
	0k3Pjh4/rI+/+fH87u9fmhegxY62OuLI2hyl4wcVkrZZ6kJnS1CdKfGRPih0
	tWTpSQRTkJmu8vY4uvWhJ/0A8Hy3hHRU+8KxMEn37b8dg+4rWDiPUeJFBiMc
	qWvEOJgALjeruLuBs20G/VHPBQ9Y16iIkHJU05vkOE8WAQsMwntJU0OOxanH
	bhTP0NpyKO/WWBmLm49dWq11Hqwqv2C7ftp07FuBcTcoPu5FsiT2olvr0yQL
	cE+0kGPcnt8tCPDHYkGJzUE5jm6ZDRCVq1zdAdgCrO/4ki8E2BoadBXQdgSV
	B5kodpnoUMmzvf612vPDflx0zn8Xe+f1ogYjVBREDsqW47mI7DmkvU4iVkUT
	jAzPLrpQNJjdQwubXWML5WCxfQhTNVlV7Uk4uuyEK8x0lqxOjJynx9tiRp4e
	YBNafMNUzMt8DYh3KgzDtUbmwCrh4ThrkxFvCavunqECdowvkGicnaA3u865
	TMSMcHm6ERoyOLBQyrs4k4Ht2F0TjDSZr5D8pbiLamE8oG1jmelFDcixCtE9
	Jd/cTzUZ9ewT2zI0nrFnwiwisIDsye6bdI0oPV8aHPtsdptZ3goJnykHhvlT
	T7TH91b2u89AryXR79jxFuO+Xc7/JNN+16YfYMYoKIsxS/iKfVibbNqHwS7Q
	2tb3QPDoXvDkz1GMlUYPb+mUcOj+nTvRepWmvdPXpb5uGSU2X9whAHz5OBAw
	t7DyW8bhMHX3Wb7EyiFR8w6BehC6g9ADNL6zb0TR7FZzsSfMPPBG6apenFDi
	MBAhA/9yTc/2SqmKvusXM22Qn0WKVo+d2atbgwmqazIFubwSP0pdB9yvAR+o
	WVPQQqcqp0IbN6Wu8Ot4bSXOlZglsSyGkWH5/p5r8JyrRWzD3eyiLoiwGTuB
	hRVFvEgGCTW2Ra7iu46n5twUWIq22Um5P+iPS/U32SbzVEwxKd1WoNf1ynZp
	mDGLFqI3quQKo1sTzpEbCCUAz5Utl9j2HvC0Q05MbKTwJYyXoZBKqsXAgcKw
	2HcK60WVimn0XXE12poX8nVEkpBDnL+4TSbx6/3e4q9sVeiePWQ4z9++Pfzp
	58d/+PbNw29fvbhn/bCHQfF4VCq9il3uqDmJTwGbNveUEtA87Uh6TMRxSwBW
	G7SHqHF+kECfwjoMDgBqlA3QMq5Q+g2szuNsauGADzYSij/q2tuD5i8yBaQk
	L2drDQbtq4qBtG0rhr/vrqkWfOArCYm+hyhm1AIVqR09Ppnvw2h37xoGcVRw
	7rmxVwZJEZ/EY83dEIvLrjgS4iMq6g8H8CxGPaCCfo8JKZSbPVYkXBWkwNWi
	aitM0+21B10CUISqe0EKPdsGVHzRvNd5+ueeYVwOWuiV6wGX4JOrwcu2cV0O
	YuiVS4AMPe8DM9Rd8MvnGD31Ahv3nby/x5SG28z/Gt67/+DhvdF4+uHfZn4s
	7jM6tMo+sS6IMoUhnefP3dsUVa2wrqUg+tljF2ElUo1Z9NnHLY9/3E7Qm77G
	WkNT8akHkW9b8oTf02AknmKgV8o0eh8wBvXy93ynGTGGkdgnbZF8j2lI7XWa
	ob0K1P2Eg9vvHFt6Bmudl2RDeidn1cLHbm86LL87N1Gs36FZNJ2M5/c4hveB
	EE8dbjs4eXJ46A2WeZ2tqY6/x2m1yXtGUORg7Ta8WC8zFJlAb2MHDL1PbEIj
	dRpcCq+OYgupQpdHJ4ksWNc9atDlwuB09rqrLBTvDYgM4fbuk5uzqrqp/q8V
	Wkzb1g6P1GcyY392kVBxdoTIi3hHvEVm6xBujh2dMP+995r66ZUNXeaS0uSi
	8GzIkjqzKTpb7H8cIO4urrT2tNxPZVtmBZfaHoXjCJWdznhQDFPqiNYgPRZf
	l8rn2kyqeYl+NBqOXmXs+zQHqbVXYyKk9UaLSVXBRDQ02cD3MiA2zoW7RIhZ
	Mk+YuDSELzLJw7sqIu1tPh6ydHtla5xECPNPUW4ic8Yn9IWiyj/fukGoklob
	Ymu3qWJy+hSz83lHvQx9hsFaaslmq0vdmKyeLHLMZcHCDt2km2wi4b8drYgr
	dGFXVBNgGjrZ5PJG8uNiCs6xf5WLt8YWLRqu009bTnTAzhlYOVi3bnFur4lJ
	tiKWQOogwyuxMC+rqaT3EWMIitqCxtRQnNNAC93Y+lFKklgmzpSGSjtyTVMJ
	gIvLUaEuJCWpaD7+rOVyKXtnqH1mHeJbK1fzCgDeoy0NwxLeLugKIzrHmqSb
	tnoP+J984ymQi40Dup3qBfB4CbjyxmNJoJC5qvkrGqsteskVkUK9y1WgpXu8
	9MPoaifdCioEonZvPyq7AsxKXqWe8GzXBcYFAnCJ2vfvChILO2doSSAbTqlT
	EVrRA+rZpA6eG4XfEnEiw0y4oJqS6zzw0Q/s4LxinJwT0InE8k5T4hIW0tC0
	eHnCyhUJLFszWO51U1jcn8cn9y9LaenktESPt2ekdHJXrvFl/zyv8WX03w5f
	2kWH/yhfhv773W7zdF8+1C/dqMNUnG9vdye0dbRXUkL0n6OEq1N5kC76rhrm
	NB58asveswbtZ0e43CsnCFzgpVerD8iLG4tqJ+StBr5lYyzQtFGfhl6b5CUu
	Ho3SV5WkuTF6hPY4Bca3WcY2/IGVNOppx2+97KDuPSp8ubxLE7JWh3CSOE4c
	QzRPSuzB33WB77tJCGdGvgOHAl59OKIXggQgSnyjd6AVeOdbbm7LO5cxTgQG
	XSe51vHJ/OFgSmKQgYP3zLMzPbEisTTBvePAtsXrqk15hmPfIuoc6HxjVXjH
	kkrmKCBCqw2w41nfehdYJ1gjCeqDx8y/A16syN/NBaRXTnIrGjTf5xhKf11L
	ulTZKbrEUdiDnfzNp54fzQ8+CQKyOL40jJqOYjcwv9nZf71LJtqgslgofMSV
	1X747U4svJwQI1GGP7492U/Nr5u7lySdXG1l6jEj/d1CdOm4/oYsRL2+L3mr
	/+hfJ08pSjCKPWgOy1Mgg1OekDVvY2UsHaKXqRgB8IOVydoAQFJWDpb9axC4
	UkC5FEeZrWuyEnGJZlTkUL0Dpa/EC9pquZzuIyl9aAnDh8EVnainTacaHIJp
	S8pQxdKdGy1LnU5gpMAdHvqP1LtBmPaVmVdt7mqRBon9VO2GStt6OY03bqRv
	sRrfT1T04c3xoYx16Gr0SSb9nivVt0cvUnDbB56N578TcBG26sWu4E1zEpPQ
	V5nTiz5JsJcT6gUtDq7/JHmyyMq5ScVlUpgaXzh8dvocZElgd9GqQPg8KPrJ
	sU7/8+TZi+dYMvOELIf41mvg2BmWnqLFIZU+uMQIbzbS1DBZK1IobJgCL5cz
	8jijy5alurwP3az9JHkFv+EQ3/eeqffQMbJyeIEtbEly7MqY7PfUvIvWQKcb
	13nuBhqJictWY1TrVsYN+BrsgI4LG1WV+rPmzPgEjaS6hEHR7fSsrdvIkDZv
	sQrHXndke5jmwjYGOT3WIGe/Rj8gV1ToD5kaarll5AjP16LkITRY2rpkZIkQ
	egpPqHuTOuIqEWIAcVdBhAR5rOa6wJG1qkD4osvxn7Gs5b3739pgl6eGbWHw
	xbMPoOm26a2nz26TfZqCmnghTdmsa0YZlI2H+NLvoBF6ZABhQHrhugeRA32r
	o2/iaIZeeOFNcYDlWlPdBboWG71ey92eYQPobHrleONW0aVaXtaJVtlqvDfC
	XHjrM/bDbvmWQ+dt9lJEpdxweKWiV7bYA1thVYobNu4VKOxUF7PnnLj147Mr
	VsoyW3oFZvHFkTIgeOPtwtCa4TVgovq4aL3cZsgBPBylr9V65N3beyA5nTC7
	pxh6QbmLdNm0tW5DLz+EJvkeW3xsKeNhWo4icwmt3IRyfVN39DWunJ5Zu4JP
	tOJ53wra85kkn3AJP/E6ffJm88mOCbR00JvT+H+ST+9/vWiHeI7M9P0nWSBU
	0ck79NaMmbEMUn6FgQXAXnhDb7vURqCbeoP5JZe2Y9/Spp5FTS2ltHfQitb7
	pne9gt/4wZgLfgfvSxFwet1WAae3/zLJVsGrvzwB7onv4T9ePKXXPu4zc/2n
	Pd2S6DKWy0JQR3tpR2L0p94Hu9qfcb9NnHjCJCrS/tVlSu/Yf5uE6Z3r3wVO
	v8DpX6yu/KGLaC8XP4AsF9WcfDYwUBZA9FkTO2zsJuKVIrD251U+TREfFqAN
	M7ovJ+z+yfEW8q1DCIVTswGq+yDhyEuK/G2c1xIv0v1ryCim0N3E0xWrvVVa
	0ehHjDPlMZflxpx3ipUJpqletGsKDe3lGtLiirPGlN3SAo4N1ZrzXeT51fwv
	5g9WgWKphAsSyCEfmH9iOP6pG7sWAHD4inK6dn89csx+CpKHP6VXN8Cj/LQt
	8fvqIVxLhvTLh+tIFL3yYOvW/1cUJTzorylL/i5DdpAhf5cd/xGy47+NzPhP
	lRWI0z9JftMOfP83s+1PZ2ZzfWlBdRc6ve7QGxz6T1IeYIe386y9xtvleHaN
	t7P19NP2CgQ7NNCsx7vL5xw2afeXXZrAzh/9JvEbxbuH8vfq3K2uGfTy7K3t
	NkOuSuzHaQU1d1sJSJJbb76qxL7ONL9Ugl+6LP8RslxE8LE5z91C/FcT4Zev
	UleYW6vh9QW6V9vtqwj1LUPZXbB7HoKvKtyDBNErhPuO679VzNs57CLqozjU
	L7Qr7irudzyAv0XwX4td7qo9XirgL72H5CpFMW2iTP5rt7glqd6TXF/QXH/m
	tw+MrtPojsLxy7ZuZ2EpUnZ3aSl5ZX9z4rIz0a8tLyWp5O8Cc6dl+qoS82uq
	wL9ZWv411OCvISnjhf8vIir93n6TuIzP319LXnY55tUCs5vN+aWSyFfD0i9u
	oy9p+gtH9BXE2CUrGsqxHa7VUiLxb9PaQVYFMkkOozbA8QCZjuHrSqyrp/TF
	cspbgr9Lpb5F6QkfwRW/vvzpFgb8cvnTM4TdZY8M5Grhc6nEsQHlBydXCpve
	9dweTiIB1VeKFY6D/kKRor3sJk56j8lvEh49Z/pqEXElU94WHHiJttNnQLyk
	GU9K9dz0udtQ+m8r3u3bvrsprzmHXaXRDpLkKhnkp09+jLMmL5E5UjWQ3g0v
	+fRvWdeU8r+StPEG/6XyxU32b8Dh9+yvJ1K8degKFM7K9UtWXhGKqGRRufsj
	WEYgJwrqIlWibUQ5OdyvJz2C3HWXNGhlClXerEpOJCbZ4Qp/doevOf6cg2gr
	TXbTnOxi8/jh21CW8CxiedK3mAme6vNmlU3gWN/d+5wQ8fIVyrKAYi+iTHXV
	raQSQBRwrQfyllS1tEVTZD2953w2eaEohZQSBuiMDJAS4EvYlY0rzU7XFR/y
	Z5KCjQmomnUGS1fn5pxvBFnZUHKvRym1NNXB8hv0fW0Kc44h2FILEzPa4VwW
	TeWXK0/H61Zzl9U+FQnCWP71HWMQUrTGn7auHQmsoAzAJ1AbwsIaPXpHb8L+
	Nb4Uw+OVH1xbDPTlwgvjB41lsq4xgbyTNaFPuIaIVslRUir5rJ4b3Qrmhlpg
	04oGPEjETjj1Y5DmmL2Dj1AVAp6YwGiqcg6kBpQKK5fNhf3LeLA3zBB0xQAa
	HfIkHDJWYNPG+aeEr7pZFdVmqeuD4+Dci9MXJ/YS4oqY/ynI9ybHsEntY9gW
	SDEHxEDlhmJ4kRaY2DiKVziodD+mwbtC2ouqPsOhlUrLi+w84Pz0CXYOuLla
	t4WrZfT4yet7jx5+/pwwh6QrjIkBRftrcwX9TGniswCZ89W6cFkolA2KVdlz
	vn0Bc1WxzPEZ2iQkxV7rVfiT5GoSfenkLLq5xEvnC3mIcLxUhC0u0D+6YhL+
	+lI4gCs08dmWmVxQBqJML+cc1zSu89ub5k+R2rgUWEpeCs/gLGyCoiOJUfKc
	CogWs6FgYNgLuhem8C6sdLeYVI29VUY3LawCK8nv0mvjKlxzK0nW2Koa4a00
	XtkNXFoS4a6erfBHrbDG+07luBFW9JSetpmVnO2IhMc1tq2RZti0m8LoFF2p
	Uy50UBuvNEm1ylAQebjNha+EV0yGV6l6csIX+uvVNGOYERV3ZhWQbuWpvAs3
	+nI/+wvd+6m68eWe1BTBoUPvch6vjkx6KwNJR/ISFhfEGbV9mz9w4MhVY/CX
	HfNdg1sK01uNMSzDPn605A6vDUkL+PyZGtaCg3yXp9des+ZyQnz9FdGibyq9
	tW7WcPo2PPY8errlEgVHa1g6A8+zTM7dcSE3/cIfByc+VOaGk+TZOd1HRcgV
	p9y928jxO1I9qNvg8kTZ0ugUBI1hAXCT5E1cx91ji5kra1Fx1RW694vrr7jL
	Kauy0AuxvCup5BqrLlX17ROxDSTOcMRSr4Vznwc+X5V7lbmiCLAnaGeZ4xGQ
	zHm6M21GhwIY0Zq5GlcitjcvB5fWH58kY7OpFJLa62i9zZUyIMdHzHGxqCGO
	s8N5j4lrdBnwBNONP9tkcA1M08/0fo+SkC+wtnN7xdhAAACVVOKqXZR/UYGy
	vAKsnWLdKJHQmFajAlInGFdfTuS63qvP/EB2m5ebZqDHwF5UEE+ETaHueiZ1
	ZpNBpCbpPJvRp3qjPbU77bYR3L1Fs1iiUp+ROjzJG7ZtZRPmyD7q2Ud+TtV1
	kO/1dMATSGArQAXG6ilSnNPWD8LyTXXjX9CAR21hMtBcCCRjGbKlsQXGedPs
	CSxQ2aXM2pKqDwHomljE7jHlxN5ADCMcpVw6xx8wl1fLS7+ID1/uFh8Gu06p
	3D0n64cjIH4h9zatvHKLXPG6cfUaqeOBIiKW6jpwKl0/WRglVb4nnO8xgaGC
	btLSmxfZphmlR6VdjCVed9DQ/iRLuXcUa3zh965q7szgHT3WC0Y9QdNVPeVy
	sOOsyLSMQrxbFq8idzdAeRjteVrx5UZcDU9mxlfRubVjCARkinf7XIDuBCq7
	U2G1aFGwoqMUW24WlRTe1c/wvj0c3Bh2fpa3Hom7CVHh1hzvG20WqFodyq2D
	IMJcqSQSpiVZdGhnsa4tHqm6kuQ4wjGFhxSpJomVxjra4ErwgcoURlpOmqAQ
	AN6LMJ/BASiXxu54YCplzmfvkd2CNx1jTwj64d98e1dnQN17cC22GNvaaDgT
	3Ec7wq6s0/oYl4ibDgqWWhaaAg/NefzBuyVSjkokinGwfaBJa6V+N3rgX+ym
	hU7i6fqXTtFtjztJOblPRYSmXdUAf/CKc7EYwW1EZnaBPQvWtqH13bdChed7
	7ukQzOEZM5CdLCqUM9UsyYo5yNF2saQide7uKxmd7RyOFc452H04XmaFWJId
	KCAh4Sz54ESZohM6xYZcJnK5t+UpZKpak2cAbelaZk2PkXReGkRVvdIu45EG
	skoL1Eh1ZGYxqxVadhg6IdJscLTAneUlX2t79gEv+GMBHtWKAXzrJ5qK7Sgq
	rTYTwOPogzlCYbIz3l4+MIwEnGoaz95ShtWLveB5XM4GYQkxoECtoKI5VpNe
	8oIYb1IjMWajCZX4CcFq+AZGj41MmIr8K/W0JgT90179l+H9wDXDPMxmZfZv
	NVkt8kdKsz9EV9vCM3qjnVswsqUlx66tlksPLO/jHTs2wzdwKFnXh947WK82
	cGiH482wbj5vv0EzukTQFoj0ZqPUjadObzKljVJ1z5bQT71CeBaxjRFy5ZMz
	LcdQm6GArqhUYFRcifUUKUGabivoN17nxTSBTdkATFimUh/xzHDFQZUgeCZn
	tlbjzGRcgo6bazIp9m4+TLjmxXaTA+xnkpUSscOlCNckBbU+ypr3xEKkDnOO
	C0RIDeugFwE3RHOJ5S03bcklpky9fNPpjrIpXv9o0QG8aF2S66KwVz713neU
	eISnt9n1G+kdKXLicmRaTJK3eKD4ALQqMPRqrKC2gKXGIj8zBR0QAYtSlTBo
	mPGTzy8SCn4gTwcyfAIXkdFw6qwsHWVBpK/cuupqNDGqEySSsH0ytkU6cKLr
	JFOjC22vg2iOgN8PkbU4hU7N3FJvPbIOBhSzrKamAFR3vi7mvvmu3/YS1hGz
	NTXJ3kRUMbLMEi/5wRu524Uo+XYYCCNB2CGvtzbBAAiRxY1Ipu/uHTZnIirB
	KhS683h8DXubvZt99O4vrJVDjJXDAZqQgGgNBj57xxgC4gsNTqE2SdZ3HzBd
	ctyQcyqbwBhBKwBRm4OmwCWH0KHRA4fkdsl0jh7L7gVmpFAwpBfeNN44Aclq
	ISEJ0oDSxxs+z0qlQYP+BRz4VcKVf7WKtrUbsnhSgsTzryZNVXOVZ8S7sWKw
	EpTcj/Vwx2WRP3muRUBn5YTWC/YDJD4IMbl+d83OUMJK7jo7MV9Zv1WD0RHx
	ZQgNMU9bjttdeM71lWiEl8Z4DeS+ZrEAMpy3Js5kXGnZxBPLUFTY/ACK9zkW
	eW4UCLH7mG6Mt6egruw97Qfucie6W2/dkg2HMRwfmCTHWs3sPJHz6W47kCtC
	vNsMhM5KGj97RGCL9FZj3QhXNlWvZbaldBM9I/kM5ZwwOTH/ldrylItatxt0
	elOZrWWFkpHoZoWMG8s68mAKFCShNLC3saDeSbc4ruT+E7QmgRKMZ8MOsglr
	8rkYo2AZtDy8VVElZMhglKW6FGFRJzi0RB2Q+YwaaVPYFS7ZJcFuvFII/6oU
	z9ecbcW5uzJDEDcdRzzYKCQ3aQ1TqkhTcJVGvNiC7u0dTYTODsX4mj6Xit1v
	Smd0TUTrDgG04zPIlbs+GZLIViyqIR8htcYQh3UcXZHHhHV5q2hxCeJOHwj6
	Juj9YAcgDtfeerYFMypkBFin5uZEb85OLdA7OBnawkQEnKlFZI9ttxAkXfdY
	tX5oV4uXLPXcuKt1PYEnhjc4M6Y+OJFDZYvMcWVnX8Elu0WDYXvwXV5Laeem
	UQQgOIlOLR2cZs1MsZwnnQUXkp6vc7mHwYcbVn91fZOZZbWC9Wws7CGjbwi+
	eKXi7vCQjc0iQ1k7s2RBxmHGlNQNkRkoLBQXN2Vj5BIjhspZPl/rLS9Whaae
	jJLGgKtDO2O0fsZjmxvR0JrEYgCPhCU0nKVl1VgvVNQbSSo+9FrrVkBpMLSg
	4VHSZdKeOAf5japKQSKX4hQtRLFnkIFkHnEltSdksmdIrarQyOguOJgLaTK4
	N8eR5SojVqvBPwx/DFb9z0np38KMjlV8jAtgfLSjvSvhOW+0C7HJe0X+6vAO
	LbI01XTv+MB5fNlWWWy8WnqsMPndOvY4r6CHGoifUbo/FuT++oi0JN/OFtyU
	mwSSJkA9orN1tfCIfzSKhNIFnE4cjF2Rm6FyNMlrWAQ+L02ClyqZUq4ZtaeQ
	aIOJQPkN8qCcwxXUiGCEP9jKxhEz6NeQwoxgmBvLh59gDgzr+3HxpUhMPawu
	+tvLxXDMkq2yrLgnPYp74GG3psUo+GCUPslWjDAuuxCa6NZ8AHFmRFOy5nDd
	Lt/uk8bX1TSb5RJDiya+VwnEhHPs8VXMVG+4kZ6mg0SRm9WbRW6QkcFJA7vV
	46xhHqgOT3STkR9SBIX4MSpCXYK5SKlK+lWp3lvhkQWsS6rs6dzrbICNjR55
	aFqyy2CFZHD/cWiQIW0eV8QWgraOCt3b5LK97TNP9LlGPUDMi+F5cx1heTEj
	aOPFUMvGp8LMxXb45q+wLLndyxHfaIQ74p1g/24LBuMNnHN08NV5c+Zcgb7l
	j7Ap0wObf0KL15Xmet+OBkuBVg62oxZo/9MNS4jMfSipERGxEupz+rGiTeVf
	sDh0Z8e2BUqEJ0a2MtGsTsLARDwcL8lBRjFanoXQKk61RuO8RP+YBvNbxTqM
	81Cdi3/CS8mwXnlt1PTK5835ia1jKFHEb6kwI/8RvkS2fHcTeECePkXbMuTS
	qqvWnfBl1v6ZhVO8KqwkJ/hp1eKwhr+gQwTKaMhleOhYqdUruF2pi4xPOPBF
	vNtO/UCLgVW7gT01F3xxe8g2+UManeVw8a10vk7Pcctkz1F7XoJ2kOjq8oi3
	WPvrvKoIfNqLUbA/lhywYYy82IpMiIivrkRchO7llPlYay80YF8dhbOTUUvj
	R5LAqqXWVXcr85SZI2ZpkNVN1py425ikLsYE5RNZaU28xWijAe8MLWQQH2J3
	1d10ipWjRfOcFIjDGr76Rp6PAH6U04xwUVFsAuDFFpnZzKhKo23qVQwU7Nl4
	/DADfXO+NtZPmqDKvFzRGL3cYTW5hg0ugXdN6NIEj3wCom8wGjxv3c5KOIqa
	q9oQRVtd7XIzv9xJ1Sd3kI3JbJtw4yUcrIyhOIx4bnNKlMcjGeHXcAbnRiBH
	Ip5s75IMUzSGeOKIgk8bpDagOWGXIG02ZbakzfW4WjWLaNWzYLsFhuHPTEa6
	NYkSOpG2YQIyxFDajeN17sCAlnNuNhorhQHRguj1rgMtaC+3HSSVL9nDiyWp
	t9pgSw5iK38hmMoKK2aceXqGWomSwIiIjD59XefnGMrRieWVB589Q8Q1bMhd
	6COxknT7T+dSY4eBTDlF6QrH4fho4CxR5Ak1/6G2ZIldKS1qQpLCkI5GbMgc
	CesmgbzLxdcgz0Ivy6w1Hj7VWAiGHQI95VgA3LW26JItzkgp1BbSJwrzwITH
	0Zlyu8HAhT9bjUwPnxgAYp4ujxPhADh+smQuScEvpFO8WID/BjHVCFvoeJk0
	GyyzX+MlcjU0sF6OmQGhqIcTLVpCQu7g+lxp2OtEmAP6X45PxB0cjUMUSUKH
	BbCjUlU+ZCO9I9DIJBuDZry4RFoJbFa0cnUSUIidBJhAWyBIrQO4o3RnsX9K
	o8yE8MXoaFzGgrWPdKQ+8WszB16FH2A24Cg5KMgYi/5qEjXdUNo4eNYxBMon
	tPZvZ0UfXGWo9+2Q6CJ+6tnixVoQaKVy82U4rNxdPEakb62ludxDmJHdl8MR
	ojg70aXpe4rJ9V5AA8BbFSNyE423zMTkbF9MMHiGXJAyewbh1OBd6sIk5Tob
	vL+alTg0ojg+lviWa2iWiI+1fWRh1szNcXIWAHujNmzFqhkvZS2HXTJwor0n
	G/iELewJZxVJ8RxA4Jwpm+Fm1KnGzCduGWIdEs6AIe2pn90K9iFUfuLdB6kx
	6QFBJXKVUX9TTl6qDUyBvAb2IA7NbESCD2BAkJqC0JDP0ZJ81uUnbIB1KkLm
	JAqb4bzUClkMjfZEkKuXLapxi4aiEjixLhh/YXiw2Ll/ryKTLwglDP6XdBTG
	P+wVRPFFPMmOhsyXpReBKzfTWccHrna/BzBYsK3ry0QTDlmEHsn6g4nFUUtJ
	eYp/klwKWPIW0+740KBDlUk+K8/YWgD8cYz2YI0FsBY/zNY6z6dr4MxqScrR
	w4GQpIEdDbNtWLCRAywfr+mn/eQgq/H2E1iRyVk+SA6mdQ4L8/u6WsFOw98l
	/JCnT2ERgD3i32U2NgUs+WMY0TIrB8lT4Hv1Bv4Gdak6HyTPAUtiRb3lOFsX
	LfxdVNTmD6ZYNpPFMp/Cj783FbDj9Hlh4EhiRz+uMSEzPc75z5+ydlGg2fol
	fly3m0HywgCF/ljBsgBshH5f4kL9MasLtPO+AnZ1Aorlcl3DKE+zs2yRn1Xp
	T8Dsmgwn9jPN82RhkPOjKZOdD3JBsO6A6m1uoxhxAsguGxOuHW5HsHrWxSZ+
	Q40ZUGvuKH1rZFsX+ZI2jFENsURUmlfrdiAht0BMGIc9sPTGPIs8Y0QoCXJX
	4qnzWtD+hSg7lO2I1f2Rauj+VM32+gHQeAWb9fHGgv/1GfMthncfUZrfMH0j
	mR/RlQfuvhvPTq3p1SNu4ntp4hmtZS6IhrKGOZ+kcTY8plBL2NLCd50Wdvzw
	2y/98KF8eDBFyypObc3uI8oK8s3gKuWJr0UGlhPGatES0swd+sC4MrxUjUwH
	wCtMeovSiBAakIy8PQoG43+eVl3kzEld4Tdhwmz88IN4jf1pln5xH0yHjHKa
	RdVvZL2+6Sz0BIuPrVe9k/cTD/3Yzr2wgoKmiu4FfYeDX4niFIRrhyE9+sET
	EPsYHcoiAEB/JlEEXQTXl6Z3RTNBLbFgrfoas5dNq5TlqG7jmxScHzpeRHvU
	7FpQ4Ea1kjxLzQwrI2tfTBynyF4knqGuUOHBjQ7ue9QNfhCsuheds5049dP7
	vedfUDo58vIPlpDuycuPDSI4z46L1oHg1sCw4557V2ydAH3zOaiPhmK4ou3W
	EJSeF73NCMg//OCZUkHf3VwuwUpff1mdW9yh7x+fWOIg7oyMgXg6sQQrKXiV
	7tp+WzyIIfnRaZU9GCX/H0FFsMJnHAEA
	</rfc>		</rfc>
End of changes. 284 change blocks.
	1392 lines changed or deleted		616 lines changed or added
This html diff was produced by rfcdiff 1.48.