<?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-basic-session-credential-02" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true">
  <front>
    <title abbrev="AEP Basic">Basic 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 39?>

<t>This document defines the Basic session-credential grant type for the Agent Enrollment Protocol (AEP).  The grant type lets an AEP Service issue an HTTP Basic credential through the AEP Grant command for deployments that already integrate with Basic authentication middleware.</t>



    </abstract>



  </front>

  <middle>


<?line 43?>

<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">basic</spanx> grant type for Services that want to reuse HTTP Basic authentication <xref target="RFC7617"/> 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[
basic
]]></sourcecode></figure>

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

<figure><sourcecode type="json"><![CDATA[
{
  "commands": {
    "grant_types": ["basic"],
    "grant_types_config": {
      "basic": {
        "default_lifetime_seconds": "86400",
        "realm": "api.example.com",
        "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">realm</spanx>, when present, identifies the HTTP Basic realm associated with credentials issued by this grant type.</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": "basic",
  "label": "legacy-basic-prod",
  "requested_scopes": ["read"]
}
]]></sourcecode></figure>

<t><spanx style="verb">grant_type</spanx> <bcp14>MUST</bcp14> be <spanx style="verb">basic</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>

<t>The Agent does not submit a password.  The Service generates the username and password, or generates the password for a Service-owned username, and returns the credential in the Grant response.</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[
{
  "credential_id": "bas_01HZY8W7Q2F8J7D3P9G9Z1N6TT",
  "expires_at": "2026-12-01T00:00:00Z",
  "password": "s3cr3tExample",
  "realm": "api.example.com",
  "scopes": ["read"],
  "username": "aep_agent_abc123"
}
]]></sourcecode></figure>

<t><spanx style="verb">username</spanx> and <spanx style="verb">password</spanx> are <bcp14>REQUIRED</bcp14>.  Agents <bcp14>MUST</bcp14> treat <spanx style="verb">password</spanx> as an opaque secret. Services <bcp14>MUST</bcp14> generate values that can be encoded according to RFC 7617 without lossy transformation. Generated passwords <bcp14>MUST</bcp14> contain at least 128 bits of entropy. Generated usernames and passwords <bcp14>MUST NOT</bcp14> contain control characters.</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">realm</spanx>, when present, identifies the associated HTTP Basic realm.</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 Basic credential has no scope-limited authorization.</t>

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

<t>The response does not include the base64-encoded <spanx style="verb">Authorization</spanx> value.  Agents construct that value locally from <spanx style="verb">username ":" password</spanx> according to RFC 7617.</t>

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

<t>On later HTTP requests, the Agent presents the credential using HTTP Basic authentication:</t>

<figure><sourcecode type="http-message"><![CDATA[
Authorization: Basic YWVwX2FnZW50X2FiYzEyMzpzM2NyM3RFeGFtcGxl
]]></sourcecode></figure>

<t>On protected resources, the Agent <bcp14>MAY</bcp14> instead use the dedicated AEP carrier while preserving the Basic field value:</t>

<figure><sourcecode type="http-message"><![CDATA[
AEP-Authorization: Basic YWVwX2FnZW50X2FiYzEyMzpzM2NyM3RFeGFtcGxl
]]></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>The encoded value is standard base64 of <spanx style="verb">username ":" password</spanx> as defined by RFC 7617.  This encoding is not AEP's base64url binary convention.</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 Basic credentials of this type for the authenticated Agent:</t>

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

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

<figure><sourcecode type="json"><![CDATA[
{
  "credential_id": "bas_01HZY8W7Q2F8J7D3P9G9Z1N6TT",
  "grant_type": "basic"
}
]]></sourcecode></figure>

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

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

<t>Basic credentials are bearer secrets once encoded into the Authorization header.  Services <bcp14>MUST</bcp14> store passwords using strong password-storage controls.  Services <bcp14>MUST NOT</bcp14> log raw passwords or Authorization header values, and Services <bcp14>MUST</bcp14> support AEP Revoke for every advertised grant type.  Agents that suspect credential disclosure <bcp14>SHOULD</bcp14> call AEP Revoke using baseline AEP authentication and then fall back to per-request signed client assertions until a new credential is issued.</t>

<t>Services <bcp14>SHOULD</bcp14> use a distinct realm or credential store for AEP-issued Basic credentials when the Service also supports human-facing Basic credentials.</t>

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

<t>Basic credentials can become correlation handles if reused outside the issuing Service.  Agents <bcp14>MUST NOT</bcp14> present AEP-issued Basic credentials to other Services.  Services <bcp14>MUST NOT</bcp14> log raw passwords or Authorization header 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="RFC7617">
  <front>
    <title>The 'Basic' HTTP Authentication Scheme</title>
    <author fullname="J. Reschke" initials="J." surname="Reschke"/>
    <date month="September" year="2015"/>
    <abstract>
      <t>This document defines the "Basic" Hypertext Transfer Protocol (HTTP) authentication scheme, which transmits credentials as user-id/ password pairs, encoded using Base64.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="7617"/>
  <seriesInfo name="DOI" value="10.17487/RFC7617"/>
</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>





  </back>

<!-- ##markdown-source:
H4sIAAAAAAAAA61Z63LbNhb+z6fAqj+23TEVSU5jR9Np103sxN34UsdpN+lk
JIiEJCQUwQVAK0riPss+yz7ZnnMA8CbZk87E00YUBByc63cujOM4stJmYsx6
P3MjE/ZSGCNVzp5okYrcSp6xZ5rnll1vCsHmSjO7FOxoAb+x41yrLFvh46VW
ViUq60V8NtPiBugdHV8yotmLUpXkfAWXpJrPbfye30iex1wU8Qw3xMZdGifV
pfFgFKXcwpHRYPQoHhzEo/0ogYWF0psxMzaNZKHHzOrS2NFg8Bj2m3K2kkTI
Aq9jdnp8fRIZy/N0wjOVC9otokKOI8aA2zHbCAOPRmmrxdxU3zer+isv7VJp
PBHD/4zJHH4477N/kQy05ERrrym94Ln8yC1wM2a/cL2W+R47zZM++/Y0P8nU
+jvaJ1ZcZmMgYf4p8zksF3zT5zKKcqVXcPpG4NVXJ0/29/cf+8eDR8MD/3g4
+j6sPh4OB/gIao+fXFwdj4l+MO71/UajrVwvhB2zpbWFGT94AOrnVvPkvdB9
Key8DzI9AEs+aBsRicaiIhoXnugDItq04aN4dECLRmgpDMirHJMMFGOFzoWN
nyLtrp/cdQU6CZ6ubYR/8S4b7bJThBxUWu73+1EUxzHjM4Ni2yi6XkrDQOKS
tJWKucyFIf93sbLttmxBsWK/KFbYt2Cr7/qMoXEaBzNhDeM5WhLCUd/IRDDw
61Lg4vPrax9WrHGtXWpVLpbuPjjmQjZRqxV4P3GSiiJTG7wfJeCW8UwLnm5A
WRBUGszE1tIuPWnUKJJOyIHZSqZpJtZcC68jtxBF36DltErLBPdFEd7ttdJg
D6TJwLUZr8SxKkgEoQx3z8usKQ4YX2hSAemuwQ3on9jkDJBDZGAQkjfJJG00
4FrE8adPIQ5ub0nDd1lySgg07RrOM+p1tabfFNOiNKJpgo6ePn3y4Xl7y9ZL
mQlWaGGQVL4gPt+LDSuUCSrijgdUBc9BLVopC9w+q3nR4j+lMCAZmBFIFSoH
BmYqhfhhYA72y8uLc6Zm70QCdqXrERLg+oRrCLKUqRvQJHFsAGuQVb8P8QL2
AQtOHSmbbZDHvvf7hkJSBbflygIHRcaBz5bu2zoA9tu6k6siE6R22yF79url
NfgoHM1LcgmeJKKw91FnqLSGN6TO+s7PTR8d8go0JrVwnv6C54sS8ANlEqT9
tdKpYT28u7fnPtn5BT1fHf/66vTq+Ck+v3x+9OJF9RD5HS+fX7x68bR+qk8+
uTg7Oz5/6g7DKmstRb2zo9fwC1qxd3F5fXpxfvSiB6HndFI5JloU9DATFJUa
nAdF5CZKhUm0nMEXOPPzk8v//Xf4EMz4N7DjaDhEe7svh8ODh+R7Ine3qTzb
+K+gtU3Ei0JwjVQgJMFJCmkhPvfQDcxSrXO2FBTk//gDNfN2zH6YJcXw4Y9+
AQVuLQadtRZJZ9srW4edEncs7bim0mZrvaPpNr9Hr1vfg94biz/8RH4WDw9/
+jFC56lLHecxDW+VBE5zCeEkzTiK/vzzT2bFBxsRgOBXgL8a4ND1Rc5nGcVB
2/EzacA3A/KALaaVB9OuCe4yUzKg30vrbmUK5ZV6LzoHTVkUUMeIlNYlnMHI
OM1NAdBQeVjfQbZbfKLyuVyUmnvsrpgHzbGinMHVS4zPehMr8xTk38nuxO3s
O6m8gt4ZoPwJMnAvHOmN2SfKyL3GWVj8o0cHe2/3tn71lKuT8KvbWy/AEqAY
LzM7yeRcWLkSEyPgHF3YO3z0cDDo7dWbIfVlK/wFAqAvPnDEqD6w2NxjEoWX
V4olJjFnYoivtbQiMOu2u31mUgg9qXPZxFkL78Lqs+cP3NLnrRe2fYerdPAW
UgI+SGcyfPT04AkzZ2l6byMkd+s8cHqXGsAtQlERQ5wDkuTgERpy2A3PqLRI
cYfF+IcEiJmHclfuEAgSLqUaKI0gl4EbTUmF0z0CF+a37tVR4jJbI1XSfszQ
KpGE3JTHm0UCVQSUhjoBg9d1rbF1swsU78JxyGl0zHNt6ooigSefWon4vbZz
qvNEIPmqTHDMc6dzrBXpcpTVax43T3tzEEj0prCrgwkA6aXOYUvjGumClnv4
qfI8Ia7nDfIa8uK0RpQ6FLavqtJ2IAHSNWtVT5FuUSu5RZHNtVp1eHI51q1d
OQU6pHR6lTmSNI0atDSktJDSp0dUq1edEW784d3a/jjtZnoSdKqKKYNrsMRV
AQX7XWypsQLDzGEDRlYv4zOR4VomFjzZ+G4T2ofU/e5dQKQT5151iL+tAqom
PnWqmlVFI7oOXUEeEvJLCKXgbHjfDcRFylJpoH7aMDrTLJQQcOUix7CT1gVX
m7HWBS1L41EXKXOxBmx2+9EBKg8XKZx4lVehU6+H3UgExEInwFWyO7p05YnT
wAZUldCgku/jhsAFxBM6WqjpoUruVPShGepeDYhhnVpdYLApuBDPZDrxO6f9
pn81XHqGHstZAYiCNZ1vowJDsFtoahfwVuBHY/dHpgkn9qBJ7+wLPxG7Vbfi
8TIQ2fPFuItjPNaQk0o60QmaVsy4JUy3poR61xjUVCfwZYW3rrTfzqbNQPVO
PxkMn795ffj7wa+jk8NfDp7uXz5+9vjN8PzR9bXzdvGhgMLYTLjFE9STD0fx
YHg9GIzpvzduX9AC7jL7id63xy5DhqC5J3f2tgKJVoPu6JgoJtTST/gsGY72
e1WohV2+zgl8TKkuDpUmev+CintyGwu32NZeijxVcHAf6HlAU9BS1ZGGZ4LR
XerzfQqmBIgBkScKYxV6ESCH2AXAA5U1w7aOQEmVlmXQw0GaAqsZP0LAzueZ
p1v7mKmbHI4IDycFh3ZuODpkMyzS1BxuhA662DSPB0WYlsN6YljzBoL4CcUC
S5YcRxZCIz5Pa0MTbgTNNYAJBcKJkmsF8Qm6BiwXoKZYFeT+DacmepsvTvqN
HN/N/3Um3+bMy+RoEKR183cnxhG1PGqASGJV2I3DJ8dePadpiLLkiB+ObJxJ
wBC0dTMnIYvtPLglrqsGsLZvdgWotJ0Z1sFldbyJm/dkeLiF3NPjX4UNFQTK
PMnKVBA9zK+PHsbBedtZduoJVYEDmgaNlol1nu8KwEwl0BJuHPhXoch64x5r
BNeuqCB4a8yLL52kvq24yCHf2TCE8Khu9hqjMa+ZLSx1pcOd0xYPijiujMFx
Dbb5nerCHXv9+2/rf49O8je/fz+AT/n64/Hm7GPx8Wx0vjnbvzoRz05s8uxD
5lDoAi2tLKAuZUqjSp2IFr+UrUGDAG8Yqb74S5sDCRq+6O0ZUO2T4DJZ6lS/
UxAo07+CMBXuVVMYx8WOQUwYviisyh3/BsctO5TRbyEwqoDGDCoM47z0EAzB
3i5nEjisZtBOSgxVhDYtErQ3zr7KzM+02vMo8FYdgiD4t/NYEIKm+xwStgsA
hNM7Xbc16Kp8188GiTLqRrrggov/bjzVUmcA1jnXG4ycG1QiwcTRXYMooJYW
SlYa+mszLj/FQiy4q7T2SPFVa2vf66CmcdBJF+CMqAuhlLPIg1pT7s5UDlne
qlp21ekh+deXohtt4XaF6AE5HfAj1rXB+uuUSvdx6pUfCsAq9TTqNYwbX911
c1aj1PU74OsCXDjDR1AtSIpNOKQYKCuSJVq4lYolFfRdK+0aumNtcSPAa+tQ
3wuRG3ALg4tNgcKkNXmqZAwt8jfsWGsw9XNwb3C2xfaQGCia6v2DoM03kFJm
ZYaB0wi96trwGof6mR2vNDj10q6YgWp9xTOstfDRCQ4PZf4+h+qcSvmZKhFj
IMSg0ZrPhcaocbEz5xJfQkDXDbENnUWiFrn8KNKpm4cdnR/hMMxAMndzLtN9
9xPSFtpK4ushN4yeN4d47XcvOEOstmPt9JmdEOS7v8/sN8KwL/77DATi+o+1
vn3BHxFovMkFAoH3v8DBU5pDFyT95zveRfkxTnglVasECVwJMkwiSAdtJX8B
B2CtlyIpNeaPrsW2gQqTyUzAv9o3ApjQkjqNAEIrZ7YmcLIlJHahW/05lWmW
nLYqxh36gnUVfITlGHdBAg+Vudkig+V7phZM83WDGPjvLiZ8h+LSZ4cdXzU2
8gFisYt4nt7gizADQjbGaFUBSLFlSjcGbpgulSaB1qYEOf0gHmvCe1LOjjc0
PtHnEHRwdMaT9xiTWBiHd1lGLhAKuu/sQKNAJYPwzcW67VDep/qNgsbzhziG
8W4gwSbWDxnb3YuzG+oGiyrvndvOspVhYFEFLRu2LCGzx3OeoPxbpwlHLrW8
4cmXOKbrNaFaICTUIvM2R3DFYm3u3jSmDHpNJFW9JcTLPX+dPhjdyhfS98sJ
xlCUYIIqv4qHIgBSZ4BgD4dpvxVYcxL8/R+zkIiCaSIAAA==

-->

</rfc>

