<?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-api-key-session-credential-01" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true">
  <front>
    <title abbrev="AEP API Key">API-Key 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 38?>

<t>This document defines the API-key session-credential grant type for the Agent Enrollment Protocol (AEP).  The grant type lets an AEP Service issue an opaque API key through the AEP Grant command for deployments that already operate header-based API-key authentication.</t>



    </abstract>



  </front>

  <middle>


<?line 42?>

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

<t>AEP session credentials allow a Service to issue a stateful credential after an Agent authenticates with a baseline AEP client assertion <xref target="AEP-CORE"/>.  This document defines the <spanx style="verb">api-key</spanx> grant type for Services that want to reuse existing API-key middleware while preserving AEP key possession as the issuance root.  Grant type request and response bodies are JSON objects <xref target="RFC8259"/> carried over HTTP semantics <xref target="RFC9110"/> as defined by AEP.</t>

<t>This grant type does not replace baseline AEP authentication.  Services that implement this grant type <bcp14>MUST</bcp14> continue to accept baseline AEP authentication on authenticated AEP commands.</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[
api-key
]]></sourcecode></figure>

<t>A Service that enables this grant type lists <spanx style="verb">api-key</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.api-key</spanx>:</t>

<figure><sourcecode type="json"><![CDATA[
{
  "commands": {
    "grant_types": ["api-key"],
    "grant_types_config": {
      "api-key": {
        "default_lifetime_seconds": "2592000",
        "header_names": ["x-api-key"],
        "scopes_supported": ["read", "write"],
        "supports_per_credential_revoke": "true"
      }
    },
    "supported": ["enroll", "grant", "inspect", "revoke", "status"]
  }
}
]]></sourcecode></figure>

<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">header_names</spanx>, when present, lists HTTP header names the Service can accept for API-key presentation.  Header names are case-insensitive on the wire, but Services <bcp14>SHOULD</bcp14> publish lowercase names.  If absent, the default header name is <spanx style="verb">x-api-key</spanx>.</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": "api-key",
  "label": "agent-prod-read",
  "requested_scopes": ["read"]
}
]]></sourcecode></figure>

<t><spanx style="verb">grant_type</spanx> <bcp14>MUST</bcp14> be <spanx style="verb">api-key</spanx>.</t>

<t><spanx style="verb">label</spanx> is <bcp14>OPTIONAL</bcp14> and is an Agent-provided display label.  Services <bcp14>MAY</bcp14> ignore it.</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>

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

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

<figure><sourcecode type="json"><![CDATA[
{
  "api_key": "aep_live_7Jm5Example",
  "credential_id": "key_01HZY8W7Q2F8J7D3P9G9Z1N6TT",
  "expires_at": "2026-12-01T00:00:00Z",
  "header": "x-api-key",
  "scopes": ["read"]
}
]]></sourcecode></figure>

<t><spanx style="verb">api_key</spanx> is <bcp14>REQUIRED</bcp14> and contains the opaque API key value. Services <bcp14>MUST</bcp14> generate API key values with at least 128 bits of entropy. Agents <bcp14>MUST</bcp14> treat the value as an opaque bearer secret.</t>

<t>API key values <bcp14>MUST</bcp14> match the following syntax. Numeric character values and repetition operators are defined by RFC 5234 <xref target="RFC5234"/>.</t>

<figure><sourcecode type="abnf"><![CDATA[
api-key-value = 1*(%x21 / %x23-2B / %x2D-3A / %x3C-5B / %x5D-7E)
]]></sourcecode></figure>

<t>This syntax permits visible ASCII characters while excluding whitespace, control characters, double quote, comma, semicolon, and backslash. The restricted character set avoids header parsing ambiguity when API keys are presented in HTTP field values.</t>

<t><spanx style="verb">header</spanx> is <bcp14>REQUIRED</bcp14> and identifies the HTTP header used for presentation.  When <spanx style="verb">header_names</spanx> is advertised, the value <bcp14>MUST</bcp14> be one of the advertised names.</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 API key has no scope-limited authorization.</t>

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

<t>Services <bcp14>MUST</bcp14> issue expiring API keys.</t>

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

<t>On later HTTP requests, the Agent presents the API key in the response-selected header:</t>

<figure><sourcecode type="http-message"><![CDATA[
x-api-key: aep_live_7Jm5Example
]]></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 API keys of this type for the authenticated Agent:</t>

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

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

<figure><sourcecode type="json"><![CDATA[
{
  "credential_id": "key_01HZY8W7Q2F8J7D3P9G9Z1N6TT",
  "grant_type": "api-key"
}
]]></sourcecode></figure>

<t>Revoke returns an empty JSON object on success.  The Service <bcp14>MUST</bcp14> return success regardless of whether a matching key 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.  An API key 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">api-key</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">api-key</spanx></c>
      <c>Description</c>
      <c>Opaque API key issued through AEP Grant</c>
      <c>Reference</c>
      <c>This document</c>
</texttable>

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

<t>API keys are bearer secrets.  Services <bcp14>MUST</bcp14> store only salted hashes or equivalent one-way verifiers.  Services <bcp14>MUST NOT</bcp14> log raw API-key values, and Services <bcp14>MUST</bcp14> support AEP Revoke for every advertised grant type.  Agents that suspect key disclosure <bcp14>SHOULD</bcp14> call AEP Revoke using baseline AEP authentication and then fall back to per-request signed client assertions until a new key is issued.</t>

<t>Services <bcp14>MUST</bcp14> validate only the configured API-key header for this grant type.  Services <bcp14>SHOULD</bcp14> reject ambiguous requests that present multiple API-key headers or multiple non-baseline bearer credentials when that ambiguity would affect authorization semantics.</t>

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

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

</section>


  </middle>

  <back>



    <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="RFC5234">
  <front>
    <title>Augmented BNF for Syntax Specifications: ABNF</title>
    <author fullname="D. Crocker" initials="D." role="editor" surname="Crocker"/>
    <author fullname="P. Overell" initials="P." surname="Overell"/>
    <date month="January" year="2008"/>
    <abstract>
      <t>Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK]</t>
    </abstract>
  </front>
  <seriesInfo name="STD" value="68"/>
  <seriesInfo name="RFC" value="5234"/>
  <seriesInfo name="DOI" value="10.17487/RFC5234"/>
</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>





  </back>

<!-- ##markdown-source:
H4sIAAAAAAAAA61Ze3PbNhL/n58Cp87NtB1R8SNpEk2vPZ/tNE4T202c67Sd
jgSRkISGIlgCtK0m6We5z3Kf7H67AJ9+9HpznnZCgcDuYve3T8ZxHDntMjUV
o4Pzk/hbtRVvlLXa5OKwVKnKnZaZ+KaUuRMX20KJpSmFWytxsMI7cZyXJss2
9HheGmcSk40iuViU6pIoHp8LUBWgOopSk+RyA0ZpKZcuficvtcxjqYpYFjp+
p7ax9YzjpGEc7+xGiXRqZcrtVFiXRroop8KVlXV7OztPd/YiWy02ms85iDcV
J8cXzyLrZJ7OZGZyxbtVVOhpJAQEnIqtsni0pnSlWtrm93bT/pSVW5uSTsT4
Xwid48XpRHzLQvOSv0t/zZQrmevfpIM0U/FCllc6H4uTPJmIT0/yZ5m5+oz3
qY3U2RQk7N91vsRyIbcTqaMoN+UGpy8VsX797HB/f/9peHy0t/8wPD7Ze1Sv
Pt3d3aFHaDo+PHt9PGX6tUUv7rcTb5XlSrmpWDtX2OmDB6l00pUyeafKiVZu
OcGdHsB0D/pWI6KxaojGRSD6gImCCNjv7ex9Ee98Ee895kWrSq0s7mu8kAKK
carMlYuPiPYQGHexIEzQ6dZG9BffZqPb7BSRBI2WJ5NJFMVxLOTC0rVdFF2s
tRW4ccXaStVS58p6yMNBgFNxE6dixQ7i/isHEZ/CWp9NhCDzdA5mylkhc7Il
fLC81IkSQHalaNEU8teKRRAkgluXplqtPSPs9w6amM0GwGcRUlVkZkuMSXjp
hMxKJdMtKKkS9hFr/FJlvJBWpc3VSKl0pYQxHHSz0WmaqSj6hCxWmrRK6GUU
EeOgC9HqAnfIAGkhm0s4U98DLgzWyyrr7Bcwuir54qyxjgjQ+5V2a5wjKTMY
gi+bZJo3WkCKJBHv39f4//iR9XqXBech1MyHBguiBlVd8TsjSlVZJdS1tk7n
q0ZJXh9XslTiaq0zJYpSWSJAeyAf7SmMrVUjPW9SgcyhjtIYBym/aSUoFWxr
cSPYDqQKk4PtwqTwF0FcXrw5OxVm8YtKYMz370MI+PhRJLKEU6XCXEKDzy8u
yB5AAJQX9lF8wD6I4NWQisWWZJwEnHfUkBpwy42DBEUmIWdP5wNgiIHG9KbI
FKvbDci+evvmAsDE0bxiKMgkUYW7j7ogpXVQkHqre3DbCQHxNTSmS+Xh/VLm
qwrxgu6kWPtXpkytGBHv0dj/K07P+Pn18XdvT14fH9Hzm+cHL182D1HY8eb5
2duXR+1Te/Lw7NWr49MjfxirorcUjV4d/IA3ZMXR2fnFydnpwcsR4pLXSQNI
sij0sAAkKAACPHRFaaNU2aTUC/zAmX8cnv/7X7sPYca/wI57u7tkb//jye7j
h/hxBQV5bibPtuEntLaNZFEoWRIVuCJAUmgHvxwTDOzaXOXw/VJBj5//RJr5
eSq+XCTF7sOvwgJduLdY66y3yDq7uXLjsFfiLUu3sGm02VsfaLov78EPvd+1
3juLX37NOIt3n3z9VUTgaasZj5gOWjUHpaWGO2k7jaLff/9dOHXtohA4aAGB
rw1tBH6Vy0XGntCHfoa4YTsxB/aYNyjmfTPaZ+dsxLCb1/3KHFWUeacGB21V
FKhdVMrrGmfIO05yWyA8NCib+HDtFw9NvtSrqpQhbjfiQ3uiqBZgvSYfbTeJ
KkdyuF3cmd85qe8V1PSLBe33yLuj+tBoKt5zHh51TmPxp1E4Ovp5fON9oN6c
xdt6d7uERcQzWWVulumlcnqjZlbhJDMdITiiOtwZjdvtPtvNqBrwIlzHAyF4
m00MydDomLdS3iSPvyq1U/3tfp+dIafO2pQ284YjUaj4HIUDH/nfj+HOfR6+
0CEurAt60N569Bjo4YkSaGVHP0dE7qOH4/wuXQAhdUURw+0RWHKAo9SJuJQZ
1xUp7XAUDpAFKRFxKst9QELe5cyDygipDYiad7U4H3PIEeHEOACYs5Dfx7WX
T3414BJIExIApd06owYadW553j1O4TJBsoihD5VbTYUbZQgie4UcMBaLyrXp
KMSWGtWoRFRJxz01ED9ZUrHHEhOJoLuuyKSTeYOPOV18iIs7Lh+kiOtky8eC
/mxb4pAWQs5n4veiyBsxEEFVYDIl87vvQbKPlgj3ajTHrkGoQq6pyhxbOmy0
jyQyxMWmAOFUEGRDwiVZfDnGlAYUbrJq6omaBG7XLZkDReZiNvoGRbEszWYg
k0/+fu21V6AP4V6vOieStlMRV5aVVtca8wNuGpoWjTZ++cuV+2o+LEH4onNT
zAXYQFok7BCaJ8Nw1wYvcvg6qpCXjzK5UBmvrkILk8Y+mtDbAAGVzjy82mDz
c+PaLfG5V9WiU8USeJgFY6ROfbVb13AjtpdIbKlItUVptxV8plvDUR7Qq5xC
gGZIDkXrMejZmo76nLdUcDUPea4KG4yrFCfe5o3ztOv1biKCixEMaJUtT6Bu
sDivxUDBi16Z0T+IKwS1us1A2T5oMuqubMh6jAt7xXrXEHOASGY6nYWd8x7k
vDiUQm2FMGYtsRn4jW4Cpy/Zb+RHmG/m89lIqgJR+1LNHr/YPDq+llRGe3D0
nIG24sRsZ/f5jz88+f7xd3vPnrx4fLR//vSbpz/unn5xceEPqesCEdHOpOM0
SA347h4a5oudnSn/96Pf54Md7WnTIL+4G4hBaAZCXQ8y0qi2l4jNrN5Bm8pp
ZtLBGSkamPQdaG9X3eo59MESvdDu3hOxoOrGLFFgoe0sYHbGcyDjIKBjpiGZ
2U6fvED9S2BUUCMBesCKCWykS3wHvTTUsVKksFtc5noiTkOeTNaSpgIgFU76
Fq1AmvWdCjfTpvRpqtNjoUwXNLLxbRg9oTX1QJCLfFnXk7GX/W9i9/NP/3q9
tyseCPyzH+/9wz8dxfsH/LR/GD/ya4+O4sfHn3mrcA/nZabwuiF9XWqrUY6K
gzeHJyftBWzoVdV1klUp3RW/0WEXaPXGbEQUIJ3tYwTwiuj8WhnHO1DUjam/
1InJTOg8FjJ5ZzNp1xOeZgB7SFMJuVerOavQ81wajY4sJNlClhyX5WaBilM7
37zUePC6bAsR5CYuKlCVZ2mwQ1uM3ARkU8N7SHYLkopmHRQKBgXH98S+X92w
G6eXNGHAoXEHaHUYNkgoxoehdmMoMyBe64u3iMhYJYzQhM9jhJ7Q1VH9hiJv
U7CcnQjG9LZtMfIHnsgxeViChKFTN3aHsAdx1KaAJTjAenuEmRc7zlpSMvfU
4kwDaVQidrMpSdbP4MMaKdQx1Cx1Gy22B2oDYuOLAh/fm3PdQH9PUQLyPt5E
UT/g+KzA+gtjHIYZB/bOkPu8g4koOsuRJl09VgnJwI47o70gn+3pSee9xBWj
8FDsDx5cIRfQtDWGnS1NLZoQPBW3pYPQct41D0FwTAujm7D450YtYZhCaryr
kApK/r9WUqGypSkUTdmYAY0qmgjAfkWtSXeiOpgJkaQ3cuvtxVidxVpu5Ly1
zRqw1yDzPgEeA0Df7HT/lyR9v4hB3XWh3vhlp6Cg7ieUH0OH7hQyYQd+rmSZ
ZvQIreKu1O7BETn9kU1JBTzjRJ02NMht411KyAh3286oY1xnZpqXkiYTKiXn
oDDrzTmay9W9zyfiuCxh3udAMnC1ujmWBEXbjLkVb740iVxUmYQInYzbsK0/
FFCZmncm5pKbIx+WEdA3MqMPAfToL4yHKn+Xo1EeC3BZmAreRV6Eunm5RIsM
kbx7LKWmMTfaKBSdKBQTs8r1b+gK/dTl4PSARi4WMc5PU+zwq0IdTsg4mj48
+GJi2R8W9Yf7NK9qDlAe+CCecUb0fx/EPzk7/fHfB5yM2z/R+3XfH5/sfArE
yVbeP+Z5xOPNgq/6QZz1K0WO0WnzXaO9Np18rVj9ieJ79lV5H08Y441KqpIq
jKFBesVGr1y0vc6I840jXPGU1cqMozlKHrwFTGgQjbRDoiCmxFdInnAOzmw3
CdEkMzMrUcqrZvbhCxpfTg3YhjTXicIUCr3zdUqO1lsI8qv2k4+t/PyP2KD3
SzJjK1wkjEgSjrh3Rvhb5vIkIi3AAXCUaj/yD8rd9RcMiy6Sir/BFxoEBlDJ
4Eq5ugr2Dia/ka25+6L2gPXtvdpPJjvfqUI95zNDL2B0dR4uWiqOmr7aNJVt
3Y+1FPK42FSZ00WmBkzYys273ORxo6IAm25wDLlEum5xayq4qUQMSVy/Zmo/
13DkOC8BpeQerNLgaIFws+FQV6rMU1lT9MR99dJ/skqFqRxRaD48kWWDWlqM
NJCsNUBzwuCIDUsY2HDGqLX6J0BNQcyUaDYoVGMLq9Ip+lLEIew//1RSzH4g
AAA=

-->

</rfc>

