<?xml version='1.0' encoding='utf-8'?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.3.37 -->
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc toc="yes"?>
<?rfc tocindent="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?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-01" category="std" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.6.0 -->
  <front>
    <title>Grant Negotiation and Authorization Protocol Resource Server Connections</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-gnap-resource-servers-01"/>
    <author initials="J." surname="Richer" fullname="Justin Richer" role="editor">
      <organization>Bespoke Engineering</organization>
      <address>
        <email>ietf@justin.richer.org</email>
        <uri>https://bspk.io/</uri>
      </address>
    </author>
    <author initials="A." surname="Parecki" fullname="Aaron Parecki">
      <organization>Okta</organization>
      <address>
        <email>aaron@parecki.com</email>
        <uri>https://aaronparecki.com</uri>
      </address>
    </author>
    <author initials="F." surname="Imbault" fullname="Fabien Imbault">
      <organization>acert.io</organization>
      <address>
        <email>fabien.imbault@acert.io</email>
        <uri>https://acert.io/</uri>
      </address>
    </author>
    <date year="2021" month="July" day="12"/>
    <area>Security</area>
    <workgroup>GNAP</workgroup>
    <keyword>Internet-Draft</keyword>
    <abstract>
      <t>GNAP defines a mechanism for delegating authorization to a
piece of software, and conveying that delegation to the software.
This extension defines methods for resource servers (RS) to communicate
with authorization servers (AS) in an interoperable fashion.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="introduction" numbered="true" toc="default">
      <name>Introduction</name>
      <t>The core GNAP protocol does not define any one specific mechanism
for the resource server (RS) to communicate with the authorization
server (AS), allowing the connection between these components
to be solved orthogonally to the core protocol's concerns. For example, 
the RS and AS roles could be fulfilled by the same piece of software with
common storage, obviating the need for any connecting protocol. However,
it is often desirable to have the RS and AS communicate at runtime
for a variety of purposes, including allowing the RS to validate and
understand the rights and privileges associated with a grant of 
access represented by an access token issued by the AS, or negotiating
the capabilities of either party. These types of 
connections are particularly useful for connecting an AS and RS from
different vendors, allowing interoperable distributed deployments
of GNAP-protected systems.</t>
      <t>This specification defines several means for a RS and AS to
communicate these aspects with each other, including structured
access tokens and RS-facing APIs. This specification also discusses
methods for an RS to derive a downstream token for calling another
chained RS.</t>
      <t>The means of the authorization server issuing
the access token to the client instance and the means of the client instance
presenting the access token to the resource server are the subject of the 
GNAP core protocol specification <xref target="I-D.ietf-gnap-core-protocol" format="default"/>.</t>
      <section anchor="terminology" numbered="true" toc="default">
        <name>Terminology</name>
        <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119" format="default"/> <xref target="RFC8174" format="default"/> when, and only when, they
appear in all capitals, as shown here.</t>
        <t>This document contains non-normative examples of partial and complete HTTP messages, JSON structures, URLs, query components, keys, and other elements. Some examples use a single trailing backslash '' to indicate line wrapping for long values, as per <xref target="RFC8792" format="default"/>. The <tt>\</tt> character 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="I-D.ietf-gnap-core-protocol" format="default"/>, and provides definitions for the protocol roles: Authorization Server (AS), Client, Resource Server (RS), Resource Owner (RO), End-user; as well as the protocol elements: Attribute, Access Token, Grant, Privilege, Protected Resource, Right, Subject, Subject Information. The same definitions are used in this document.</t>
      </section>
    </section>
    <section anchor="structure" numbered="true" toc="default">
      <name>Access Token Formats</name>
      <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
in order to determine how to respond to the request. The core GNAP
protocol makes no assumptions or demands on the format or contents
of the access token, and in fact the token format and contents are opaque
to the client instance. However, such token formats can be the topic of agreements
between the AS and RS.</t>
      <t>Self-contained structured token formats allow for the conveyance
of information between the AS and RS without requiring the RS to
call the AS at runtime as described in <xref target="introspection" format="default"/>. Structured tokens
can also be used in combination with introspection, allowing the token itself
to carry one class of information and the introspection response to carry
another.</t>
      <t>Some token formats, such as Macaroons and Biscuits, allow for
the RS to derive sub-tokens without having to call the AS
as described in <xref target="token-chaining" format="default"/>.</t>
      <t>The supported token formats can be communicated dynamically at runtime
between the AS and RS in several places.</t>
      <ul spacing="normal">
        <li>The AS can declare its supported token formats as part of RS-facing discovery <xref target="discovery" format="default"/></li>
        <li>The RS can require a specific token format be used to access a registered resource set <xref target="rs-register-resource-handle" format="default"/></li>
        <li>The AS can return the token's format in an introspection response <xref target="introspection" format="default"/></li>
      </ul>
      <t>In all places where the token format is listed explicitly, it MUST be one of the registered
values in the GNAP Token Formats Registry <xref target="iana-token-format" format="default"/>.</t>
    </section>
    <section anchor="resource-server-facing-api" numbered="true" toc="default">
      <name>Resource-Server-Facing API</name>
      <t>To facilitate runtime and dynamic connections, the AS can offer an
RS-Facing API consisting of one or more of the following optional
pieces.</t>
      <ul spacing="normal">
        <li>Discovery</li>
        <li>Introspection</li>
        <li>Token chaining</li>
        <li>Resource reference registration</li>
      </ul>
      <section anchor="discovery" numbered="true" toc="default">
        <name>RS-facing AS Discovery</name>
        <t>A GNAP AS offering RS-facing services can publish its features on
a well-known discovery document using the URL <tt>.well-known/gnap-as-rs</tt> appended
to the grant request endpoint URL.</t>
        <t>The discovery response is a JSON document <xref target="RFC8259" format="default"/> consisting of a single JSON
object with the following fields:</t>
        <dl>
          <dt>
introspection_endpoint (string):  </dt>
          <dd>
            <t>OPTIONAL. The URL of the endpoint offering introspection. 
  The location MUST be a URL <xref target="RFC3986" format="default"/>
  with a scheme component that MUST be https, a host component, and optionally,
  port, path and query components and no fragment components.
  <xref target="introspection" format="default"/></t>
          </dd>
          <dt>
token_formats_supported (array of strings):  </dt>
          <dd>
            <t>A list of token formats supported by this AS. The values in this list
  MUST be registered in the GNAP Token Format Registry. <xref target="iana-token-format" format="default"/></t>
          </dd>
          <dt>
resource_registration_endpoint (string):  </dt>
          <dd>
            <t>The URL of the endpoint offering resource registration.
  The location MUST be a URL <xref target="RFC3986" format="default"/>
  with a scheme component that MUST be https, a host component, and optionally,
  port, path and query components and no fragment components.
  <xref target="rs-register-resource-handle" format="default"/></t>
          </dd>
          <dt>
grant_request_endpoint (string):  </dt>
          <dd>
            <t>REQUIRED. The location of the AS's grant request endpoint, used by the RS
  to derive downstream access tokens.
  The location MUST be a URL <xref target="RFC3986" format="default"/>
  with a scheme component that MUST be https, a host component, and optionally,
  port, path and query components and no fragment components. This URL MUST
  be the same URL used by client instances in support of GNAP requests.
  <xref target="token-chaining" format="default"/></t>
          </dd>
          <dt>
key_proofs_supported (array of strings)  </dt>
          <dd>
            <t>OPTIONAL. A list of the AS's supported key
  proofing mechanisms. The values of this list correspond to possible
  values of the <tt>proof</tt> field of the key section of the request.</t>
          </dd>
        </dl>
      </section>
      <section anchor="authentication" numbered="true" toc="default">
        <name>Protecting RS requests to the AS</name>
        <t>Unless otherwise specified, the RS MUST protect its calls to the AS using any of the signature
methods defined by GNAP. This signing method MUST cover all of the appropriate
portions of the HTTP request message, including any body elements, tokens, or
headers required for functionality.</t>
        <t>The RS MAY present its keys by reference or by value in
a similar fashion to a client instance calling the AS in the core protocol
of GNAP, described in <xref target="I-D.ietf-gnap-core-protocol" format="default"/>. In the protocols defined here,
this takes the form of the resource server identifying itself using a <tt>key</tt> field or
by passing an instance identifier directly.</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
"resource_server": {
    "key": {
        "proof": "httpsig",
        "jwk": {
            "kty": "EC",
            "crv": "secp256k1",
            "kid": "2021-07-06T20:22:03Z",
            "x": "-J9OJIZj4nmopZbQN7T8xv3sbeS5-f_vBNSy_EHnBZc",
            "y": "sjrS51pLtu3P4LUTVvyAIxRfDV_be2RYpI5_f-Yjivw"
        }
    }
}
]]></artwork>
        <t>or by reference:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
"resource_server": "7C7C4AZ9KHRS6X63AJAO"
]]></artwork>
        <t>The AS MAY require an RS to pre-register its keys
or could allow calls from arbitrary keys in a trust-on-first-use
model.</t>
      </section>
      <section anchor="introspection" numbered="true" toc="default">
        <name>Token Introspection</name>
        <t>The AS issues access tokens representing a set of delegated access rights
to be used at one or more RSs. The AS can offer an introspection service
to allow an RS to validate that a given access token:</t>
        <ul spacing="normal">
          <li>has been issued by the AS</li>
          <li>has not expired</li>
          <li>has not been revoked</li>
          <li>is appropriate for the RS identified in the call</li>
        </ul>
        <t>When the RS receives an access token, it can call the introspection
endpoint at the AS to get token information. 
[[ <eref target="https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/115">See issue #115</eref> ]]</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
+--------+       +------+       +------+
| Client |--(1)->|  RS  |       |  AS  |
|Instance|       |      |--(2)->|      |
|        |       |      |       |      |
|        |       |      |<-(3)--|      |
|        |       |      |       +------+
|        |<-(4)--|      |               
+--------+       +------+               
]]></artwork>
        <ol spacing="normal" type="1"><li>The client instance calls the RS with its access token.</li>
          <li>The RS introspects the access token value at the AS.
 The RS signs the request with its own key (not the client instance's
 key or the token's key).</li>
          <li>The AS validates the access token value and the Resource Server's request
 and returns the introspection response for the token.</li>
          <li>The RS fulfills the request from the client instance.</li>
        </ol>
        <t>The RS signs the request with its own key and sends the access
token as the body of the request.</t>
        <dl>
          <dt>
access_token (string):  </dt>
          <dd>
            <t>REQUIRED. The access token value presented to the RS by the client instance.</t>
          </dd>
          <dt>
proof (string):  </dt>
          <dd>
            <t>RECOMMENDED. The proofing method used by the client instance to bind the token to the RS request.</t>
          </dd>
          <dt>
resource_server (string or object):  </dt>
          <dd>
            <t>REQUIRED. The identification used to authenticate the resource server making this call, either
  by value or by reference as described in <xref target="authentication" format="default"/>.</t>
          </dd>
          <dt>
access (array of strings/objects):  </dt>
          <dd>
            <t>OPTIONAL. The minimum access rights required to fulfill the request. This MUST be in the
  format described in the Resource Access Rights section of <xref target="I-D.ietf-gnap-core-protocol" format="default"/>.</t>
          </dd>
        </dl>
        <artwork name="" type="" align="left" alt=""><![CDATA[
POST /introspect HTTP/1.1
Host: server.example.com
Content-Type: application/json
Signature-Input: sig1=...
Signature: sig1=...
Digest: sha256=...

{
    "access_token": "OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0",
    "proof": "httpsig",
    "resource_server": "7C7C4AZ9KHRS6X63AJAO"
}
]]></artwork>
        <t>The AS MUST validate the access token value and determine if the token is active. An
active access token is defined as a token that</t>
        <ul spacing="normal">
          <li>was issued by the processing AS,</li>
          <li>has not been revoked,</li>
          <li>has not expired, and</li>
          <li>is appropriate for presentation at the identified RS.</li>
        </ul>
        <t>The AS responds with a data structure describing the token's
current state and any information the RS would need to validate the
token's presentation, such as its intended proofing mechanism and key
material.</t>
        <dl>
          <dt>
active (boolean):  </dt>
          <dd>
            <t>REQUIRED. If <tt>true</tt>, the access token presented is active,
  as defined above. If any of the criteria for an active token
  are not true, or if the AS is unable to make a
  determination (such as the token is not found), the value is 
  set to <tt>false</tt> and other fields are omitted.</t>
          </dd>
        </dl>
        <t>If the access token is active, additional fields from the single access token
response structure defined in <xref target="I-D.ietf-gnap-core-protocol" format="default"/> are included. In
particular, these include the following:</t>
        <dl>
          <dt>
access (array of strings/objects):  </dt>
          <dd>
            <t>REQUIRED. The access rights associated with this access token. This MUST be in the
  format described in the Resource Access Rights section of <xref target="I-D.ietf-gnap-core-protocol" format="default"/>.
  This array MAY be filtered or otherwise limited for consumption by the identified RS, including
  being an empty array.</t>
          </dd>
          <dt>
key (object/string):  </dt>
          <dd>
            <t>REQUIRED if the token is bound. The key bound to the access token, to allow the RS
  to validate the signature of the request from the client instance. If the access
  token is a bearer token, this MUST NOT be included.</t>
          </dd>
          <dt>
flags (array of strings):  </dt>
          <dd>
            <t>OPTIONAL. The set of flags associated with the access token.</t>
          </dd>
        </dl>
        <t>The response MAY include any additional fields defined in an access
token response and MUST NOT include the access token <tt>value</tt> itself.</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store

{
    "active": true,
    "access": [
        "dolphin-metadata", "some other thing"
    ],
    "key": {
        "proof": "httpsig",
        "jwk": {
                "kty": "RSA",
                "e": "AQAB",
                "kid": "xyz-1",
                "alg": "RS256",
                "n": "kOB5rR4Jv0GMeL...."
        }
    }
}
]]></artwork>
      </section>
      <section anchor="rs-register-resource-handle" numbered="true" toc="default">
        <name>Registering a Resource Set</name>
        <t>If the RS needs to, it can post a set of resources as described in the Resource Access Rights section of 
<xref target="I-D.ietf-gnap-core-protocol" format="default"/> to the AS's resource registration endpoint along with information about
what the RS will need to validate the request.</t>
        <dl>
          <dt>
access (array of objects/strings):  </dt>
          <dd>
            <t>REQUIRED. The list of access rights associated with the request in the format described
  in the "Resource Access Rights" section of <xref target="I-D.ietf-gnap-core-protocol" format="default"/>.</t>
          </dd>
          <dt>
resource_server (string or object):  </dt>
          <dd>
            <t>REQUIRED. The identification used to authenticate the resource server making this call, either
  by value or by reference as described in <xref target="authentication" format="default"/>.</t>
          </dd>
          <dt>
token_format_required (string):  </dt>
          <dd>
            <t>OPTIONAL. The token format required to access the identified resource. If the field is omitted,
  the token format is at the discretion of the AS. If the AS does not support the requested
  token format, the AS MUST return an error to the RS.</t>
          </dd>
          <dt>
token_introspection_required (boolean):  </dt>
          <dd>
            <t>OPTIONAL. If present and set to <tt>true</tt>, the RS expects to make a token introspection request as
  described in <xref target="introspection" format="default"/>. 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.</t>
          </dd>
        </dl>
        <t>The RS MUST identify itself with its own key and sign the
request.</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
POST /resource HTTP/1.1
Host: server.example.com
Content-Type: application/json
Signature-Input: sig1=...
Signature: sig1=...
Digest: ...

{
    "access": [
        {
            "actions": [
                "read",
                "write",
                "dolphin"
            ],
            "locations": [
                "https://server.example.net/",
                "https://resource.local/other"
            ],
            "datatypes": [
                "metadata",
                "images"
            ]
        },
        "dolphin-metadata"
    ],
    "resource_server": "7C7C4AZ9KHRS6X63AJAO"

}
]]></artwork>
        <t>The AS responds with a reference appropriate to represent the
resources list that the RS presented in its request as well as
any additional information the RS might need in future requests.</t>
        <dl>
          <dt>
resource_reference (string):  </dt>
          <dd>
            <t>REQUIRED. A single string representing the list of resources registered in the request. 
  The RS MAY make this handle available to a client instance as part of a 
  discovery response as described in <xref target="I-D.ietf-gnap-core-protocol" format="default"/> or as
  documentation to client software developers.</t>
          </dd>
          <dt>
instance_id (string):  </dt>
          <dd>
            <t>OPTIONAL. An instance identifier that the RS can use to refer to itself in future calls to
  the AS, in lieu of sending its key by value.</t>
          </dd>
          <dt>
introspection_endpoint (string):  </dt>
          <dd>
            <t>OPTIONAL. The introspection endpoint of this AS, used to allow the RS to perform
  token introspection. <xref target="introspection" format="default"/></t>
          </dd>
        </dl>
        <artwork name="" type="" align="left" alt=""><![CDATA[
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store

{
    "resource_reference": "FWWIKYBQ6U56NL1"
}
]]></artwork>
      </section>
    </section>
    <section anchor="token-chaining" numbered="true" toc="default">
      <name>Deriving a downstream token</name>
      <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 initial grant
request, the RS is not capable of referencing or modifying the existing grant. As such, 
the RS needs to request or generate a new token access token for its use at the secondary RS.
This internal secondary token is issued in the context of the incoming access token.</t>
      <t>While it is possible to use a <xref target="structure" format="default">token format</xref> that allows for the
RS to generate its own secondary token,
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
RS is acting as its own client instance from the perspective of GNAP, this process
uses the same grant endpoint, request structure, and response structure as a client
instance's request.</t>
      <artwork name="" type="" align="left" alt=""><![CDATA[
+--------+       +-------+       +------+       +-------+
| Client |--(1)->|  RS1  |       |  AS  |       |  RS2  |
|Instance|       |       |--(2)->|      |       |       |
|        |       |       |<-(3)--|      |       |       |
|        |       |       |       +------+       |       |
|        |       |       |                      |       |
|        |       |       |-----------(4)------->|       |
|        |       |       |<----------(5)--------|       |
|        |<-(6)--|       |                      |       |
+--------+       +-------+                      +-------+
]]></artwork>
      <ol spacing="normal" type="1"><li>The client instance calls RS1 with an access token.</li>
        <li>RS1 presents that token to the AS to get a derived token
 for use at RS2. RS1 indicates that it has no ability
 to interact with the RO. Note that
 RS1 signs its request with its own key, not the token's
 key or the client instance's key.</li>
        <li>The AS returns a derived token to RS1 for use at RS2.</li>
        <li>RS1 calls RS2 with the token from (3).</li>
        <li>RS2 fulfills the call from RS1.</li>
        <li>RS1 fulfills the call from the original client instance.</li>
      </ol>
      <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
<xref target="I-D.ietf-gnap-core-protocol" format="default"/> and presenting the existing access token's
value in the "existing_access_token" field.</t>
      <t>Since the RS is acting as a client instance, 
the RS MUST identify itself with its own key in the <tt>client</tt> field and sign the
request just as any client instance would, as described in <xref target="authentication" format="default"/>.</t>
      <artwork name="" type="" align="left" alt=""><![CDATA[
POST /tx HTTP/1.1
Host: server.example.com
Content-Type: application/json
Detached-JWS: ejy0...

{
    "access_token": {
        "access": [
            {
                "actions": [
                    "read",
                    "write",
                    "dolphin"
                ],
                "locations": [
                    "https://server.example.net/",
                    "https://resource.local/other"
                ],
                "datatypes": [
                    "metadata",
                    "images"
                ]
            },
            "dolphin-metadata"
        ]
    },
    "client": "7C7C4AZ9KHRS6X63AJAO",
    "existing_access_token": "OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0"
}
]]></artwork>
      <t>The AS responds with a token for the downstream RS2 as described in 
<xref target="I-D.ietf-gnap-core-protocol" format="default"/>. The downstream RS2 could
repeat this process as necessary for calling further RS's.</t>
    </section>
    <section anchor="Acknowledgements" numbered="true" toc="default">
      <name>Acknowledgements</name>
      <t>(TODO: the ACK section should probably be split between the documents)</t>
    </section>
    <section anchor="IANA" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>[[ TBD: There are a lot of items in the document that are expandable
through the use of value registries. ]]</t>
      <section anchor="iana-token-format" numbered="true" toc="default">
        <name>GNAP Token Format Registry</name>
        <t>This specification establishes the GNAP Token Format Registry to define token formats.</t>
        <section anchor="registry-template" numbered="true" toc="default">
          <name>Registry Template</name>
        </section>
        <section anchor="initial-registry-contents" numbered="true" toc="default">
          <name>Initial Registry Contents</name>
          <t>The table below contains the initial contents of the GNAP Token Format Registry.</t>
          <table align="center">
            <name>Initial contents of the GNAP Token Format Registry.</name>
            <thead>
              <tr>
                <th align="left">Name</th>
                <th align="left">Status</th>
                <th align="left">Description</th>
                <th align="left">Reference</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="left">
                  <tt>jwt-signed</tt></td>
                <td align="left">Active</td>
                <td align="left">JSON Web Token, signed with JWS</td>
                <td align="left">
                  <xref target="RFC7519" format="default"/></td>
              </tr>
              <tr>
                <td align="left">
                  <tt>jwt-encrypted</tt></td>
                <td align="left">Active</td>
                <td align="left">JSON Web Token, encrypted with JWE</td>
                <td align="left">
                  <xref target="RFC7519" format="default"/></td>
              </tr>
              <tr>
                <td align="left">
                  <tt>macaroon</tt></td>
                <td align="left">Active</td>
                <td align="left">Macaroon</td>
                <td align="left">&nbsp;</td>
              </tr>
              <tr>
                <td align="left">
                  <tt>biscuit</tt></td>
                <td align="left">Active</td>
                <td align="left">Biscuit</td>
                <td align="left">&nbsp;</td>
              </tr>
              <tr>
                <td align="left">
                  <tt>zcap</tt></td>
                <td align="left">Active</td>
                <td align="left">ZCAP</td>
                <td align="left">&nbsp;</td>
              </tr>
            </tbody>
          </table>
        </section>
      </section>
    </section>
    <section anchor="Security" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>[[ TBD: There are a lot of security considerations to add. ]]</t>
      <t>All requests have to be over TLS or equivalent as per <xref target="BCP195" format="default"/>. Many handles act as
shared secrets, though they can be combined with a requirement to
provide proof of a key as well.</t>
    </section>
    <section anchor="Privacy" numbered="true" toc="default">
      <name>Privacy Considerations</name>
      <t>[[ TBD: There are a lot of privacy considerations to add. ]]</t>
      <t>When introspection is used, the AS is made aware of a particular token being used at a particular AS, and the 
AS would not otherwise have insight into this.</t>
      <t>When the client instance receives information about the protecting AS from an RS, this can be used to
derive information about the resources being protected without releasing the resources themselves.</t>
    </section>
  </middle>
  <back>
    <references>
      <name>Normative References</name>
      <reference anchor="BCP195" target="https://www.rfc-editor.org/info/bcp195">
        <front>
          <title>Recommendations for Secure Use of Transport Layer Security (TLS) 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" target="https://www.rfc-editor.org/info/rfc2119">
        <front>
          <title>Key words for use in RFCs to Indicate Requirement Levels</title>
          <author fullname="S. Bradner" initials="S." surname="Bradner">
            <organization/>
          </author>
          <date month="March" year="1997"/>
          <abstract>
            <t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, 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" target="https://www.rfc-editor.org/info/rfc3986">
        <front>
          <title>Uniform Resource Identifier (URI): Generic Syntax</title>
          <author fullname="T. Berners-Lee" initials="T." surname="Berners-Lee">
            <organization/>
          </author>
          <author fullname="R. Fielding" initials="R." surname="Fielding">
            <organization/>
          </author>
          <author fullname="L. Masinter" initials="L." surname="Masinter">
            <organization/>
          </author>
          <date month="January" year="2005"/>
          <abstract>
            <t>A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource.  This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet.  The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier.  This specification does not define a generative grammar for URIs; 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="RFC7519" target="https://www.rfc-editor.org/info/rfc7519">
        <front>
          <title>JSON Web Token (JWT)</title>
          <author fullname="M. Jones" initials="M." surname="Jones">
            <organization/>
          </author>
          <author fullname="J. Bradley" initials="J." surname="Bradley">
            <organization/>
          </author>
          <author fullname="N. Sakimura" initials="N." surname="Sakimura">
            <organization/>
          </author>
          <date month="May" year="2015"/>
          <abstract>
            <t>JSON Web Token (JWT) is a compact, URL-safe means of representing 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) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="7519"/>
        <seriesInfo name="DOI" value="10.17487/RFC7519"/>
      </reference>
      <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174">
        <front>
          <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
          <author fullname="B. Leiba" initials="B." surname="Leiba">
            <organization/>
          </author>
          <date month="May" year="2017"/>
          <abstract>
            <t>RFC 2119 specifies common key words that may be used in protocol  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" target="https://www.rfc-editor.org/info/rfc8259">
        <front>
          <title>The JavaScript Object Notation (JSON) Data Interchange Format</title>
          <author fullname="T. Bray" initials="T." role="editor" surname="Bray">
            <organization/>
          </author>
          <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 ECMAScript Programming Language Standard.  JSON defines a small set of formatting rules for the portable representation of structured data.</t>
            <t>This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance.</t>
          </abstract>
        </front>
        <seriesInfo name="STD" value="90"/>
        <seriesInfo name="RFC" value="8259"/>
        <seriesInfo name="DOI" value="10.17487/RFC8259"/>
      </reference>
      <reference anchor="I-D.ietf-gnap-core-protocol" target="https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-05.txt">
        <front>
          <title>Grant Negotiation and Authorization Protocol</title>
          <author fullname="Justin Richer">
            <organization>Bespoke Engineering</organization>
          </author>
          <author fullname="Aaron Parecki">
            <organization>Okta</organization>
          </author>
          <author fullname="Fabien Imbault">
            <organization>acert.io</organization>
          </author>
          <date day="28" month="April" year="2021"/>
          <abstract>
            <t>   GNAP defines a mechanism for delegating authorization to a piece of
   software, and conveying that delegation to the software.  This
   delegation can include access to a set of APIs as well as information
   passed directly to the software.

            </t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-ietf-gnap-core-protocol-05"/>
      </reference>
      <reference anchor="RFC8792" target="https://www.rfc-editor.org/info/rfc8792">
        <front>
          <title>Handling Long Lines in Content of Internet-Drafts and RFCs</title>
          <author fullname="K. Watsen" initials="K." surname="Watsen">
            <organization/>
          </author>
          <author fullname="E. Auerswald" initials="E." surname="Auerswald">
            <organization/>
          </author>
          <author fullname="A. Farrel" initials="A." surname="Farrel">
            <organization/>
          </author>
          <author fullname="Q. Wu" initials="Q." surname="Wu">
            <organization/>
          </author>
          <date month="June" year="2020"/>
          <abstract>
            <t>This document defines two strategies for handling long lines in width-bounded text content.  One strategy, called the "single backslash" strategy, is based on the historical use of a single backslash ('\') character to indicate where line-folding has occurred, with the continuation occurring with the first character that is not a space character (' ') on the next line.  The second strategy, called the "double backslash" strategy, extends the first strategy by adding a second backslash character to identify where the continuation begins and is thereby able to handle cases not supported by the first strategy.  Both strategies use a self-describing header enabling automated reconstitution of the original content.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="8792"/>
        <seriesInfo name="DOI" value="10.17487/RFC8792"/>
      </reference>
    </references>
    <section anchor="history" numbered="true" toc="default">
      <name>Document History</name>
      <ul spacing="normal">
        <li>
          <t>-01
          </t>
          <ul spacing="normal">
            <li>Better described RS authentication.</li>
            <li>Added access token format registry.</li>
            <li>Filled out introspection protocol.</li>
            <li>Filled out resource registration protocol.</li>
            <li>Expanded RS-facing discovery mechanisms.</li>
            <li>Moved client-facing RS response back to GNAP core document.</li>
          </ul>
        </li>
        <li>
          <t>-00
          </t>
          <ul spacing="normal">
            <li>Extracted resource server section.</li>
          </ul>
        </li>
      </ul>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAFdl7GAAA91c6XYTSZb+H08RY34Ap5XyAoZCM92nhA2NKWO7JNNMUcWx
U8qQlDiVqc5I2aiM61nmWebJ5i6xZSptwyynz7R/gJ0Z6427fHeJjKJIVGmV
qZ58+Ncyzit5pKZFlcZVWuQyzhPZX1azokx/5ycnZVEV4yKTA6WLZTlWcqjK
S1XKvSLP1Rjb6IciKcZ5PIcxkzKeVFGqqkk0zeNFVJpekaZeOtraFuO4ginL
VU/qKhEiXZQ9WZVLXe1sbb3Y2hFxqeIeTDNelmm1EldFeTEti+WiJ/961D8R
F2oFj5KePMgrVeaqivZxUiF0Bcs/i7Mih4WslBaLtCd/hdV3JPyT5onKq47U
RVmVaqLht9Xc/FKV6RhejYv5Ija/zKExvErzLM1VR8IG5/FikebTT0LERKGe
kDKCBron33blIB3PVAmPpGRKvIUNpXn4vCincW7o2pMvlV4UF0q+yqcwgyph
aGql5nGa9SSS8MfPNEa3pDG60J9aAFl6clZVC93b3BzpxUU3LTbpTVnguaok
rYpS+OX1u/IEiDq+SIP19eMSjzd4bmaO8cWPC37RBVK0LP74oorX10I9w45+
Ca+78mA+ipdZFSzhdTxKVV57UZ8mHquygt2Fy5tQp27KnX6sNamvxrzZFCIv
yjkMeal61Ozl3sn2i13+HX6quJyqCuTB9ry6uuqWk3HEhES6b6b5pNgcjRfQ
76Hrx2I0UMwuCS1ay0lRMvMq+V4rWUzkKcgZHHZZycN4pUrH2vLR6eHwMQnd
flzF0zKe39F2HxvbuWEymPpdvJI7W9u79qlnTPMTSf+75JP4pSuHMzWZGKa8
rdmgK98U2e9Bm7UmJzBSnOZV1M+TUtHrweu9ne3tFz37x5MXPzxzfzzfDd78
sP38qf9jZ9e8OYj2u157jItSRQujgXpCRFEk4xGIK0ipEKgNZKImID5axnKu
xjPgHT2nE0hUpqZwIvnUUMUqtKqQMWgGNaaj0cWkugKO7dApjIv8Uq2wTzWL
KzcG96pmyjXvitNZqqX6Uqlc43u7jLmCuRJmAqv7pNF98tEAThtGQn5Z5inq
QXGVVrPGCl3zPjRPUSnDv6DqioUq41GmQAT0DBp2mSDzNEkyJcQDVIhlkSxJ
KQtYoZJIQNKa0lIRNBksMy8qs2QYfSVBY0q9UON0ko49HQVuAnfd2EjbPiTt
AxvX9iJsD9gKkDjLiiumLi7N2g85UtWVAkUAj7UiLQwLAvUrYI4REj27VAmo
Bhh4WuQwysqeB+3Pbu2hxkFB6nPdla9h7epLPF9kcLYC2w6GbN6GpCax7TJL
cPzJMpukWQZTjFZ8yqCd5BqL0BYF7hnPCBRDPIWhi9FlymyGPUGRJ3T2SFW7
Q3hnl4hCdaWAIh2RVhI4CMZWyD065aOFfc3iSyXrCw4JDXxZLvMqnSs6n1he
xiVIzAqXuliWi0IrslvjbJkQ94dEhyFhhss4SxMaK0/EEuxiSaaTzzqdzipN
Ey/K9DIFCUDp0hosKHRJ+KBjOSXsAHOKeDxWWgOTLIBP4NiYjsC05kUFVg44
WOulp3B/CJQrgVwGeoDto+OMF6Dds7RKFZJGKpgLuAdMSrXqylNij2q14JfC
cxAsEPkAmqXjZRaXwCBLreBc6SyCc4BV9ZmqQIlJCSYqSVEVwrLlJajwotQB
m9alLkkRJ4yWuMFELbJiRRhBwFJQwkhPwTTwVq90pea6K1hLWMli6baaQiMb
xBmIW2yMRhyceFWI8NBZMmIcCQ6HjkDF45kskD7hacMSQf7B9iQiJL82e44m
8Rib9U8ONBJ0bXVxpgvc6XipgY9EqM6Adsw+wC9gSmG5SXGVw4QKzBYfMlEb
yMekpsUJUCawX5y8yzqJNwxUW9MWVr8gr1iWqDGRlfosxQMDIwRsOyY2pue1
kRuNhOFOKwlt4zb1HDIV6YPl6DMQ3o7MhqemehpUvL6+w47d3AAhHjyQp6qc
p3mRFdMVEwaArURkq+XGu/fD040O/y+Pjun3wauf3x8MXu3j78M3/cND94sw
LYZvjt8f7vvffM+943fvXh3tc2d4KmuPxMa7/i8bbAI3jk9OD46P+ocbaHoq
5BDAvktkdaYHqWSSDKAocnusBeivMYgG/AF9AF39539sPwUi/IuBAzc35g80
+vDH1UzlPFuRg6jyn0DZlQCIreKSjF6WoTpIK+BIaAt8OgNuk8BRYHyNYLmF
gYRXwGVo1/LIgT2r/4klSDmAuLGZx8cgVm9OT0+Aa7QGVQ6zvB0eH3kJggfv
B4fw79+XqlwFZqmDJ6XNBkhBAU4gXQCAqJgH8y5RaKUGnkPVXgJ+RfYbxeML
nYENlw9/e4gEBdeExRx9DXlVsqNB0gTOzBT19VIxFUAZWVo+f7EDrIRaUZ7/
di5BzhAWIdvCujIVsz4AhwYJkPOwcEIZwyU4SgQBSBbL1zQNCqlnTI8KYJnE
9kh20mAJ8wfsK2xuLLqVQZSR7xKNjrE8xWUKTMVTpR5X46BO5siM9xr+6jAE
HHukAzprvisCmODp8VVOD4/h4as8ieDYyn9Fal8p4EL4vzatPWyYuTIGoSP7
rE5OUZ10JDnWHfCdjQHtkBvNxsHOCvOjqe3IIWsX9wvAuAmzMEA8Ol7CIyEp
8PRgkcmaiKJmqa0FcRAMpeX1A8fYN0J8mDHcQlNDllmvGWwkN/FvxZq/YwCE
QIyjHVDRyPBO8Xowgcx3hSB6TdmmdJQClg66DuhOFoWZSEkQcnxQonOMWt0q
ZpBBXTE1HKYV7kjm8QWBWsQpy/mCiUROwByWQuyPwzBZJUOCyhrv5gKZBWF5
YCt5+Y4gcyJG4rrTQRSLGFYn2m2TB3xgRcBgh0MBBI0R/Jo5FiBlsBxwAxUz
mAhwsYctcMRDlU0io/MQbjib3xiegIyTG3ZuyBbCNKlnMtk6D6GMYlkR8dOy
hiAFGnnX3AFSFJWaKbi+TtElIdgCE6G6GjYWqwUSgWDHyDM1KNtRmvPqCO3U
xml4EoatKg1kwWMYx2XJPs0YtCzxZbhbixZqQxqO02TgaABhAAzSG3m8Rlpz
mrDfdzG0LgqDsF4ickorCyKJ0T3uNsAJ4ERkUJmlMYgS7aaQAWXFOjmpW0SQ
CtoTkiAFsVxgyGCNAQx/BUgSoOsqj+fpmLyowJdo54E0dzh1kaEl6UpwOkkM
0S2JEc4CkUEKYNO3LgPtlrEzHoIiyCwu0bJeX7vfb27M6AMenXmPjKg3RIEw
WpZBp55FOIY+U0DqCjksAHQVTFPqyL70gUnwdcF9dhP37cTAo7lnr4faTukc
8jbmWWN4IQ4YyzD5EOuUal2pgE7McF0JYIdFlo7TKlsBrK8kAUDYJXKz0VV+
f4KBgTXEZJ/rWn9AbYnGaZzHzHYRT8o41NmjiG1j9Np5CMBbBSpBdMgQnTgp
zx0XBV687ljeQfoV6FVBSwEH7kfE5jrVBMJhN7SpUs5RoZvNTQor2QWp8Tjj
WA06U5Hct3wCvx+EhMbDo41b0YAHzryXijy8sSVdyaEJxOCBRzT0o4Ox9Bwp
RJ8pCy1oV9ja90NXIcWTxV0vliM4xhkJw0TFhCJhlyImJBFd5AhhPeM7/LrU
VpcB4pTnXd96k0BSDIyrzyUCODCwibU17IMb4yjh1aIA9sMxjF7wUzkOTVFE
COi62a+vTQgOoHn9gBx2xQ6iYHjiIj3+rCapyhLdE6LG/WduRY/Qc86nj3ui
J61/wcYc92uO3rV2VK6N1uUYJXbKCgMmrXTENA7tAyOOIHbY1EQq9HgG9tTj
d47t2a4U8wV1DchDV76RQfeGB0EYaUTUbh3QZTguvG46BvQQUMikjKfGL7Gv
utS/RT2QRJ4ZTXnmNegjsEExBXWYdpqI1yc1QRSraVjfjwIscMj9IRM4VBFG
y9BS7P4DbXmbGnFapNuuRoSwyvQsFLD247/30Esvtn6s7j/D2d9tfgRJ85mR
5nbi2RBAt04KQ8v+EKxUu07osJk00TcA8ZS/cIgkCOTUokb/v8nO8S1cJs5M
oxmwTQ4VvrBUaaB2khcjU9LE9yxN3XE2sZjAzOQZ+CTF5G5BrinBQKLtEfq+
MCATAQdF4XCxeV2TbuptpBv9o8B9WhRap6OM0zNhcyXPadhz1t72IQahGl68
9b7IYhpHlo2go4l11MBGXj/AmB5G2phjgC7v8wx5iuD0VapdSEAl1qlk3jAR
VDKfCFDDYdlEUrKCV6VTMI1oYV2Q0sYl4DzxwGx8E9ox6bAVT0RGkWCZ9f8W
MPeixAi3QNqzA8nvKEhkBcoEi2oBdljTqEhWLjDQMdKDIW4xUzG6xBbJcnZg
sszHzOZptTK2GonQ/0WaMCXRAMNMuBsPYKAv/E3HCCsQaJ/nKeBvmxIiILwW
H7UhWevw5+u5ExvF7jQ9jrsDmYDCasERfwiIczuCuLIi79w64J6r6sHWFNPz
6YSyb+zL2TOX50AIx6alAAoswK8z8Xy3SzNACmMlQOkxQGgg7R9//CE2nH3i
uTZ68prkYQMGdn/QAxIJeLRBSiqdbnT8u89XF7XGPEKFI2y82gta0otxeYkv
QJYWO7vPLrab7y/SBN/vbO1sR1vPo61npztbvZ2d3taTj82mX7Bh9PbF8duD
j5+f5vNi8XH089Hz0x++XD7RIzXcjSZnly+PhquzV2/ylx/Hzf60Qv25HO5u
Lw6r5ZOTp4fvT/92ueoffBlM9v92NlI7g18WB7tnk+iXz+nl1Ybrzlr9RtwQ
HQWzn2PH3q3k3Xi+93zvaf/ji5/eDIbP/v3Zk/7b/vEGD2K8LGR2597Z1AJw
v7ORTgQEBWwwWcdONasGzN7IuBylABHAJJCsoG/GpSRRAfgkLeEXUPFiXiQq
Q9cVw+6EbGreA+isOi5zi7SxsVoqxWW6mDvRtwSeNsliDIibhBhl0kwOkwwN
xp4Cl2cwNFq84TM1nEvjYeBAvH9HLZfHI/MayynY8noUD05IRnIGDvhItSTh
7EuMBIPjifopfER9SnUJI9Fz9B28onSBJYwTWNlzKBIPKYgzkq0YK1jgWqSR
/Fzcvwt91PYvHBIywUTKjskpUN0EfsJwqfjt199+lb8OleLNygfb27ufHtnK
jingk+UIa1M2SaldTUmvba4rt00++k3o/lj+9um3T8zrf4rMz5+MhPyp/U/x
1QSf5dcoerT9OPrLV4lEkF9NQ/i/j3+KrwdGgQVv6D/ot8P96E9h38tmw8af
tzf8t+jRk8dR9M0jBpuRfoinwRCy/nMveVxD0gTbJqDbYq605RqO/lV1GQS9
vtO1cSLPLXo92Mym0nGOB7TQEZGBDhGOnwz9dERCj1AMWsK6DzUNhE2MENgo
ETx6DMt74iTbCuntizPxyEaS4qG2y6KpsBUHpfRd0ctJuBxYx1NHJlPlUN8w
KdG2sLXDJN9AJFwaqMMk3CH7tTZ3QvBoDU1yyzNuebub00IyX2lgACIs1Ci1
9Y2QSW+M75KfPEWArwkkhs5SkztRn6fmyGrZYw+Hu4FHbAtgeHrkFg6jtGzU
KlHjabnApofTqhU5zeMLRncpw+aOqZtgj8fCxYbtbonVN3D7jTuidR9mkzeh
WyI6c3CH5st53Qp6+AsbMpzYzOzA6q2HyDaE1m8CpLWl1qTFZLsGPE/gutyf
hEcldHIMU256aSK4v7nd3RZvwDvtGRp3TUqXqhr3OPsTna4WqocWMTMk2/ys
wV4NrWMSHeSLJQ6RTrf/3O12/Zvg2X46VTTPLAaYSI+EAaehfCCmOh6+eLdz
8u7NT+8Hz56evvzh6NnLD8+PP778YW//9fHRyc72i8HJ9uHploF/t2HZb4dr
N3XAhocTQI5blZnP5qWTMEGDOhzz8uD0gutCv65lBq37EGOY0ogXgBsM/l7B
szqAgQ1ibw7fdkQ7cAmfG4xDkQbRimeMZjGZItb9AbhxRSxYRcZOtrZBDyBL
7HNxlmNrSSowG+NlSdVGujIFWOQ/hvkpa/gI8VJBWR3qKWFtTbhYn5FC1Yz1
GRgpbokc0JwYWIDpFGyccLE5jUejoshUnDeU08FEnsO+1Hln/di9Knbny2wW
B4c5KvDUYZjAfwfi0Py2tsgsgUblAUyJAs5M1WKpjZHgVMvc1sth8ldyNbLl
PCbkI0uRGg/ikJNimSePO77qAV/QCJpgpTyfxJlW50GJB4e4OeE7TyvYMHDC
wXr2OCCDjJMkZTffdnf21sTVw57CGfGQiVypxT3qjFbGQQlYGvg3wpfDdUz9
mHldD973vlHLtxplWy3YKA8kU1QDbP8I/c5QD1dC+0KHE6s904zD3WiKXUQq
S+FQTXQGcyCmisBqmpoKCII/JqhoQhEKOq14ti5FA+UjpuBmC7hZU44jZEqm
LnalPy22qPtLzhOsB3NrutmFxxq463bIJ2vcbAa1HA2bBAYr3QrcaWIx2Sjg
PCEmWTxtYaYWqGA8Z+6wzkOqiflPGfywkOBxWoZGtbIubIHwOJfT4FI3Cgq4
20coHzWZPiclcW7iUgY5WKAgd7a25PFP98GCvXg8UxE2KousB2oowhpiFVh7
VBobPdZ3IQKAZ7/6KFRSZItZmkcAVWM0OVjRR0U4rKfgZPIpB3A+df6Xglw8
Cge6BsN+I7xEb3HhG/2f+y/bXppQ15fV71EzDMbbzKY8NCCgtveEfi6OX+6W
g6dvL7f++k4dAk7q3hqmwsSuCSJxiCZwrSp5/eCuRIxT6mCCbaWTi1AsMGHh
Ij62q17D0t+mwMR9Kt1Fv8kXbEmL+fRZTIWCplQmqHUBLVIJV4dF/jQg7zZU
seaYBSJs7MBmKMqNXJRJYtxnF7weSms1WY58dJLm3UY7DTe+D+X/k7hiYaL4
zLlTt2fWa/UloftlNVvdrNmdODPA4Xa8osBwh+Wyao6MxoGZC4sNSlVPSLrR
ALS5iyc2sRZwgzn3cGRXTkLq2dTjoJEty6L0PrejTL30wBMohLSeQrAsm2nh
8AXDvgDlgqyAu8BRJQsyXcSxHnthho61waB3F8AhCh7RxLCNOtx0EztSxcgD
6QLZDWXWIg63oNvWQmEgG63OzP2UgvkyLIoKck9IZZuDsQmY9lAPIAuCb853
Dz1pN/o/yI9ed6Br5rORvYm5dKnWxL0sVZy0maMr9FzaXhjTvFF786mRjLGZ
9FsmtZHqBr1yVW22TWmbO/HF4bNNwgJ3rwOxA92laV+Hhxfr79I51ss3hvfG
OEATa2ClBky+ORBhDfutvnegSwOHngqJrZgzx1qLTfaqCuxi4MdSLWkg1rYM
XDRgZovTPkcDxeYVC4iXBMB94UBYKGMX3B747FsP0RirWs6pCgyu39J6JY8X
UCR3kGQm5UHKgFGPjC/jNLMO9XoCOSjgjHmwlsqydSt2N7pBt9+oTFOJ5q5a
mvndzbtEXaoML2IhDe2qztLbzF+/PSscHjeiuaU2LDLhKnSj9PzB2RoEZ/n6
5PsB7dWSPBvFde4mUekMfPe/UQhX1+NBWZQt5+p4FBL4fpQ0VSUyYuix1Qvn
WsrO/g8cmHXeRoF+/eHDwU+/vPz52fvdZ0eH2y6o+EDuY+0R4/O1i2TXDxrV
NaYIOy7HsxRrRKiyci19jAX7FDlsuyHGl3G44impu4N8+w5QJegUTCYDrJDD
lKL9JsfE5riytUPIU9WKOWoeG5eRrmeAXqASLGsdO40h6Ipjplh0mU4GjM6L
xJQ/YA/1xZRh0mjA05oCfP4uq7uGYRUVDDFVuSoprgivrwwt1251ILuamx20
oXDbfLGKrnehivPvXCjAhGBdEQk0/eLql4BmABfxTOue+4dZmmGNOA5gK5Jw
7Xwmv4a479Mjf1PlsclsI8O7C0BiYBLAZq8WnzTW2hGVT603RcbSjGTLd6yR
yhfl4pELE2yu5YYK8HNSpFNLkshPgYFqMJmN8QMOE8wesbmjqt2WmsO62A2q
QpLmSyVd5Q5txixTwDK151euCvTVgHZxjtIdk2Bci0AG4iR89jNwFu/Kit+T
Jb81Tb69nif3fw6GO3flzdcS583Xt6a91xLk39GzfZ/f0bPx8y09I/9DSXn6
+cu37dP33LU9o7aeQJFnj4NX9632Xk5o/HhOuL8iAPmC8V7eUg2Abw1G0sbU
h9lZXzXibYDPNQSX3YC9eDB7K9OMllYmjST5ivrKemKkLOOwMH5w3JVHhanL
4W9cwHicSQ+hZdO96jgjY7NF2DcoMlirQsCXtWoDWyLQ2CSuE9fQ2CfVB+Bz
S+Advwmjk1HjgFBA090uNajVEVDJDrWBUaDNMx7uljZ3qUy81LseefN3zYPl
YA1VrQIgrWyETjhjmAfask/VASY2Y4cK8H0IW+8NyvH91BoWd7Y65Eo4PVun
ycEs2+qsltflOAteMmvgDW8N1uCMBwHf5rWbFZzzMLaSss2Xl/jFIZozXyuK
5oxk59uiVT4gUH35n4cC9sF9BPCZRG8/DHtSfV5t3ZEnDwLdLQEA/GmJbt8V
CKAGtwQD6N1tAQF62RoUwJ9PLZ713cEBavJ9AYJal/uDBLet6+5gATW5I2BA
79uCBjRd7clNM0rRGkDw/Uz7DebVWyMIplW7CH5PaUWjJqIZh/AgmyKi3q1B
zdkUnPtUDSv1xiBUCAviulBxVUN8OHyON+U0Is3wSxyTZUmpocHwIfrPdEMc
L5dlKplyxTr4W81H4HE9Oj3eP+6xBt37yQXd9YwqE2DaEXgyK/pCD8hrVbtG
bF16/Zg+TNQ/6uMH4zSoqtJ8Juv6AT6Faahi8/TlPt0NQsRJ9z2zgpyKFD+k
YhWYu7HGXkGJmncBagwdKtCIZbGcsu1a8ne3WP+ahEmKl1e5kPPBgzsuOWEx
8Nodp9YvuYC+jOm+n0Had4xJlow+t1S7t0VXKh74ZqcKZBnvINDjA+NPutd7
9to5819FjuRIUU20/QJG6Ii6a+rGO7vjZpcQX4/AUfg6BDlf6q/7xKeUAv86
sO484EL83lTzH/H1/PNVFaEpUcn51z57JQgK6ZrhBzWyn0XgJiwroMmhBd0f
wu+CgWG1A8FU5WpR3TOWa2WHe9Uy3Nxczq6NZG9sI2rFRiO+s11rY+5x2ya/
g9dee/9xDyhJL697/B24P28cfD/VN+QNiof7xtuaiNg394mJtiOM6yNgTCRJ
LN/3AYi5Gzv8mSkqTqfbMKeHQ4SZGFIBuaHEiP3cCH8vDxXSO8QFHDPUJtoi
9CzGmCMsAcAn3QK2crgKLqCPUnf0sQ3csCwXwnzug4uVOMhIyQaOvLLKwm9p
xOMWEpkX91FoYfrfSSAqV69H4lL2+F02Cv6mgE9MgUlaqy+0MdLNBSG25L/W
AON4tuBX9F2VF67R1aLQyYAsUywZVsN5m25QTd9EZq60fi33a+vk7J2t/tBc
nLCf9EjdVwJMeFEYyN0+lA838yb9R6/85yIyFbvQiW8Pf80Bnl7yVW5QHPgZ
HIoDWq3+JsWAIirgGf92g2V/+MVQNN6RfKkqvBbibSh+LqsGPbumZT9J/D2M
RiLUKjxu+Zo//IYLr5+7+2LbesP2VHyzwysyTSr86pYPmgf3+EzzdwU6a3yw
tv1g6CMySC1pP8JDV7eCb74glbakm5i+j1j//AFlp40Fhw7/BevlxZ4GVgAA

-->

</rfc>
