<?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-03" 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="August" day="24"/>

    
    
    

    <abstract>


<?line 41?>

<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 45?>

<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>OPTIONAL</bcp14> and contains the granted scope strings when present.  A missing or <spanx style="verb">null</spanx> value means the token has no scope-limited authorization.  The Service <bcp14>MAY</bcp14> return an empty array with the same meaning.</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>On protected resources, the Agent <bcp14>MAY</bcp14> instead use the dedicated AEP carrier while preserving the Bearer field value:</t>

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

<t>Services implementing this grant type <bcp14>MUST</bcp14> accept both carriers on protected resources. Agents <bcp14>MUST</bcp14> use only one AEP carrier per request, and the ambiguity and precedence rules are defined by AEP core.</t>

<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="August" day="24"/>
  </front>
  <seriesInfo name="Internet-Draft" value="draft-kavian-agent-enrollment-protocol-03"/>
</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:
H4sIAAAAAAAAA61Z63LbNhb+z6fAqn+6O5ZiO2kSazrtuonTOJvYru1sp+10
JIiEJMQUwQVIK2riPss+yz7ZngtAgpSSujvraScUCByc63cuHA6HSaWrXI3F
4Py4rpbiOyWtsuJKOadNIZ5Zlami0jIX31tZVOJ6UyoxN1ZUSyWOF/BOnBTW
5PkKHy+sqUxq8kEiZzOrboHs8cmFINKDJDNpIVdwV2blvBreyFsti6FU5dBI
2DB0fOkwbS4d7j9MMlnBkcP9w8fD/afDw0dJCgsLYzdj4aos0aUdi8rWrjrc
3z/aP0xcPVtpIlQBr2NxenL9InGVLLKJzE2haLdKSj1OhABux2KjHDw6Yyur
5q75vVm1P5E/Y/HEEP4XQhfw4mwk/kEy0BKL1l0zdiEL/ZusgJuxeCXtWhd7
4rRIR+LL0+JFbtZ/pX1qJXU+BhLu77qYw3IpNyOpk6QwdgWnbxVeffni2cOH
D4/84+MnX+37x6eHX4XVo4MDWgW1D5+dX56MiX6w8fXnjUZbpV2oaiyWVVW6
8YMHoH5ZWZneKDvSqpqPQKYHYMkHXSMi0aFqiA5LT/QBEd2yIS46ZbVyIK9h
JgUoplK2UNXwOdLu+8mnrkAnwdOtjfBvuMtGu+yUIAddLT8BTwqPjx8fjpPR
aJQkw+FQyJlDZVRJcr3UToAeatJhpua6UI6iohNI2z4tFhRI1b0CSXwJhvzr
SAi0XHQwV5UTskAzQ6zaW50qAU5fK1wkBoau2uQqsCHTFBgBd79RBdxoTb1Y
8s1AgCM7NasVBIlYLzWcK61ySLdYiJl0KgfpaG+aa+RPOniLXk1aR8FSyT9Z
B9aYSpg5B6bX3UpnWa6S5Au0szVZneIJ1OQfKqDRL7OKbF6qWxAmcO1IlaZE
iqBir3XRat2JDx9CTNzdgUKvdmwBVaH+kMzKRy3RzVSZmw3yhdLJSqzJEEZY
VTsl1HvtKtRUTxcs8Jqoziu0QuEFXYKawH1vwRilcYFb0JeGG1DNmniqNuJG
bUafc7YpQ+eMzDyNXGTbZ8g/XOMgO13jwwePLHd3n3cTIP99S9qqfwFpNgw4
TmkKUMvMZFqxUl9dnZ8JM3un0srxHQhZcEcqLYBAJkAVVry8vr4A0wF5UKHf
h3gG+0BfLHUmZhvkhsQDpUTyZQZuK8Dv0KK418vJuBDsSQfcHmyaA6dLlht+
s/waPdOVilxzT2B40jrkMsNWhYt/BCML2cSdeg82hKspx0ib+Wt3EGSREFJA
JKDdUvVvAHfgjSqy0mjiUoNOs1sMNUcGN+hu4TVqJZI/NcVcL2rLbGKcXYJZ
tFXsuK9lsagBRDngwK/E2lgInMGbt1fXgz3+V5yd0/PlyQ9vTy9PnuPz1cvj
16+bh8TvuHp5/vb18/apPfns/M2bk7PnfBhWRWcpGbw5/gneoKsMzi+uT8/P
jl8PQE8gXezk6DYQYTOFKlQW8KgC40uXZMqlVs/gB5z57tnFf/598AjU9xfQ
3+HBAeqPfzw9ePIIfqzBWHybKfKN/wkuvUlkWUIEIBWZ5+CJpa4ABPZQq25p
1oVYKqtAj3/7BTXz61h8PUvLg0ff+AUUuLMYdNZZJJ1tr2wdZiXuWNpxTaPN
znpP011+j3/q/A56jxa//pYwfnjw9NtvEnSett5jj4mRhNBpriFmtRsnye+/
/y4q9b5KYjDC1SQ5bsKEgFMVcpaTJ3djNwcEdX0wA8tMA76PaPMEN7spmdMf
oXVemVrKCb2Dri5LKO1URusBYE8LCsrG30acl3jxWRxJsQygR1HWM7h62Q03
URcZaGMnuxPeOeoI57X2zsEFH6DUGISTg7H4QLXKICIBi78M4vODX/e2Nvl7
GgLwtnOkXYc3jPoTAqkJ1z/+llIClgf6tBfQVNZ5Ncn1XEFmVBOn4CpidXC0
vz+ItnbgbhKQCjeGehLCbKTey1WZqxHI/EDHx1tAvNdZG591qUElNOYmaayS
GcLQ2uqqK5Tf5yalspO2CJiwD+Gt2CYM/IE7+vfOK717B5ekeAsZAx80OxI+
enrwBPmhqt3g1wTJ3XF4THfZARyV0jTkRrnBqgBqTigvXMh5W4XAlI3mo+Dd
GuMBEyYCZYl1rbiVOSRoIED1hxMEYNDuSMyWVW0xscaFAOUWpgobFpDVcnyH
FR1AQZOSMsEsQ/RMP+UlQRqsvgBV4UwB3FudMlPEs6ZiBlKysXgfFZ8F4z0k
WqoeWAd40W4fiyCg50HTPUJ94anuUWrBWuNKvL18zZVjL3eDJ3FcQy1ZGZPj
zdxTSSrnvBax+EMw8bUoEsI9VGhlu4pQZL/vp1vsMbB5yBmGsoeOBU9oK8lU
FqH6IuKf9Wo2hScC9ZnJlcSC5nSOjQ1djub1lsTN08Ec2FaDKYrfhXL2G9gS
XaMZZKVPHk0pSO7meQvaWmsskpBSj8L2VU1lF0iAdHFH5SnSLWaltyiKuTWr
Hk9u1Ca5S1Zg3IroAkm6qPCtXacZmh7HZeWYNn4NoffNtN8GkKAQolMB15BD
haw16ieBFs0RgDrojdAz8JZW2YS9qMU4grZBDCNEgcG8QZuW/pS1Net3EOhE
/VvIbULJ0LEO5kPO4nO1xm6X9qPRGq9U2Cq8LRp3b9fDbiQCfKDhcJVsRT1k
8J5pYIMAkf0VNwQuIAbQOXz/i1E5r/Mo7Jo2u3811dekB3ZmAdgCoKSzid9J
6oiV2lcFOgxja9yfbFey2wi9pUe9KBD96CxgwRzgsEhVx0tZH1iQuJrAGuXs
hZpuEJP7ra1CI8446CMbeXgUsip7WSd4KBOam8n+wcuff3r645MfDl88ffXk
+cOLo++Pfj44e3x9zYegC4JWw03Y8WjUc3A43D+43t8f038/874/5bjRuxAU
3LUOdiZQsk4ow0nVkIEqCdmYzO8bXm7MyGqteTkm+sebGPmujY5W0O39nOmg
+RA4qOOmDp+wm4aUCFlmVZI3Rs5J9DZtZui42LYQFG5b+SDOIORZNAIFvIK7
pkWd51OfbVeA+EyI1YCTiMIwtWGuIQYx68bQ5r08dlUfLSCqWpXVxhcqHtCB
Kbnii3zC7gRQP9uFds7FIT0EkAXf7dQXXUjvk/GJDbuLuD1BXWOyYGE5TzCA
NCdjJPlMnoILgsv0irCQnPzQoTtYaEsuCGe1RnSg1IK2aXOLXIB9+SYp+HiT
aPoTN0KEaC5/wYL4XuW8ELmswjDFw5jbi6aMXvDYCTi1RSHSy2AuXaqV8kiC
xfgQfNnhLKGXBP3xGFI4TM/RVKZimwIDprap6rBFEFgAOMuM6iouRDJkAY7Q
6JFmRXZ7QBkxDkbPMzbUTnahOrsvy94nnNC4hqbmu7qNK3kMYlBZQUEF9vNc
Qq28U+RRpwJHQWksYcJ41csIPhuMx8MLKrtXM2g4cSqIK6CAFJ0A3NbWuR+0
dYdkgBw0wThuzRl06Ye97SyJ+EGk0UVNk5cgVDz97fqFnzFhlHyqdPIx9H+t
nXwti4FoBP+gCc6uuXtnvEvdC7Ya8ehddnWDEmylzM+UZSEPtaygKSN4J5iK
Mabpt3qItj0R+F/S8D1Y9TYJ9XuD4lHRgM7rS4w+/EfVkt/RaxBBYOzlAMgA
uNMlBQ2hDI3JoRzs2+0TplLQY26iUNuLuy5UKDq3mAKFSWc21IgXmqIvxIm1
YO2X4PDYyXkAj4K4dj79oCMq2oxd5KzOJbDQKez8teHbE+Xa8FVFUsvE9UG2
B+LnmL3wkaWFh7q4KaAJpsnyzNQY2BBpItNzqvcqH0JzqXNqwaeQWKAYTc2i
0L9Br8hjquOzY5xROUh03Ka6flIKwI+20fjJqvIfGLZHbN3xPs77mlNYlXwU
LwhT+e+j+CeVEX/q7yMQGbZ/ovPrnn9EJPoEDUR6otyXk+dhLAIK+fiZTyG+
iw9fQVoVIZHLUJ+TTrq6vycnYMgrldYW8bxvzLhSZWCvHZU2M8T+jSilrTbs
cXE6X9F3LZ+2/PiYuyIHcFtBfXeLEoXCpNkaxtkiNwth5bqrCO5vOA11j4RK
qTcD4ciNhkSdr1I+iol5V/PAlS/KtEtz42oQ1zOfIj58Oo9sp6SQKwsIITg6
k+kNRhiWgOEblYNGC3jql1WAK0Alh2DEMi24gPeCUVQOcE+gqdpnD2ErwTU7
8glw6LOi/6IHGnj143Vv2BZsVaR5ndE3SFlnmvzLF7ObUOjgpfjs+dkyo1Xv
Go1iX4BfjBpiTa0aqPq2OFX6NiaKznlh9a1M/8g3cf40A3xaETBalbMZloi1
WDvN+RtpJkxdIZlPyBAXReiI3qvjcVr3XtC2oTQTpP+z/ozQZ2ymC4R42Ofo
Y5/CSo+A779oDvwYGyMAAA==

-->

</rfc>

