<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.39 (Ruby 3.4.7) -->


<!DOCTYPE rfc  [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">

]>


<rfc ipr="trust200902" docName="draft-kavian-aep-oauth-session-credential-01" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true">
  <front>
    <title abbrev="AEP OAuth">OAuth Bearer Session Credential Grant Type for the Agent Enrollment Protocol</title>

    <author initials="N." surname="Kavian" fullname="N. Kavian">
      <organization>Jarwin, Inc. (InFlow)</organization>
      <address>
        <email>nas@inflowpay.ai</email>
      </address>
    </author>

    <date year="2026" month="June" day="28"/>

    
    
    

    <abstract>


<?line 40?>

<t>This document defines the OAuth Bearer session-credential grant type for the Agent Enrollment Protocol (AEP).  The grant type lets an AEP Service issue an OAuth-style Bearer access token through the AEP Grant command while preserving baseline AEP client assertion authentication as the root of trust.</t>



    </abstract>



  </front>

  <middle>


<?line 44?>

<section anchor="introduction"><name>Introduction</name>

<t>The Agent Enrollment Protocol (AEP) defines Grant and Revoke commands for optional session credentials <xref target="AEP-CORE"/>.  Session credentials are an optimization for deployments that want to reuse existing authentication middleware after an Agent has proven possession of its AEP identity key.</t>

<t>This document defines the <spanx style="verb">oauth-bearer</spanx> grant type.  The grant type issues an OAuth Bearer access token <xref target="RFC6750"/> through the AEP Grant command.  Grant type request and response bodies are JSON objects <xref target="RFC8259"/> carried over HTTP semantics <xref target="RFC9110"/> as defined by AEP.  This grant type does not redefine OAuth authorization grants, refresh tokens, token introspection, or token revocation.  When a Service exposes standard OAuth token introspection <xref target="RFC7662"/> or revocation <xref target="RFC7009"/> endpoints, it advertises those endpoints as grant type configuration.</t>

</section>
<section anchor="requirements-language"><name>Requirements Language</name>

<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.</t>

<?line -18?>

</section>
<section anchor="grant-type"><name>Grant Type</name>

<t>The grant type identifier is:</t>

<figure><sourcecode type="text"><![CDATA[
oauth-bearer
]]></sourcecode></figure>

<t>A Service that enables this grant type lists <spanx style="verb">oauth-bearer</spanx> in <spanx style="verb">commands.grant_types</spanx> and lists <spanx style="verb">grant</spanx> and <spanx style="verb">revoke</spanx> in <spanx style="verb">commands.supported</spanx> in its AEP Inspect document.</t>

</section>
<section anchor="inspect-configuration"><name>Inspect Configuration</name>

<t>A Service <bcp14>MAY</bcp14> publish configuration under <spanx style="verb">commands.grant_types_config.oauth-bearer</spanx>:</t>

<figure><sourcecode type="json"><![CDATA[
{
  "commands": {
    "grant_types": ["oauth-bearer"],
    "grant_types_config": {
      "oauth-bearer": {
        "access_token_formats": ["opaque"],
        "default_lifetime_seconds": "900",
        "introspection_endpoint": "https://api.example.com/i",
        "revocation_endpoint": "https://api.example.com/r",
        "scopes_supported": ["read", "write"],
        "supports_per_credential_revoke": "true"
      }
    },
    "supported": ["enroll", "grant", "inspect", "revoke", "status"]
  }
}
]]></sourcecode></figure>

<t><spanx style="verb">access_token_formats</spanx> is an array of strings.  This document defines <spanx style="verb">opaque</spanx> and <spanx style="verb">jwt</spanx> as descriptive values.  Agents <bcp14>MUST</bcp14> treat returned access tokens as opaque regardless of the advertised format.</t>

<t><spanx style="verb">default_lifetime_seconds</spanx> is an AEP-owned numeric value and is therefore represented as a JSON string.</t>

<t><spanx style="verb">introspection_endpoint</spanx> and <spanx style="verb">revocation_endpoint</spanx>, when present, are HTTPS URLs for standard OAuth operational tooling.  AEP-aware Agents use AEP Revoke for AEP-issued session credentials.</t>

<t><spanx style="verb">scopes_supported</spanx>, when present, lists Service-defined scope strings an Agent can request.</t>

<t><spanx style="verb">supports_per_credential_revoke</spanx> is a string boolean.  If absent, the default is <spanx style="verb">"false"</spanx>.  A Service that returns <spanx style="verb">credential_id</spanx> in a Grant response <bcp14>MUST</bcp14> support Revoke with that <spanx style="verb">credential_id</spanx>.  A Service that does not support per-credential Revoke <bcp14>MUST</bcp14> omit <spanx style="verb">credential_id</spanx> from Grant responses.</t>

</section>
<section anchor="grant-request"><name>Grant Request</name>

<t>The Agent invokes AEP Grant using baseline <spanx style="verb">Authorization: AEP &lt;jwt&gt;</spanx> authentication with <spanx style="verb">op</spanx> equal to <spanx style="verb">grant</spanx>.</t>

<figure><sourcecode type="json"><![CDATA[
{
  "grant_type": "oauth-bearer",
  "requested_scopes": ["read"],
  "token_format": "opaque"
}
]]></sourcecode></figure>

<t><spanx style="verb">grant_type</spanx> <bcp14>MUST</bcp14> be <spanx style="verb">oauth-bearer</spanx>.</t>

<t><spanx style="verb">requested_scopes</spanx> is <bcp14>OPTIONAL</bcp14>.  A Service <bcp14>MAY</bcp14> grant fewer scopes than requested.  Unsupported requested scopes <bcp14>MAY</bcp14> be omitted from the response <spanx style="verb">scopes</spanx> array.  If the Service cannot issue a useful credential for the requested scopes, it <bcp14>MUST</bcp14> return <spanx style="verb">invalid_request</spanx>.</t>

<t><spanx style="verb">token_format</spanx> is <bcp14>OPTIONAL</bcp14>.  The values defined by this document are <spanx style="verb">opaque</spanx> and <spanx style="verb">jwt</spanx>.  A Service <bcp14>MAY</bcp14> ignore this preference.</t>

</section>
<section anchor="grant-response"><name>Grant Response</name>

<t>A successful Grant response is a JSON object:</t>

<figure><sourcecode type="json"><![CDATA[
{
  "access_token": "ya29.example",
  "credential_id": "tok_01HZY8W7Q2F8J7D3P9G9Z1N6TT",
  "expires_at": "2026-12-01T00:00:00Z",
  "scopes": ["read"],
  "token_format": "opaque",
  "token_type": "Bearer"
}
]]></sourcecode></figure>

<t><spanx style="verb">access_token</spanx> is <bcp14>REQUIRED</bcp14> and contains the Bearer token value.</t>

<t><spanx style="verb">token_type</spanx> is <bcp14>REQUIRED</bcp14> and <bcp14>MUST</bcp14> be <spanx style="verb">Bearer</spanx>.</t>

<t><spanx style="verb">expires_at</spanx> is <bcp14>REQUIRED</bcp14> and is an RFC 3339 <xref target="RFC3339"/> timestamp for credential expiry.</t>

<t><spanx style="verb">scopes</spanx> is <bcp14>REQUIRED</bcp14> and contains the granted scope strings.  The Service <bcp14>MAY</bcp14> return an empty array when the token has no scope-limited authorization.</t>

<t><spanx style="verb">token_format</spanx>, when present, describes the Service-selected format.</t>

<t><spanx style="verb">credential_id</spanx>, when present, is a stable identifier for per-token Revoke.  If present, the Service <bcp14>MUST</bcp14> support Revoke with this value.</t>

<t>This document does not define refresh tokens.  Agents renew by invoking AEP Grant again with a fresh baseline client assertion.</t>

</section>
<section anchor="credential-presentation"><name>Credential Presentation</name>

<t>On later HTTP requests, the Agent presents the token using the Bearer authentication scheme:</t>

<figure><sourcecode type="http-message"><![CDATA[
Authorization: Bearer ya29.example
]]></sourcecode></figure>

<t>Authenticated AEP command endpoints <bcp14>MUST</bcp14> continue to accept baseline AEP authentication.</t>

</section>
<section anchor="revoke"><name>Revoke</name>

<t>The Agent invokes AEP Revoke using baseline <spanx style="verb">Authorization: AEP &lt;jwt&gt;</spanx> authentication with <spanx style="verb">op</spanx> equal to <spanx style="verb">revoke</spanx>.</t>

<t>To revoke all OAuth Bearer session credentials of this type for the authenticated Agent:</t>

<figure><sourcecode type="json"><![CDATA[
{
  "grant_type": "oauth-bearer"
}
]]></sourcecode></figure>

<t>To revoke one credential when the Service returned <spanx style="verb">credential_id</spanx>:</t>

<figure><sourcecode type="json"><![CDATA[
{
  "credential_id": "tok_01HZY8W7Q2F8J7D3P9G9Z1N6TT",
  "grant_type": "oauth-bearer"
}
]]></sourcecode></figure>

<t>Revoke returns an empty JSON object on success.  The Service <bcp14>MUST</bcp14> return success regardless of whether a matching token existed.</t>

<t>To revoke all session credentials of every grant type, Agents use the core <spanx style="verb">all_grant_types</spanx> Revoke request.</t>

</section>
<section anchor="error-handling"><name>Error Handling</name>

<t>This grant type uses the AEP error vocabulary defined by the core protocol.  A token that is expired, malformed, revoked, unknown, or bound to a different Agent fails as <spanx style="verb">not_recognized</spanx>.</t>

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

<t>This document requests registration of <spanx style="verb">oauth-bearer</spanx> in the AEP Grant Types registry.</t>

<texttable>
      <ttcol align='left'>Field</ttcol>
      <ttcol align='left'>Value</ttcol>
      <c>Grant Type</c>
      <c><spanx style="verb">oauth-bearer</spanx></c>
      <c>Description</c>
      <c>OAuth Bearer access token issued through AEP Grant</c>
      <c>Reference</c>
      <c>This document</c>
</texttable>

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

<t>Bearer tokens are usable by any party that presents them.  Services <bcp14>SHOULD</bcp14> issue short-lived tokens.  Services <bcp14>MUST NOT</bcp14> log raw access token values, and Services <bcp14>MUST</bcp14> support AEP Revoke for every advertised grant type.  Agents that suspect token disclosure <bcp14>SHOULD</bcp14> call AEP Revoke using baseline AEP authentication and then fall back to per-request signed client assertions until a new token is issued.</t>

<t>Services <bcp14>MUST</bcp14> bind issued tokens to the authenticated AEP Agent identity.  JWT access tokens <bcp14>SHOULD</bcp14> include an audience identifying the issuing Service.  Services <bcp14>MUST</bcp14> reject tokens whose audience does not identify the receiving Service.</t>

</section>
<section anchor="privacy-considerations"><name>Privacy Considerations</name>

<t>Bearer tokens can become correlation handles if reused outside the issuing Service.  Agents <bcp14>MUST NOT</bcp14> present AEP-issued Bearer tokens to other Services.  Services <bcp14>MUST NOT</bcp14> log raw access token values in ordinary logs or telemetry.</t>

</section>


  </middle>

  <back>


<references title='References' anchor="sec-combined-references">

    <references title='Normative References' anchor="sec-normative-references">



<reference anchor="RFC3339">
  <front>
    <title>Date and Time on the Internet: Timestamps</title>
    <author fullname="G. Klyne" initials="G." surname="Klyne"/>
    <author fullname="C. Newman" initials="C." surname="Newman"/>
    <date month="July" year="2002"/>
    <abstract>
      <t>This document defines a date and time format for use in Internet protocols that is a profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="3339"/>
  <seriesInfo name="DOI" value="10.17487/RFC3339"/>
</reference>
<reference anchor="RFC6750">
  <front>
    <title>The OAuth 2.0 Authorization Framework: Bearer Token Usage</title>
    <author fullname="M. Jones" initials="M." surname="Jones"/>
    <author fullname="D. Hardt" initials="D." surname="Hardt"/>
    <date month="October" year="2012"/>
    <abstract>
      <t>This specification describes how to use bearer tokens in HTTP requests to access OAuth 2.0 protected resources. Any party in possession of a bearer token (a "bearer") can use it to get access to the associated resources (without demonstrating possession of a cryptographic key). To prevent misuse, bearer tokens need to be protected from disclosure in storage and in transport. [STANDARDS-TRACK]</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="6750"/>
  <seriesInfo name="DOI" value="10.17487/RFC6750"/>
</reference>
<reference anchor="RFC8259">
  <front>
    <title>The JavaScript Object Notation (JSON) Data Interchange Format</title>
    <author fullname="T. Bray" initials="T." role="editor" surname="Bray"/>
    <date month="December" year="2017"/>
    <abstract>
      <t>JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the 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="RFC9110">
  <front>
    <title>HTTP Semantics</title>
    <author fullname="R. Fielding" initials="R." role="editor" surname="Fielding"/>
    <author fullname="M. Nottingham" initials="M." role="editor" surname="Nottingham"/>
    <author fullname="J. Reschke" initials="J." role="editor" surname="Reschke"/>
    <date month="June" year="2022"/>
    <abstract>
      <t>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes.</t>
      <t>This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230.</t>
    </abstract>
  </front>
  <seriesInfo name="STD" value="97"/>
  <seriesInfo name="RFC" value="9110"/>
  <seriesInfo name="DOI" value="10.17487/RFC9110"/>
</reference>

<reference anchor="AEP-CORE" target="https://datatracker.ietf.org/doc/draft-kavian-agent-enrollment-protocol/">
  <front>
    <title>The Agent Enrollment Protocol</title>
    <author initials="N." surname="Kavian" fullname="N. Kavian">
      <organization></organization>
    </author>
    <date year="2026" month="June" day="27"/>
  </front>
  <seriesInfo name="Internet-Draft" value="draft-kavian-agent-enrollment-protocol-01"/>
</reference>


<reference anchor="RFC2119">
  <front>
    <title>Key words for use in RFCs to Indicate Requirement Levels</title>
    <author fullname="S. Bradner" initials="S." surname="Bradner"/>
    <date month="March" year="1997"/>
    <abstract>
      <t>In many standards track documents several words are used to 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="RFC8174">
  <front>
    <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
    <author fullname="B. Leiba" initials="B." surname="Leiba"/>
    <date month="May" year="2017"/>
    <abstract>
      <t>RFC 2119 specifies common key words that may be used in 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>



    </references>

    <references title='Informative References' anchor="sec-informative-references">



<reference anchor="RFC7009">
  <front>
    <title>OAuth 2.0 Token Revocation</title>
    <author fullname="T. Lodderstedt" initials="T." role="editor" surname="Lodderstedt"/>
    <author fullname="S. Dronia" initials="S." surname="Dronia"/>
    <author fullname="M. Scurtescu" initials="M." surname="Scurtescu"/>
    <date month="August" year="2013"/>
    <abstract>
      <t>This document proposes an additional endpoint for OAuth authorization servers, which allows clients to notify the authorization server that a previously obtained refresh or access token is no longer needed. This allows the authorization server to clean up security credentials. A revocation request will invalidate the actual token and, if applicable, other tokens based on the same authorization grant.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="7009"/>
  <seriesInfo name="DOI" value="10.17487/RFC7009"/>
</reference>
<reference anchor="RFC7662">
  <front>
    <title>OAuth 2.0 Token Introspection</title>
    <author fullname="J. Richer" initials="J." role="editor" surname="Richer"/>
    <date month="October" year="2015"/>
    <abstract>
      <t>This specification defines a method for a protected resource to query an OAuth 2.0 authorization server to determine the active state of an OAuth 2.0 token and to determine meta-information about this token. OAuth 2.0 deployments can use this method to convey information about the authorization context of the token from the authorization server to the protected resource.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="7662"/>
  <seriesInfo name="DOI" value="10.17487/RFC7662"/>
</reference>



    </references>

</references>



  </back>

<!-- ##markdown-source:
H4sIAAAAAAAAA61Z73LbNhL/zqfAqV/ajqlITpvEmk57buI0ziW2azvXaTsd
CSIhCTFF8ADQipq4z3LPck92uwuABCnFTW/O004oENj/+9tdME3TxEpbiAkb
nB/XdsW+F1wLza6EMVKV7KkWuSit5AX7QfPSsuttJdhCaWZXgh0v4R07KbUq
ijU+XmhlVaaKQcLncy1ugezxyQUj0oMkV1nJ18Ar13xh0xt+K3mZclGlisOG
1DimadYwTUfjJONWLJXeTpixeSIrPWFW18YejkZHo8PE1PO1pHMWRJuw05Pr
54mxvMynvFCloN0iqeQkYQyEm7CtMPBolLZaLEzze7tuf6I4SuOJFP5nTJbw
4mzI/kEi05LTpLum9JKX8nduQZoJe8n1RpYH7LTMhuzz0/J5oTZf0D6x5rKY
AAnzd1kuYLni2yGXSVIqvYbTtwJZXz5/+vDhwyP/+Ojx1yP/+OTw67B6NB7T
Klg5fXp+eTIh+sGl1/f7iLZyvRR2wlbWVmby4EHOLbeaZzdCD6WwiyHo9AAc
96DrMySaioZoWnmiD4goEAH2h6PDR+noUXr4mBaN0FIY0Fc5IRkYxgpdCps+
Q9r9sPgYC4wJPN36CP/SfT7a56cEJeha+TFEUnh89OhwkgyHwyRJ05TxuUFj
2CS5XknDwA412TAXC1kKQ0nQyZvdEGZLyhv7SXnDPgdHfjFkDD0XHSyENYyX
6GZITX0rM8Eg6GuBiyRAauy2EEEMnmUgCIT7jSiBo1b1cuU4AwGXyJlaryFJ
2GYl4VylhUG65ZLNuREFaEd7s0KifNzAW4xqsjoqlnH309lAK2WZWrjE9LZb
yzwvRJJ8hn7WKq8zPIGW/FMDNPZ1oqKYl+IWlAlSGzKlqpAimNhbnbVWN+z9
+5ATd3dg0Ks9W8BUaD8ks/ZZS3RzURVqi3KhdtyyDTlCMS1qI5h4J41FS/Vs
4RTeENWFRS+UXtEVmAnC9xacUSkTpAV7SeCAZpYkk92yG7Ed3hdsM4eUc3Lz
LAqR3Zih+DBNgOwNjffvPbLc3d0fJkD+h5a0Fv8C0s4xEDiVKsEsc5VL4Yz6
8ur8jKn5W5FZ43ggZAGPjGsAgZyBKTR7cX19Aa4D8mBCvw/xDPaBvZzWOZtv
URpSD4wS6Zcr4FZC3KFHca/X0+FC8CcdMAewaQGSrpze8NvpLzEyTSUoNA8Y
pietQ+lSzqvA+CdwMuNN3ol34ENgTTWG69yz3UPQqYSQAioB7ZaqfwO4A29E
mVdKkpQSbJrfYqoZcrjCcAuv0SqR/pkqF3JZaycm5tkluEVq4QL3FS+XNYCo
SziIK7ZRGhJn8PrN1fXgwP3Lzs7p+fLkxzenlyfP8PnqxfGrV81D4ndcvTh/
8+pZ+9SefHr++vXJ2TN3GFZZZykZvD7+Gd5gqAzOL65Pz8+OXw3ATqBdHOQY
NpBhc4EmFBrwyILzuUlyYTIt5/ADznz/9OI//x5/Beb7G9jvcDxG+7kfT8aP
v4IfG3CW46bKYut/QkhvE15VkAFIhRcFRGIlLYDAAVrVrNSmZCuhBdjxy1/R
Mr9N2DfzrBp/9a1fQIU7i8FmnUWy2e7KzmFnxD1Le9g01uys9yzdlff4587v
YPdo8ZvvCOPT8ZPvvk0weNr2zkVMjCSETgsJOSvNJEn++OMPZsU7m8RghKtJ
ctykCQGnKPm8oEju5m4BCGr6YAaemQV8H9LmKW42M3KnP0LrbmWmqSb0Dpq6
qqC1EzmtB4A9LSkpm3gburrkFp/GmRTrAHZkVT0H1qtuurG6zMEae8Wdup3D
jnLeam8NMHgPrcYgnBxM2HvqVQYRCVj8dRCfH/x2sLPJ82kIwNvOkXYd3jjU
nxJITV3/47lUHLA80Ke9gKa8Luy0kAsBlVFMjQBWJOrgaDQaRFs7cDcNSIUb
Qz8JaTYU7/i6KsQQdH4g4+MtIH7SWR2fNZlCIzTuJm204DnC0EZL21XK7zPT
Suhp2wRMXQwhVxwTBv7AHf17543e5eFaUuRCzsAH6QIJHz09eIL6YGsz+C1B
cncuPWb7/ACBSmUaaiPfYlcAPSe0FybUvJ1GYOac5rPg7QbzAQsmAmWFfS27
5QUUaCBA/YdhBGAw7nCslrbWWFjjRoBqi6MKG5ZQ1Qp8hx0dQEFTknLmRIbs
mX0sSoI22H0BqsKZEqTXMnNCkcySmhkoyUojP2o+S4f3UGipe3A2QEb7YyyC
gF4EzQ4I9ZmnekClBXuNK/bm8pXrHHu1GyLJ5TX0klapAjm7mYpTO+etiM0f
gonvRZEQ7qFGK9/XhKL4/TjdEc8Bm4ecNLQ9dCxEQttJZrwM3RcRvzeqnSs8
EejPVCE4NjSnCxxsiDm613sSN88GCxBbDGaofhfKXdzAloiNdCDLffFoWkEK
Ny9bsNZGYpOElHoUdlk1nV0gAdrFE5WnSFzUWu5QZAut1j2ZzLAtcpfOgPEo
IkskaaLGtzadYWh2HLeVE9r4DaTet7P+GECKQorOGLChgApVa9gvAi2aIwB1
0BuhZ+A9LfKpi6IW4wjaBjGMEAUH5g3atPRnzlrz/gSBQdTnQmETWoaOd7Ae
uiq+EBucdmk/Oq2JSoGjwpuyCfd2PexGIiAHOg5XyVc0Q4bomQUxCBBdvOKG
IAXkAAaHn38xKxd1EaVdM2b3WVN/TXZwwcwAWwCUZD71O8kcsVH7psCAcdga
zye7newuQu/YUS5LRD86C1iwADgsM9GJUmcPbEhMTWCNevZSTTaI6eatnUYj
rjgYI1t+eBSqqouyTvJQJVQ309H4xS8/P/np8Y+Hz5+8fPzs4cXRD0e/jM8e
XV+7QzAFwahhpi7w6KpnfJiOxtej0YT++8Xt+0uBG70LSeGm1sHeAkreCW04
mRoqkOVQjcn9fuB1gxl5rXWvy4n+8SZHvm+zo1V0d7+rdDB8MLyoc0MdPuE0
DSURqsy6omiMgpPobdvK8CdKULr164GPxDicfESDOGJd2a1vJqjSIBlnBLyH
KJWjlRYSMhBrbgxsOwnQr1ZhHDNxSqYAkhB7nf6gC8l9Mr4w4XQQjxdoKwR7
J67DeQcAzckYCe6pM8AguLzXRIXi4i8NuhcDbcsE6Sg2mN1UGrAWtLWBL8E/
jhNn7nhTKPo3ZpTR0TX6hVPEzxrnJSu4DZchHobMQXRL6BU3kRtdaYpCvFeB
TLYSa+GRAJvpFGLR4F1Ar4j54zEk+DGuJQhOpYtAf13Y3kaQ8TFWZVnT7I6p
Wdnu/WFXMn9LgX76WPH1Xvy/Vl/fDWEoKOZ+0B3AvpvbzgUh9b/YrMaXt7xr
G9RgB3TvKewByVpRFEZNGyBNzoYobzr2Xk7tzpT/C5B/gqjeJ6EDbDAmKjsM
w84VqT44RfXW7+iNGKAwTgOQSgAd2Ypim+KcLlqhoej77SOuEjClbKNbhoO4
b0eDZlhwZ0Bh2rldaNQLbfVn7ERr8PYLCHicBTyERPcXtfEAiIEoaDPOIfO6
4CBCpzXwbMPXC+oDwr08p6bbVZj8ANQvED/x0WkLD3V5U8IYRXeTc1VDBmKm
sVwuqGOwPoUWXBY0xM0A2qCdydSylL/DtOEuOo7PjvGWwwDUukHH9GExQA/6
RuJHD+uvqHcvaboXxHhj1JzCuvaBPZeiyP3g/YH9k8a+v/T3AYik7R/r/PrE
PyISfbMEIj1VPlWSZ2GwBoN8uOcy3c+B4R69NRESuQwdHtmka/tPlAQceSWy
WuN3gr4z417H3cHXhoorxCAvt6zi2m5dxMUFZU1fRihRYQR1F5CurzYAtxZ6
hFvUKJTGZmu4EGWFWjLNN11DuA7Z3cJ2j4Ra3ZuiXeZG1wyd7xo+i0l4U7sr
O8colyYrlKlBXS98hvjw8TqyW5JISFyAFIKjc57dYIZhExK+chho1UGmfmEH
XAEqBSQjNgohBHwUQB50NZ9L6hddhDgvAZs99QQk9FXRfxMCC7z86bp3XRN8
VWZFndNXLF7nkuLLt1Pb0CMgU3z28uy4UYu3jUUNgDF+c2iINd1SoOoHq0zI
25goBueFlrc8+7PYxBuMOeDTmoBRi8K5YYVYC7zkwn1ly5mqLZL5iA7xxRYG
oo/q+EKmyxesrajMBO3/ajwj9CmdyxIhHvYZ+lwEje9aEPD9Fx16euBMIQAA

-->

</rfc>

