<?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 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-hardt-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="June" day="12"/>

    <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, 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. 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, 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, 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 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;
&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="June"/>
  </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="June"/>
  </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="B." surname="Campbell">
      <organization></organization>
    </author>
    <author initials="J." surname="Bradley">
      <organization></organization>
    </author>
    <author initials="N." surname="Sakimora">
      <organization></organization>
    </author>
    <author initials="T." surname="Lodderstedt">
      <organization></organization>
    </author>
    <date year="2018" month="June"/>
  </front>
</reference>


    </references>



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

<section anchor="draft-hardt-oauth-distributed-00" title="draft-hardt-oauth-distributed-00">

<t><list style="symbols">
  <t>Initial version.</t>
</list></t>

</section>
<section anchor="draft-hardt-oauth-distributed-01" title="draft-hardt-oauth-distributed-01">

<t><list style="symbols">
  <t>resource identity expanded from just a hostname “host”, to a URI that contains the hostname “resource URI”</t>
  <t>use oauth discovery document to obtain token endpoint rather than explicitly returning token endpoint</t>
  <t>use <xref target="RFC8288"/> to provide resource and discovery URIs</t>
  <t>allow any authorization grant type be used to obtain an authorization grant</t>
  <t>change attribute “host” to “resource”</t>
  <t>require linking resource URI to access token</t>
  <t>add client restriction to mitigate access token reuse</t>
  <t>added Nat and Brian as authors</t>
</list></t>

</section>
</section>


  </back>

<!-- ##markdown-source:
H4sIAPAcIFsAA81be2/bRhL/X59ioaB3MSrJjzya6JpDZTtuHPhVW4Fx90+w
JlfS1iSXxyWtKGmA+yD36e6T3Mzsg1yKst1LgbugRRVyOTM7j988djscDnul
LBMxZodSl4W8qUoRs/NJVS56sYoynsKruOCzcrjgRVwOFYdXw7hePNzZ68W8
hGV7O7uvhjsvh7t7vQgezFWxGjNdxj2ZF2NWFpUu93Z2XsN6Xgg+ZlciqgpZ
rnpLVdzOC1XlY8OZXcMDmc3Zz/iw10OWqhj3GBvCv4zJTIO8I/YOJaInRs5D
Gd02HqpizjP5mZdSZWM2SflnldELkXKZjFk/hvUj2tZPc3w0ilTaD7nsj9gB
T/MbkSQNRvuF5Fn4ImR2gdIfxyIrcX9Nnjf46SgeRfbjjZzPRuyK38q0KniD
8xkvw8ch37PL44BbNtR28U9ZIYHL6Ne83+tlqkjhizuBOr08Otjb3X1tf754
/eqV/fnyh+ev/c8XO/bnDy/82h9evtyzP1/tmc9OpydXYxLBupUx6N5oh51W
ZcUTBgvYQSJBNQxfoYoikp7xLGYHoijlDJ8Itq8qeDKJIqE1m6pbkWlDmRdz
UY7ZoixzPd7eBu/jZcGjW1GMpChnI9DJNjjvtvFbfGTdNi0TvU00jMfyCJXA
ltbdyAeNt9Oi2u/wz9D+19rndMTeq0zo7rdtv1lb8H4EXsTjRKy631+P2KHI
MqmRwfnk6nSDVicko3UACKniThTsVJQctfKN6oIojxTQW/0/6ux8Mt3foBPy
FbYvsxgk/EYdlEhreGNo/VF6+GbvcOCgLAqsLZiO2ImKY1FogOiy15PZrI75
3nA4ZPxGowbg3XQh1tGf5YWayUQwkfGbRGiITvsiMsFbKub8gy0XAEs88ERt
PFEV9pdmKV+xG8EqDSzgY3VTcglBb8Kb1KwZCMk4m4OUGSuEVlURiQEBA7HI
eQEoWALdO55UAj9DOe9kLGDbDNAkoAck/gGrypHZcSpj0Giv94QdZ2Wh4ipC
SXu944x9+WLx7uvXAZIpgB5smWkwLejAieJ2hQJ1bXcElBkYRTDA8zwRn2hl
I1kyvQKDpBr2ZPVo9GKlTnm2guWzGQgAKm6xha+WCxkt2IKD49XLuiQhWnyO
nmloj9gR6FZ84ihXzd5ZxSzC5eVSdYgAGiUDGGVrUEwqE16wWZWRFnkCiW7A
YJNMcBARtIfGbVCaC5UrWAXYngDZOXzk9oNmkgX6WLCTWaHSDZtLFGaIGHkQ
uw7iYPQJyCvhY3abqWUi4rlgNyvyErt5NaO/FSIh8nohcw3aKJei4X+e6ZrV
tX8F280UqgdRAWXgmihnVXqDUTB7BDX/RgMBUEaVj9i0ljUTItZB1KlsGEOi
p+BANXYGIHxgo6Ct3UeGmgkyjh60L8ifAA4CORZqiX+3PszRSUoRoXn8pnmi
lUcSCpAZRIdESlrNyiUUhCwWdyJReUourVm04NnchDhqEnjlAiIAKsckvU97
EQDVguc5bCteQdGE5khWbCkBujJlySJVq9dIxQJ85ckTdqZKbnyZHajsDisT
sDHhQ7kAC0N+qFA6Qgh2K1YI/mCT/umHq2l/YP7Lzs7p9+XbXz4cX7497A96
/at3k5MTfEg/3Iqrd+cfTg7rX/WXB+enp2/PDt/Sy9PJ34AG7rd/fjE9Pj+b
nPQZ6gu2cIOwBzbKC4HqBq1BbEaANSY09g8u2O7zQY/QDWu8r1/NTqeiSGWm
EjVfwfa0rgQW6LApsHq5Am/WFUFBC08Hxo4YTZnz8E4YhNBLEqYQSBmIh/YC
gUm8mcyMcA3IJWvav7/Y+fqVZLwAL1KRStg5ULyTYtnrHcl5BXR2mQaXo4zk
khi4EzghhFnczmMgC2XF74f2z/fs/j9+oVtvvv/Nvf9tOHw62YJ0cuiqI3Zp
AwyX/xUXXjq/x/Xt7x/gT+9tHdf5/Y/Dp/tt/joHTxUkQJv+7+X/4P7X6T11
cEopvQ3j84Jn5dbDVL5NKrDKwdawVQ57w4BVwjeev21FHmWVhlm6rHK4RaIF
HQuz8v4PrPJt9ECfbzfvh7y86eb/lZc/oM8j5E84YLKJZ7dZn98Q5b32Eoc2
YzZxKOMx6QjgpkeVM+IagvGiEJCkSgEFxJKelv6dy2RUzyBmmjoaIQtq8d0t
NvG5dOWTNWCMKx79GxvlEP41D5fG3Dpt0jekK1tVUbGd8ltBeFl33JSeTXnc
LDNwJSZxJ4dNvx05HTOqgnpPV3merFy+CMNsITj0IANqA/wykENmUMDLOMgu
Rox2qW12DVmWEjhn76bTC/Z8Z7dWByZwUlUis1ttai1Tz7FyBTUD6zuaH6tC
9mkpStqnBu+j4fMxtS0zrQk0EqlsJjGH0UcLpcu+aT9qg+JMA5ZlgmphVD78
DbHQpLqyua8Pl8emzJqJMlqAeFTAGpdote+4lpbm8PDLF5wCQLKsLQ2tNGqW
6qnO4k/gtwpKBKSkR6bVc/0bOEKN2FkXaBNfYmLqZPPQKLWVwbXd+nNgsgce
3abn3fpgi2rF9vtGYyWzKKliYfUd2g5NbIzTXfz5/oSHnaXpXrCl01pFkrzf
enaLA1kWNvHMb2ItXhggo/u67a7EJ/SY9R3UzAMZoT03DvEpN6HmZIGOtXPM
4yuAujQaEAYheoCx763JB0308M1FIniRbSzsNLqbpHrRNoRYbdODViNPL6no
g8d56XqGbighi8Ja24s23fpRzLCV2Ui50ajgGksw2D0voSfPS10jJcOm4R7s
o8DsKmexfPXBsDcCe4hPqAALX93Ih7uF1oSgrR9Yuu99ziApm0mRxGFfCMIZ
T0NowimxC9cOuUmNS66di8I72xGHEGYQSvM7jPTS1foW/EBdpsQerfvd/pYB
mfthnIhdX18PGxNg0TcKsBs1ARtAgSgKVTTYu5RgwBg23bfK/UhaNUgP7ZPp
WiwtQ4q6SbOgTx1lk6xB23VzPjNa4ax/AkFsxX1nxPXf4CAcviHxqR90fNGr
MfjXElRXfmqGgE9rZvE9WQvMUc942FNSj/gEpQvTOY+EdllSsBvY9K0JHIiO
PIHAy6siV1pgVklWW+O6HsJtbu+OdinrfsgcLojYr2hbcsz2AUbI6qDaN30r
0Uej6cFapbX2h8xTf2es9YjvyEPetNzAf4ZWG7Mf3QyY53JkOeDxy7azQv+v
f0EDvQnN0uZek9EBldFSJMmQWuRtM0EOgHRoDOdYbDZmkKvJkWzI+lCHzF6Q
E/kpVlBhaDC6iCQAhq9BOlLRwFUq3RFuCwQgsbHWyXzGCWBpTeQAO7sqpA0w
aypdC5cIXRatRQiDVM4UAuQWdyIsjax+NpZYjcRnR1k0VMGC36NVo27oLFyC
Cg3DLAJnLzGTJFLToPHBYs2kAijZXMV2ghXbkzDz/4wlWOAbjyjhcKpslZAK
7EakTu+t4J6EPZ9to9fR/mArEMX2DlnnEN6XPI/bO/UMcmb0BWia4UOq4O64
TLCewCE2bDFWabICOonxHVzlfRV1P2LHs2ayBxJV5uoR68hONuJLntT4ADNI
Cf1XuJxnZry1zi9QiR3tNetIx8xUIqyiqTtVaOglMwhrrXEWD9rx1oLuCQe8
mqX1ISrNb7WcZ1ROov5sSLlWzDLwg7oYJIowaR+KXNB5FlNdtZ5xnJo3ndg0
kmLoLkElZTxg0zmMScjNpOgRqY9ioufEsbQz2Pqwx0ehz/RtQGmdboDfGLXi
um4nB7nt6OcAemS0DVQJJrwGlryReamqJMay9I/IpxfnsPltoxSXV+nFO8Dd
sbVYM5/QywACILlyLSMWff77Af/58oo/O9o5/Zxn14dH6S8p/N57f01fHYA3
wL6GUygbxoxD920P2rc/DZfL5RAPBIdVkYBTQAcdGwHJ9h+x0nhjTPoxqtVD
K/5kknOQm80LZ5A3lBq/ezb5bu8I/mnlWXjiFq4DyuGWmap0owS5jkfi9azi
/YT02Kqx6ThqyVd1K+GPvXApWBJYmHRpS+KudgLd7P311DgVXoUApzInq2WL
oW0x/v3Pf0Hk9SFAuEzNDhqHoBGeM6w63PkaQcigLx1WYi4nVRjGL1/uAWOE
MiBkGMlgmZ+OuDxMudbkeJInFXQy5VXWbm0ktEOu/3TpACNqfRy3bsW3YVqw
StabsvymehvaJ5Pi1w+nL+zhNO0OAwwV0QFlXd0TRSkeaHUdcXS0NEd2Nx2S
E3tym3UbosMpLIHp/DOq3Sr0yk1a+bMOPQKt4C5MYWhrCRvi9oRqStPHTCxp
DsnBdCIVxVxg8ZS1kl/zUMx1xl4Tm2YyTUD0xaEet1EejDBYa/1kCgbWAOl1
Y5lCeR5JVWmHeHTi06o5gBge4dZrNxO2vuX8LYuNLB2ZyA6I4tZBsE3Jm3nZ
9t3k/NZLyviSDoFTSF5zqhKBPkQdzo3rhBxOpBSmb1OiRz47U9kTvjIi4pma
XYP8wQQQJF10ZesQMDi6bMyNu2ry9elYQBr2RImbapOmb0OoKIOrFIvhdMZD
TKSKAqunEGr8jAjxs6TJc1u7V1CtgNrv16dF9FgRzBWqmi8AVfA+Gt7pwNp8
uo+/lK2HyZJ1kUPSBzpBgoQqqpVzArb17pyZwJP9SYXtNo6bIXC/U5fQPur6
ekbjokzXRNNumtIJKW/j5RGbUho+n8MKuoCyfsx7fyx0R1bjBsDvC5OGSGar
zrz3zNobtwTb1aBhNvCwZUkblO4k3dWMPtxgA/guzJxqfcAPNjEHHSvLIhaQ
/4t6v+uqAa859Ro3R/L3O0pEdSnQlBRUIZjxNYg1wFJ3BXbW6peZTNv+ipYV
ggraBodGTdgYwsnYtxw4wrJuyzrmnebuSUd9ZV0EUgyPbu/zlPu6pkazFTZR
YX1Y+KbKwcQ3tFR4qWxyNlnLzBdVoStujEI1Dt6vtZfMQA1JopZImwaDNN/D
y0uIcuZ+0VImCZrJPBXWg/ByL80s4Kuhv7z0k7vIiNfdAILsiPGM7g1vHDTB
0kNKF7m9Jp01LlJ2DEtGRNvi/piRuVyqsvC2xrw5drqXn8fNt24SEMywOoey
o71HiITFhb8EhokQi6b9Q3sx8AacDdccuiz5DpSt8FgFovKBy+87uN/jTGIw
IMhoc/Xs4Q938UMf1NLeFcfDH4geN3D7tcKCq57sG9wamBBHoHHnTfUIr17b
RKQ+MMNkRoI0DpV9YVAnmtYspolzIBziQ5kgKJRVYeIiWG/5BLPw+pJmfSEs
ONrGIRx8yDEcCDW7BhIUHh0XSDvnXkDN3vSqZ5kW9OHTeuxANqBzcoom3E8A
5HVWo22ikHHsQMjXYYrSn8OqjqrYfAdy4/193Lv5Pwi4uysD7vgfalvmE4sx
AAA=

-->

</rfc>

