<?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-00" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true">
  <front>
    <title abbrev="AEP API Key">API-Key Session Credentials 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="27"/>

    
    
    

    <abstract>


<?line 38?>

<t>This document defines an API-key session-credential extension for the Agent Enrollment Protocol (AEP).  The extension 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.  Extension request and response bodies are JSON objects <xref target="RFC8259"/> carried over HTTP semantics <xref target="RFC9110"/> as defined by AEP.</t>

<t>This extension does not replace baseline AEP authentication.  Services that implement this extension <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 supports this extension 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 extension 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 extension.  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-00"/>
</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:
H4sIAAAAAAAAA61Z/XLbNhL/n0+BU+dm2o6oWHbSJJpee67tNE4T27Wd66Sd
jASRkISEIliCtKwmzrPcs9yT3W8X4KftdHpznWZMgcDuYve3nwzDMCh0kaiJ
GOyfHYc/qa24UNZqk4qDXMUqLbRMrFiYXBQrJfaXWBFHaW6SZE2PZ7kpTGSS
QSDn81xdEZ2jMwFaArQGQWyiVK5BPs7logjfyyst01CqLJSZDt+rbWgduzCq
2YU7O0EkC7U0+XYibBEHOssnoshLW+zu7Dzd2Q1sOV9rPldsM1A/Prp8FthC
pvFUJiZVvFsFmZ4EQkDAidgqi0dr8iJXC1v/3q6bn7IsVianEyH+CaFTvDgZ
iZ9YaF5yd+mumXwpU/2HLCDNRLyQ+UanQ3GcRiPx5XH6LDGbr3ifWkudTEDC
/lOnCyxncjuSOghSk69x+koR6/NnB3t7e0/946PdvYf+8cnuo2r16Xi8Q4/Q
dHhwen40YfqVHS8/byfeKvOlKiZiVRSZnTx4EMtCFrmM3qt8pFWxGOFOD2C6
B12rEdFQ1UTDzBN9wERBBOx3d3a/CXe+CXcf86JVuVYW9zVOSAHFFCpPVREe
Eu0+MO5jQZig042N6L/wLhvdZaeAJKi1PBqNgiAMQyHnlq5dBMHlSluBG5es
rVgtdKqskCkhmWAqbsNUqOtCpewqf+oe4kvY6quREGSc5lyiCscELnOh8isd
KQFYl4oWTSZ/xxO5EglQrHJTLleOD/b/mEswiMx6DdSzBLHKErMlvha7ZCFk
kisZb0FJ5TCOWOGXysO5tCquL0YapQtFDGCvmLWO40QFwRdkrtzEZUQvg4AY
e02IqBUfZAI8C1lfojDVPeC/YL0ok9Z+AYurnC/OCmuJAKVvdLHCOZIygRX4
slGieaMFnkgS8eFDBf6bG1brXeYjVc18nJmJJSuM4gVry4vqVbXhd0bkqrRk
IW0LnS5rJTl9bGSuxGalEyWyXFkiQHsgH+3JjK1UIx1vUoFMoY7cmAJSHtWG
zxVMa3EhmA6UMpOC69zEmkAHJi8uTk+Emb9TEWz54YN3/5sbEckcDhULcwUF
Pr+8JHMAANCd30exAfsggdNCLOZbEnHkMd6ALzZglpoCAmSJhJQdjfdgIXr6
0ussUazsokv11euLS6ASJ9OScSCjSGXF54gL0lgLArEzuUO2HREKz6EvnSuH
7ZcyXZaIFHQjxarfmDy2YkC8B0P3V5yc8vP50c+vj8+PDun54vn+y5f1Q+B3
XDw/ff3ysHlqTh6cvnp1dHLoDmNVdJaCwav9N3hDNhycnl0en57svxwgIjmV
1Ggke0IPc+CBQh+QQ1eUNoiVjXI9xw+c+eHg7D//Hj+EEf8GK+6Ox2Rt9+PJ
+PFD/NhAQY6bSZOt/wmtbQOZZUrmRAV+CIhkuoBTDgkEdmU2KRw/V9Dj17+R
Zt5OxLfzKBs//M4v0IU7i5XOOouss9srtw47Jd6xdAebWpud9Z6mu/Luv+n8
rvTeWvz2e8ZZOH7y/XcBgcdFyks4vkNMKxBojkgLDWfSdhIEnz59EgXAHPio
QQuIek1cI+zbMstQR9g+9BMEDdsKOLDHrEYxM50SUztjI/rdvO5WZqifzHvV
O+i5qZjXNc6QdxynNkNwqFE2crHaLR6YdKGXZS590K7Fh/ZEVs7BekU+2mwS
ZYrMcLe4U7dzVN3Lq+mdBe0PyLiD6tBgIj5wBh60TmPxt4E/Ong7vPXeU6/P
4m21u1nCIqKZLJNimuiFKvRaTa3CSWY6QGhEXbgzGDbbXaqbUh3gRLgOe0Lw
NhsZkqHWMW+lpEkev8l1obrbveWnSKjTJp9NneFIFCo7B/7ADf+98Xfu8nAl
DnFhXdCDdtajR08PT5Q9Szt4GxC5GwfH2X26AEKqciKE2yOwpABHriNxJRMu
KmLaUVA4QApUFPkpj6UuICHpct5BTYS8BkTN2lqcDTnkCH9i6AHMOcjt46rL
Zb4KcBGk8QmAcm6VTj2NKrU8bx+ncBkhWYTQBzkWlWyUIYjsBjlgKOZl0WQj
H1sqVKMMUTkdd9RA/HhBZR5LTCS87toik05mNT5mdPE+Lu65vJcirFItH/P6
s019Q1rwGZ+JfxZFzoieCGoCkyiZ3n8Pkn2wQLhXgxl29UIVck2Zp9jSYqNd
JJE+LtblB6cCLxsSLsniajGm1KNwm1VdTlQkcLt2tewpMhez1rcoikVu1j2Z
XPJ3a+dOgS6EO73qlEjaVjlcWlZaVWvM9rldqJsz2vjtu03x3axfgvBFZyab
CbCBtEjYPjSP+uGuCV7k8FVUIS8fJHKuEl5d+uYlDl00obceAiqeOng1weZt
7doN8ZlT1bxVwhJ4mAVjpEp9lVtXcCO2V0hssYi1RWW3FXymXcJRHtDLlEKA
Zkj2Resw6NiajroEulBwNQd5LgprjKsYJ16ntfM069VuIoKLEQxolS1PoK6x
OKvEQLmLLpnR34srBLWqx0DN3uswqo6sz3qICzvFOtcQM4BIJjqe+p2zDuSc
OJRCbYkwZi2x6fmNrgOnK9hv5UeYb+ry2UCqDFH7Sk0fv1g/OrqWVEU7cHSc
gbbixHRn/PzXN09+efzz7rMnLx4f7p09/fHpr+OTby4v3SF1nSEi2qksOA1S
6z3eDXfGlzs7E/7/V7fPBTva06RBfnE/EL3QDISqHmSkUW0vEZtZvb0eldPM
qIUzUjQw6drPzq6qzyvQBEt0QuPdJ2JO1Y1ZCEU9ZwazM549mQICFszUJzPb
apLnqH8JjApqJED3WDEBdP+Ra58XhtpVihR2i8tcj8SJz5PRStI8AKT8Sdeg
ZUizrlPhTtrkLk21OiyU6YKGNa4Joyf0pQ4Icp4uqnoydLL/Q4y//vLv17tj
8UDgz164+4N7Ogz39vlp7yB85NYeHYaPj75yVuEOzslM4XVN+rrSVs/Rke5f
HBwfNxewvlFV11FSxnRX/EZ7naHTG7IRUYC0tg8RwEui83tpCt6Bom5I3aWO
TGJ85zGX0XubSLsa8SQD2EOaisi9Gs1ZhZ7nymh0ZD7JZjLnuCzXc1ScunDN
S4UHp8umEEFu4qICVXkSezs0xchtQNY1vINkuyApadBBoaBXcPxC7LvVDbtx
fEXjBRwatoBWhWGDhGJcGGo2+jID4jW+eIeIjFXCCM32HEboCV0d1W8o8tYZ
y9mZLoHetilG/sQTOSb3SxA/cGrHbh/2II5aZ7AEB1hnD54secdZSUrmjlqY
aCCNSsR2NiXJuhm8XyP5OkYSqlqNFtsDtQGxcUWBi+/1uXag/0xRAvIu3gRB
N+C4rMD68zMchhkH9maoLc5amAiCU/RvsqiGKj4Z2GFrrOflsx096bSTuEIU
Hor9wYHL5wKas4aws6WpRR2CJ+KudOBbzvvmIQiOcWZ0HRb/2qjFD1NIjfcV
Ul7J/9dKyle2NIOiERszoFFFHQHYr6g1qaZz7GVdHZCkt3Lr3cVYlcUabuS8
lc1qsFcgcz4BHj1A3+50/5ck/XkRvbqrQr32y1ZBQd2PLz/6Dt0qZPwO/FzK
PE7oEVrFXandgyNy+iObkgp4wIk6rW+Qu2a7lJAR7ratucmwysw0LCVNRlRK
zkBh2plz1Jerep8vxFGew7zPgWTganlrKAmCth5xK957ZSI5LxMJCVoJt+Za
fSGgKjVtTcsl90YuKiOer2VCXwDo0d0XD2X6PkWfPBTgMjclnIucCGXzYoEO
GXd13rGQmkbc6KJQc6JOjMwy1X+gKXRDl/2TfZq4WIQ4N0yx/c8JVTQh22j6
4uBqiUV3VtQd7NO4qj5AaeCjeMYJ8aP4F6elj8HHMAz5H941h7ChIUuvDnnM
mDHPj+K0W7FxrIzrjwsNfzp5rlgPEdHs3ugj3fxCRWVO2bx/+05i75RmttOF
cGwvyIg80bQy4ciJ8gJvYRMa+iLEE0P4b7hBogIQOYvcJkRTw8QsRS439ZzB
FQ+udOmx9SmlFfEo7Digt9J7g3nC17L5tmJLN2sjNuizosTYEhfx44iIo9u9
0fSOGTiJSAtAG45SnUVgpDxZfSuw6Nio0Op9CoETgkoC3KZq423qzXorM3Kn
Q6U469u5kJsCtj4I+drJReG2c7ZV7u+ZKw5QrrAzpW2gzkryKVOsy6TQWaJ6
PNjI9bvUpGGtIY+adhzyYVsW7TrSlHAJCX+Nim550nwXYS89y4Gk6DNQpRnN
HK695rCSq8RRWVGgwn31wn0aioUpC6JQf+Ahw3q1NBCpEVlpgEZy3tdqlrCv
4eBcafUvYJoChslR11NYxBZWZaHomwyHi/8CFEwgE9kfAAA=

-->

</rfc>

