<?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-02" 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="July" day="23"/>

    
    
    

    <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>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>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="June" day="27"/>
  </front>
  <seriesInfo name="Internet-Draft" value="draft-kavian-agent-enrollment-protocol-02"/>
</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:
H4sIAAAAAAAAA61Z/XLbNhL/n0+BU/9pO6ZiO20cazrtOYnTOJfYru1cp+lk
JIiEJMQUwQNAK2riPss9yz3Z7S4AEqQU17k5TzuhQGCxn7/9YJqmiZW2ECM2
ODuq7YI9EVwLzS6FMVKV7KkWuSit5AX7WfPSsqt1JdhMaWYXgh3N4R07LrUq
iiU+nmtlVaaKQcKnUy1ugOzR8Tkj0oMkV1nJl3BXrvnMptf8RvIy5aJKFYcN
qXGXpllzabq7n+TcwpH93f1H6e5Buv8wyWBhrvR6xIzNE1npEbO6NnZ/d/cQ
9pt6upREyAKvI3ZyfPU8MZaX+ZgXqhS0WySVHCWMAbcjthYGHo3SVouZaX6v
l+1P5E9pPJHC/4zJEl6cDtk/SAZacqJ115Se81L+wS1wM2IvuV7JcoedlNmQ
fX1SPi/U6hvaJ5ZcFiMgYf4uyxksV3w95DJJSqWXcPpG4NUXz58+fPjw0D8+
Ovh+1z8+3v8+rB7u7dEqqD19enZxPCL6wcZXdxuNtnI9F3bEFtZWZvTgAaif
W82za6GHUtjZEGR6AJZ80DUiEk1FQzStPNEHRDS24aN0/4AWjdBSGJBXOSYZ
KMYKXQqbPkPafT/53BXoJHi6tRH+pdtstM1OCXLQ1fIBeFJ4fPRof5QMh8Mk
SdOU8alBZdgkuVpIw0APNekwFzNZCkNR0QmkTZ9mcwoke69AYl+DIb8ZMoaW
iw4WwhrGSzQzxKq+kZlg4PS1wEViIDV2XYjABs8yYATc/VqUcKNW9XzhbgYC
LrIztVxCkLDVQsK5SguDdMs5m3IjCpCO9maFRP64gbfo1aR1FCzj7qfTgVbK
MjVzgel1t5R5Xogk+QrtrFVeZ3gCNfmXCmj061hFNi/EDQgTuDakSlUhRVCx
1zprtW7Yx48hJm5vQaGXW7aAqlB/SGbpo5bo5qIq1Br5Qum4ZSsyhGJa1EYw
8UEai5rq6cIJvCKqM4tWKL2gC1ATuO8NGKNSJnAL+pJwA6pZEk92za7FeniX
s00cdE7JzJPIRTZ9hvzDNA6y1TU+fvTIcnt7t5sA+Z9b0lr8C0g7w4DjVKoE
tUxVLoVT6svLs1Ompu9FZo27AyEL7si4BhDIGahCsxdXV+dgOiAPKvT7EM9g
H+jLSZ2z6Rq5IfFAKZF8uYLbSvA7tCju9XI6XAj2pANmBzbNgNOFkxt+O/kl
eqapBLnmDsPwpHXIZcpZFS7+FYzMeBN34gPYEK6mHMN17q/dQtCJhJACIgHt
lqp/A7gDb0SZV0oSlxJ0mt9gqBkyuEJ3C69RK5H8mSpncl5rxybG2QWYRWrh
HPcVL+c1gKgLOPArtlIaAmfw+s3l1WDH/ctOz+j54viXNycXx8/w+fLF0atX
zUPid1y+OHvz6ln71J58evb69fHpM3cYVllnKRm8PvoN3qCrDM7Or07OTo9e
DUBPIF3s5Og2EGFTgSoUGvDIgvG5SXJhMi2n8APOPHl6/p9/730H6vsb6G9/
bw/153483jv4Dn6swFjuNlUWa/8TXHqd8KqCCEAqvCjAEytpAQR2UKtmoVYl
WwgtQI/f/o6aeTdiP0yzau+7H/0CCtxZDDrrLJLONlc2Djslblnack2jzc56
T9Ndfo9+6/wOeo8Wf/iJMD7de/zTjwk6T1vvOY+JkYTQaSYhZqUZJcmff/7J
rPhgkxiMcDVJjpowIeAUJZ8W5Mnd2C0AQU0fzMAyk4DvQ9o8xs1mQub0R2jd
rUw05YTeQVNXFZR2Iqf1ALAnJQVl429Dl5fc4tM4kmIZQI+sqqdw9aIbbqwu
c9DGVnbHbuewI5zX2nsDF3yEUmMQTg5G7CPVKoOIBCz+PojPD97tbGzy9zQE
4G3nSLsObxzqjwmkxq7+8bdUHLA80Ke9gKa8Luy4kDMBmVGMjYCriNXB4e7u
INragbtxQCrcGOpJCLOh+MCXVSGGIPMDGR9vAfFeZ3V81mQKldCYm6TRgucI
QystbVcov8+MK6HHbREwdj6Et2KbMPAHbunfW6/07h2uJMVbyBj4IJ0j4aOn
B0+QH2xtBu8SJHfrwmOyzQ7gqJSmITfyNVYFUHNCeWFCztsoBCbOaD4K3q8w
HjBhIlBWWNeyG15AggYCVH8YRgAG7Q7HbGlrjYk1LgQotziqsGEOWa3Ad1jR
ARQ0KSlnjmWInsnnvCRIg9UXoCqcKYF7LTPHFPEsqZiBlKw03kfFZ+nwHhIt
VQ9OB3jRdh+LIKDnQZMdQn3mqe5QasFa45K9uXjlKsde7gZPcnENtaRVqsCb
XU/FqZzzWsTiD8HE16JICPdQoZVvK0KR/b6fbrDngM1DThrKHjoWPKGtJDNe
huqLiN/p1c4UngjUZ6oQHAuakxk2NnQ5mtdbEjdPBjNgWwwmKH4Xyp3fwJbo
GulAlvvk0ZSC5G6et6CtlcQiCSn1KGxe1VR2gQRIF3dUniLdopZygyKbabXs
8WSGbZK7cAqMWxFZIkkTFb616TRDk6O4rBzRxh8g9H6c9NsAEhRCdMLgGnKo
kLWG/STQojkCUAe9EXoG3tIiHzsvajGOoG0QwwhRcGDeoE1Lf+K0Ne13EOhE
/VvIbULJ0LEO5kOXxWdihd0u7UejNV4psFV4Uzbu3q6H3UgE+EDD4SrZinrI
4D2TwAYBovNX3BC4gBhA5/D9L0blrC6isGva7P7VVF+THpwzM8AWACWZj/1O
Ukes1L4q0GEctsb9yWYlu4nQG3qU8xLRj84CFswADstMdLzU6QMLElMTWKOc
vVCTDWK6fmuj0IgzDvrImu8fhqzqvKwTPJQJ1fV4d+/F298e/3rwy/7zxy8P
nj08P/z58O3e6aOrK3cIuiBoNczYOR6Nevb20929q93dEf331u37IseN3oWg
cF3rYGsCJeuEMpxUDRnIcsjGZH7f8LrGjKzWmtfFRP94EyNP2uhoBd3c7zId
NB8MB3WuqcMn7KYhJUKWWVbkjZFzEr11mxn+QggKt34+8J4Yu5P3aGBHLCu7
9sUEZRok45SAc4hSOVppISECMefGwLYRAP1sFdoxE4dkCiAJvtepD7qQ3Cfj
ExN2B3F7gbpCsHfsOpx3ANCcjJHgjjwDFwST94qokFz80KA7GGhLJghHscLo
ptSAuaDNDXwO9nE3ceaON4miPzGjiI7m6udOEN9rnJWs4DYMQzwMmZ1oSugF
N5EZXWqKXLyXgUy2EEvhkQCL6RR80eAsoJfE/PEYElyYnaGplHU2BQZUrTPR
YYsgrARw5TnVRa6QyJEFOEKjQ5r16M0BY8Q4GL3InaG2sgvV1X1Z9j5hmMQ1
NLW7q9t4kscghlQWCiKwn+cSat2tIg87FTQKSmMFFcajXkbw2WA8N3ygsnk5
hYYRp3q4AgrI0AnAbXVd+EFZd8gFkU8TiKPWnEGXfljbzoKIH0QKWdY0OQlC
xdPbrl/4GRFGyedKHx9D/9fax9eiGIiKuR80gdk2N++MZ6n7wFYhHp3zrm5Q
go2Ud0dZFfJIywqaMoLnBjEDxjT9Ug/RNjv6/yWN3oNVb5NQfzcIHyV9dF5f
IvRTQ1Tt+B29Bg8Exl4MgAyAO1tQ0BDK0Jgbyrm+3T5jKgE94joKtZ24a0KF
onOzCVAYd2Y7jXihqfmKHWsN1n4BDo+dmAfwKIhr49MPOqKgzdgFTuuCAwud
wsxfG74dURUWvopwanlcfs93QPwCsxc+OmnhoS6vS2hiaTI8VTUGNkQay+WM
6jXrQ2jGZUEt9AQSCxSTmZqX8g/o9dyY6ej0CGdMBhKdazNNPykF4EfbSPzk
ZP0Hgs0RWXc8j/O65hRWFZ/Yc8JU9/eJ/ZOa7i/6+wRE0vaPdX7d84+IRJ+Q
gUhPlPty8iyMNUAhn+74lOG78PAVo1URErkI9TXppKv7e3IChrwUWa0Rz/vG
jCtNB+y1odJmiti/ZhXXdu08Lk7nS/ou5dOWH/+6rsYA3Fqo0G5QolCYNFvD
OJoVas40X3UV4foTl4a6R0Kl1JthuMiNhjydr0o+iol5U7uBqbsolyYrlKlB
XM98hvjw+TyymZJCriwhhODolGfXGGFYAoZvTAYaJeCpX1YBrgCVAoIRy7Tg
At4LhlE54Gp6SdW68xBnJbhmSz4BDn1W9F/kQAMvf73qDcuCrcqsqHP6hsjr
XJJ/+WJ2HQodvBSfPT8bZtTifaNRA2CMX3waYk2tGqj6tjYT8iYmis55ruUN
z/7KN3F+NAV8WhIwalE4MywQa7F2mrlvnDlTtUUyn5EhLorQEb1Xx+Ow7r2g
bUVpJkj/pf6M0Kd0LkuEeNhn6GOdwEqPgO+/Zut/NNsiAAA=

-->

</rfc>

