<?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.2.6 -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC5988 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5988.xml">
<!ENTITY RFC6125 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6125.xml">
<!ENTITY RFC6749 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6749.xml">
<!ENTITY RFC6750 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6750.xml">
<!ENTITY RFC7519 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7519.xml">
<!ENTITY RFC7662 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7662.xml">
<!ENTITY RFC8288 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8288.xml">
]>


<rfc ipr="trust200902" docName="draft-ietf-oauth-distributed-01" category="std">

  <front>
    <title>Distributed OAuth</title>

    <author initials="D." surname="Hardt" fullname="Dick Hardt">
      <organization>Amazon</organization>
      <address>
        <email>dick.hardt@gmail.com</email>
      </address>
    </author>
    <author initials="B." surname="Campbell" fullname="Brian Campbell">
      <organization>Ping Identity</organization>
      <address>
        <email>brian.d.campbell@gmail.com</email>
      </address>
    </author>
    <author initials="N." surname="Sakimura" fullname="Nat Sakimura">
      <organization>NRI</organization>
      <address>
        <email>n-sakimura@nri.co.jp</email>
      </address>
    </author>

    <date year="2018" month="October" day="19"/>

    <area>Security</area>
    <workgroup>OAuth Working Group</workgroup>
    

    <abstract>


<t>The Distributed OAuth profile enables an OAuth client to discover what authorization server or servers may be used to obtain access tokens for a given resource, and what parameter values to provide in the access token request.</t>



    </abstract>


  </front>

  <middle>


<section anchor="introduction" title="Introduction">

<t>In <xref target="RFC6749"/>, there is a single resource server and authorization server. In more complex and distributed systems, a clients may access many different resource servers, which have different authorization servers managing access. For example, a client may be accessing two different resources that provides similar functionality, but each is in a different geopolitical region, which requires authorization from authorization servers located in each geopolitical region.</t>

<t>A priori knowledge by the client of the relationships between resource servers and authorizations servers is not practical as the number of resource servers and authorization servers scales up. The client needs to discover on-demand which authorization server to request authorization for a given resource, and what parameters to pass. Being able to discover how to access a protected resource also enables more flexible software development as changes to the scopes, realms and authorization servers can happen dynamically with no change to client code.</t>

<section anchor="notational-conventions" title="Notational Conventions">

<t>In this document, the key words “MUST”, “MUST NOT”, “REQUIRED”,
“SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”,
and “OPTIONAL” are to be interpreted as described in BCP 14,
<xref target="RFC2119"/>.</t>

</section>
<section anchor="terminology" title="Terminology">

<t>Issuer: the party issuing the access token, also known as the authorization server.</t>

<t>All other terms are as defined in <xref target="RFC6749"/> and <xref target="RFC6750"/></t>

</section>
<section anchor="protocol-overview" title="Protocol Overview">

<t>Figure 1 shows an abstract flow of distributed OAuth.</t>

<figure><artwork><![CDATA[
 +--------+                               +---------------+
 |        |--(A)-- Discovery Request ---->|   Resource    |
 |        |                               |    Server     |
 |        |<-(B)-- Discovery Response ----|               |
 |        |                               +---------------+
 |        |
 |        |  (client obtains authorization grant)
 |        |
 |        |                               +---------------+
 |        |--(C)- Authorization Request ->| Authorization |
 | Client |                               |     Server    |
 |        |<-(D)----- Access Token -------|               |
 |        |                               +---------------+
 |        |
 |        |                               +---------------+
 |        |--(E)----- Access Token ------>|    Resource   |
 |        |                               |     Server    |
 |        |<-(F)--- Protected Resource ---|               |
 +--------+                               +---------------+

            Figure 1: Abstract Protocol Flow
]]></artwork></figure>

<t>There are three steps where there are changes from the OAuth flow:</t>

<t>1) A discovery request (A) and discovery response (B) where the client discovers what is required to make an authenticated request. The client makes a request to the protected resource without supplying the Authorization header, or supplying an invalid access token. The resource server responds with a HTTP 401 response code and links of relation types “resource_uri” and the “oauth_server_metadata_uri”. The client confirms the “host” value from the TLS connection is contained in the resource URI per <xref target="RFC6125"/> section 6, and fetches each OAuth Server Metadata URI and per <xref target="OASM"/> discovers one or more authorization server end point URIs.</t>

<t>The client then obtains an authorization grant per one of the grant types in <xref target="RFC6749"/> section 4.</t>

<t>2) An authorization request (C) to an authorization server and includes the “resource_uri” link as a resource parameter per <xref target="OARI"/> 2.1. The authorization servers provides an access token that is associated to the “resource_uri” value.</t>

<t>3) An authenticated request (E) to the resource server that confirms the “resource_uri” linked to the access token matches expected value.</t>

</section>
</section>
<section anchor="authorization-server-discovery" title="Authorization Server Discovery">

<t>Figure 1, step (A)</t>

<t>To access a protected resource, the client needs to learn the authorization servers or issuers that can issue access tokens that are acceptable to the protected resource. There may be one or more issuers that can issue access tokens for the protected resource. To discover the issuers, the client attempts to make a call to the protected resource URI as defined in <xref target="RFC6750"/> section 2.1, except with an invalid access token or no HTTP “Authorization” request header field. The client notes the hostname of the protected resource that was confirmed by the TLS connection per <xref target="RFC6125"/> section 6, and saves it as the “host” attribute.</t>

<t>Figure 1, step (B)</t>

<t>The resource server responds with the “WWW-Authenticate” HTTP header that includes the “error” attribute with a value of “invalid_token” and MAY also include the “scope” and “realm” attribute per <xref target="RFC6750"/> section 3, and a “Link” HTTP Header per <xref target="RFC8288"/> that MUST include one link of relation type “resource_uri” and one or more links of type “oauth_server_metadata_uri”.</t>

<t>For example (with extra spaces and line breaks for display purposes only):</t>

<figure><artwork><![CDATA[
HTTP/1.1 401 Unauthorized
  WWW-Authenticate: Bearer realm="example_realm",
                           scope="example_scope",
                           error="invalid_token"
    Link: <https://api.example.com/resource">; 
             rel="resource_uri",
          <https://as.example.com/.well-known/oauth-authorization-server>; 
             rel="oauth_server_metadata_uri"
]]></artwork></figure>

<t>The client MUST confirm the host portion of the resource URI per <xref target="RFC6125"/> section 6, as specified in the “resource_uri” link, contains the “host” attribute obtained from the TLS connection in step (A). The client MUST confirm the resource URI is contained in the protected resource URI where access was attempted. The client then retrieves one or more of the OAuth Server Metadata URIs to learn how to interact with the associated authorization server per <xref target="OASM"/> and create a list of one or more authorization server token endpoint URLs.</t>

</section>
<section anchor="authorization-grant" title="Authorization Grant">

<t>The client obtains an authorization grant per any of the mechanisms in <xref target="RFC6749"/> section 4.</t>

</section>
<section anchor="access-token-request" title="Access Token Request">

<t>Figure 1, step (C)</t>

<t>The client makes an access token request to the authorization server token endpoint URL, or if more than URL is available, a randomly selected URL from the list. If the client is unable to connect to the URL, then the client MAY try to connect to another URL from the list.</t>

<t>The client SHOULD authenticate to the issuer using a proof of possession mechanism such as mutual TLS or a signed token containing the issuer as the audience.</t>

<t>Depending on the authorization grant mechanism used per <xref target="RFC6749"/> section 4, the client makes the access token request and MUST include “resource” as an additional parameter with the value of the resource URI. For example, if using the <xref target="RFC6749"/> section 4.4, Client Credentials Grant, the request would be (with extra spaces and line breaks for display purposes only):</t>

<figure><artwork><![CDATA[
POST /token HTTP/1.1
Host: issuer.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials
&scope=example_scope
&resource=https%3A%2F%2Fapi.example.com%2Fresource
]]></artwork></figure>

<t>Figure 1, step (D)</t>

<t>The authorization server MUST associate the resource URI with the issued access token in a way that can be accessed and verified by the protected resource. For JWT <xref target="RFC7519"/> formatted access tokens, the “aud” claim MUST be used to convey the resource URI. When Token Introspection <xref target="RFC7662"/> is used, the introspection response MUST containe the “aud” member with the resource URI as its value.</t>

</section>
<section anchor="accessing-protected-resource" title="Accessing Protected Resource">

<t>Figure 1, step (E)</t>

<t>The client accesses the protected resource per <xref target="RFC6750"/> section 2.1. The Distributed OAuth Profile MUST only use the authorization request header field for passing the access token.</t>

<t>Figure 1, step (F)</t>

<t>The protected resource MUST verify the resource URI in or referenced by the access token is the protected resource’s resource URI.</t>

</section>
<section anchor="security-considerations" title="Security Considerations">

<t>Three new threats emerge when the client is dynamically discovering the authorization server and the request attributes: access token reuse, resource server impersonation, and malicious issuer.</t>

<section anchor="access-token-reuse" title="Access Token Reuse">

<t>A malicious resource server impersonates the client and reuses the access token provided by the client to the malicious resource server with another resource server.</t>

<t>This is mitigated by constraining the access token to a specific audience, or to a specific client.</t>

<t>Audience restricting the access token is described in this document where the resource URI is associated to the access token by inclusion or reference, so that only access tokens with the correct resource URI are accepted at a resource server.</t>

<t>Sender constraining the access token can be done through <xref target="MTLS"/>, <xref target="OATB"/>, or any other mechanism that the resource can use to associate the access token with the client.</t>

</section>
<section anchor="resource-server-impersonation" title="Resource Server Impersonation">

<t>A malicious resource server tells a client to obtain an access token that can be used at a different resource server. When the client presents the access token, the malicious resource server uses the access token to access another resource server.</t>

<t>This is mitigated by the client obtaining the “host” value from the TLS certificate of the resource server, and the client verifying the “host” value is contained in the host portion of the resource URI, rather than the resource URI being any value declared by the resource server.</t>

</section>
<section anchor="malicious-issuer" title="Malicious Issuer">

<t>A malicious resource server could redirect the client to a malicious issuer, or the issuer may be malicious. The malicious issuer may replay the client credentials with a valid issuer and obtain a valid access token for a protected resource.</t>

<t>This attack is mitigated by the client using a proof of possession authentication mechanism with the issuer such as <xref target="MTLS"/> or a signed token containing the issuer as the audience.</t>

</section>
</section>
<section anchor="iana-considerations" title="IANA Considerations">

<t>Pursuant to <xref target="RFC5988"/>, the following link type registrations will be registered by mail to link-relations@ietf.org.</t>

<t><list style="symbols">
  <t>Relation Name: oauth_server_metadata_uri</t>
  <t>Description: An OAuth 2.0 Server Metadata URI.</t>
  <t>Reference: This specification</t>
  <t>Relation Name: resource_uri</t>
  <t>Description: An OAuth 2.0 Resource Endpoint specified in <xref target="RFC6750"/> section 3.2.</t>
  <t>Reference: This specification</t>
</list></t>

</section>
<section anchor="acknowledgements" title="Acknowledgements">

<t>TBD.</t>

</section>


  </middle>

  <back>

    <references title='Normative References'>

&RFC2119;
&RFC5988;
&RFC6125;
&RFC6749;
&RFC6750;
&RFC7519;
&RFC7662;
&RFC8288;
<reference anchor="MTLS" target="https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/">
  <front>
    <title>OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens</title>
    <author initials="M." surname="Jones">
      <organization></organization>
    </author>
    <author initials="B." surname="Campbell">
      <organization></organization>
    </author>
    <author initials="J." surname="Bradley">
      <organization></organization>
    </author>
    <author initials="W." surname="Denniss">
      <organization></organization>
    </author>
    <date year="2018" month="October"/>
  </front>
</reference>
<reference anchor="OASM" target="https://datatracker.ietf.org/doc/draft-ietf-oauth-discovery/">
  <front>
    <title>OAuth 2.0 Authorization Server Metadata</title>
    <author initials="M." surname="Jones">
      <organization></organization>
    </author>
    <author initials="B." surname="Campbell">
      <organization></organization>
    </author>
    <author initials="J." surname="Bradley">
      <organization></organization>
    </author>
    <date year="2018" month="October"/>
  </front>
</reference>
<reference anchor="OATB" target="https://datatracker.ietf.org/doc/draft-ietf-oauth-token-binding/">
  <front>
    <title>OAuth 2.0 Token Binding</title>
    <author initials="M." surname="Jones">
      <organization></organization>
    </author>
    <author initials="B." surname="Campbell">
      <organization></organization>
    </author>
    <author initials="J." surname="Bradley">
      <organization></organization>
    </author>
    <author initials="W." surname="Denniss">
      <organization></organization>
    </author>
    <date year="2018" month="October"/>
  </front>
</reference>
<reference anchor="OARI" target="https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/">
  <front>
    <title>OAuth Resource Indicators</title>
    <author initials="B." surname="Campbell">
      <organization></organization>
    </author>
    <author initials="J." surname="Bradley">
      <organization></organization>
    </author>
    <date year="2018" month="October"/>
  </front>
</reference>


    </references>



<section anchor="document-history" title="Document History">

<t>[[ to be removed by the RFC Editor before publication as an RFC ]]</t>

<t>draft-ietf-oauth-distributed-01</t>

<t><list style="symbols">
  <t>added reference to OAuth Resource Indicators draft</t>
  <t>added reference to RFC 6125 for matching host</t>
</list></t>

<t>draft-ietf-oauth-distributed-00</t>

<t><list style="symbols">
  <t>Initial version adopted from draft-hardt-oauth-distributed-02</t>
</list></t>

</section>


  </back>

<!-- ##markdown-source:
H4sIAEFuylsAA81be4/bxhH/X59iISOtDxF1p/MjsRoX0b3iM3yP3J1xaIPA
WJEraXskl+WSJ8uJgX6Qfrp+ks7MPvgQpbvUARqjRWRyOTM7z9/MroMg6BWy
iMWYHUld5HJaFiJiF5OyWPQiFaY8gVdRzmdFIEUxCxSHN0FUrQ329nsRL2DV
/t7o22C0F4xe9UJ4MFf5asx0EfVklo9ZkZe62N/bewXreS74mF2LsMxlseot
VX43z1WZjQ1jdgsPZDpnP+DDXg9ZqnzcYyyA/zMmUw3iDtkbnkcFPTFiHsnw
rvZQ5XOeyk+8kCods0nCP6mUXoiEy3jM+hGsHy5w/fdzfDQMVdJvcjkYskOe
ZFMRxzVGB7nkafNFk9klSn8aibTA/dV5TvHTYTQM7ccbOZ8P2TW/k0mZ8xrn
c140Hzf5nl+dNrilgbaLv09zCVyG/8j6vV6q8gS+uBeo06uTw/3R6JX9+eLV
t9/any9H+y/cz2+ev/I/X+zZn9+88J998/Llvv357b6hcHbz7npM0lgHM7bd
H+6xs7IoecxgATuMJWiJ4SvUVkgbYTyN2KHICznDJ4IdqBKeTMJQaM1u1J1I
taHM87koxmxRFJke7+6CI/Ii5+GdyIforkNQzy648e6aBydFrHeJhnFeHqI+
2NJ6Hrmj8XtaVLkg/gnsf62pzobsrUqF7n7bdqG1BW+H4FA8isWq+/3tkB2J
NJUaGVxMrs82aHVCMlpfgOjK70XOzkTBUStfqC4I+FABvdUfUWcXk5uDDToh
X2EHMo1Awi/UQYG0gqmh9UfUw8O+c3XaoacroVWZh4Kdws4g3FT+pcGVW4qB
9BR/L339do0w1pPprMp4vSAIGJ9q3ErR690sxHrpY1muZjIWTKR8GgsNCcm+
CE2+KhRzIcGWC0jKvBF82gSfyu0vzRK+YlPBSg0s4GM1LbiEPGcyGnmWZiAk
42wOUqbMqXBAuZBYZDyHGlAA3XselwI/QznvZSRg6wwSaIMekPgnrCqGZseJ
jEApvd4TMHORq6gMUdJe7zRlv/xiU/znzwMkkwM92DLTYB3QgRPF7QoF6tru
ECizRMHXUM2yWHyklTWowPRKFyLRsCerR6MXK3XC0xUsn81AAFBxiy18tVzI
cMEWHHynWtYlCdHic3QuQ3vITkC34iNHuSr2zipmES4vlqpDBNAoGcAoW4Ni
EhnznM3KlLTIYyjzAwabZIKDiKA9NG6N0lyoTMEqiIYYyM7hI7cfNJPM0cca
O5nlKtmwuVhhUYyQB7HrIA5Gn4C8Ej5md6laxiKaCzZdkZfYzasZ/S0XMZHX
C5lp0EaxFDX/80zXrK79K9huqlA9GNgoA9dEOS2TKUbB7BHU/BsNBEAZZTZk
N5WsqRCRbkSdSoMIYA4FB6qxMwDhAxsFbe0+MtRMkHH0oANB/gTpoCHHQi3x
79aHOTpJIUI0j980j7XymYQCZAbRIZGSVrNiCXCYReJexCpLyKU1Cxc8nZsQ
R00Cr0xABABujpNt2gshUS14lsG2ohVARjRHvGJLCakrVZYsUrV6DVUkwFee
PGHnquDGl9mhSu8RjIGNKT8UC7AwJPoSpaMMwe7ECvM32KR/9v76pj8w/2Xn
F/T76vjH96dXx0f9Qa9//Wby7h0+pB9uxfWbi/fvjqpf1ZeHF2dnx+dHx/Ty
bPI3oIH77V9c3pxenE/e9RnqC7YwxbQHNspygeoGrUFshpBrTGgcHF6y0fNB
j7IbItzPn81Ob0SeyFTFar6C7WldCmxPYFNg9WIF3qxLSgWtfDowdsRoSp2H
d6ZBCL04ZgoTKQPx0F4gMIk3k6kRrpZyyZr27y/2Pn8mGS/Bi1SoYnYBFO+l
WPZ6J3JeAp0R0+ByVJFcEQN3AieEMIvadQxkoQr4dWD/fM22//EL3Xrz/a/u
/a9B8HSyA+XkyAFCgA8mwHD5X3GhxxO4vv39A/zpvYWund9/Fzw9aPPXGXiq
IAHa9H8r/wf3v07vqUunVNLbaXye87TYeZjKl0kFVjncCVodgDcMWKX5xvO3
3dejrFIzS5dVjnZItEaTxqy8/werfBk90Ofx5v2Ql9fd/H/y8gf0eYL8KQ+Y
auLZbdbnF0R5r73EZZsxm7gs43PSCaSbHiFnzGuYjBe5gCJVCAAQS3pa+Heu
khGewZxpcDSmLMDiox028bV05Ys15BgHHv0bG+UQ/hUPV8bcOm3KN5Qri6oI
bCf8TlC+rIYMVJ4NPK7DDFyJRdzJYctvR03HiqoA7+kyy+KVqxfNMFsIHol8
QG2AXwZyyBQAvIwa1cWI0YbaZtdQZamAc/bm5uaSPd8bVerAAk6qimV6pw3W
MniOFSvADKzvaH4oc9mnpShpnzq1D4bPh8ROCWhNQyOhSmcSaxh9tFC66Jv2
ozIojnFgWSoIC6Py4W+YC02pK+r7en91yjLYmKl3o/0XUP+0/fClAWAzUYQL
EJygrXGW1iyDqOBSQwlHIkCm8gHop1HnhLQ6YaHAbxWAB6Skh6YJdJ0duEiV
y9OudE58iYlB0OahUXertru9PQcm++DrbXre4Q93CEW239daLpmGcRkJa4mm
VdH4iDB4pemqW3RaujoFgfaHI2PfbvzoWxzebE5NA4RdodYqlBRANjhaopBz
wG6f+d2uhRyD5Oq+bns88Wk63fpWK+YNGaHDN57zMTPR6mSBprdzOOZBRIWu
BpTGMAGBV2yF9YN6AvL9SSx4nm7Ehhr9UhLktD0lAnZ60JoF0EvCjfA4K1zb
0Z2NyKKw1razdf9/FDPshjZSrvU6uMYSbOyeF9DWZ4Wuki3DvmNL+qQI7kLE
iIB91ICzDsCaqACbAbuTJ+4WuhvKjv2Gpfve50wyZjMp4qjZWoJwxtMwu+GY
3cV1h9ykxiXXzkXhnW2qW1nwgSSn+T0mi8I1EjazgiINfh+ue+TBjslT22sE
Ebu9vQ1qE3XRN6qxKjCh3MgmIs9VXmPv6o3J9KCOvlX7B9K3KSPQm5mWyNIy
pKhVNQv61K7WyVZaaRr6mdEKZ/13EN5W3DdGXP8NHizANyQ+NZuOL/o7ZcB2
9esqfvXg8DXTLN5SEsEc1QCJPSX1iI+Ai5jOeCi0K8GCTWHTdyakIG6yGEIy
K/NMaYGFKV7tjA3Ywi3ujoYjKufvU5ctRGShWNuGY3YAqYXsDUp93beyfDA6
HqwBuNYfMkv1lbHSg1+RX7xuGd9/hLYas+/cfJhncmjp43nWrtN9/69/YeuM
wFCvm+ZpS1MR1g26w6WI44D68F0zb26k2sAYcDPTzWZuAAFyMRvmPj0AbMjJ
vfzw7JHARoOjiFBC+vGgqKOwDRx06s4KFpcAiY3gK/X1q5Hk1jbTELwLsm1I
2gZ62+SLidDmftFMqoSicgFyi3vRRGRWcxuRXa2M2tkaTXmwA/EZroZCOvFS
AxhiaIYQJgXWpVhqmnw+iBFNYQGk6IDiOwSKT5o44gdEfg2veQRyxDG3VUIi
sD2SOtkKHJ80m1Db169XiMOdhii2mUk7TwU8gHrc3qmJkTOjL8jAKT4kPHjP
ZYzoBKfqsMVIJfEK6MTGd3CV91XU/ZCdzurQAUiUqUM31pGdbMSXPKn2AVad
AhrC5nKemnnbOr+GSuyssY5KHTODa1hJxwCE99BLZhDwWuPhAGjHWwvaOZw4
a5ZUB9k0UNZynhI4Rf3ZkHK9oWXgJ4cRSBRioT8SmaAzRaa6kKNxnIo3HSHV
CmnTXRq4zHjApoMhU8TrhdRnpD41E+A5USTtULjqJ3wUenTQTiit4xbwG6NW
XNft5CC3nUUdQtOOtgFkYcJrYMkbmZeqjCMEub9HDb68gM3vGqW4emyKM+Td
sbVYvfbQy0YKgLLMtQxZ+Onvh/yHq2v+7GTv7FOW3h6dJD8m8Hv/7S19dQje
APsKbgBqjBnPsthedtj9GCyXywBPKIMyj8EpoKWPjIBk+w+ITl4bk34IK/XQ
ij+Zwt6o6+aFM8hrKqNfPZt8tX8C/2tVaXjiFq4nlKMdM+bpzhLkOj4Tr1cV
7yekxxZip/OxJV9VjYk/h8OlYElgYcqlBdhdzQm62dvbG+NUeB0FnMoc9RYt
hrZh+c+//g2R14cA4TIxO6idyoZ48LHqcOdbTEIm+9LpKdZyUoVh/PLlPjDG
VAaEDCPZWObHNa4OU601NZ7kSQQdlXmVtRslCc2V62ZdOcCIWp8PrlvxuFkW
rJL1piq/CaP7ycH6afmlPS2n3WGAoSI6UllXL0ZRiidsXWcuHW3Qid1Nh+TE
ntxm3YbocArBMx3IhpVbNb1yk1b+rJsegVZw99cwtLWEDXF7ZHZD49BULGkw
ysF0IhH5XCB4SlvFr35K5/psr4lNo6B6QvTgUI/bWR6MMFhrF2UCBtaQ0gs6
g0ZyCYD7UKpSu4xHR1AtzAHE8Ey5WruZsPUt529pZGTpqER23BS1TqZtSd7M
yw4DTM1vvaSKL+lUOoHiNSeUCPQh6nCQXRXk5nxLYfk2ED301ZlgT/OVEREP
+ewa5A8mgCDpoitbp5KNs9TaILuNx9fnbA2ysB8q2oRL6n4NYaJMTqU4bM55
fHoJVZ4jcmqmGT9twtxZ1IeJXrPXgFRA5dt1abN5pCjF5aqcLyCj4H1AvGCC
uPzmAH8pi4XJihXAIekbOkGClFFUq9402Fa7cyYCL/bHJrbTOK27/3aHLqDN
1NVdkdqtna7ZqN00lRJS3sabLLac1Pw9gxV0G2b9zHl7HHRHVe06wm8LkZpI
ZqvOvFsG/7Vbmm0kaJgNfMqypE2G7iTd1Yg+1HZDiuO0SWpL1mJpaq5tgJ8Z
FpGA2p9X+11XDXjNmde4uR+w3VFCwqRAU1JQNRMZX0uvJqlUHYGd2vplpsq2
v6JluSAwW+NQw4O1oZ2MfLuBIy/rtqxjcmouwnRgK+siUF54eLfNU7Z1TLVG
q9lANbFh7hsqlya+oJ3CG26T88laVb4sc11yYxTCN3jV2d54AzXEsVoibRok
0jwQb1JhljOXnZYyjtFM5qmwHoT3rGleAV8F/ibV9+56JN69gxRkR5LndIV7
4/gJlh5RqcjsjfW0dpG1Y1AyJNo2748ZmcuVKZve1pjXR05b+fm8eeymAI35
VecQd7j/CJEQWPgbaVgEETAdHNlbilNwNlxz5CrkG1C2wgMaxn76yd76yUUC
MMn7IUjCjqFPBZeZihkOKLJyGvur5NTI4pqff+71tv9LhhFqDHpeigO7C+S5
8Z6svbXa+RGyxEEghRgdTaF7YTZ7SIw9FOM0lRjVmC1NKEWKCjNlX/M9/dOF
7n+RgX/+CzKnvfrcMQAA

-->

</rfc>

