draft-hanson-oauth-session-continuity.xml

<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.6.2 (Ruby 2.6.8) -->


<!DOCTYPE rfc  [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">

<!ENTITY RFC6749 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6749.xml">
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC8174 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY RFC7519 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7519.xml">
<!ENTITY RFC9068 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.9068.xml">
<!ENTITY RFC8693 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8693.xml">
<!ENTITY I-D.wdenniss-oauth-device-posture SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.wdenniss-oauth-device-posture.xml">
<!ENTITY RFC7662 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7662.xml">
]>


<rfc ipr="trust200902" docName="draft-hanson-oauth-session-continuity-latest" category="std" consensus="true" submissionType="IETF">
  <front>
    <title>OAuth 2.0 Session Continuity</title>

    <author initials="J." surname="Hanson" fullname="Jared Hanson">
      <organization>Okta</organization>
      <address>
        <email>jared.hanson@okta.com</email>
      </address>
    </author>
    <author initials="K." surname="McGuinness" fullname="Karl McGuinness">
      <organization>Okta</organization>
      <address>
        <email>kmcguinness@okta.com</email>
      </address>
    </author>

    <date year="2022" month="March" day="17"/>

    <area>Security</area>
    <workgroup>Web Authorization Protocol</workgroup>
    

    <abstract>


<t>This specification defines a mechanism by which an OAuth 2.0 authorization
server can maintain a logical authorization session in which protected resources
can be accessed over a period time.  This specification also extends existing
OAuth 2.0 endpoints so that dynamic context about the session, such as user
location or device health, can be communicated to the authorization server
throughout the lifetime of the session.  Combined, this functionality provides
a lightweight approach to continuous authorization.</t>



    </abstract>



  </front>

  <middle>


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

<t>In OAuth 2.0 <xref target="RFC6749"/>, an authorization server issues an access token and
refresh token to a client.  The client uses the access token to access protected
resources hosted by a resource server, and uses the refresh token to obtain
access tokens from the authorization server.  While the authorization server,
client, and resource server are separate entities, the usage of the access token
and refresh token forms a logical authorization session shared between each
entity.</t>

<t>The access token and refresh token are issued by the authorization server after
authenticating the resource owner and obtaining authorization.  Authorization is
typically obtained by interacting with the resource owner via the authorization
endpoint.  Once authorization has been obtained, issuance of the tokens
initiates an ongoing session in which protected resources may be accessed over
a period of hours or even days.</t>

<t>During this time, the status of the resource owner and her device, such as role,
location, or security posture, may change.  Increasingly, access to protected
resources needs to be based on this dynamically changing context.  However,
typical OAuth deployments evaluate this context infrequently - often only at
session initiation.</t>

<t>This specification provides mechanisms by which an OAuth deployment can both
increase the frequency of access policy evaluation during a session, as well as
increase awareness of dynamically changing context about the session used to
inform policy decisions.  Combined, this functionality provides a lightweight
approach to continuous authorization.</t>

<section anchor="client-profiles"><name>Client Profiles</name>

<t>This specification has been designed around the client profiles defined in
Section 2.1 of <xref target="RFC6749"/>:</t>

<dl newline="true">
  <dt>web application:</dt>
  <dd>
    <t>A web application is a confidential client running on a web server.  Resource
owners access the client via an HTML user interface rendered in a user-agent on
the device used by the resource owner.  The client credentials as well as any
access token issued to the client are stored on the web server and are not
exposed to or accessible by the resource owner.</t>
  </dd>
  <dt>user-agent-based application:</dt>
  <dd>
    <t>A user-agent-based application is a public client in which the client code is
downloaded from a web server and executes within a user-agent (e.g., web
browser) on the device used by the resource owner.  Protocol data and
credentials are easily accessible (and often visible) to the resource owner.
Since such applications reside within the user-agent, they can make seamless use
of the user-agent capabilities when requesting authorization.</t>
  </dd>
  <dt>native application:</dt>
  <dd>
    <t>A native application is a public client installed and executed on the device
used by the resource owner.  Protocol data and credentials are accessible to the
resource owner.  It is assumed that any client authentication credentials
included in the application can be extracted.  On the other hand, dynamically
issued credentials such as access tokens or refresh tokens can receive an
acceptable level of protection.  At a minimum, these credentials are protected
from hostile servers with which the application may interact.  On some
platforms, these credentials might be protected from other applications residing
on the same device.</t>
  </dd>
</dl>

</section>
<section anchor="token-locality"><name>Token Locality</name>

<t>After obtaining approval of the end-user via interaction within the end-user's
user-agent, OAuth issues delegation-specific access tokens and refresh tokens to
clients.  This specification defines two token localities, based on where tokens
reside relative to the user-agent in which the issuance was approved:</t>

<dl newline="true">
  <dt>off device:</dt>
  <dd>
    <t>A token is off device when it resides with an application that is not located
on the same device as the end-user's user-agent.  Tokens issued to a web
application are off device, as the application runs on a web server acceessed
remotely via the user-agent.</t>
  </dd>
  <dt>on device:</dt>
  <dd>
    <t>A token is on device when it resides with an application that is located on
the same device as the end-user's user-agent.  Tokens issued to native
native applications and user-agent-based applications are on device, as the
application is executing either on the device or within the user-agent itself.</t>
  </dd>
</dl>

</section>
<section anchor="notational-conventions"><name>Notational Conventions</name>

<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" 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>

</section>
</section>
<section anchor="json-web-token-claims"><name>JSON Web Token Claims</name>

<t>Access tokens and refresh tokens are opaque, and can have different formats,
structures, and methods of utilization based on resource server and
authorization server security requirements.  Although the mechanisms described
herein can be used with any type of token, this section defines claims to
express such semantics specifically for JSON Web Token (JWT) <xref target="RFC7519"/>.
Similar definitions for other types of tokens are possible but beyond the scope
of this specification.</t>

<section anchor="access-tokens"><name>Access Tokens</name>

<t>JSON Web Token Profile for OAuth 2.0 Access Tokens <xref target="RFC9068"/> defines a
profile for issuing OAuth 2.0 access tokens in JSON Web Token (JWT) format.
OAuth 2.0 deployments implementing this specification MAY issue access tokens
in conformance that profile.  Deployments that do not issue access tokens in
conformance with that profile SHOULD include semantically equivalent claims in
a deployment-specific token format.</t>

<t>The following additional claims SHOULD be included to facilitate session
continuity.</t>

<t>sid - as defined in Section 3 of OpenID.FrontChannel.</t>

</section>
<section anchor="refresh-tokens"><name>Refresh Tokens</name>

<t>Unlike access tokens, refresh tokens are intended only for use with
authorization servers.  Thus, their format is an internal implementation detail
of an authorization server and there is little need for a profile to establish
interoperability between implementations.</t>

<t>OAuth 2.0 deployments implementing this specification MAY issue refresh tokens
in JWT format.  Implementations that issue refresh tokens in JWT format SHOULD
include the following claims.</t>

<t>iss - as defined in Section 4.1.1 of <xref target="RFC7519"/>.</t>

<t>exp - as defined in Section 4.1.4 of <xref target="RFC7519"/>.</t>

<t>aud - as defined in Section 4.1.3 of <xref target="RFC7519"/>.</t>

<t>sub - as defined in Section 4.1.2 of <xref target="RFC7519"/>.</t>

<t>client_id - as defined in Section 4.3 of <xref target="RFC8693"/>.</t>

<t>iat - as defined in Section 4.1.6 of <xref target="RFC7519"/>.  This claim identifies the
time at which the JWT refresh token was issued.</t>

<t>jti - as defined in Section 4.1.7 of <xref target="RFC7519"/>.</t>

<t>sid - as defined in Section 3 of OpenID.FrontChannel.</t>

<t>This specification registers the "application/rt+jwt" media type, which can be
used to indicate that the content is a JWT refresh token.  JWT refresh tokens
MUST include this media type in the "typ" header parameter to explicitly declare
that the JWT represents a refresh token.</t>

<t>Deployments that do not issue refresh tokens in JWT format SHOULD include
semantically equivalent claims in a deployment-specific token format.</t>

</section>
</section>
<section anchor="session-continuity"><name>Session Continuity</name>

<t>An authorization server can issue an access token and, optionally, a refresh
token in response to any authorization grant defined by <xref target="RFC7519"/> and subsequent
extensions.  To facilitate session continuity, an authorization server SHOULD
include the "sid" claim in the access token and refresh token, if any.</t>

<t>For example, the client makes the following HTTP request using TLS to the token
endpoint (with extra line breaks for display purposes only):</t>

<figure><artwork><![CDATA[
  POST /token HTTP/1.1
  Host: server.example.com
  Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
  Content-Type: application/x-www-form-urlencoded

  grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA
  &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
]]></artwork></figure>

<section anchor="refreshing-an-access-token"><name>Refreshing an Access Token</name>

</section>
</section>
<section anchor="signal-sharing"><name>Signal Sharing</name>

<section anchor="refreshing-an-access-token-1"><name>Refreshing an Access Token</name>

<section anchor="from-on-device"><name>From On Device</name>

<t>A native application possessing a refresh token that is on device shares signals
by making a refresh request that includes device posture, as defined in section
6 of <xref target="I-D.wdenniss-oauth-device-posture"/>.</t>

<t>For example, the client makes the following HTTP request using transport-layer
security (with extra line breaks for display purposes only):</t>

<figure><artwork><![CDATA[
  POST /token HTTP/1.1
  Host: server.example.com
  Content-Type: application/x-www-form-urlencoded

  grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA
  client_id=s6BhdRkqt3&device_posture=%7B%22screen_lock%22%3Atrue%2C
  %22device_os%22%3A%22iOS%22%2C%22device_os_version%22%3A%2211.1%22
  %7D
]]></artwork></figure>

</section>
<section anchor="from-off-device"><name>From Off Device</name>

<t>A web application posessing a refresh token that is off device shares signals by
making a refresh request that includes user-agent posture, as defined by User
Agent Posture Signals.</t>

<t>For example, the client makes the following HTTP request using transport-layer
security (with extra line breaks for display purposes only):</t>

<figure><artwork><![CDATA[
  POST /token HTTP/1.1
  Host: server.example.com
  Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
  Content-Type: application/x-www-form-urlencoded

  grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA
  client_id=s6BhdRkqt3&user_agent_posture=%7B%22user_agent%22%3A%22Mozilla%2F5.0
  %20%28Macintosh%3B%20Intel%20Mac%20OS%20X%2010_14_5%29%20AppleWebKit%2F537.36
  %20%28KHTML%2C%20like%20Gecko%29%20Chrome%2F75.0.3770.142%20Safari%2F537.36%22
  %2C%22ip_address%22%3A%2293.184.216.34%22%7D
]]></artwork></figure>

<t>The client MUST only include user-agent posture in online access scenarios.
Refresh tokens used in offline scenarios, when the end-user is not present, are
decoupled from the session and lack end-user user agent context.</t>

</section>
</section>
<section anchor="token-introspection"><name>Token Introspection</name>

<section anchor="introspection-request"><name>Introspection Request</name>

<t>A resource server querying for to determine the state of an access token shares
signals by making an by making an introspection request to the introspection
endpoint, as defined in Section 2.1 of <xref target="RFC7662"/>.</t>

<t>In addition to the parameters defined by Section 2.1 of <xref target="RFC7662"/>, the
following parameters are also defined:</t>

<dl>
  <dt>user_agent_posture</dt>
  <dd>
    <t>OPTIONAL. URL-encoded JSON dictionary, containing user-agent posture signals,
as defined by User Agent Posture Signals.</t>
  </dd>
</dl>

<t>For example, the client makes the following HTTP request using transport-layer
security (with extra line breaks for display purposes only):</t>

<figure><artwork><![CDATA[
  POST /introspect HTTP/1.1
  Host: server.example.com
  Accept: application/json
  Content-Type: application/x-www-form-urlencoded
  Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW

  token=mF_9.B5f-4.1JqM&token_type_hint=access_token
  &user_agent_posture=%7B%22user_agent%22%3A%22Mozilla%2F5.0
  %20%28Macintosh%3B%20Intel%20Mac%20OS%20X%2010_14_5%29%20AppleWebKit%2F537.36
  %20%28KHTML%2C%20like%20Gecko%29%20Chrome%2F75.0.3770.142%20Safari%2F537.36%22
  %2C%22ip_address%22%3A%2293.184.216.34%22%7D
]]></artwork></figure>

<t>Note that the locality of an access token is always off device when presented to
a resource server.</t>

</section>
</section>
</section>
<section anchor="comparison-to-caep"><name>Comparison to CAEP</name>

<t>Use of existing endpoints is
intended to provide a lightweight approach to continuous authorization, while
complimenting future protocols that provide real-time access evaluation using a
publish-subscribe approach.</t>

</section>


  </middle>

  <back>

    <references title='Normative References'>

&RFC6749;
&RFC2119;
&RFC8174;
&RFC7519;
&RFC9068;
&RFC8693;
&I-D.wdenniss-oauth-device-posture;
&RFC7662;


    </references>




  </back>

<!-- ##markdown-source:
H4sIAJZ6M2IAA+1a624cN7L+z6fgkWGfBDsz0c2SLcDAkSXLlm1ZtiTDm/0j
cLo5M4x6mp1mt8bjIHmW8yz7ZPtVkX2baSmOs1hgFxvEkvpCsliXr74q9nA4
FLGNUjXXBzLO1aQYzlTqbDq0qixmQ6edM7iKbFqYtDTFcpioQrtCRPg1tfny
QLoiFibLD2SRl67Y3tx8urktXDmeGx57tcww9+mLqxMhClMkuDg/xNxye7Qp
L/388qieX9C6Nj8QUg7xT0qTugP5eiRfsVx8y4v7WuU6bt+2+RRz3xSKr/Rc
meRA/kRvjfym/s/i4Siy8+7kb0byLHpZmjSFNK0F3qg8WX3Su8bNPJqGl5ol
BBZWB9hhVOa0r4XNb6a5LbMD+UmP5SFv03xRBe3/fW4LG9lEiOFwKNXYFbmK
CiGuZsZJl+nITEzkX431xGAlqeRcR9iXcXM5XsrFzEQzqdKWclV7CeF0fqtz
GeEVSJ0W+Ic5EjvFxEn3XRnMDvWEeTPIp6MC+s61s2UeaSdoprGWKsKFwxNL
0yuZ6dzYWBZmrkdS9mxAJc5K/bnQaezw2zhYfioasXE/sxAQ46wsZqqQ8RIG
MZEkL8RA6MeWBR7pStCBdCXt3skS2xSJDUvZHOq6NZGWM62SYjaQQWgYaF6m
JBEELyzPtaoCUpcoZjDZdFatl5iJpp1JO2mvj40e2fkYdokHuI8tT8o0onlU
AtuT+m5NDJ1B4WY6KxaafkqV4YGC4JAgRJgtXVeQkfA+MTdxnGghHsjTtMht
XPL0Qpy2Lf7LL/9zcXK0t7/79NdfB+QMfXuSiMuSHCgNtsPyNxoXaSxyPYGB
Z+EOxFIySoxOCzalDhekZed11p6AXvfXtbuI2l3kzDpSNlxV1U4UJCJR42bS
NSHsmLxVtBeDhnM7v9NuEPfTzCT6zhcGwm/FL70ij0To4s9M5fAP+CNgy2g3
4MlKp6a1+dsSCT9RW/SJzefud4PMzRjIxhpugUEaDiF4zeWIAECvWWllFRKW
TcrKvWvDEtgOf6ZHNDkFSDoN6g6bt4uU3sMCXuH0QtcX5QpsGSeKZUZ7S5Zh
kJcC4asJwWiKhYF39ix0a9S6tKKKfqx1nkare5khxMekpWqxAW9d0ZvBJt49
BMQvDKUq8nObTi2J8jW4BnRcruGaqHENqwANckfYom8hSayWDoY6BsqzQhH8
hBDeW1yhCkR0EK1H0zNdQVSDYblN9KAGsQGt5EIWkRmiqMzxMklJ8D8llD1N
IyQbBwGS5aDxl944TLWO+SH2OFa8wdSLHWCWjclT04YC5mKRV3ahOXKCyQPu
xDpL7HKuCbD1rUpKihmer4Jrk8Jdfy7xBiYeQhkFGTDFhSpEYxK2l0e8nqxR
QWiT9VxP2muE8Uhvixk8gZXjsSBIEi3JJhVa2cTgRhCec6w3pmryC8yy0AlC
2DXzqQVCj5I+zXWf8tYTFoEdJR5MRiBRiRBjx/TYfW1CkZ2EIr4yoTx4II88
kIN3TACTrlfldbBhITOlyFZIhnDaoskEWZgg0JIYdhSgPDx+e7RFmmknpQMh
fjmQty5TkX62sbnxq1iAC0HsJCx6IA7koVy5iRinRGTTCfaMXcH3wvJ5mTJM
Ea3gUTX8XwSHFxxrrg6KRnTCH/jIq6uzt0wbPGhNIBkCNY11zrvBvPRwCNTH
GAAUzRBIBRsxYG43trvpEv4S5HYtR8Liy05Oq1A88JEwmHNRYfMqUHVrnwwh
9EJqC6E/Axz8cCCGn9iMkQP7JRSi2dfQA8GaHe57wxslK8cJMTMva42rLfkj
G1N+QpmxSBOrYszCqVut7kN/BsgRYFPCWFX8d3o0HQ1oiBjndoEH31fq+Bpj
VPwaaF0oZjodm0CDBJ+ESI3avuNMyGB1a/jW95VpVlV5aSgBefxuNOToPXhs
tSFPH6otcYJYBj5+Q8ig5gn5Al4RIWG0FBCpTI1NwkwESoZQjGRMntcCPMUf
t3rdnuv3+62ItJUkZO7GLHFX3eKPqVuuqrulZ69TsTbJacHCISbm5NVUCCBi
6rBoERlI1pqfADopYx+9TDBa2w38H6BM9ASVIdEMfgupAo4I5AbitsBchKBs
b6BK1F1CiqDrEDPHi+U60qxzz1+zQtGeE2TShMAxZOhArgqq6pAJ5+Wc3QNJ
ZlVxTUrnKCJWTTzXx5GPnVYMtrdOjKHiZX7bzs61yFDQM1HtW3HOdcq4tawP
Xq+sdV+nSi74iUMNHZzFp5wrxri3oDWUwoQ4JELappqUvJCDK7YEDB4yLhNQ
14QSs7fCqXrnf51oR5YnA6HOiXWipyzksMpvK5Zb49T0JBQIrr+IrarwYmED
eCd+Y1wo1LwKgZrXlDSgQa4TH4YBTFpB3sHPmtguyNVYOTpeT6B2Mglq9jFe
pRLZPPB4YYqAR8FLqP5ruQcHGIYhlfBeyMXWTUlu31V8S35SlVdfk8kY5kV7
IfLiRrZBNWP7FaR1t5rT2WbMyKHIObwRaF2VEC0RhGDr9Okj/RZ1BFVUmf/P
qMKjbw84u6r+vTPZ+tivd1ApTawgucdqCiZtOEK7KRII1ZuKoAunk4kP03e2
UJ5oUlfulpAA6/tK9AYJa2Fz1A8bZx8vrzYG/rd8d85/X7z48PH04sUx/X35
6vDt2/oPEd64fHX+8e1x81cz8uj87OzFu2M/GHdl55bYODv8ccMX6xvn769O
z98dvt3wAE+Vi43KeUWWfGnDgJHlmmwH0g4zR7kZ+6Tw/Oj93/9/azcw0+2t
LTDTcPFka38XF+QhfjWuU/wl5WvSuFY5E0OwOGRlg1zp2CBuhtRFFR0Bnngg
X1+ev+Nen0e+o0SZORR5+HvYw6bOFLK7F4HSyEzBZWIzmWB27JMAWxVuIFyR
lxFVhM6/O9dgAjFXJHCEpKqba0Ba63SACvW2C+qKk2iGQcQFLDxM8HI59RDV
qsVqBQtSgKkzLfOEEGBgC8vMF+q001DZuFAuVJAasZ4IgcFoc1IV51un54ry
fQuJqdaCJlYV/d3rT1ffB3vuPybjEkObm0TlfhHjQ4qG+kRGYrlarpBobUWf
S8qASxsKHxfZLBC01azgAyjY14e/ECvChYqLF28ad50xQfSnm3tP4Ip1v1dk
raGEKhTnrW5vx61ggF6teMcZtdqt7frdzLOELV23MrpZD0Ho8ay7miBzW65k
OWExdgZp4TLHrRV8P9dylumZicrH9kyhd9RMJwNuBI5XewX7AnkqCATTZe9E
1DVs7bAhAE2DjrTB4DaxSWIXzETi2AQIDPOEVRlXArkEzKBWJEZODY9Q14vm
oASzIrvIISFDUxzLqjjeIXc7z3R6ejw6yTHqCJGU6sT70EVAhMqJPqaJuVnR
1aAPNwj20lgH3CJPQQCyGnvD3LOb0nM/kweFMO9OPYSSEmq3qLgPKFtCIXBX
h1n5WOHGpISGChiO+k4skKptCRWigAEhNo7aNFgNoZX7MmdZN0S7q1Ov7c86
b1dv5L2IjcoZUHh0F6yowPpI2RkZnKQqP3y7qfYp70gQHhPd6RS7o612z6QC
LwLCe8fs9oxR5d3OR2N2esa4cnzvmO2eMZ4mX9/j6rvttZ7sPd3hcQYau2+t
vbW1AhFnTUrfCZoYf2Yg+FAGMzb0mQzTbZQTj/ZsDMv/VJh7l9/vU8+3xXNP
+ZDrqXEFFWwk6kaLxv2QF3/5aVFsILfGxG6RmQZhVz6jitA6xOIxH2B5/+SO
C7UbUx++6/uH/tbuOcH8rXFZ41oLVwX0Bi426AgtRmzTqQhYBmVNOsYjwQ01
dmMNw+SwRCWNX4wyOIenWpFGiPvzwleEWiW3+N0sIL8qCzzoO48Wh3eAHJkj
pLD1k7QBGJxPIdyRr3YjQjXCRCwDuDAIEjPqLjHNsZ/azcbLjicyvCJUnW+q
Cz5LrdrGV31pSTZp6e5jwR742oDHb1QBl66f+K2R14E0lBUo+Z3QAclnRVg6
aPcDqdnlVsDx1dXV+6qfhYRFt67eXlYFsj9eqw6G5HdMCriDg9ySgqDlWt14
OhcblyVqKbMyp2ao4zT4PYrm3377TUj5/hzO/oOXndb8AXAr6GTDFQdV6zjI
HD4T6Jx3HcjnylGf7MvfjtTLi0u1c7J59iVLPx2fzD/M8ff2609CsvOQm/kv
H9qx/Xm4WCyG5G/DMoeHUm80FhjC9r6mmHvWsc01vfGIfjy7zJLPyflz/bcP
H34c/3i59+nz5fj0EGMf5QjYHDB0DcL+bFYUmXu4c/hw+wT/e50/3H4RdoW/
sC96MGaVtLgGE5+0w0S5irk0U+IAlzNFZyK/O+IBnp9Qi+g8BfHjVqHobTwS
vybv5HOWlSPfUHs3FTufkQJEWRYnEBBwo+7Qyn38YO/ErhpfH5t1wTuUHqLK
NafD49ECiQUljQtfwPgJhmECTgN/0rPhtyliPy+G8FSdi7rS+lbHDv99k3//
OV8Nur/mFR91rp4VL7/c7rw+vznZ/OvLxx8+b18lbz6xv9aE4Znbez6LL25+
LnYeeTVfBzU/e7j//OH2NipKEMDrxEY3uIJTo9iFCx9hElyHIdb5Z/hpzi/p
7+2j9tNrornYUP3WFpSCXzTJ/nFbfy3fnUxazrt6GsUGuN9xm9Zb13MB5eIr
PbfVnunzXoTAR/rW5ZDfeO/fCMHq/sOc9F8Pwv88xyYzXrMZV5y7eVB75pn9
YpJEAZ4fjzbZyTcfbj85QzpPC+tmD3cwbvMU+0rwG7fxkzx+86/4t7V5vbV7
/fjh9lNcHGK7GqX/G1PQZDv7o529er43dOLJQbJJRSV+vdTRjfUjj2bwf9w7
2YcIo539/c3R1i5CavNSTZAA6tlCAHGomewaFTN1auqdPN0ZbT3ZHW1v7Y12
dunuSqS1DkeZgHK1WjGPdc8nrMYr5G6Bf7hIp5DHwtUvukSR6TG9P5nwgPrN
ge/7do4WQr87kNQBldACRNaWWVIddbRP7YnvJCq6aSbgH+GELnwp0Trs4E+1
iG36b7UIXzq3kEk56AhlVjtzeJAvKRQpssCEYuLcc9pR9WEJd9JWuafHG9Hg
TZ0p0+6F6QhSY5CnXJ2HNfVaTZ+9B/37e3vbnCZP07qRUk1b1w4dHLtnGoYu
0SBVawI+RaRPCcNM9MWoFOvhJg5k1TAeyY8Xb4ch4n1/DCUU0/QcxJgMGM6i
elwwaHQg1kFY/ruCcGPmr0ViPsLs4ulP/vvbPwq43wLrGOQxeH5y/XT0/PFk
iFL99c9nj/guQ/c1aGnxzIeEB2yiyP9F4T4Ufmfb3YNwgLnsQxXqKCQLtVw/
VQzQ6b9mWvuy0x+EHNk5Atc4DwRHhy/eC4G4oYWq739bX/0aJ+oupv+GjT51
kn/801numyRawHXhjFVncFJykGbhEwVXt5dv/eGsSoa+meT33/oqzAelEvy1
hJsNqQTnM49ampH4BzbST+FRLwAA

-->

</rfc>