<?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-00" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true">
  <front>
    <title abbrev="AEP OAuth">OAuth Bearer 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 40?>

<t>This document defines an OAuth Bearer session-credential extension for the Agent Enrollment Protocol (AEP).  The extension 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 44?>

<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.  Extension request and response bodies are JSON objects <xref target="RFC8259"/> carried over HTTP semantics <xref target="RFC9110"/> as defined by AEP.  This extension 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 extension 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 supports this extension 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>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 extension 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-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>

    <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:
H4sIAAAAAAAAA61Z63ITRxb+P0/Rq/xJUh4hGwJYRSXrgAlmwXZss1SSSkmt
mZbUeDQ92z1joYB5ln2WfbI9l+65SYZkaykoZnq6zzl9Lt+5KI7jqNRlpsZi
cHZUlUvxo5JWWXGpnNMmF0+tSlVeapk5MTdWlEsljhawIo5za7JshY/n1pQm
MdkgkrOZVTdA7Oj4XBDBQZSaJJcr4JBaOS/ja3mjZR5LVcRGwobYMas4qVnF
o1GUyFItjN2MhSvTSBd2LEpbufJgNDocHUSumq00nSs3BdA+Ob56HrlS5ulE
ZiZXtFtFhR5HQoBwY7FRDh6dsaVVc1e/b1bNK4pjLJ6I4Z8QOocPp0PxDxKZ
lvgm3TVjFzLXf8gSpBmLl9Kudb4nTvJkKL4+yZ9nZv0N7VMrqbMxkHB/1/kc
lgu5GUodRbmxKzh9o5D1xfOn9+/fP/SPDx99N/KPjw++C6uH+/u0ClqOn55d
HI+JfjDk1edtRFulXahyLJZlWbjxvXupLGVpZXKt7FCrcj6EO90Dw93r2gyJ
xqomGhee6D0iCkSA/cHo4GE8ehgfPKJFp6xWDu5rWEgBiimVzVUZP0Pafbe4
iwX6BJ5ubIR/4l022mWnCCXoavkReFJ4fPjwYBwNh8MoiuNYyJlDZZRRdLXU
ToAeKtJhquY6V07IXHSCZduDhXpfqpwi6ItRI74GM34zFALt1pzLVEmcMJIu
lb3RiRLg8ZWq2ceu3GQqCCGTBMQAX79WOTC0plosmTEQ+MlK4JiY1QoiRKyX
Gs4VVjmkmy/ETDqVwdVob5JpFE86+IouTSrHayWSXx2RtcaUwsw5Kr3iVjpN
MxVFX6GRrUmrBE+gGr94/1q5LCqKeaFu4DJBasYfUyBFULDXuUhaAPXhQwiI
21vQ5+WOLaAq1B+SWfmQJbqpKjKzQbnwdrIUa5SiNMKqyqFZtCtRUz1d8IXX
RHVeohVyf9ElqAl89waMURgXpAV9aeCAatYkU7kR12ozvMvTUNFThskZmXkq
FqQfRD3vMs0C+8e2f3Zc48MHDyu3t593EyB/XHujVf8CymwX8JvC5KCVmUm1
Yp2+vDw7FWb2TiWlYxYIV8AikRYAIBWgCSteXF2dg+WAOmjQ70Msg32gLr50
KmYbFIZuBzppIiI1wCwHr0N74lZ/S4aEYE1Sh9uDTXMQdMm3hne+vUa/dIUi
x9wTGJu0DlnLsE2B71swsZB11Kn3YEFgTelF2tSz3UGQb4RoAjcC2g1V/wUg
B76oPC2MJik1qDS9wUBzZG6DzhY+o1Ka6ycmn+tFZVlKDLILMIq2ir32lcwX
FcAnRxs4lVgbC1EzeP3m8mqwx/+L0zN6vjj++c3JxfEzfL58cfTqVf0Q+R2X
L87evHrWPDUnn569fn18+owPw6roLEWD10e/wBd0lMHZ+dXJ2enRqwGoCS7X
9nB0GgivmUINKgtgVILppYtS5RKrZ/ACZ358ev6ff+8/AO39DdR3sL+P6uOX
x/uPHsDLGmzF3Eyebfwr+PMmkkUB7o9UZJaBHxa6BATYQ6W6pVnnYqmsAj1+
+xtq5vexeDJLiv0H3/sFvHBnMeiss0g6217ZOsxK3LG0g02tzc56T9NdeY9+
6bwHvbcWn/xAAB/vP/7h+widh2P9CmCDPaYNIwRNcw0Rq904ij59+iRKcMSo
jUS4GkVHdZQQarqqKKDCcmzsVjID+HR9JAPLTAO4D4n9BNm7KZnTH6F1Xpla
Sgi9g56lSmk9oOtJTjFZ+9uQkxIvPm1HUvsOoEdRVDNgveyGm6jyFLSxU9wJ
7xx2Lue19s4Bgw9QZAzCycFYfKAqZdAiAYu/DdrnB7/vbW3yfGoC8LVzpFmH
Lwz5E8KoCVc+nkshAckDfdoLYCqrrJxkeq4gLaqJU8CKRB0cjkaD1tYO2k0C
UOHGUElCmA3Ve7kqMjWEO9/T7eMNHv6ps7Z91iUGlVCbm25jlUwRhtZWl91L
BU+cFMpOmgpgwj6EXLFBGPgDt/T/rVd6lwcXo8iFjIEPmh0JHz09eIL0UFZu
8HuE5G45PKa77ACOSjkaMqPcYEkA1SbUFi5kvK0qYMpG81Hwbo3xgOkSgbLA
ilbcyAzSMxCg4sMJAjBodCQmy7KymFbbVQClFqYKGxaQ1DL8huUcQEGdkVLB
IkP0TO/yknAbLL0AVeFMDtJbnbBQJLOmSgYysrHIjyrPnPEe8izVDqwDZLTb
x1oQ0POg6R6hvvBU9yi1YKVxKd5cvOKysZe6wZM4rqGQLI3JkDN3U5JqOa9F
rPwQTHwhioRwD1VZ6a4KFMXv++mWeAxsHnLiUPTQseAJTRmZyLr2IuKf9Wo2
hScC1ZnJlMR65mSOLQ0xR/N6S+Lm6WAOYqvBFK/fhXL2G9jSYqMZZKVPHnUh
SO7mZQvaWmuskZBSj8I2q7qwCyTgdu1mylMkLmaltyiKuTWrnkxu2CS5C1Zg
uw/ROZJ0raq3cp1OaHrUrirHtPEJhN73034PQBeFEJ0KYEMOFbLWsJ8EGjRH
AOqgN0LPwFtapRP2ogbjCNoGbRghCgzmNdo09KesrVm/fUAn6nMhtwklQ8c6
mA+5LpirNTa6tB+NVnulwj7hTV67e7MediMRkAMNh6tkK2ogg/dMgxgEiOyv
uCFIATGAzuGbX4zKeZW1wq5usfusqbwmPbAzC8AWACWdTvxOUkdbqX1VoMMw
tra7k+1Kdhuht/SoFzmiH50FLJgDHOaJ6ngp6wMLElcRWOM9e6Gma8Tkbmur
0GhnHPSRjTw4DFmVvawTPJQJzfVktP/i118ev33088Hzxy8fPbt/fvjT4a/7
pw+vrvgQNEHQargJOx4NefYP4tH+1Wg0pr+/8r6/5LitbyEouGUd7EygZJ1Q
hpOqIQOVErIxmd93u9yXkdUa83JM9I/XMfJjEx3NRbf3c6aD5kPgiI57OnzC
VhpSImSZVUHe2JkEAb1Nkxm+cAkKt34+8J7Ydifv0SCOWhXlxhcTlGmQDCsB
hxC5YVpxpiECMee2gW0rAPrZKrRjrh2SMYAk+F6nPuhCcp+MT0xylnXaC9QV
gj2LyzjPAFCfbCPBZ/IMMAgm7xVRIbn4mUF3LtCUTBCOao3RTakBc0GTG+QC
7MOcpODjdaLoj8soopuxuTjni/he4wx6IVmGUYiHIbfXmhD6i7uWGTk1tVy8
l4FcslQr5ZEAi+kYfNHhLKCXxPzxNiT4Nq4hCEalKaCfFTbDCFI++qrOK+rd
MTSLsjs87ErmpxRop7uSr7fi/zX7+moIXcEIfqEZwK6hbWc6SPUvFqvYBYes
Iru6wRtsge5nEntAskYUg17TOEgds8HL64q9F1PbPeX/AuR/QlRvk1AB1hjT
SjsC3Y6TVB+cWvnW7+i1GHBh7AYglAA6kiX5Nvk5TVmhoOjb7Q5TKehSNq25
xV67bkeFJphwp0Bh0pku1NcLZfVX4thasPYLcHjsBTyENOOLynn8Qz9UtBfb
kFmVSZCgUxl4ruFnCyoDwkxeUs3NCSbdg9tnCJ/4yJeFhyq/zqGLosnkzFQQ
gBhoItVzKhhKH0FzqTPq4aaAbFDNJGaR6z+g2eA5x9HpEQ45HCAt9zmuj4oB
edA0Gn/tKP14entG0x0O48CoPoVp7aN4rlWWio/in9TvfYw+xnFM/+Bbcwg2
9Gjj92ehiQXuHz8ztfY9VxhYN/IgkYtQTQGJ7jU/ojouVVJZnLT3VdIuGHiM
XTnKUGBJmW9EIW25Ybu1UXlFvy2Qt0Mfx1M8Lk4dYFYJifYGRQ35pd4apooi
Mwth5bp7Qy4zeZTZPRISXq8VZfdv9eqdXwZ8KPipHM+9mFGqXZIZV8F1vfAJ
BtndYLyN6yQkLoAjwtGZTK7RTzGThx8KHNS7IFM/O0JwApUMXBqzbbCtNy94
U/fmM01FF5uerQRsdoAySOhTi/9VBTTw8u1Vb+YRbJUnWZXS70CySjU5jq9J
NiHRIlN89vJsmdGqd7VGHSAazu1rYnXJEaj67iRR+qZNFJ3z3OobmXzJN3EM
MIMoXxG8WJWxGZYIWMBLz/l3qlSYqkQyd9yhPR1CR/Re3Z5qdPmCtg1hdbj9
X/VnBBBjU50jUMI+Rz+5QPW4UgQf/wXtrB7mgSAAAA==

-->

</rfc>

