IETF-RFC.xml

<?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.34 (Ruby 3.2.10) -->


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

]>


<rfc ipr="trust200902" docName="draft-ietf-ocm-open-cloud-mesh-04" category="std" consensus="true" submissionType="IETF">
  <front>
    <title>Open Cloud Mesh</title>

    <author initials="G." surname="Lo Presti" fullname="Giuseppe Lo Presti">
      <organization>CERN</organization>
      <address>
        <email>giuseppe.lopresti@cern.ch</email>
        <uri>https://cern.ch/lopresti</uri>
      </address>
    </author>
    <author initials="M. B." surname="de Jong" fullname="Michiel de Jong">
      <organization>Ponder Source</organization>
      <address>
        <email>michiel@pondersource.org</email>
        <uri>https://pondersource.com</uri>
      </address>
    </author>
    <author initials="M." surname="Baghbani" fullname="Mahdi Baghbani">
      <organization>Ponder Source</organization>
      <address>
        <email>mahdi@pondersource.org</email>
        <uri>https://pondersource.com</uri>
      </address>
    </author>
    <author initials="M." surname="Nordin" fullname="Micke Nordin">
      <organization>SUNET</organization>
      <address>
        <email>kano@sunet.se</email>
        <uri>https://code.smolnet.org/micke</uri>
      </address>
    </author>

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

    <area>Applications and Real-Time</area>
    
    <keyword>Internet-Draft</keyword>

    <abstract>


<?line 38?>

<t>Open Cloud Mesh (OCM) is a server federation protocol that is used to
notify a Receiving Party that they have been granted access to some
Resource.  It has similarities with authorization flows such as
OAuth, as well as with social internet protocols such as ActivityPub
and email.</t>

<t>A core use case of OCM is when a user (e.g., Alice on System A) wishes
to share a resource (e.g., a file) with another user (e.g., Bob on
System B) without transferring the resource itself or requiring Bob to
log in to System A.</t>

<t>While this scenario is illustrative, OCM is designed to support a
broader range of interactions, including but not limited to file
transfers.</t>

<t>Open Cloud Mesh handles interactions only up to the point where the
Receiving Party is informed of their access to the Resource.  Actual
Resource access is subsequently managed by other protocols, such as
WebDAV.</t>



    </abstract>



  </front>

  <middle>


<?line 60?>

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

<t>Open Cloud Mesh was initially conceived of in 2015 and has been deployed
since 2016.  OCM has been implemented by several platforms, including
CERNBox, Nextcloud, OpenCloud, ownCloud, and Seafile.</t>

<t>The goal of OCM is to provide a secure, scalable, and flexible
infrastructure for securely sharing and collaborating on resources and
has seen wide adoption, not least in the academic sector.</t>

<t>The core idea of OCM is to make it simple for users to do the right
thing.  This is achieved by providing a protocol that abstracts away
security and authentication details from the users to the servers acting
on behalf of the users.  Another important point of the protocol is the
invitation mechanism that lets users connect over established human
relationships and use those connections to establish contact between
their respective OCM servers.</t>

</section>
<section anchor="terms"><name>Terms</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 [RFC2119] [RFC8174] when, and only when,
they appear in all capitals, as shown here.</t>

<t>We define the following concepts, with some non-normative references to
related concepts from OAuth [RFC6749] and elsewhere:</t>

<t><list style="symbols">
  <t><strong>Resource</strong> - The piece of data or interaction to which access is
being granted, including but not limited to: a file or folder, a video
call, a contact, a printer queue, etc.</t>
  <t><strong>Remote Resource</strong> - A Resource provided by the Sending Server.</t>
  <t><strong>Shared Resource</strong> - A Resource shared by an OCM Server, becoming a
Remote Resource if accepted by the Invite Receiver OCM Server.</t>
  <t><strong>Share</strong> - A policy rule stating that certain actors have specific
access rights to a Resource; it MAY also refer to a record in a
database representing this rule.</t>
  <t><strong>Sending Party</strong> - A person or party who is authorized to create
Shares; similar to "Resource Owner" in OAuth [RFC6749], identified by
its OCM Address.</t>
  <t><strong>Receiving Party</strong> - A person, group or party who is granted access
to the Resource through the Share; similar to "Requesting Party / RqP"
in OAuth-UMA, identified by its OCM Address.</t>
  <t><strong>Share Creation Notification</strong> - A server-to-server request from the
sending server to the receiving server, notifying the receiving server
that a Share has been created.</t>
  <t><strong>Sending Server</strong> - The server that:
  <list style="symbols">
      <t>holds the Resource ("file server" or "Entreprise File Sync and Share
(EFSS) server" role),</t>
      <t>provides access to it (by exposing at least one "API"),</t>
      <t>takes the decision to create the Share based on user interface
gestures from the Sending Party (the "Authorization Server" role in
OAuth [RFC6749]),</t>
      <t>takes the decision about authorizing attempts to access the Resource
(the "Resource Server" role in OAuth [RFC6749]),</t>
      <t>sends out Share Creation Notifications when appropriate (see below).</t>
    </list></t>
  <t><strong>Receiving Server</strong> - The server that:
  <list style="symbols">
      <t>receives Share Creation Notifications (see below),</t>
      <t>actively or passively notifies the receiving user or group of any
incoming Share Creation Notification,</t>
      <t>acts as an API client, allowing the receiving user to access the
Resource through an API (e.g., WebDAV [RFC4918]) of the sending
server.</t>
    </list></t>
  <t><strong>Sending Gesture</strong> - A user interface interaction from the Sending
Party to the Sending Server, conveying the intention to create a
Share.</t>
  <t><strong>Share Creation</strong> - The addition of a Share to the database state of
the Sending Server, in response to a successful Sending Gesture or for
another reason.</t>
  <t><strong>Sharing User</strong> - A user providing access to a Resource through a
Share.</t>
  <t><strong>FQDN</strong> - Fully Qualified Domain Name, such as <spanx style="verb">"cloud.example.org"</spanx>.</t>
  <t><strong>OCM Server</strong> - A server that supports OCM.</t>
  <t><strong>OCM API Discovery</strong> - Process of evaluating properties of a Remote
Resource, after establishing contact with an OCM Server.</t>
  <t><strong>Discovering Server</strong> - A server that tries to obtain information in
OCM API Discovery.</t>
  <t><strong>Discoverable Server</strong> - A server that tries to supply information in
OCM API Discovery.</t>
  <t><strong>Federation</strong> - A group of OCM Providers that have established
mutual trust and agree on certain policies for interaction.  A
Federation MAY be facilitated by a Directory Service.</t>
  <t><strong>FQDN</strong> - Fully Qualified Domain Name, such as <spanx style="verb">"cloud.example.com"</spanx>.</t>
  <t><strong>Invite Acceptance Gesture</strong> - Gesture from the Invite Receiver to
the Invite Receiver OCM Server, supplying the Invite Token as well as
the OCM Address of the Invite Sender, effectively allowlisting the
Invite Sender OCM Server for sending Share Creation Notifications to
the Invite Receiver OCM Server.</t>
  <t><strong>Invite Acceptance Response</strong> - HTTP response to the Invite
Acceptance Request.</t>
  <t><strong>Invite Acceptance Request</strong> - API call from the Invite Receiver OCM
Server to the Invite Sender OCM Server, supplying the Invite Token as
well as the OCM Address of the Invite Receiver, effectively
allowlisting the Invite Sender OCM Server for sending Share Creation
Notifications to the Invite Receiver OCM Server.</t>
  <t><strong>Invite Creation Gesture</strong> - Gesture from the Invite Sender to the
Invite Sender OCM Server, resulting in the creation of an Invite
Token.</t>
  <t><strong>Invite Message</strong> - Out-of-band message used to establish contact
between parties and servers in the Invite Flow, containing an Invite
Token (see below) and the Invite Sender's OCM Address.</t>
  <t><strong>Invite Receiver</strong> - The party receiving an Invite, identified by its
OCM Address.</t>
  <t><strong>Invite Receiver OCM Server</strong> - The server holding an address book
used by the Invite Receiver, to which details of the Invite Sender are
to be added.</t>
  <t><strong>Invite Sender</strong> - The party sending an Invite, identified by its
OCM Address.</t>
  <t><strong>Invite Sender OCM Server</strong> - The server holding an address book
used by the Invite Sender, to which details of the Invite Receiver are
to be added.</t>
  <t><strong>Invite String</strong> - A base64 encoded string containing an Invite Token
and the FQDN of an Invite Sender OCM Server joined by an <spanx style="verb">@</spanx>-sign.</t>
  <t><strong>Invite Token</strong> - A hard-to-guess string used in the Invite Flow,
generated by the Invite Sender OCM Server and linked uniquely to the
Invite Sender's OCM Address.</t>
  <t><strong>OCM Address</strong> - identifies a user or group "at" an OCM Server.
The OCM Address contains a server specific Party identifier, a host
locating the OCM Server and an optional port.  The OCM Address is not a
URI as it does not have scheme and the identifier may contain reserved
characters.  <vspace blankLines='1'/>
    <figure><artwork><![CDATA[
  ocm-address = identifier "@" host [ ":" port]
]]></artwork></figure>
  <vspace blankLines='1'/>
The identifier is an opaque, case-sensitive UTF-8 string.  It is
  separated from the host by the last "@" in the OCM Address.  It is
  possible to have multiple @-signs in a OCM-address, e.g. when an
  email address is the local part of the address like
  <spanx style="verb">nomen.nescio@example.org@ocm.example.org</spanx>.  <vspace blankLines='1'/>
host is an IP literal encapsulated within square brackets, an IPv4
  address in dotted decimal form, or a registered name as described in
  [RFC3986].  <vspace blankLines='1'/>
    <figure><artwork><![CDATA[
  host = IP-literal / IPv4address / reg-name
]]></artwork></figure>
  <vspace blankLines='1'/>
The optional port subcomponent can be used to specify a port to use
  for discovery (see Discovery Process).  <vspace blankLines='1'/>
The OCM Server MUST be discoverable at the given host and optional
  port via the Well-Known [RFC8615] path <spanx style="verb">/.well-known/ocm</spanx>.  The OCM
  Address MUST NOT contain a path.</t>
  <t><strong>OCM API Discovery</strong> - Process of evaluating properties of a Remote
Resource, after establishing contact with an OCM Server.</t>
  <t><strong>OCM Server</strong> - A server that has the OCM Provider function.</t>
  <t><strong>Discovering Server</strong> - A server that tries to obtain information in
OCM API Discovery.</t>
  <t><strong>OCM Notification</strong> - A message from the Receiving Server to the
Sending Server or vice versa, using the OCM Notifications endpoint.</t>
  <t><strong>Receiving Party</strong> - A person, group or party who is granted access
to the Resource through the Share; similar to "Requesting Party / RqP"
in OAuth-UMA, identified by its OCM Address.</t>
  <t><strong>Receiving Server</strong> - The server that:
  <list style="symbols">
      <t>receives Share Creation Notifications (see below),</t>
      <t>actively or passively notifies the receiving user or group of any
incoming Share Creation Notification,</t>
      <t>acts as an API client, allowing the receiving user to access the
Resource through an API (e.g., WebDAV [RFC4918]) of the sending
server.</t>
    </list></t>
  <t><strong>Remote Resource</strong> - A Resource provided by the Sending Server.</t>
  <t><strong>Resource</strong> - The piece of data or interaction to which access is
being granted, including but not limited to: a file or folder, a video
call, a contact, a printer queue, etc.</t>
  <t><strong>Sending Gesture</strong> - A user interface interaction from the Sending
Party to the Sending Server, conveying the intention to create a
Share.</t>
  <t><strong>Sending Party</strong> - A person or party who is authorized to create
Shares; similar to "Resource Owner" in OAuth [RFC6749], identified by
its OCM Address.</t>
  <t><strong>Sending Server</strong> - The server that:
  <list style="symbols">
      <t>holds the Resource for instance, a file server,</t>
      <t>provides access to it (by exposing at least one "API"),</t>
      <t>takes the decision to create the Share based on user interface
gestures from the Sending Party (the "Authorization Server" role in
OAuth [RFC6749]),</t>
      <t>takes the decision about authorizing attempts to access the Resource
(the "Resource Server" role in OAuth [RFC6749]),</t>
      <t>sends out Share Creation Notifications when appropriate (see below).</t>
    </list></t>
  <t><strong>Share</strong> - A policy rule stating that certain actors have specific
access rights to a Resource; it MAY also refer to a record in a
database representing this rule.</t>
  <t><strong>Share Creation</strong> - The addition of a Share to the database state of
the Sending Server, in response to a successful Sending Gesture or for
another reason.</t>
  <t><strong>Share Creation Notification</strong> - A server-to-server request from the
sending server to the receiving server, notifying the receiving server
that a Share has been created.</t>
  <t><strong>Share Name</strong> - A human-readable string, provided by the Sending
Party or the Sending Server, to help the Receiving Party understand
which Resource the Share grants access to.</t>
  <t><strong>Share Permissions</strong> - protocol-specific allowances granted to the
Receiving Party on the modes of accessing the Resource.</t>
  <t><strong>Share Requirements</strong> - Protocol-specific restrictions on the modes
of accessing the Resource.</t>
  <t><strong>Shared Resource</strong> - A Resource shared by an OCM Server, becoming a
Remote Resource if accepted by the Invite Receiver OCM Server.</t>
  <t><strong>Sharing User</strong> - A user providing access to a Resource through a
Share.</t>
  <t><strong>Trusted Server</strong> - An OCM Server that is considered trustworthy by
  another OCM Server, based on out-of-band information, federation
  membership or prior interactions, SHOULD be recorded in an internal
  registry of trusted servers, that SHOULD be updated over time based
  on new information.  The registry SHOULD include the FQDN of the
  trusted server and the Public Key used for HTTP Signatures.  It MAY
  also include additional metadata such as the inviteAcceptDialog URL
  or supported capabilities.</t>
  <t><strong>WAYF Page</strong> - A Where-Are-You-From page is a discovery service used
to identify the OCM Server of an Invite Receiver.</t>
</list></t>

<section anchor="functions"><name>Functions</name>

<t>Open Cloud Mesh defines distinct functions.  It is not necessary for an
implementation to provide all of them.  In fact, it may be useful to
have separate implementations for different functions.</t>

<section anchor="ocm-provider"><name>OCM Provider</name>

<t>An OCM Provider is an entity that can take on the two <em>roles</em> of a
<em>Sending Server</em> and a <em>Receiving Server</em>.  An OCM Provider MUST be a
<em>Discoverable Server</em> and SHOULD be able to receive <em>Notifications</em>.</t>

</section>
<section anchor="ocm-directory-service"><name>OCM Directory Service</name>

<t>An OCM Directory Service is an entity that exposes information about a
<em>Federation</em> of OCM Providers.</t>

</section>
</section>
<section anchor="roles"><name>Roles</name>

<t>Open Cloud Mesh defines two distinct roles that an OCM Provider MUST
take on: the <em>Sending Server</em> role and the <em>Receiving Server</em> role.</t>

<section anchor="sending-server"><name>Sending Server</name>

<t>A Sending Server is an OCM Provider that holds Resources and exposes
APIs to allow access to them.  It allows its users to create <em>Shares</em>
to give other users access to those Resources.  A Sending Server MAY
provide its users with the ability to generate <em>Invites</em> to establish
contact with other users on other OCM Providers.  When doing so it MAY
provide a <em>WAYF Page</em> to facilitate the Invite Flow.  The WAYF page MAY
be limited to a set of trusted OCM Providers, for instance those in the
same <em>Federation</em>.</t>

</section>
<section anchor="receiving-server"><name>Receiving Server</name>

<t>A Receiving Server is an OCM Provider that receives <em>Share</em> Creation
Notifications from Sending Servers, notifies its users about incoming
<em>Shares</em>, and acts as an API client to allow its users to access Remote
Resources.  It MAY provide its users with an <em>Address Book</em> of
<em>Contacts</em> and the ability to accept <em>Invites</em>.</t>

<t>In Appendix D, an object model is presented as a non-normative guide for
implementers to understand the relationships between these terms.</t>

</section>
</section>
</section>
<section anchor="general-flow"><name>General Flow</name>

<t>The lifecycle of an Open Cloud Mesh Share starts with prerequisites such
as establishing trust, establishing contact, and OCM API Discovery.</t>

<t>Then the share creation involves the Sending Party making a Sending
Gesture to the Sending Server, the Sending Server carrying out the
actual Share Creation, and the Sending Server sending a Share Creation
Notification to the Receiving Server.</t>

<t>After this, the Receiving Server MAY notify the Receiving Party and/or
the Sending Server, and will act as an API client through which the
Receiving Party can access the Resource.  The Receiving Party or
the Sending Party MAY then update or delete the Share: the respective
Server MAY send a Notification to the other party about the change.</t>

</section>
<section anchor="establishing-contact"><name>Establishing Contact</name>

<t>Before the Sending Server can send a Share Creation Notification to the
Receiving Server, it MUST establish the Receiving Party's OCM
Address (containing the Receiving Server's FQDN, and the Receiving
Party's identifier), among other things.  Some steps may preceed the
Sending Gesture, allowing the Sending Party to establish (with some
level of trust) the OCM Address of the Receiving Party.  In other cases,
establishing the OCM Address of the Receiving Party happens as part of
the Sending Gesture.</t>

<section anchor="direct-entry"><name>Direct Entry</name>

<t>The simplest way for this is if the Receiving Party shares their OCM
Address with the Sending Party through some out-of-band means, and the
Sending Party enters this string into the user interface of the Sending
Server, by means of typing or pasting into an HTML form, or clicking a
link to a URL that includes the string in some form.</t>

</section>
<section anchor="public-link-flow"><name>Public Link Flow</name>

<t>An interface for anonymously viewing a Resource on the Sending Server
MAY allow any internet user to type or paste an OCM address into an HTML
form, as a Sending Gesture.  This means that the Sending Party and the
Receiving Party could be the same person, so contact between them does
not need to be explicitly established.</t>

</section>
<section anchor="public-invite-flow"><name>Public Invite Flow</name>

<t>Similarly, an interface on the Sending Server MAY allow any internet
user to type or paste an OCM address into an HTML form, as a Sending
Gesture for a given Resource, without itself providing a way to access
that particular Resource.  A link to this interface could then for
instance be shared on a mailing list, allowing all subscribers to
effectively request access to the Resource by making a Sending Gesture
to the Sending Server with their own OCM Address.</t>

</section>
<section anchor="invite-flow"><name>Invite Flow</name>

<section anchor="rationale"><name>Rationale</name>

<t>Many methods for establishing contact allow unsolicited contact with the
prospective Receiving Party whenever that party's OCM Address is known.
The Invite Flow requires the Receiving Party to explicitly accept it
before it can be used, which establishes bidirectional trust between the
two parties involved.</t>

<t>OCM Servers MAY enforce a policy to only accept Shares between such
trusted contacts, or MAY display a warning to the Receiving Party when a
Share Creation Notification from an unknown Sending Party is received</t>

</section>
<section anchor="steps"><name>Steps</name>

<t><list style="symbols">
  <t>the Invite Sender OCM Server generates a unique Invite Token and helps
the Invite Sender to create the Invite Message</t>
  <t>the Invite Sender uses some out-of-band communication to send the
Invite Message, containing the Invite Token and the Invite Sender OCM
Server FQDN, to the Invite Receiver</t>
  <t>the Invite Receiver navigates to the Invite Receiver OCM Server and
makes the Invite Acceptance Gesture.  This step MAY be facilitated if
the Invite Sender OCM Server implements a WAYF Page, such that the
Invite Message would include a link to it for the Invite Receiver to
navigate to: the Invite Receiver would then be able to indicate their
OCM Server and proceed with the Invite Acceptance Gsture without
manually copying the Invite Token.</t>
  <t>the Invite Receiver OCM Server discovers the OCM API of the Invite
Sender OCM Server using generic OCM API Discovery (see section below)</t>
  <t>the Invite Receiver OCM Server sends the Invite Acceptance Request to
the Invite Sender OCM Server</t>
</list></t>

</section>
<section anchor="invite-acceptance-request-details"><name>Invite Acceptance Request Details</name>

<t>Whereas the precise syntax of the Invite Message and the Invite
Acceptance Gesture will differ between implementations, the Invite
Acceptance Request SHOULD be a HTTP POST request:</t>

<t><list style="symbols">
  <t>to the <spanx style="verb">/invite-accepted</spanx> path in the Invite Sender OCM Server's OCM
API</t>
  <t>using <spanx style="verb">application/json</spanx> as the <spanx style="verb">Content-Type</spanx> HTTP request header</t>
  <t>its request body containing a JSON document representing an object
with the following string fields:
  <list style="symbols">
      <t>REQUIRED: <spanx style="verb">recipientProvider</spanx> - FQDN of the Invite Receiver OCM
Server.</t>
      <t>REQUIRED: <spanx style="verb">token</spanx> - The Invite Token.  The Invite Sender OCM Server
SHOULD recall which Invite Sender OCM Address this token was linked
to.</t>
      <t>REQUIRED: <spanx style="verb">userID</spanx> - The Invite Receiver's identifier at their OCM
Server.</t>
      <t>REQUIRED: <spanx style="verb">email</spanx> - Non-normative / informational; an email address
for the Invite Receiver.  Not necessarily at the same FQDN as their
OCM Server.</t>
      <t>REQUIRED: <spanx style="verb">name</spanx> - Human-readable name of the Invite Receiver, as a
suggestion for display in the Invite Sender's address book</t>
    </list></t>
  <t>using TLS</t>
  <t>using httpsig [RFC9421]</t>
</list></t>

<t>The Invite Receiver OCM Server SHOULD apply its own policies for
trusting the Invite Sender OCM Server before making the Invite
Acceptance Request.</t>

<t>Since the Invite Flow does not require either Party to type or remember
the <spanx style="verb">userID</spanx>, this string does not need to be human-memorable.  Even if
the Invite Receiver has a memorable username at the Invite Receiver OCM
Server, this <spanx style="verb">userID</spanx> that forms part of their OCM Address does not need
to match it.</t>

<t>Also, a different <spanx style="verb">userID</spanx> could be given out to each contact, to avoid
correlation of identities.</t>

<t>If the Invite Sender OCM Server implements a WAYF Page, such a page MAY
include a fixed list of servers, in addition to, or instead of, a
free-text input where any OCM Server can be entered.  This is especially
useful if the Invite Sender is part of a federation of associated OCM
Servers.  In order to populate the list of associated OCM Servers, the
Invite Sender's server MAY make use of a Directory Service, which is
expected to follow the specification detailed in Appendix C.</t>

<t>Implementors that provide a WAYF Page SHOULD make the URL for the API
endpoint of such a Directory Service configurable, allowing the OCM
Server to be part of a network of associated OCM Servers.  The
configuration mechanism MAY allow an OCM Server to be part of multiple
networks, thus displaying a union of multiple lists in its WAYF Page.</t>

</section>
<section anchor="invite-acceptance-response-details"><name>Invite Acceptance Response Details</name>

<t>The Invite Acceptance Response SHOULD be a HTTP response:</t>

<t><list style="symbols">
  <t>in response to the Invite Acceptance Request</t>
  <t>using <spanx style="verb">application/json</spanx> as the <spanx style="verb">Content-Type</spanx> HTTP response header</t>
  <t>its response body containing a JSON document representing an object
with the following string fields:
  <list style="symbols">
      <t>REQUIRED: <spanx style="verb">userID</spanx> - the Invite Sender's identifier at their OCM
Server</t>
      <t>REQUIRED: <spanx style="verb">email</spanx> - non-normative / informational; an email address
for the Invite Sender.  Not necessarily at the same FQDN as their
OCM Server</t>
      <t>REQUIRED: <spanx style="verb">name</spanx> - human-readable name of the Invite Sender, as a
suggestion for display in the Invite Receiver's address book</t>
    </list></t>
</list></t>

<t>A 200 response status means the Invite Acceptance Request was
successful.
A 400 response status means the Invite Token is invalid or does not
exist.
A 403 response status means the Invite Receiver OCM Server is not
trusted to accept this Invite.
A 409 response status means the Invite was already accepted.</t>

<t>The Invite Sender OCM Server SHOULD verify the HTTP Signature on the
Invite Acceptance Request and apply its own policies for trusting the
Invite Receiver OCM Server before processing the Invite Acceptance
Request and sending the Invite Acceptance Response.</t>

<t>As with the <spanx style="verb">userID</spanx> in the Invite Acceptance Request, the one in the
Response also doesn't need to be human-memorable, doesn't need to match
the Invite Sender's username at their OCM Server.</t>

</section>
<section anchor="addition-into-address-books"><name>Addition into address books</name>

<t>Following these step, both servers MAY display the <spanx style="verb">name</spanx> of the other
party as a trusted or allowlisted contact, and enable selecting them as
a Receiving Party.  OCM Servers MAY enforce a policy to only accept
Share Creation Notifications from such trusted contacts, or MAY display
a warning to users when a Share Creation Notification from an unknown
party is received.</t>

<t>Both servers MAY also allowlist each other as a server with which at
least one of their users wishes to interact.</t>

<t>In addition, if the identity provider of either server supports the
registration of external users, it may happen that the just received
email contact from the other party matches an external user already
known in the local identity provider, and therefore already present
in the address book.  In such a case, implementers MAY support linking
of the two identities belonging to that same user, so that when a Share
Creation gesture is made to that recipient, both a regular share and an
OCM Share Creation Notification are issued.</t>

<t>Note that Invites act symmetrically, so once contact has been
established, both the Invite Sender and the Invite Receiver MAY take on
either the Sending Party or the Receiving Party role in subsequent
Share Creation events.</t>

<t>Both parties MAY delete the other party from their address book at any
time without notifying them.</t>

</section>
<section anchor="invite-format"><name>Invite format</name>
<t>To accept an invite, two pieces of information are required: a <spanx style="verb">token</spanx>
and a <spanx style="verb">provider</spanx>.  There are two recognized formats:</t>

<t><list style="symbols">
  <t><strong>Invite string format:</strong>
A base64-encoded string containing the token and the provider’s FQDN,
joined by an <spanx style="verb">@</spanx> sign.  Example:  <vspace blankLines='1'/>
If the <spanx style="verb">token</spanx> is <spanx style="verb">a55a966e-15c1-4cb9-a39d-4e4c54399baf</spanx> and the
<spanx style="verb">provider</spanx> is <spanx style="verb">cloud.example.org</spanx>, the combined string is
<spanx style="verb">a55a966e-15c1-4cb9-a39d-4e4c54399baf@cloud.example.org</spanx>,
which when base64-encoded becomes
<spanx style="verb">YTU1YTk2NmUtMTVjMS00Y2I5LWEzOWQtNGU0YzU0Mzk5YmFmQG15LWNsb3VkLXN0b
3JhZ2Uub3Jn</spanx>.  <vspace blankLines='1'/>
When parsing an invite string, implementors must base64-decode it,
then split on the last <spanx style="verb">@</spanx> sign, taking care to allow multiple <spanx style="verb">@</spanx>
characters in the token part.</t>
  <t><strong>Link format:</strong>
If the inviting OCM Server supports a WAYF page, the invite may be
provided as a link with the token as a request parameter.  Example:  <vspace blankLines='1'/>
<spanx style="verb">https://cloud.example.org/wayf?token=
a55a966e-15c1-4cb9-a39d-4e4c54399baf</spanx></t>
</list></t>

<t>Implementations MUST be able to accept invites in the invite string
format.  This format is considered canonical.  The link format is only
useful if the Receiving OCM Server exposes the <spanx style="verb">inviteAcceptDialog</spanx>
in its Discovery endpoint.  Implmentations SHOULD support the link
format when they implement a WAYF Page that leverages those
<spanx style="verb">inviteAcceptDialog</spanx> targets.</t>

</section>
<section anchor="security-advantages"><name>Security Advantages</name>

<t>It is important to underscore the value of the Invite in this scenario,
as it provides four important security advantages.  First of all, if the
Receiving Server blocks Share Creation Notifications from Sending
Parties who are not in the address book of the Receiving Party, then
this protects the Receiving Party from receiving unsolicited Shares.  An
attacker could still send the Receiving Party an unsolicited Share, but
they would first need to convince the Receiving Party through an
out-of-band communication channel to accept their invite.  In many use
cases, the Receiving Party has had other forms of contact with the
Sending Party (e.g., in-person or email back-and-forth).  The
out-of-band Invite Message thus leverages the filters and context which
the Receiving Party may already benefit from in that out-of-band
communication.  For instance, a careful Receiving Party MAY choose to
only accept Invites that reach them via a private or moderated
messaging platform.</t>

<t>Second, when the Receiving Party accepts the Invite, the Receiving
Server knows that the Sending Server they are about to interact with is
trusted by the Sending Party, which in turn is trusted by the Receiving
Party, which in turn is trusted by them.  In other words, one of their
users is requesting the allowlisting of a server they wish to interact
with, in order to interact with a party they know out-of-band.  This
gives the Receiving Server reason to put more trust in the Sending
Server than it would put into an arbitrary internet-hosted server.</t>

<t>Third, equivalently, the Sending Server knows it is essentially
registering the Receiving Server as an API client at the request of the
Receiving Party, to whom the right to request this has been traceably
delegated by the Sending Party, which is one of its registered users.</t>

<t>Fourth, related to the second one, it removes the partial 'open relay'
problem that exists when the Sending Server is allowed to include any
Receiving Server FQDN in the Sending Gesture.  Without the use of
Invites, a Distributed Denial of Service attack could be organised if
many internet users collude to flood a given OCM Server with Share
Creation Notifications which will be hard to distinguish from
legitimate requests without human interaction.  An unsolicited (invalid)
Invite Acceptance Request is much easier to filter out than an
unsolicited (possibly valid, possibly invalid) Share Creation
Notification Request, since the Invite Acceptance Request needs to
contain an Invite Token that was previously uniquely generated at the
Invite Sender OCM server.</t>

</section>
</section>
</section>
<section anchor="ocm-api-discovery"><name>OCM API Discovery</name>

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

<t>After establishing contact as discussed in the previous section, the
Sharing User MAY send the Share Creation Gesture to the Sending Server.
The Sharing User MUST provide the following information:</t>

<t><list style="symbols">
  <t>Resource to be shared</t>
  <t>Protocol to be offered for access</t>
  <t>Sending Party's identifier</t>
  <t>Receiving Party's identifier</t>
  <t>Receiving Server FQDN</t>
  <t>OPTIONAL: Share Requirements</t>
  <t>OPTIONAL: Share Name</t>
  <t>OPTIONAL: Share Permissions</t>
</list></t>

<t>The next step is for the Sending Server to additionally discover:</t>

<t><list style="symbols">
  <t>if the Receiving Server is trusted</t>
  <t>if the Receiving Server supports OCM</t>
  <t>if so, which version and with which optional functionality</t>
  <t>at which URL</t>
  <t>the public key the Receiving Server will use for HTTP Signatures (if
any)</t>
</list></t>

<t>The Sending Server MAY first perform denylist and allowlist checks on
the FQDN.</t>

<t>If a finite allowlist of Receiving Servers exists on the Sending Server
side, then this list MAY already contain all necessary information.</t>

<t>If the FQDN passes the denylist and/or allowlist checks, but no details
about its OCM API are known, the Sending Server can use the following
process to try to fetch this information from the Receiving Server.</t>

<t>This process MAY be influenced by a VPN connection and/or IP
allowlisting.</t>

<t>When OCM API Discovery can occur in preparation of a Share Creation
Notification, the Sending Server takes on the 'Discovering Server' role
and the Receiving Server plays the role of 'Discoverable Server'.</t>

</section>
<section anchor="process"><name>Process</name>

<t>At the start of the process, the Discovering Server has either an OCM
Address, or just an FQDN from for instance the <spanx style="verb">recipientProvider</spanx>
field of an Invite Acceptance Request.</t>

<t>Step 1: In case it has an OCM Address, it SHOULD first extract <spanx style="verb">&lt;fqdn&gt;</spanx>
from it (the part after the last <spanx style="verb">@</spanx> sign).
Step 2: The Discovering Server SHOULD attempt OCM API Discovery via a
HTTP GET request to <spanx style="verb">https://&lt;fqdn&gt;/.well-known/ocm</spanx>.
Step 3: If that results in a valid HTTP response with a valid JSON
response body within reasonable time, go to step 7.
Step 4: If not, try a HTTP GET with <spanx style="verb">https://&lt;fqdn&gt;/ocm-provider</spanx> as
the URL instead.
Step 5: If that results in a valid HTTP response with a valid JSON
response body within reasonable time, go to step 7.
Step 6: If not, fail.  Implementations MAY fallback to HTTP instead
of HTTPS in testing setups and retry steps 2-5, in particular when
an optional port is given in the address.
Step 7: The JSON response body is the data that was discovered.</t>

</section>
<section anchor="fields"><name>Fields</name>

<t>The JSON response body offered by the Discoverable Server SHOULD
contain the following information about its OCM API:</t>

<t><list style="symbols">
  <t>REQUIRED: enabled (boolean) - Whether the OCM service is enabled at
this endpoint</t>
  <t>REQUIRED: apiVersion (string) - The OCM API version this endpoint
supports.  Example: <spanx style="verb">"1.3.0"</spanx></t>
  <t>REQUIRED: endPoint (string) - The URI of the OCM API available at
this endpoint.  Example: <spanx style="verb">"https://cloud.example.org/ocm"</spanx></t>
  <t>OPTIONAL: provider (string) - A friendly branding name of this
endpoint.  Example: <spanx style="verb">"MyCloudStorage"</spanx></t>
  <t>REQUIRED: resourceTypes (array) - A list of all resource types this
server supports in both the Sending Server role and the Receiving
Server role, with their access protocols.  Each item in this list
MUST itself be an object containing the following fields:
  <list style="symbols">
      <t>name (string) - A supported resource type (file, calendar,
contact, ...).
Implementations MUST offer support for at least one
resource type, where <spanx style="verb">file</spanx> is the commonly supported
one.  Each resource type is identified by its <spanx style="verb">name</spanx>:
the list MUST NOT contain more than one resource type
object per given <spanx style="verb">name</spanx>.</t>
      <t>shareTypes (array of string) -
The supported recipient share types.  MUST contain
<spanx style="verb">"user"</spanx> at a minimum, plus optionally <spanx style="verb">"group"</spanx> and
<spanx style="verb">"federation"</spanx>.
Example: <spanx style="verb">["user"]</spanx></t>
      <t>protocols (object) - The supported protocols for accessing Shared
Resources of this type.  Implementations that offer <spanx style="verb">file</spanx>
Resources MUST support at least <spanx style="verb">webdav</spanx>, any other combination
of Resources and protocols is optional.  Example:      <vspace blankLines='1'/>
        <figure type="json"><artwork><![CDATA[
        {
          "webdav": "/remote/dav/ocm/",
          "webapp": "/app/ocm/",
          "talk": "/apps/spreed/api/"
        }
]]></artwork></figure>
      <vspace blankLines='1'/>
Fields:
- webdav (string) - The top-level WebDAV [RFC4918] path at this
  endpoint.  In order to access a Remote Resource, implementations
  SHOULD use this path as a prefix (see sharing examples).
- webapp (string) - The top-level path for web apps at this
  endpoint.  In order to access a remote web app, implementations
  SHOULD use this path as a prefix (see sharing examples).
- ssh (string) - The top-level address in the form <spanx style="verb">host:port</spanx>
  of an endpoint that supports ssh and scp with a public/private
  key based authentication.
- Any additional protocol supported for this Resource type MAY be
  advertised here, where the value MAY correspond to
  a top-level URI to be used for that protocol.</t>
    </list></t>
  <t>OPTIONAL: capabilities (array of string) - The optional capabilities
supported by this OCM Server.
As implementations MUST accept Share Creation Notifications
to be compliant, it is not necessary to expose that as a
capability.
Example: <spanx style="verb">["exchange-token", "webdav-uri"]</spanx>.  The array MAY
include one or more of the following items:
  <list style="symbols">
      <t><spanx style="verb">"enforce-mfa"</spanx> - to indicate that this OCM Server can apply a
Sending Server's MFA requirements for a Share on their behalf.</t>
      <t><spanx style="verb">"exchange-token"</spanx> - to indicate that this OCM Server exposes a
[RFC6749]-compliant endpoint, which allows to exchange a secret
received in the protocol properties of a Share Creation Notification
for a short-lived bearer token.</t>
      <t><spanx style="verb">"http-sig"</spanx> - to indicate that this OCM Server supports
[RFC9421] HTTP Message Signatures and advertises public keys in the
format specified by [RFC7517] at the <spanx style="verb">/.well-known/jwks.json</spanx>
endpoint for signature verification.</t>
      <t><spanx style="verb">"invites"</spanx> - to indicate the server would support acting as an
Invite Sender or Invite Receiver OCM Server.  This might be useful
for suggesting to a user that existing contacts might be upgraded
to the more secure (and possibly required) invite flow.</t>
      <t><spanx style="verb">"notifications"</spanx> - to indicate that this OCM Server handles
notifications to exchange updates on shares and invites.</t>
      <t><spanx style="verb">"invite-wayf"</spanx> - to indicate that this OCM Server exposes a WAYF
Page to facilitate the Invite flow.</t>
      <t><spanx style="verb">"webdav-uri"</spanx> - to indicate that this OCM Server can append a
relative URI to the path listed for WebDAV [RFC4918] in the
appropriate <spanx style="verb">resourceTypes</spanx> entry</t>
      <t><spanx style="verb">"protocol-object"</spanx> - to indicate that this OCM Server can
receive a Share Creation Notification whose <spanx style="verb">protocol</spanx> object
contains one property per supported protocol instead of containing
the standard <spanx style="verb">name</spanx> and <spanx style="verb">options</spanx> properties.</t>
    </list></t>
  <t>OPTIONAL: criteria (array of string) - The criteria for accepting a
Share Creation Notification.
As all Receiving Servers SHOULD require the use of TLS in API
calls, it is not necessary to expose that as a criterium.
Example: <spanx style="verb">["http-request-signatures"]</spanx>.  The array MAY include
for instance:
  <list style="symbols">
      <t><spanx style="verb">"http-request-signatures"</spanx> - to indicate that API requests
without http signatures will be rejected.</t>
      <t><spanx style="verb">"token-exchange"</spanx> - to indicate that API requests without
token exchange will be rejected (see the <xref target="code-flow">Code Flow</xref>
section).</t>
      <t><spanx style="verb">"denylist"</spanx> - some servers MAY be blocked based on their IP
address</t>
      <t><spanx style="verb">"allowlist"</spanx> - unknown servers MAY be blocked based on their IP
address</t>
      <t><spanx style="verb">"invite"</spanx> - an invite MUST have been exchanged between the
sender and the receiver before a Share Creation Notification can be
sent</t>
    </list></t>
  <t>DEPRECATED: publicKey (object) - Use public keys at
<spanx style="verb">/.well-known/jwks.json</spanx> instead for RFC 9421 support.</t>
  <t>OPTIONAL: inviteAcceptDialog (string) - URL path of a web page where
a user can accept an invite, when query parameters <spanx style="verb">"token"</spanx> and
<spanx style="verb">"providerDomain"</spanx> are provided.  Implementations that offer the
<spanx style="verb">"invites"</spanx> capability SHOULD provide this URL as well in order to
enhance the UX of the Invite Flow.  If for example
<spanx style="verb">"/index.php/apps/sciencemesh/accept"</spanx> is specified here then a WAYF
Page SHOULD redirect the end-user to <spanx style="verb">/index.php/apps/sciencemesh/
accept?token=zi5kooKu3ivohr9a&amp;providerDomain=cloud.example.org</spanx>.</t>
  <t>OPTIONAL: tokenEndPoint (string) - URL of the token endpoint where the
Sending Server can exchange a secret for a short-lived bearer token.
Implementations that offer the <spanx style="verb">"exchange-token"</spanx> capability MUST
provide this URL as well.
Example: <spanx style="verb">"https://cloud.example.org/ocm/token"</spanx>.</t>
</list></t>

</section>
</section>
<section anchor="share-creation-notification"><name>Share Creation Notification</name>

<t>To create a Share, the Sending Server SHOULD make a HTTP POST request</t>

<t><list style="symbols">
  <t>to the <spanx style="verb">/shares</spanx> path in the Receiving Server's OCM API</t>
  <t>using <spanx style="verb">application/json</spanx> as the <spanx style="verb">Content-Type</spanx> HTTP request header</t>
  <t>its request body containing a JSON document representing an object
with the fields as described below</t>
  <t>using TLS</t>
  <t>using httpsig [RFC9421]</t>
</list></t>

<section anchor="fields-1"><name>Fields</name>

<t><list style="symbols">
  <t>REQUIRED shareWith (string)
OCM Address of the user, group or federation the provider
wants to share the Resource with.  This MUST be known
in advance, either via a previous Invitation or through
other means.
Example: "51dc30ddc473d43a6011e9ebba6ca770@geant.org"</t>
  <t>REQUIRED name (string)
Name of the Resource (file or folder).
Example: "resource.txt"</t>
  <t>OPTIONAL description (string)
Optional description of the Resource (file or folder).
Example: "This is the Open API Specification file (in YAML
format) of the Open Cloud Mesh API."</t>
  <t>REQUIRED providerId (string)
Opaque value to identify the Shared Resource at the provider side.
This MUST be unique per Resource and per share, such that multiple
shares of a given Resource are guaranteed to get different values.
Example: 7c084226-d9a1-11e6-bf26-cec0c932ce01</t>
  <t>REQUIRED owner (string) -
OCM Address of the user who owns the
Resource.
Example: "6358b71804dfa8ab069cf05ed1b0ed2a@apiwise.nl"</t>
  <t>REQUIRED sender (string) -
OCM Address of the user that wants to share
the Resource.
Example: "527bd5b5d689e2c32ae974c6229ff785@apiwise.nl"</t>
  <t>OPTIONAL ownerDisplayName (string)
Display name of the owner of the Resource
Example: "Dimitri"</t>
  <t>OPTIONAL senderDisplayName (string)
Display name of the user that wants to share the Resource
Example: "John Doe"</t>
  <t>REQUIRED shareType (string)
SHOULD have a value of "user", "group", or "federation", to
indicate that the first part of the <spanx style="verb">shareWith</spanx> OCM Address refers
to a Receiving Party who is a single user of the Receiving Server,
a group of users at the Receiving Server, or a group of users that
spans multiple OCM Servers belonging to a federation as exposed by
a Directory Service, including at least one user at the Receiving
Server.
In the federation case, OCM Servers MAY resolve the actual
recipients by either querying external AAI systems, or exchanging
the groups' metadata between themselves.  Such exchange is out of
scope for this version of the this specification.
Alternatively, the Receiving Server MAY hold the federated groups'
metadata and act as an OCM proxy, forwarding the OCM requests to
the actual members of the federation.</t>
  <t>REQUIRED resourceType (string)
Resource type (file, folder, calendar, contact, ...).  If the
Resource is a folder, implementations SHOULD advertise it as
<spanx style="verb">folder</spanx> rather than <spanx style="verb">file</spanx>, in order to streamline the processing
by the Receiving Server.</t>
  <t>OPTIONAL expiration (integer)
The expiration time for the OCM share, in seconds
of UTC time since Unix epoch.  If omitted, it is assumed that the
share does not expire.  A sender server MAY use it to signal that
the resource represents a cached copy of a dataset that was made
available for an efficient data transfer to the destination server.</t>
  <t>REQUIRED protocol (object)
JSON object with specific options for each protocol.
The supported protocols are: - <spanx style="verb">webdav</spanx>, to access the data -
<spanx style="verb">webapp</spanx>, to access remote web applications - <spanx style="verb">ssh</spanx>, to access
the data via a public/private key pair.
Other custom protocols might be added in the future.
In case a single protocol is offered, there are three ways to
specify this object:
Option 1: Set the <spanx style="verb">name</spanx> field to the name of the protocol,
and put the protocol details in a field named <spanx style="verb">options</spanx>.
Option 2: Set the <spanx style="verb">name</spanx> field to the name of the protocol,
and put the protocol details in a field carrying the name of
the protocol.
Option 3: Set the <spanx style="verb">name</spanx> field to <spanx style="verb">multi</spanx>, and put the
protocol details in a field carrying the name of the protocol.
Option 1 using the <spanx style="verb">options</spanx> field is now deprecated.
Implementations are encouraged to transition to the new
optional properties defined below, such that this field
may be removed in a future major version of the spec.
When specifying more than one protocol as different ways to
access the Share, the <spanx style="verb">name</spanx> field needs to be set to <spanx style="verb">multi</spanx>.
If <spanx style="verb">multi</spanx> is given, one or more protocol
endpoints are expected to be defined according to the
optional properties specified below.
Otherwise, at least <spanx style="verb">webdav</spanx> is expected to be
supported, and its options MAY be given in the opaque
<spanx style="verb">options</spanx> payload for compatibility with v1.0
implementations (see examples).  Note though that this
format is deprecated.
Warning: client implementers should be aware that v1.1+
servers MAY support both <spanx style="verb">webdav</spanx> and <spanx style="verb">multi</spanx>, but v1.0
servers MAY only support <spanx style="verb">webdav</spanx>.</t>
  <t>Protocol details for <spanx style="verb">webdav</spanx> MAY contain:
  <list style="symbols">
      <t>OPTIONAL accessTypes (array of strings) - The type of access
being granted to the remote resource.  If omitted, it defaults to
<spanx style="verb">['remote']</spanx>.  A subset of:
      <list style="symbols">
          <t><spanx style="verb">remote</spanx> signals the recipient that the resource is available
for remote access and interactive browsing.</t>
          <t><spanx style="verb">datatx</spanx> signals the recipient that the resource is
available for data transfer.  If no expiration is given, the share
is suitable e.g. for sync use-cases, whereas if an expiration date
is set, the above clause MAY apply and the recipient SHOULD notify
the sender upon completing the data transfer, in order to ease
cache operations on the Sending Server.  The recipient MAY delegate
a third-party service to execute the data transfer on their behalf.</t>
        </list></t>
      <t>REQUIRED uri (string)
A URI to access the Remote Resource.  The URI
SHOULD be relative, in which case the prefix
exposed by the <spanx style="verb">/.well-known/ocm</spanx> endpoint MUST
be used.  Absolute URIs are deprecated.</t>
      <t>REQUIRED sharedSecret (string)
A secret to be used to access the Resource, such as
a bearer token.  To prevent leaking it in logs it
MUST NOT appear in any URI.</t>
      <t>OPTIONAL permissions (array of strings) -
The permissions granted to the sharee.  A subset of:
      <list style="symbols">
          <t><spanx style="verb">read</spanx> allows read-only access including download of a copy.</t>
          <t><spanx style="verb">write</spanx> allows create, update, and delete rights on the Resource.</t>
          <t><spanx style="verb">share</spanx> allows re-share rights on the Resource.</t>
        </list></t>
      <t>OPTIONAL requirements (array of strings) -
The requirements that the sharee MUST fulfill to
access the Resource.  A subset of:
      <list style="symbols">
          <t><spanx style="verb">must-use-mfa</spanx> requires the consumer to be MFA-authenticated.
This MAY be used if the recipient provider exposes the
<spanx style="verb">enforce-mfa</spanx> capability.</t>
          <t><spanx style="verb">must-exchange-token</spanx> requires the recipient to
exchange the given <spanx style="verb">sharedSecret</spanx> via a signed HTTPS request
to the Sending Server's {tokenEndPoint} [RFC6749].
This MAY be used if the recipient provider exposes the
<spanx style="verb">exchange-token</spanx> capability.</t>
        </list></t>
      <t>OPTIONAL size (integer)
The size of the resource to be transferred, useful
especially in case of <spanx style="verb">datatx</spanx> access type.</t>
    </list></t>
  <t>Protocol details for <spanx style="verb">webapp</spanx> MAY contain:
  <list style="symbols">
      <t>REQUIRED uri (string)
A URI to a client-browsable view of the Shared
Resource, such that users MAY use the web
applications available at the site.  The URI SHOULD
be relative, in which case the prefix exposed by
the <spanx style="verb">/.well-known/ocm</spanx> endpoint MUST be used.
Absolute URIs are deprecated.</t>
      <t>REQUIRED viewMode (string)
The permissions granted to the sharee.  A subset of:
      <list style="symbols">
          <t><spanx style="verb">view</spanx> allows access to the web app in view-only mode.</t>
          <t><spanx style="verb">read</spanx> allows read and download access via the web app.</t>
          <t><spanx style="verb">write</spanx> allows full editing rights via the web app.</t>
        </list></t>
      <t>OPTIONAL sharedSecret (string)
An optional secret to be used to access the remote
web app, for example in the form of a bearer token.</t>
    </list></t>
  <t>Protocol details for <spanx style="verb">ssh</spanx> MAY contain:
  <list style="symbols">
      <t>OPTIONAL accessTypes (array of strings) - The type of access
being granted to the remote resource.  If omitted, it defaults to
<spanx style="verb">['remote']</spanx>.  A subset of:
      <list style="symbols">
          <t><spanx style="verb">remote</spanx> signals the recipient that
the resource is available for remote access, e.g. via sshfs.</t>
          <t><spanx style="verb">datatx</spanx> signals the recipient to transfer the resource
from the given URI via scp.  The recipient MAY delegate a
third-party service to execute the data transfer on their behalf.</t>
        </list></t>
      <t>REQUIRED uri (string)
The full address to be used for ssh or scp access, in the form
<spanx style="verb">username@host.fqdn:port/resource/path</spanx>, where the <spanx style="verb">username</spanx> is
chosen by the Sending Server and does not necessarily need to match
the recipient's OCM Address.  Authentication is expected to take
place via public/private key: the Receiving Server MUST reply to
such a Share Creation Notification by sending back their public
key, for the Sender Server to authorize access to the Resource.</t>
    </list></t>
</list></t>

</section>
<section anchor="response"><name>Response</name>

<t>The Share Creation Notification Response SHOULD be a HTTP response:</t>

<t><list style="symbols">
  <t>in response to the Share Creation Notification Request</t>
  <t>using <spanx style="verb">application/json</spanx> as the <spanx style="verb">Content-Type</spanx> HTTP response header</t>
</list></t>

<t>A 201 response status means the Share Creation Notification Request was
successful.  In this case, the response body MUST contain a JSON
document representing an object with the following string fields:
  - REQUIRED: <spanx style="verb">recipientDisplayName</spanx> - the Recipient's display name.
  - OPTIONAL: <spanx style="verb">recipientPublicKeys</spanx> - the Recipient's public key(s).
    This property MUST be returned when the protocol of the incoming
    share was <spanx style="verb">ssh</spanx>.
A 400 response status means some parameters were invalid or missing.
A 401 response status means the Sender cannot be authenticated as
a trusted service.
A 403 response status means the Sender is not authorized to create
shares.
A 501 response status means either the Receiver does not support
incoming external shares, or the share type or the resource type
are not supported.
A 503 response status means that the Receiver is temporary unavailable.</t>

</section>
<section anchor="decision-to-discard"><name>Decision to Discard</name>

<t>The Receiving Server MAY discard the notification if any of the
following hold true:</t>

<t><list style="symbols">
  <t>the HTTP Signature is missing but the Sending Server does expose a
keypair discoverable from the FQDN part of the <spanx style="verb">sender</spanx> field in the
request body</t>
  <t>the HTTP Signature is missing</t>
  <t>the HTTP Signature is not valid</t>
  <t>no keypair is trusted or discoverable from the FQDN part of the
<spanx style="verb">sender</spanx> field in the request body</t>
  <t>the keypair used to generate the HTTP Signature doesn't match the one
trusted or discoverable from the FQDN part of the <spanx style="verb">sender</spanx> field
in the request body</t>
  <t>the Sending Server is denylisted</t>
  <t>the Sending Server is not allowlisted</t>
  <t>the Sending Party is not trusted by the Receiving Party (e.g., no
Invite was exchanged and/or the Sending Party's OCM Address does not
appear in the Receiving Party's address book)</t>
  <t>the Receiving Server is unable to act as an API client for (any of)
the protocol(s) listed for accessing the Resource</t>
  <t>an initial check shows that the Resource cannot successfully be
accessed through (any of) the protocol(s) listed</t>
</list></t>

</section>
<section anchor="receiving-party-notification"><name>Receiving Party Notification</name>

<t>If the Share Creation Notification is not discarded by the Receiving
Server, they MAY notify the Receiving Party passively by adding the
Share to some inbox list, and MAY also notify them actively through for
instance a push notification or an email message.</t>

<t>They could give the Receiving Party the option to accept or reject the
share, or add the share automatically and only send an informational
notification that this happened.</t>

</section>
</section>
<section anchor="share-acceptance-notification"><name>Share Acceptance Notification</name>

<t>In response to a Share Creation Notification, the Receiving Server MAY
discover the OCM API of the Sending Server, starting from the <spanx style="verb">&lt;fqdn&gt;</spanx>
part of the <spanx style="verb">sender</spanx> field in the Share Creation Notification.</t>

<t>If the OCM API of the Sending Server is successfully discovered, the
Receiving Server MAY make a HTTP POST request</t>

<t><list style="symbols">
  <t>to the <spanx style="verb">/notifications</spanx> path in the Sending Server's OCM API</t>
  <t>using <spanx style="verb">application/json</spanx> as the <spanx style="verb">Content-Type</spanx> HTTP request header</t>
  <t>its request body containing a JSON document representing an object
with the fields as described below</t>
  <t>using TLS</t>
  <t>using httpsig [RFC9421]</t>
</list></t>

<section anchor="fields-2"><name>Fields</name>

<t><list style="symbols">
  <t>REQUIRED notificationType (string) - in a Share Acceptance
Notification it MUST be one of:
  <list style="symbols">
      <t>'SHARE_ACCEPTED'</t>
      <t>'SHARE_DECLINED'</t>
    </list></t>
  <t>REQUIRED providerId (string) - copied from the Share Creation
Notification for the Share this notification is about</t>
  <t>OPTIONAL resourceType (string) - copied from the Share Creation
Notification for the Share this notification is about</t>
  <t>OPTIONAL notification (object) - optional additional parameters,
depending on the notification and the resource type</t>
</list></t>

<t>For example, a notification MAY be sent by a recipient to let the
provider know that the recipient declined a share.  In this case, the
provider site MAY mark the share as declined for its user(s).
Similarly, it MAY be sent by a provider to let the recipient know that
the provider removed a given share, such that the recipient MAY clean
it up from its database.  A notification MAY also be sent to let a
recipient know that the provider removed that recipient from the list
of trusted users, along with any related share.  The recipient MAY
reciprocally remove that provider from the list of trusted users, along
with any related share.</t>

<t>Notifications from Sending Server to Receiving Server SHOULD use
httpsig [RFC9421] so the Receiving Server can authenticate the origin
of the notification.  Receiving Servers SHOULD decline notifications
from Sending Servers without httpsig as it can't identify where the
notification is coming from.</t>

</section>
</section>
<section anchor="resource-access"><name>Resource Access</name>

<t>To access the Resource, the Receiving Server MAY use multiple ways,
depending on the body of the Share Creation Notification and the
protocol required for access.  The procedure is as follows:</t>

<t><list style="numbers" type="1">
  <t>The receiver MUST extract the OCM Server FQDN from the <spanx style="verb">sender</spanx>
field of the received share, and MUST query the
<xref target="ocm-api-discovery">Discovery</xref> endpoint at that address: let
<spanx style="verb">&lt;sender-ocm-path&gt;</spanx> be the <spanx style="verb">resourceTypes[0].protocols.webdav</spanx> value
to be used later, if defined.</t>
  <t>If <spanx style="verb">protocol.name</spanx> is <spanx style="verb">multi</spanx>, the receiver MUST inspect the
<spanx style="verb">protocol.{protocolName}</spanx> properties corresponding to the protocol
of concern, and act according to its semantics.  For the specific
case where <spanx style="verb">protocol.webdav</spanx> is available and the receiver wants
to use it, the following steps are to be followed.</t>
  <t>The <spanx style="verb">protocol.webdav.requirements</spanx> MUST be inspected:
3.1. If it includes <spanx style="verb">must-exchange-token</spanx>, the receiver MUST make a
 signed POST request to the path in the Sending Server’s
 {tokenEndPoint}, to exchange the <spanx style="verb">protocol.webdav.sharedSecret</spanx>
 token for a short-lived bearer token, and only use that bearer
 token to access the Resource (See the <xref target="code-flow">Code Flow</xref>
 section).  If the <spanx style="verb">must-exchange-token</spanx> requirement is not present
 and the Discovery endpoint inspected at step 1. exposes the
 <spanx style="verb">token-exchange</spanx> capability, the receiver MAY attempt to perform
 the token exchange as above, but it MUST fall back to the following
 steps should the process fail.
3.2. If it includes <spanx style="verb">must-use-mfa</spanx>, the Receiving Server MUST ensure
 that the Receiving Party has been authenticated with MFA, or prompt
 the consumer in order to elevate their session, if applicable.</t>
  <t>The <spanx style="verb">protocol.webdav.uri</spanx> property MUST now be inspected: if it's a
complete URI, the receiver MUST make a HTTP PROPFIND request against
it to access the Remote Resource, otherwise it is to be taken as an
identifier <spanx style="verb">&lt;id&gt;</spanx>, in which case the receiver MUST make a HTTP
PROPFIND request to: <spanx style="verb">https://&lt;sender-host&gt;&lt;sender-ocm-path&gt;/&lt;id&gt;</spanx>
in order to access to the Remote Resource.  The receiver MUST pass
an <spanx style="verb">Authorization: bearer</spanx> header with either the short-lived bearer
token obtained in step 3.1., if applicable, or the
<spanx style="verb">protocol.webdav.sharedSecret</spanx> value.</t>
  <t>Otherwise, if <spanx style="verb">protocol.name</spanx> is <spanx style="verb">webdav</spanx> the receiver SHOULD inspect
the <spanx style="verb">protocol.options</spanx> property: if <spanx style="verb">protocol.options.sharedSecret</spanx>
is defined, then the receiver SHOULD make a HTTP PROPFIND request to
<spanx style="verb">https://&lt;sharedSecret&gt;:@&lt;sender-host&gt;&lt;sender-ocm-path&gt;</spanx>.  Note that
this access method, based on Basic Auth, is <em>deprecated</em> and may be
removed in a future release of the Protocol.  If a secret cannot be
identified (e.g. because <spanx style="verb">protocol.options</spanx> is undefined), then
the receiver SHOULD discard the share as invalid.</t>
</list></t>

<t>In all cases, in case the Shared Resource is a folder and the Receiving
Server accesses a Resource within that shared folder, it SHOULD append
its relative path to that URL.  In other words, the Sending Server
SHOULD support requests to URLs such as
<spanx style="verb">https://&lt;sender-host&gt;&lt;sender-ocm-path&gt;/path/to/resource.txt</spanx>.</t>

</section>
<section anchor="code-flow"><name>Code Flow</name>

<t>This section defines the procedure for issuing short-lived bearer access
tokens for use by the Receiving Server when accessing a resource shared
through OCM.  The mechanism is aligned with the OAuth 2.0
<em>authorization_code</em> grant type but is performed entirely as a
server to server interaction between the Sending and Receiving Servers.
No user interaction or redirect is involved. [RFC6749]</t>

<section anchor="token-request"><name>Token Request</name>

<t>To obtain an access token, the Receiving Server MUST send an HTTP POST
request to the Sending Server’s {tokenEndPoint} as discovered in the
OCM provider metadata, following section 4.4.2 of [RFC6749].  The
request payload MUST be in <spanx style="verb">x-www-form-urlencoded</spanx> form, as shown
in the following example (with line breaks in the Signature headers
for display purposes only):</t>

<sourcecode type="http">
POST {tokenEndPoint} HTTP/1.1
Host: cloud.example.org
Date: Wed, 05 Nov 2025 14:00:00 GMT
Content-Type: application/x-www-form-urlencoded
Digest: SHA-256=ok6mQ3WZzKc8nb7s/Jt2yY1uK7d2n8Zq7dhl3Q0s1xk=
Content-Length: 101
Signature-Input:
  sig1=("@method" "@target-uri" "content-digest" "date");
  created=1730815200;
  keyid="receiver.example.org#key1";
  alg="rsa-sha256"
Signature: sig1=:bM2sV2a4oM8pWc4Q8r9Zb8bQ7a2vH1kR9xT0yJ3uE4wO5lV6bZ1cP
  2rN3qD4tR5hC=:

grant_type=authorization_code&amp;
client_id=receiver.example.org&amp;
code=my_secret_code
</sourcecode>

<t>The request MUST be signed using an HTTP Message Signature
[RFC9421].  The <spanx style="verb">client_id</spanx> identifies the Receiving Server and MUST be
set to its fully qualified domain name.  The <spanx style="verb">code</spanx> parameter carries
the authorization secret that was issued by the Sending Server in the
Share Creation Notification.  It is allowed to send the additional
parameters defined in [RFC6749] for the <spanx style="verb">authorization_code</spanx> grant type,
but they MUST be ignored.</t>

</section>
<section anchor="token-response"><name>Token Response</name>

<t>If the request is valid and the code is accepted, the Sending Server
MUST respond with HTTP 200 OK and a OAuth-compliant JSON object
containing the issued token:</t>

<figure type="json"><artwork><![CDATA[
{
  "access_token": "8f3d3f26-f1e6-4b47-9e3e-9af6c0d4ad8b",
  "token_type": "Bearer",
  "expires_in": 300
}
]]></artwork></figure>

<t>The <spanx style="verb">access_token</spanx> is an opaque bearer credential with no internal
structure visible to the Receiving Server.  The token authorizes the
Receiving Server to access the shared resource using the appropriate
transport protocol (e.g., WebDAV).  The <spanx style="verb">expires_in</spanx> value indicates
the token lifetime in seconds.  No <spanx style="verb">refresh_token</spanx> is issued, instead
the same request to the {tokenEndPoint} MUST be repeated before the
<spanx style="verb">access_token</spanx> has expired, to recieve a new <spanx style="verb">access_token</spanx> that can
then be used in the same manner.</t>

</section>
<section anchor="error-responses"><name>Error Responses</name>

<t>If the request is invalid, the Sending Server MUST return an HTTP 400
response with a JSON object containing an OAuth 2.0 error code
[RFC6749]:</t>

<figure type="json"><artwork><![CDATA[
{ "error": "invalid_request" }
]]></artwork></figure>

<t>Permitted error codes are <spanx style="verb">invalid_request</spanx>, <spanx style="verb">invalid_client</spanx>,
<spanx style="verb">invalid_grant</spanx>, <spanx style="verb">unauthorized_client</spanx> and <spanx style="verb">unsupported_grant_type</spanx>.</t>

</section>
</section>
<section anchor="share-deletion"><name>Share Deletion</name>

<t>A <spanx style="verb">"SHARE_ACCEPTED"</spanx> notification followed by a <spanx style="verb">"SHARE_UNSHARED"</spanx>
notification is equivalent to a <spanx style="verb">"SHARE_DECLINED"</spanx> notification.</t>

<t>Note that the Sending Server MAY at any time revoke access to a
Resource (effectively undoing or deleting the Share) without notifying
the Receiving Server.</t>

</section>
<section anchor="share-updating"><name>Share Updating</name>

<t>Some implementations have experimented with a
<spanx style="verb">"RESHARE_CHANGE_PERMISSION"</spanx>notification, but the payload and side
effects such a notification may have are out of scope of this version
of this specification.
The Receiving Party sending such a notification has no way of knowing
if the Sending Party understood and processed the reshare request
or not.</t>

</section>
<section anchor="resharing"><name>Resharing</name>

<t>The <spanx style="verb">"REQUEST_RESHARE"</spanx> and <spanx style="verb">"RESHARE_UNDO"</spanx> notification types MAY be
used by the Receiving Server to persuade the Sending Server to share the
same Resource with another Receiving Party.
The details of the payload and side effects such a notification may
have are out of scope of this version of this specification.
Note that the Receiving Party sending such a notification has no way of
knowing if the Sending Party understood and processed the reshare
request or not.  In all cases, the Receiving Server MUST NOT reshare
a Resource without an explicit grant from the Sending Server.</t>

</section>
<section anchor="iana-considerations"><name>IANA Considerations</name>

<section anchor="well-known-uri-for-the-discovery"><name>Well-Known URI for the Discovery</name>

<t>The following value is to be registered in the "Well-Known URIs"
registry (using the template from [RFC5785]):
   URI suffix: ocm
   Change controller: IETF
   Specification document(s): the present Draft, once in RFC form
   Related information: N/A</t>

</section>
<section anchor="jscontact-types-registry"><name>JSContact Types Registry</name>

<t>The following entry is to be registered in the "JSContact Types"
registry (using the template from [RFC9553]):
   Type Name: ocmAddress
   Intended Usage: common
   Since Version: 1.0
   Until Version: N/A
   Change Controller: IETF
   Reference or Description:</t>

<t>An object representing an OCM address.  The object contains:</t>

<figure><artwork><![CDATA[
 - "address" (String, required): The OCM federated address in format
   "user@provider" where provider is the FQDN of an OCM-capable
   server.
 - "trusted" (Boolean, optional): Whether shares from this address
   are automatically accepted. Default: false.
 - "source" (String, optional): How this address was established.
   See "JSContact Enum Values" registry for allowed values.
 - "label" (String, optional): Human-readable label for this
   address.
]]></artwork></figure>

</section>
<section anchor="jscontact-properties-registry"><name>JSContact Properties Registry</name>

<t>The following entry is to be registered in the "JSContact Properties"
registry (using the template from [RFC9553]):
   Property Name: ietf.org:ocmAddresses
   Property Type: String[ocmAddress]
   Property Context: Card
   Intended Usage: common
   Since Version: 1.0
   Until Version: N/A
   Change Controller: IETF
   Reference or Description:</t>

<t>A map of OCM addresses for a contact. The keys are arbitrary
   identifiers (e.g., "primary", "work") and the values are ocmAddress
   objects as defined in the JSContact Types Registry.</t>

</section>
<section anchor="jscontact-enum-values-registry"><name>JSContact Enum Values Registry</name>

<t>The following entries are to be registered in the "JSContact Enum
Values" registry (using the template from [RFC9553]).
   Property Name: ietf.org:ocmAddresses/source
   Context: Card
   Since Version: 1.0
   Until Version: N/A
   Change Controller: IETF
   Reference or Description:</t>

<t>Values indicating how an OCM address was established.</t>

<t>Initial Contents:</t>

<figure><artwork><![CDATA[
   +==============+==========================================+
   | Enum Value   | Reference/Description                    |
   +==============+==========================================+
   | invite       | Address established via OCM invite flow  |
   |--------------|------------------------------------------|
   | share        | Address established by receiving a share |
   |--------------|------------------------------------------|
   | direct entry | Address added directly by the user       |
   |--------------|------------------------------------------|
]]></artwork></figure>

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

<section anchor="trust"><name>Trust</name>

<t>There are several areas that are not covered by this specification.
Most importantly we do not provide a way of establishing trust between
servers, even though some features of the protocol rely on trust, such
as the <spanx style="verb">mfa-enforced</spanx> requirement.</t>

<t>Trust needs to be established out of band, but there are some features
of the protocol that <em>can</em> be used to assist operators in establishing
trust.  For instance, invite flow can be used to establish that users
know and have out of band connections with other users on an OCM server.</t>

<t>Further more the Directory Service feature can be used to establish a
trusted federation, where a central authority can be trusted to
implement measures for auditing and adding only trusted servers into the
discovery service.</t>

<section anchor="httpsig"><name>httpsig</name>

<t>It is RECOMMENDED to use signed messages, "httpsig" [RFC9421], to
verify that an OCM server is the server you expect it to be, and SHOULD
be done unless you have a niche use case.</t>

</section>
</section>
<section anchor="legacy-shared-secrets"><name>Legacy shared secrets</name>

<t>The legacy format of an OCM Share Notification with shared secrets is
only provided for backwards compatibility with existing implementations.
Implementers SHOULD NOT use it and prefer short-lived tokens instead.</t>

</section>
<section anchor="code-flow-1"><name>Code Flow</name>

<t>All <spanx style="verb">{tokenEndPoint}</spanx> requests MUST be transmitted over HTTPS and
signed using HTTP Signatures.  Bearer tokens MUST be treated as
confidential and never logged, persisted beyond their lifetime, or
transmitted over unsecured channels.</t>

</section>
</section>
<section anchor="references"><name>References</name>

<section anchor="normative-references"><name>Normative References</name>

<t>[RFC2119] Bradner, S. "<eref target="https://datatracker.ietf.org/doc/html/rfc2119">Key words for use in RFCs to Indicate
Requirement Levels</eref>",
March 1997.</t>

<t>[RFC3986] Berners-Lee, T., Fielding, R. and Masinter, L.
"<eref target="https://datatracker.ietf.org/doc/html/rfc3986">Uniform Resource Identifier (URI): Generic Syntax
</eref>", January 2005</t>

<t>[RFC4918] Dusseault, L. M. "<eref target="https://datatracker.ietf.org/html/rfc4918/">HTTP Extensions for Web Distributed
Authoring and Versioning</eref>",
June 2007.</t>

<t>[RFC6749] Hardt, D. (ed), "<eref target="https://datatracker.ietf.org/html/rfc6749">The OAuth 2.0 Authorization Framework</eref>", October 2012.</t>

<t>[RFC7515] Jones, M., Bradley, J., Sakimura, N., "<eref target="https://datatracker.ietf.org/doc/html/rfc7515">JSON Web Signature
(JWS)</eref>", May 2015.</t>

<t>[RFC7517] Jones, M., "<eref target="https://datatracker.ietf.org/doc/html/rfc7517">JSON Web Key (JWK)</eref>", May 2015.</t>

<t>[RFC8032] Josefsson, S., Liusvaara, I., "<eref target="https://datatracker.ietf.org/doc/html/rfc8032">Edwards-Curve Digital
Signature Algorithm (EdDSA)</eref>", January 2017.</t>

<t>[RFC8174] Leiba, B. "<eref target="https://datatracker.ietf.org/html/rfc8174">Ambiguity of Uppercase vs Lowercase in RFC 2119
Key Words</eref>", May 2017.</t>

<t>[RFC8615] Nottingham, M. "<eref target="https://datatracker.ietf.org/doc/html/rfc8615">Well-Known Uniform Resource Identifiers
(URIs)</eref>", May 2019</t>

<t>[RFC9421] Backman, A., Richer, J. and Sporny, M. "<eref target="https://tools.ietf.org/html/rfc9421">HTTP Message
Signatures</eref>", February 2024.</t>

<t>[RFC9553] Stepanek, R., Loffredo, M., "<eref target="https://datatracker.ietf.org/doc/html/rfc9553">JSContact: A JSON
Representation of Contact Data</eref>, May 2024"</t>

</section>
</section>
<section anchor="appendix-a-multi-factor-authentication"><name>Appendix A: Multi-factor Authentication</name>

<t>If a Receiving Server exposes the capability <spanx style="verb">enforce-mfa</spanx>, it
indicates that it will try and comply with a MFA requirement set on a
Share.  If the Sending Server trusts the Receiving Server, the Sending
Server MAY set the requirement <spanx style="verb">mfa-enforced</spanx> on a Share, which the
Receiving Server MUST honor.  A compliant Receiving Server that signals
that it is MFA-capable MUST NOT allow access to a Resource protected
with the <spanx style="verb">mfa-enforced</spanx> requirement, if the Receiving Party has not
provided a second factor to establish their identity with greater
confidence.</t>

<t>Since there is no way to guarantee that the Receiving Server will
actually enforce the MFA requirement, it is up to the Sending Server to
establish a trust with the Receiving Server such that it is reasonable
to assume that the Receiving Server will honor the MFA requirement.
This establishment of trust will inevitably be implementation
dependent, and can be done for example using a pre approved allow list
of trusted Receiving Servers.  The procedure of establishing trust is
out of scope for this specification: a mechanism similar to the
<eref target="https://sciencemesh.io">ScienceMesh</eref> integration for the
<xref target="invite-flow">Invite</xref> capability may be envisaged.</t>

</section>
<section anchor="appendix-b-jwks-and-http-signature-examples"><name>Appendix B: JWKS and HTTP Signature Examples</name>

<section anchor="jwks-endpoint"><name>JWKS Endpoint</name>

<t>An OCM Server that advertises the <spanx style="verb">http-sig</spanx> capability MUST expose its
public keys at <spanx style="verb">/.well-known/jwks.json</spanx> in the format specified by
[RFC7517].  Here is an example response from
<spanx style="verb">https://sender.example.org/.well-known/jwks.json</spanx>:</t>

<figure type="json"><artwork><![CDATA[
{
  "keys": [
    {
      "kty": "OKP",
      "crv": "Ed25519",
      "kid": "sender.example.org#key1",
      "x": "11qYAYKxCrfVS_7TyWQHOg7hcvPapiMlrwIaaPcHURo"
    }
  ]
}
]]></artwork></figure>

</section>
<section anchor="signing-a-request-sender"><name>Signing a Request (Sender)</name>

<t>Given a Share Creation Notification request:</t>

<sourcecode type="http">
POST /ocm/shares HTTP/1.1
Host: receiver.example.org
Date: Fri, 16 Jan 2026 13:37:00 GMT
Content-Type: application/json
Content-Digest: sha-256=:LkpHyFOVbBDPxc7YbHDOWNzAv88qWuVfLNf4TUf9Uo8=:

{
  "shareWith": "marie@receiver.example.org",
  "name": "spec.yaml",
  "providerId": "7c084226-d9a1-11e6-bf26-cec0c932ce01",
  "owner": "einstein@sender.example.org",
  "sender": "einstein@sender.example.org",
  "ownerDisplayName": "Albert Einstein",
  "senderDisplayName": "Albert Einstein",
  "shareType": "user",
  "resourceType": "file",
  "protocol": {
    "name": "multi",
    "webdav": {
      "uri": "spec.yaml",
      "sharedSecret": "hfiuhworzwnur98d3wjiwhr",
      "permissions": ["read", "write"]
    }
  }
}
</sourcecode>

<t>The signature base is constructed according to [RFC9421] (with line
breaks in @signature-params for display purposes only):</t>

<sourcecode type="http">
"@method": POST
"@target-uri": https://receiver.example.org/ocm/shares
"content-digest": sha-256=:[digest-value]=:
"@signature-params": ("@method" "@target-uri" "content-digest");
    created=[timestamp];
    keyid="sender.example.org#key1";
    alg="ed25519"
</sourcecode>

<t>Sign this base using for example Ed25519 ([RFC8032]) to produce the
signature, then add headers (line breaks for display purposes only):</t>

<sourcecode type="http">
Signature-Input: sig1=("@method" "@target-uri" "content-digest");
  created=[timestamp];
  keyid="sender.example.org#key1";
  alg="ed25519"
Signature: sig1=:[signature-value]=:
</sourcecode>

</section>
<section anchor="verifying-a-signature-receiver"><name>Verifying a Signature (Receiver)</name>

<t>To verify an incoming signed request:</t>

<t><list style="numbers" type="1">
  <t>Extract the provider domain from the <spanx style="verb">sender</spanx> field in the
request body</t>
  <t>Fetch the public key from
<spanx style="verb">https://&lt;provider-domain&gt;/.well-known/jwks.json</spanx></t>
  <t>Extract <spanx style="verb">keyid</spanx> from <spanx style="verb">Signature-Input</spanx> header and find the key
matching the <spanx style="verb">kid</spanx> value in the [RFC7517] response</t>
  <t>Reconstruct the signature base from the request using the
components listed in <spanx style="verb">Signature-Input</spanx> as specified in [RFC9421]</t>
  <t>Verify the signature using the appropriate algorithm
(e.g., Ed25519 [RFC8032])</t>
</list></t>

</section>
<section anchor="validating-the-payload"><name>Validating the Payload</name>

<t>Following the validation of the signature, the host SHOULD also confirm
the validity of the payload, that is ensuring that the actions implied
in the payload actually initiated on behalf of the source of the
request.</t>

<t>As an example, if the payload is about initiating a new share, the file
owner has to be an account from the instance at the origin of the
request.</t>

</section>
</section>
<section anchor="appendix-c-directory-service"><name>Appendix C: Directory Service</name>

<t>A third-party Directory Service is a back-end service used to federate
multiple OCM Servers and facilitate the Invite flow.  It is expected to
expose, via anonymous HTTPS GET, a signed JWS document [RFC7515], where
the signing key MUST be made available offline and the payload MUST
adhere to the following format:</t>

<t><list style="symbols">
  <t>REQUIRED: <spanx style="verb">federation</spanx> - a human-readable name for the list of OCM
Servers exposed by the Directory Service</t>
  <t>REQUIRED: <spanx style="verb">servers</spanx> - a JSON array of objects to describe the list
of OCM Servers with the following string fields:
  <list style="symbols">
      <t>REQUIRED: <spanx style="verb">url</spanx> - an absolute URL identifying the
OCM Server.  It MUST:
      <list style="symbols">
          <t>include scheme: either <spanx style="verb">https://</spanx> or
(for testing purposes) <spanx style="verb">http://</spanx></t>
          <t>include host (either a FQDN or an IP address)</t>
          <t>MAY include a non-default port</t>
          <t>MUST NOT include a base path (e.g., <spanx style="verb">/ocm</spanx>)</t>
          <t>MUST NOT include userinfo, query, or fragment</t>
        </list></t>
      <t>REQUIRED: <spanx style="verb">displayName</spanx> - a human-readable name
for the OCM Server
Example:</t>
    </list></t>
</list></t>

<figure type="json"><artwork><![CDATA[
{
  "payload": {
    "federation": "The ScienceMesh Directory",
    "servers": [
      {
        "url": "https://ocm-server-1.example.org",
        "displayName": "OCM Server 1"
      },
      {
        "url": "https://ocm-server-2.example.org:4443",
        "displayName": "OCM Server 2"
      },
      {
        "url": "http://192.168.1.1:8080",
        "displayName": "OCM Server 3"
      }
    ]
  },
  "protected": {"alg": "RS256"},
  "signature": "..."
}
]]></artwork></figure>

</section>
<section anchor="appendix-d-object-models"><name>Appendix D: Object models</name>

<t>An implementor of OCM MAY choose any internal object model to represent
an <em>Address Book</em>, a <em>Contact</em>, an <em>Invite</em>, a <em>Provider</em>, a <em>Share</em>,
and a <em>User</em>.  The following diagrams are provided to clarify
the concepts and their relationships, as a guide for implementors.</t>

<section anchor="address-book"><name>Address Book</name>

<t>An <em>OCM Provider</em> MAY offer its <em>Users</em> an address book tool, where OCM
Addresses can be stored over time in a labeled and/or searchable way.
This decouples the act by which the OCM Address string is passed into
the Sending Server's database from the selection of the <em>Receiving
Party</em> in preparation for Share Creation.</t>

<t>The Address Book entity maintains a collection of contacts for a user
within the OCM provider.  It serves as the primary mechanism for
managing federated relationships between users across different OCM
Servers. <em>Contacts</em> may be added to the Address Book through the Invite
flow or direct entry.  It provides a convenient way for users to
organize and access their federated contacts, and MAY allow users to
generate <em>Invites</em>.</t>

<figure><artwork><![CDATA[
+-----------------+
|  Address Book   |
|                 |
| - owner: User   |--------+
| - contacts: []  |        |
+-----------------+        |
       |                   |
       | contains          | generates
       | 0..*              |
       v                   v
+-----------------+  +----------------+
|    Contact      |  |    Invites     |
+-----------------+  +----------------+
]]></artwork></figure>

<section anchor="properties"><name>Properties</name>

<t><list style="symbols">
  <t><strong>owner</strong>: Reference to the User who owns this address book</t>
  <t><strong>contacts</strong>: Array of Contact objects stored in the address book</t>
</list></t>

</section>
<section anchor="relationships"><name>Relationships</name>

<t><list style="symbols">
  <t>An Address Book belongs one or more Users.</t>
  <t>An Address Book contains zero or more Contacts.</t>
  <t>An Address Book MAY allow its owner to generate Invites.</t>
</list></t>

</section>
</section>
<section anchor="contact"><name>Contact</name>
<t>A Contact represents a federated user relationship established through
the OCM protocol.  Contacts are stored in <em>Address Books</em> and may be
created through the Invite process or via direct entry.  A Contact MAY
of course contain much more detailed information about the referenced
user such as if it was added via <em>Invites</em> or direct entry.</t>

<figure><artwork><![CDATA[
+-----------------+
|    Contact      |
+-----------------+
| - addedDate     |
| - email         |
| - name          |
| - provider      |
| - userID        |
+-----------------+
       ^
       | referenced by
       |
+-----------------+
|  Address Book   |
+-----------------+
]]></artwork></figure>

<section anchor="properties-1"><name>Properties</name>

<t><list style="symbols">
  <t><strong>addedDate</strong>: Timestamp of when contact was added</t>
  <t><strong>email</strong>: Contact email address (informational)</t>
  <t><strong>name</strong>: Human-readable display name</t>
  <t><strong>userID</strong>: The identifier of the contact at their OCM Server</t>
  <t><strong>provider</strong>: The FQDN of the contact's OCM Server</t>
</list></t>

</section>
<section anchor="relationships-1"><name>Relationships</name>

<t><list style="symbols">
  <t>A Contact may be referenced by one or more Address Books.</t>
</list></t>

</section>
</section>
<section anchor="invite"><name>Invite</name>

<t>The Invite entity represents the bidirectional trust establishment
mechanism in OCM.  It facilitates secure contact exchange between users
on different OCM Servers.</t>

<figure><artwork><![CDATA[
+-----------------+
|     Invite      |
+-----------------+
| - acceptedTime  |
| - createdTime   |
| - sender: User  |
| - token         |
+-----------------+
       |
       | generated by
       v
+-----------------+
|   Address Book  |
+-----------------+

]]></artwork></figure>

<section anchor="properties-2"><name>Properties</name>

<t><list style="symbols">
  <t><strong>acceptedTime</strong>: Timestamp of invite acceptance (if accepted)</t>
  <t><strong>createdTime</strong>: Timestamp of invite creation</t>
  <t><strong>sender</strong>: Reference to the User who sent the Invite</t>
  <t><strong>token</strong>: Unique, hard-to-guess string generated by Invite Sender
           OCM Server</t>
</list></t>

</section>
<section anchor="relationships-2"><name>Relationships</name>

<t><list style="symbols">
  <t>An Invite is generated by an Address Book entry action.</t>
  <t>An Invite is associated with exactly one User as the sender.</t>
</list></t>

</section>
</section>
<section anchor="provider"><name>Provider</name>

<t>The Provider entity represents an OCM Server's capabilities and
configuration as discovered through the OCM API Discovery process.  It
represents both the Sending Server and Receiving Server roles, and an
implementor might find it useful to have a Provider object model to
store the discovered information about federation peers or other remote
OCM Providers.</t>

<t>The following diagram is illustrative and non-exhaustive. The single
source of truth for Provider properties is the OCM API Discovery Fields
section; for the box contents below, see the Properties subsection and
the normative capability, criteria, and resource type definitions in
that section.</t>

<figure><artwork><![CDATA[
            +-----------------------+
            |      Provider         |
            |    (OCM Server)       |
            +-----------------------+
            | - apiVersion          |
            | - enabled             |
            | - endPoint            |
            | - inviteAcceptDialog  |
            | - provider            |
            | - publicKey           |
            | - tokenEndPoint       |
            | - ...                 |
            +-----------------------+
                   |
                   | exposes
                   |
         +---------+---------+----------------------+
         |                   |                      |
         v                   v                      |
+------------------+  +------------------+          |
| ResourceTypes[]  |  | Capabilities[]   |          |
+------------------+  +------------------+          |
| - name           |  | - enforce-mfa    |          |
| - shareTypes[]   |  | - exchange-token |          |
| - protocols{}    |  | - http-sig       |          |
| - ...            |  | - invites        |          |
+------------------+  | - notifications  |          |
       |              | - protocol-object|          |
       |              | - webdav-uri     |          |
       |              | - ...            |          |
       |              +------------------+          |
       |                                            |
       |                           +----------------+
       |                           |
       |                           v
       |              +--------------------------+
       |              |    Criteria[]            |
       |              +--------------------------+
       |              | - allowlist              |
       |              | - denylist               |
       |              | - http-request-signatures|
       |              | - invite                 |
       |              | - token-exchange         |
       |              | - ...                    |
       |              +--------------------------+
       |
       | supports
       v
+------------------+
|   Protocols      |
+------------------+
| - ssh            |
| - webapp         |
| - webdav         |
| - ...            |
+------------------+
]]></artwork></figure>

<section anchor="properties-3"><name>Properties</name>

<t><list style="symbols">
  <t><strong>apiVersion</strong>: Version string of supported OCM API</t>
  <t><strong>capabilities</strong>: Optional features supported</t>
  <t><strong>criteria</strong>: Requirements for accepting Share Creation Notifications</t>
  <t><strong>enabled</strong>: Boolean indicating if OCM service is active</t>
  <t><strong>endPoint</strong>: Base URI for OCM API endpoints</t>
  <t><strong>provider</strong>: Friendly branding name</t>
  <t><strong>publicKey</strong>: Optional public key for HTTP signatures</t>
  <t><strong>resourceTypes</strong>: Array of supported resource types with protocols</t>
</list></t>

</section>
</section>
<section anchor="share"><name>Share</name>

<t>The Share entity represents a policy granting access to a <em>Resource</em>
from a Sending Party to a Receiving Party.</t>

<figure><artwork><![CDATA[
+-----------------+                      +------------------+
|  Sending Party  |                      | Receiving Party  |
+-----------------+                      +------------------+
       |                                        |
       | creates                                | accesses
       v                                        v
+------------------+     notification    +------------------+
|     Share        |-------------------->| Receiving Server |
+------------------+                     +------------------+
| - expiration     |                            |
| - name           |                            | mediates access to
| - owner          |                            v
| - protocol       |                     +------------------+
| - providerId     |                     | Resource (remote)|
| - requirements[] |                     +------------------+
| - resourceType   |
| - sender         |
| - shareType      |
| - shareWith      |
| - state          |
+------------------+
       |
       | governs access to
       v
+-----------------+
|    Resource     |
+-----------------+
]]></artwork></figure>

<section anchor="properties-4"><name>Properties</name>

<t><list style="symbols">
  <t><strong>expiration</strong>: Optional expiration timestamp</t>
  <t><strong>name</strong>: Human-readable name of the shared Resource</t>
  <t><strong>owner</strong>: OCM Address of the Resource owner</t>
  <t><strong>protocol</strong>: Access protocol name and details (webdav, ssh, webapp)</t>
  <t><strong>providerId</strong>: Unique identifier for the Share at the provider</t>
  <t><strong>requirements</strong>: Array of access requirements (must-use-mfa,
                  must-exchange-token)</t>
  <t><strong>resourceType</strong>: Type of resource (file, folder, calendar, etc.)</t>
  <t><strong>sender</strong>: OCM Address of the party creating the Share</t>
  <t><strong>shareType</strong>: Type of recipient (user, group, federation)</t>
  <t><strong>shareWith</strong>: OCM Address of the Receiving Party</t>
  <t><strong>state</strong>: Current state of the Share (accepted, pending, deleted)</t>
</list></t>

<section anchor="share-states"><name>Share States</name>

<t><list style="symbols">
  <t><strong>Accepted</strong>: Share accepted, Resource accessible</t>
  <t><strong>Deleted</strong>: Share removed or expired</t>
  <t><strong>Pending</strong>: Awaiting acceptance by Receiving Party</t>
</list></t>

</section>
</section>
<section anchor="relationships-3"><name>Relationships</name>

<t><list style="symbols">
  <t>A Share is created by a User (local).</t>
  <t>A Share is received by a User (remote).</t>
  <t>A Share governs access to a Resource.</t>
</list></t>

</section>
</section>
<section anchor="user"><name>User</name>

<t>The User entity represents the party in OCM who can send and receive
Shares and Invites and manage Contacts, and interact with Resources.</t>

<figure><artwork><![CDATA[
                +-----------------------+
                |        User           |
                +-----------------------+
                | - email               |
                | - name                |
                | - ocmAddress          |
                | - uid                 |
                +-----------------------+
                            |
                  +---------+---------+
                  |                   |
                  | owns              | participates in
                  v                   v
         +------------------+  +------------------+
         |  Address Book    |  |    Shares        |
         +------------------+  +------------------+
         | - contacts[]     |  | - receiving[]    |
         +------------------+  | - sending[]      |
                  |            +------------------+
                  |
                  | issues
                  v
         +------------------+
         |    Invites       |
         +------------------+
         | - sent[]         |
         +------------------+
]]></artwork></figure>

<section anchor="properties-5"><name>Properties</name>

<t><list style="symbols">
  <t><strong>email</strong>: User's email address</t>
  <t><strong>name</strong>: Human-readable display name</t>
  <t><strong>ocmAddress</strong>: Full OCM Address</t>
  <t><strong>uid</strong>: Unique identifier within the OCM Provider</t>
</list></t>

</section>
<section anchor="relationships-4"><name>Relationships</name>

<t><list style="symbols">
  <t>A User owns one or more Address Book(s).</t>
  <t>A User issues zero or more Invites.</t>
  <t>A User participates in zero or more Shares as Sending or Receiving
Party.</t>
</list></t>

</section>
</section>
<section anchor="resource"><name>Resource</name>

<t>The Resource entity represents the data or service being shared between
OCM Providers.  It is the target of Shares and is accessed by the
Receiving Party through the Sending Server's API.  In general a Resource
is a much more complex entity, but for the purpose of OCM we only need
to model a few key properties.</t>

<figure><artwork><![CDATA[
+-----------------+
|    Resource     |
+-----------------+
| - location      |
| - owner: User   |
| - resourceID    |
| - type          |
+-----------------+
       ^
       |
       | accessed via
       |
       v
+------------------+
|     Share        |
+------------------+
]]></artwork></figure>

<section anchor="properties-6"><name>Properties</name>

<t><list style="symbols">
  <t><strong>location</strong>: URI or path to access the Resource</t>
  <t><strong>owner</strong>: Reference to the User who owns the Resource</t>
  <t><strong>resourceID</strong>: Unique identifier of the Resource</t>
  <t><strong>type</strong>: Type of Resource (file, folder, calendar, etc.)</t>
</list></t>

</section>
</section>
</section>
<section anchor="changes"><name>Changes</name>

<t>This section collects the changes with respect to the previous
version in the IETF datatracker.  It is meant to ease the review
process and it shall be removed when going to RFC last call.
The complete changelog is updated in the OCM-API GitHub repository.</t>

<section anchor="version-04"><name>Version 04</name>
<t><list style="symbols">
  <t>Clarified that the diagrams in Appendix D are illustrative and
not normative.</t>
  <t>Minor formatting fixes.</t>
</list></t>

</section>
<section anchor="version-03"><name>Version 03</name>
<t><list style="symbols">
  <t>Fixed formatting of artworks, code blocks and bullet lists.</t>
</list></t>

</section>
<section anchor="version-02"><name>Version 02</name>
<t><list style="symbols">
  <t>Added the <em>Changes</em> section.</t>
</list></t>

</section>
<section anchor="version-01"><name>Version 01</name>

<t><list style="symbols">
  <t>Introduced functions, roles, and object models to the specification.</t>
  <t>Added support for SSH as a share access method.</t>
  <t>Introduced <spanx style="verb">accessType</spanx> property in shares and removed the datatx
"protocol" in favor of a cleaner access model.</t>
  <t>Improved resource access description with token exchange, and
specified request payload format for the <spanx style="verb">/token</spanx> endpoint.</t>
  <t>Added RFC 9421 HTTP Message Signatures support via <spanx style="verb">http-sig</spanx>
capability and RFC 7515 (JWS) compliant JWKS and prescribed use of
JWS for the Directory Service.</t>
  <t>Updated and homogenized capabilities across the specification.</t>
  <t>Added JSContact extension to IANA Considerations.</t>
  <t>Changed example domain to use cloud.example.org per RFC 2606.</t>
</list></t>

</section>
</section>
<section anchor="acknowledgements"><name>Acknowledgements</name>

<t>Our deepest thanks and appreciation go to the people who started the
work on what would become this specification in 2015.  In particular we
want to thank (in alphabetical order) Guido Aben, Russell Albert,
Holger Angenent, David Antoš, Hrachya Astsatryan, Kurt Bauer,
Charles du Jeu, Andreas Eckey, David Gillard, Andranik Hayrapetyan Wahi,
Dimitri van Hees, Christoph Herzog, David Jericho, Frank Karlitschek,
Christian Kracher, Ralph Krimmel, Massimo Lamanna, Simon Leinen,
Jari Miettinen, Jakub Moscicki, Frederik Orellana, Vlad Roman,
Christian Schmitz, Woojin Seok, Rogier Spoor, Christian Sprajc,
Peter Szegedi, Ron Trompert, Benedikt Wegmann and Jonathan Xu.</t>

<t>We would also like to thank Ishank Arora, Gianmaria Del Monte,
Jörn Friedrich Dreyer, Richard Freitag, Hugo González Labrador,
Matthias Kraus, Maxence Lange, Lovisa Lugnegård, Sandro Mesterheide,
Antoon Prins and Björn Schießle for their direct contributions
to the specification.</t>

<t>Over the years many more people have been involved in the development
of OCM.  We would like to thank all of them for their contributions,
including Jean-Thomas Acquaviva, Samuel Alfageme Sainz,
Karsten Asshauer, Miroslav Bauer, Felix Böhm, Maciej Brzeźniak,
Diogo Castro, Gavin Charles Kennedy, Jarosław Czub, Milan Danecek,
Michael D'Silva, Lukasz Dutka, Pedro Ferreira, Renato Furter,
Klaas Freitag, Raman Ganguly, Eva Gergely, Hilary Goodson, Daniel Halbe,
Dave Heyns, Jan Holesovsky, Jan Hornicek, Carina Kemp, Fergus Kerins,
Andreas Klotz, Matthias Knoll, Christian Kracher, Mario Lassnig,
Claudius Laumanns, Anthony Leroy, Patrick Maier, Vladislav Makarenko,
Anna Manou, Rita Meneses, Zheng Meyer-Zhao, Crystal Michelle Chua,
Yoann Moulin, Daniel Müller, Frederik Müller, Rasmus Munk,
Michał Orzechowski, Jacek Pawel Kitowski, Iosif Peterfi,
Alessandro Petraro, Rene Ranger, Angelo Romasanta, David Rousse,
Carla Sauvanaud, Klaus Scheibenberger, Marcin Sieprawski,
Tilo Steiger, C.D. Tiwari, Alejandro Unger and Tom Wezepoel.</t>

</section>


  </middle>

  <back>








  </back>

<!-- ##markdown-source:
H4sIAAAAAAAAA+2963LbWJYu+B9PsYMVcSxVk7Qk31WdNSlbdlpOy1ZJcrqz
MjwiSIIiUiTABEDJdFV1TJy3mF8T58e8wvkxMf8q+kXmSWZd9wUAKTmruqf6
zFF0V5oksK9rr70u31qr1+tFVVrNkn1z7/0iycyLWb4cm+OknN6Lxvkoi+fw
07iIJ1UvTapJLx/Nezk82Bvhg705PNjbeRiN4iq5zIvVvimrcRSli2LfVMWy
rPZ2dp7t7EVxkcT75mCxmKXwaJpnpYmzsTlN4lnvPJ0n0VWyusmL8b45yqqk
yJKqd4idRlFZwYMX8SzPYCCrpIQvoK05PPjy/FUUxctqmhf7kTE9k2blvvmu
b97m5qRIyiqFb43hKXyXLstksUhqP+bFZZylX2hI++bFy9N39HUyj9PZvrmU
l/qzfEHvfDuCsfVHU3poWaT7ZlpVi3L//n354b4+GbkRHfef9804MW/y7NIb
0XE6mqbJLPglHM5Jno2Twpzly2KU+OOa86vfLuiBkn7vw7vNYQVPjPJ5MCzz
PL6cDqFDf1TxdJyGP9x1UPjm3zykd0AEaRYu01Xifx0O5+zDu5fn/jCu4iz/
tlwCBfXLpGWf8nHSL+f5DB+Apu7Psf0o6vV6Jh4CbcUjILraUTBb718cb5sU
iNaUSXEN858kMAkag1kUeZWP8pmppnGFDwHRjE2VR1lepZMVvHOajJL0Os0u
zUlcVCt+sJomKzONrxMzTKC3yyIGyh+beDRKyhJeN2UO5+I0kZUy5qiCx0tT
pvN0FhdplSaluUmrqeEzIEtiJrP8Bp5ajuCHMnp/AD924V/mJpnN6L/4SpmP
0ngGq86Hzc7BvmgORhUMuVqdLIcRHlVa3n4UHZhRXiQ4RzOK4X/yiYHFwWnf
TGEaMf5SmK2kf9nvmgM47vBIZs5WZZXMzcE2dF9O4RTj/KbAFeCFQqaoL8Vm
ks6SbZkbLOIUGvRbfZ4Poc1I2nzOT+ZLWFJYw3KSFAUuNbzmmk6rMplNgHbg
q1+WKT2AzcAuzfJLWAdccB0kzPLjFIYATcC0ylGSwXLnOMV0NlsijcDSJF2d
9zgp08uMthxWb7HIi8rE0bDIYzwoMKRLWiVaa6AuZH5d+DSaLcc4jCEMHCZp
ZrCvFbeC8490MmW/SY9T2JEZbL/fJizJbGWWC2wA577I4VfclAIngpQUEiFO
J5vkxRz6hOHBI2nhUR824REfkMMynlly1AdxfZbDEtY0ySrofh5n8SU0OFwZ
3jdLWF1Lkh+T4eHBD30+c/N0DDOJot8g4y/y8ZIm05zxTYzDBaKPZ9DNKM9w
Mjxy2Ly9nd1HdKHgAaHjNE4Ws3yVjKMSVjrBBx7DLHDH7CPpfDFL5gmdOhhv
mcC5hjOxmMUVLou/SRHeDM/zz13zLvlc0dUH2w9DfMH/zG/0XziIsyTGHYQZ
nsMiXubQqDslsLSwJtfpOCFmMloWQEnlKJ7Fw1nC709myecUPkWwP0UM9AaL
Ao8ZGJW8AUuApwc3E1+A9YXXc6RL+AaOm9I93bIRcQ2c8Q31Os4XuMZdproE
OiD6n+KmAskCQ8ReqryQCdB5hzfjcBbz+ArPFfIjWEcaHB5S+m3M9FOkl9Mq
glOUXcLin+NpQh6Kl9c1LzovBc2jxkeVGcPzN/EqonkDO6L5IsODfRNRAva6
At5UmkmRz6lfOw78wAwbu8XVieD5YTKNkRlM3MNI4cJpYDpwgoEZywmSx+zo
cPZT3Bvgjtz/PBnBgUzLOY98llSlDAHoNIOlNDleGSAWwB4j+wM6XcJJiWAj
WRiapgsWiJCtAi9D5sqv0smGmdiX8YcK5gKzqG5gUyM+uLDjC3wcrhPcIpl0
Hw/WeQLEzFsJUpZBMas0neMPZ+edLv/XvHtP/z59+YcPR6cvD/HfZ68P3r61
/4jkibPX7z+8PXT/cm++eH98/PLdIb8M35rgq6hzfPBjh8m78/7k/Oj9u4O3
HaY7ZKH5aIkn0eCNALMdJszaQJaiO7GMgMmOinQIH+Cd5y9OzO5D89Ppqxd7
u7vPPtG/nu4+efiJLiHuhtghfYzoqo1BkIsLfB1YCNxdC9g+ZEt4OKZwgA1y
SmT9CRDUJM2IawJZz+A+RQIlnrOo4A25QecJnKCslwGvoAsB9gDYdZLhsYN7
hTY3Gdv3mDzpPqbxPn7yEEZOV+usTIhP70fRb83FhTLZiwsQjHDbFmkyojtk
HFcxXmIe38flupmmyFqVJYPUM0xwyCJTbL5t9uXCxXZhtnBn4RWMDCqHhoAx
zfCzUF2Xzil1b4DnL4FjJdWoL8Oe55W7NGj0B/ajcj069riyZ0lGIzojUuUm
zlAkGK9touSfh8gFiMz53S5MFwRJ4iIw5No4TDqhpVlUru8jPLyJyGUwFdeW
Nw7pfZGDELMyxRKWqKyYxdI5B5Ef+E6GjCWHs06iHB7CdJKOYBiyHcQD6QjH
dki/Q74JBwIoscyZbPiBAuZREInjRHC3hyhjFQkqFcjxqG84MDgaGaosI13q
OmSUrzPc0AVd9TdTkl5UTmQhYwRqVIUSMk22/J0Klvhbxy7e+5ssKeig1ii3
i1cCjGiS0rJCOyBj0UIejMfQXqlEEUgdwQC7QKA5CCz1cYaiMLRcE0fgA7x3
OWUywtHXBw+kWVZO1LlvTn856eAQZRq9D8cHtQm0D59aNy9wqfCsvUOJXq4d
mQpz2l6V90QzKLh3extBt6XskTwh0yns0pRCxqwwOOE1/B0Xgm5GnrMTZHgn
xyE9MDlbFqJdQwOsLE/hqJfhsm51iA/wox3cls5LEMqA+FIgwlf429kqG7GM
g0Mg9Wrr5auzs237VpGD7N6lLuTEl55UCXS/BWudfF7kJZ1XlUBAvTedg5Oj
jrxbgXTBwxvDiSqF0fFM3b4bPB7I6lk/IL40iUUvvYRdAFnJkwuCs2K28KvO
QaA8nXmzMKJw1gh//QBBBAPuqqeMpwcKxUKOvyyCt+K8fjQMuwm1EazpHSkK
JH7obgOFqkq2gI2APcSV2wI5EIgGrrTt+vm8jWCYHGHOG3v0OuCRxiSUwFVM
p7ws+QNReioL6AiddhEeFL4AjDtb0SLBBcYMfkPntr8S73S4IYCczGiWwiHv
4p3P13hLh8HmUHcNTiOtiQLKGgxtysNnu08/bauQKAed2ij9+0QI7zsmSWEd
Ic0Gl3qdZKFFMR3kLZdnF6/n68RyDmwpq8IzEyunb2Nsdtfj8TilF3HtZbGl
S3sb4SWI0gjxo+ZQUlI/FkAMCV9qoPfh4k6WM1NbBxY5kLGpmg/jgYvBDREf
/lAKWcqKeTqD5Stxy5aFE371h8N31MqrJWqQfwBtlln/YT7HW/xdPE+sjmoG
HVLy+snnGLUbtBR1BtyQkxWCG4B5s+j/dJO4x5F0DtNyhGoAX4EnRU5Dh2VO
ruPZksUKPKcgVOC5oPVnSSZy9Ah0PKl8VUIEU1IIxF7SEGa059ohDwdeFXQa
c5MPSahh0wAfMuKDjXmEjaP2eofWcX1g9e/a+itrZZNGLWPAF074fkFVDzsh
AcxTsqDZ+RKtFmyJZs3xskjIIKXCG0l3OLhJKFajQggNuAGQvAZ6CRzVdIaa
nwiiMOSCtOUVTT8d/V3oDbid0pvIqgckwsZozPC5iJ4kyzDqom2VyzldL/N2
ZVuUfciT5/kV3h7WcijteDKSsj15AU83tpZMJolyfeK7sB8iuiIxB097wxD7
hnCTTZfMHea0bu1OhTXR4r0+Pz8JmJVrMzLhWyTTrW+UfmYaxUsHNcy1OwKD
RNYUyILr1uSWrYF21Ky7eWu082BzkO/WtufXbA40U9+er9kcu8d3IWsZF/ew
gZa6uK3LGU1LjFsj7YfECrfNtJbBiI5h/eJLHsj7ZdXLJ70hMo85f6/2/aZN
hhRvssqQQpOy/c1aoGQg0ssrWPkuv5lmbMmrDcoXpqihxkLca1FZasvujAgk
PzjRx3bXoggpR97Qrqndg57MiKqF9BALNQ7z/AoapZVr18G7zpCh9rw27mJY
7WAbEbSuak/wUG3OSra/csYN4vqb5qtM8pbZ2mW+Zb4VXutyOaJ09vihSTJ0
cgHZ0W+tFMb0RXIXUxXeVsHBaOEAP+dpZq0vg28HPXR7BKOhVmUwwCLGqBVf
LnE9ZCy0Hi3HIEJtLcObds16+ePAMc/S7AoeXWYpcN7Zag1DaDse3hc0UksJ
pfqurP7RiatOXaA6r7FZWV3PM6gmIHWzaPtkVpvmZRXN8lFsGW5tYtAdm+fR
EwGSJNnNwy7Tkix4cfTh9Ag5P+jU4zzhL9kINZom88TurRuBmccrHTEySOx2
HI1gq4B5sbnYyB/6+ZWYv/Gb6HzboVmYn0xnv0Nj/MSvnYd9pSVPJv4FrYTo
K+zBQSxTMpV+OH/VeypUwa5NMlui1gRnlsjAsn7qTYhihrYCHIIQkb+9fjOL
HDRNFEmBMGhN5ngZoJ/iWyJbYsYxvq6zhJsRdDvRmDPnUbZHmu3+BjdvRoxF
T6w+MEuvWHscZPkcrpQsKUdp/q2nQnwLq+qrFANZcJohr9fRCbRTkSMKznG8
gEuMVgOFexhy+cuSzB6wYVcJ2qLpleuH1IwdaQYEUeFbaJqYQ1MobXeRsNHE
eAnXfYJ2VHSwIwH5tnVqCBXbB8+ePv7kEQSN8RvorKfju089a6f3seUeNumo
IaBkdBSCWAuyFhr6RzH6YexVyocGxWl6FL5Zivce5Y6xagV8I1olQdWo7b7r
0ztP5NqATsa+jsKed3MJVJjxpMhZICMV4oEhXKcxPfgR5Kve9xk6CMjL8Hj3
0SfYflC1Bvf7KHz1rvDH+7C1A3dYqR09sOpisUcvpgb60T+IgrhRo516sqUq
XGayzFhL+vdXMPHrFrOrymKWS9QNWe5KCA0UeApQSzMoksVdoDOfE4eCLLxI
PsD/IUzZ/9PS9x9h6fs7OMH+k7r//gFtnP/YrrG/wVPDxqqSrA8KmFIv0v90
vfwncb38Z3Iy/+fwFvwn89TSb2gHVpUZQUE9eGRMkiprR911d4Zll3nRurKo
+SSzRU044leWBMFFZDVaEOn68C5CPeF0f3gsxB/2SVLM0xLPHqvRCo/qWfWX
7uGY0DAqBVmRrD6enLW5eT4WyZa61OW1MESv/1OCcRJ8r1SBuTYAxGEXqQVH
uh5gAHfp4x8Eh/L3c4GdoxskGQcyuj9+owBmuGlLlPNxy/CdG1CIpiu+ytzp
Cyaul0Hu2Us9Eb/rAaapkXkyHwIJTlOWmYs0FGtAsxWA2TARhsWWozgT0LLo
aqzOgiqIcpnMT+ytXZ6Pa2e5GJMuTWi8Kp3LHcao8sxkyY0/ZFHmbAfSDstS
SWA1U2EyHIA1wJwsQRUbme+TFeu7eHuT6+EsvcxiuijZeAHcmlcYObZ2pEwW
1Oh5UsUkA6rbiAUhpCH2RhymMcKZP5y+Fai8OiQRhxYv4iG6rkAYZ3r4ePDj
KziAl0rfHxGD1juA//8xX/ZeIVdcoI5FuHeng5fs5qK5sEYj4s6qbtAKDIpK
5IhJ/I15JRpk2YT6MvquxB7hLgK9VbVNa+IhETZLkPJjGBCuZ5xFFs8bq1ho
gbazmWzTHJvI0IkHsizcj2gQYzMEXjhVHvEFK0YoEzZZijFiQjA/f1w4pd8E
KnIUydGyOjPbd3ChNAIAbSAoyyhzgnNmLlD4KC9o6aK6iMgWQtNU5Qi+Gnan
xg9opc1HyyAeezRisZWJ6mcuAmHmwptgw91pZ9r4pWXKJH0mZaD9i+wW+d7e
houXqeYUF2c9xeACWqqhhZR7uGVtIln5fVr6xkqTDKgHuLng9LusSvgqRkjU
LA68DMEI2LRCgr1ybfYVyQJFII8zV8dbNITlz/kY0C8lqRYW7yxCOt9f5QVG
WaChy7gYijJoC4HGtn8kovrQkSPpKXI9kSGJTJ/EUEhjU/u9EWcA0LDvIosC
I5Q/Hrw07H3i9tsgO0JDJolVuQizkcPOe+yLYiasX77uXRBGTo8TP8N2gOa9
gAs03lf+FRKMpRvoW7JsbICOSrSh+pQLREFUUScZpIuGjWodZVgLjCgJztca
KhkkuYZbVnadycXtGJ8xta1ESiCMlG41pDjiCyhMqEcMjz7t8P1l1lALtH2h
9tDneX6FJzy6eMFEUV7Yo+ZRFAtLjp5gZYF1HywWON/P5pCM3/nwZwTYo1xH
0HzRYQg0DtsaArQvlzgy1CFc7AdPywnEItD7wHz16cIvqKUgnJ6A9d8Ryc+I
yBhfP0snyWg1miVy9dUZFcuu0A9ChGhdYLwUkVTiFOlej2DggfmWaLLbatLl
/WuxnOJo+FLhKCvr/AZpIZ9di/ocKuXz+IoDMVTBUL1rjT2m+R3caEVBWhFF
Y8HxiClsqKYpd+1u1163jto6wsCnemdCDQ8TxqaR7Rt11267TRgJVKLy2tQi
GNZ9II62yeKIb1KEWgC1Nc+KCNysSlUt0VZ417eYIYQ3NfShcBD8JQ6+wm1l
ORalOyD6xDfK7Av1aixI5M0bFxdWtm0pJVSL12Aoe2cwqOWSLjnz0qc9ObRR
9DyZ5EXSTgeZ9rdBL1d9sL5NJJmR/OIQFi3bxd7dSLnKlufobtt8eBzldUd8
9oFIm3Pey214bJ4jIdPSUAgTMrkzjPqAGwK4AoqOC2TUCTUX1awVNUN0uJUB
eGTLxpNEs+Q6mdl7aHsdqKe2ECzT8kjRz1p2o5CB3KkVM8UImYxuAnFvBkQo
82JBjGU9g/DwFbM+DgMr4YKPWSKvJNwrbe+N+BIdhrQI9tEKF7UlkyNGcTd5
gMqJs9LuahS+pRyeAjkZgwDqI1N9zTQtq6LMz2q2K+6Bfl8tiLmRf6OyjQGx
vz4/fuu8rMAVRsxLIwQqsIQBSpko2KzYMSOwg+KJYRO8wqI0vsX3+YI5yLzR
ss6TZ6t5vixnK3OdJjfMOq0VQLSKmnjKFkESKrOVCwBW9whMMdEJJiqcOMey
m23Es6Vbtk4iEuvH66bBzrX91P1qMMp8ORujSkKrg9KVethACKzFvpE0TOCH
iDVClubgZRCjEdeJIakeIjRYWU9CjKIzNvDPVl1rYWCiaFtD076G0VevoWmu
ob10aYPFTe28uxrpLPHMfvgknjsroEW06gRCGy3Rc+GH8holSj6idrK89HTF
kIykAu/QWrxQWzOIisAuETbocTlUsjEWmKAEJFVFPhBUja3tEcZ0zGryh5JT
1Cp/WD4B7AOd84F7Bbc52F+SyGM2o4DGeoz7Nk9gLces1Lf6y3mLl1lJGGGJ
5XNKDFIvbICNu6xTMnoAEmtWW7gry0fyEHiAYUXegCVKPSlbWSfeHo6+RUxO
K9Bp6D5OA3RFV4QSdwxAoAWaKTi41KKjvSMVoR6tAEYRGPHsOMtOSUcgQSUe
Y8HVfYHe/cwNiZUM2zIJt6pgyUqWxC+xMdDbF7N4RYRc8CVel/PcsgJj3SRX
kFoES7DMaHlrnAc9G6xfjUWBx/scwRie4tiEnamCSzgxwp3V0LgYfp7MFoqT
biBWPQ9aCDRt7XmJZpLGZQf62xw6d/ITSVmVD32TRgNoqde8G2zrbB0ymYWl
dixvOGJrvs7i6/SSluhWCLBh38PcuvLWwtz1NkGpqw2En05aF9zryip7uHXW
aiDge72eGgtobogdWjOs5Zpwvibic2kF2+sqkHO97akbx2c901sKNDoSAkkL
AcR4yMAFIoIECbZuxfjqkEuCljdbSsKERSuGvL9mJ72+1fDrQcxB8QnQqgKy
Cd9jYA2dGrhtGzoq+0NL5kLiF719MOx8bZ+9YGUa0QGNoYmFZn0LhwzJxTQg
CfoYqTWU9TEOslzBsfpcg+sqzYTnKmpSMyuRbEO2nLFmZu6uaUKH55lt2Y9w
8h50JblgKYZcjt/gPjsHeup3GjByLUTgNtZHFCuDGwaN8UYOYpe86f7PIJAN
1AExQIUQBt87B7lnoEEVPNRpgklQoBE0B+mXw3y8CmDJ5s3Z+3cuCUDgibY2
HvRUKum7qHyRn0Fnm41LxktoFoN9M8AtW6CGrua1AQbkOK/NmtgM5YH9ensV
npmBeL+Dc2T8r5oUR23ytsGYUFTiW7n5gsoGJJtRf5T7hAHP7GXKG+NCyfPo
sDYwnVSg2Ar+Mb11qgR+xRbfBSa0+77pPp79jgz8Pk7WgjZblrdPkSLWc5Oi
qFA5QZ82Ji4tA/RZYGN8iDTF4b0OneaEaV0X+4KCNiO2lpcIUSFZgfGlJHu0
nQtYvQDUr+fh/O2Z/Tcll0ovCSry7OHe7qcoatkHn48JLcQcDQdnA8UUPxaN
BaUay24yWRH5RHTeyDb6qOVko4Z53IHHReg0SUqmBAfGEn0G3e3otSWzgNJc
N1CubVueLsawBng1Jw8UEMFLVGpSNi/UF2lK2pB9mhRTBipXa0+ss0jCSOxh
oJudMvn4cO00PGbBgCNKa1PBuUxxuQ5mZd4l16d6/GzbVktlBY1MZiCVx6Op
M82iMnadp+NolBdqUKZ8RXQY2Q0bHbXFuNxVdomdP8OJKZP0czIm5Qw7s77w
NHNwnSrvGvFowLmBx2CW0aRIkl6VfEYDxWKpmaNQUfKGI4oFmVVAJ3BJfcjk
SMmZInGmpm0zS91exH4ONfxcUlIy8b7InpZi2ypEhl7kCwLEU9M6x/BN5wdB
qa5+lkunwVMCoyWnMGsJ41TFKS0j0LbgN8nNRVcPMy1BmvhZiBilYJ0UL3CL
dQtzjVR1Tiy7o8oRaFDYOJqLlI3iPaxYZNpU3vymwxVob5JeLgvJJeUbIN2a
yrF0+5AliPC4Wr+UfLtFtvVa1iPfHBLASYJ+NAIjku5og5alMl8WBEC3YWqw
8Rq4yRTSgFzSLld/vQgnYDIrw52vERbluYYwpXA0EqRq8LSNguevFpWk/Zqs
JN/+xwlLTohouwRvFyHWShDZ3y5B8DD+BvlhnfgwvVV80IC9rxMePOErEB+i
A7O3s+O2F+GRS2cq3aTXgBgYOXRkH1p6eJeWWOEnQ991PEvH5DeSWw84W4qS
ATb14Pam2iQZRuNYu47z29JlzC9yB89u7wAl3XiGu7GyWLl+cISbN6QcYIw/
EbdeiK0SG260fmHJB75WEjO+JBZtWAmRxRYcuVMT3Vy3kd+tejzX7TyvF8oi
nmPEntSQ5JozY0US8d2CVrBcjxBmSAXZvU2yWrfxDIlHURuDqAlqaYhmJHZ9
oAIIG8G9cwF8+lXuXVcle9m68CP6xjyjox43Wgg+xXJeyQEWiRcTxSWlSbSk
a5y7Mz2yyyjJGGubzJKRbvIcI+sbWVv7Pju5kwF0k41SsBtsgrrFJhoFNlEB
VXCy1a+wgsrKeNZP2JXn9eUlwrCrxRItexZjL8aVSFHCTqrIhRFYEVuRH2Ru
JuMWQzsZw6GCaFeFRBGJNR8kQwdFDZEubWYVpGMBZVrZEaRWgoRyvxbZxx5N
54H6GQ3d1vbLl46a9G2kgu8MJ2pPGMXmd6FMKmL7spxDDg1tzMX6JgtmEMrg
5N6ONPmmdxxY6hUxD126XRMgVsifL6lm0TKAjiM5BWi7dxoGGdayS2tOxxQ1
eEZxEuRRo698YoosMUkQB1LMPB4ntgFrVJHTSTGl5GSSjL4Uxszegg3kGVPT
5ZLo8F1OMj20LmgfwlmUq/k8QQw36hU0XMylaLdMYfWR5+KTMTU1j5rF2zJw
QlUwFDASims6K0UYqbsiNFDEpcCtH/nkGlU3PWjqU6Gz7aAbPsUpGWIuXo8g
DKEYVxGhltUJGAQhzEORmCWs6Nxex+TW5OQH5N7BmLKS0+d6UMwiUSvAGAPD
xOAVMe50oBQtga641wVTHEK0LzOKn+LWShKff/tbGY5KnvTb/m9/i8ZFyVfQ
W5+vgOg58FfoCP6f/+1/FzgHtFRPTGAoMYExLznSeh+Dg0XPVgse2gniR4/i
Z48fJ73dR6Pd3sPR8FkvfvBs3HuYPBw9evjg2bNhPBlYP7Xxpk+vNxJEDfi6
HeXzIY1HXfso0N6ps29bmrTxGXRGaytG4QYUzzD48fzD7o/nV3vv5h+q4/Mf
fj4+29n5ce/o0duPL7+8//iH6t13H3Z+/PJh5/jL1aMf56/mf/huF357Vw4f
/HD19l/e7QyhkQdvpn/c+7AcPniTcWQ6ITCBLkvRLVJ/Mz2WhIrtnJyIPL5x
guMDLtxlSzycEFCIKvWmUxC/7lMXTx/tu0QPsSZp9T94DuMQbY4CZbZMF3ho
+kxphJTwCUy2nAaNHfhuBL1MYgcL7bqnE8GFQyM2+IauP3IBWTms0gRJsTVt
I24cWBapKj75DWz++foW37+JV5P/hZr6BkOb7kKUnk1BhAmL9hZnkjqFhZnK
mgX7F/FaqQ2HP9WiP0YIMUH2K/btmVtjfBJlnZq5x7FIb7kV9U0nsBmvMIhE
vXfOIRt5DdsIU/VmKuK+3n6VjEpmw8ekwny/ljoDM4tkaEY0/CWNCAYWtY0J
yLK4TKrSgrwl//TB+DqGwVwiDp2DEVzCaAskHSkuDkP36wqlJj3WxPLdiJN4
2JjNSb7001C71Ne2a1iWV2kh1i+M0OXVbyDpzBBkkqtbArl9EDFB4aiwwDQn
5o6m0RYBZQ2GjM4QpqQmJC7c6aOqHcJAfXrB2R7GglEDFNEQxVWFiS4KsbeC
GoYgk6QO4LOQomZDXQx55gTQ7Had0LqpOoMxxdYo3izToCHh0XofPBrBsmQW
KL54ezNJsSA3RysqJrRgdF5rZyjMTNEYS8IAm61hkRuIk1ogLYepp1nPBTaz
XDuEhevBcHsTDN7aFhOeP4+a65KMcf7JSDCsmFguzzoj4zDdRlHbDJBnqmw7
TLJkkopUnYoI7nUeBYuI5FyLaMbbANlKvRMUnUbTPCd7XOSjTVRwFBk1ZiDu
nBJ5UNT6tYBmEStOKWYiTiKBjWvSf3SSwOWVEWxGENQNMhtxPm93pGs7qnZW
VA5a8G822A6TkqMMNRT3gSpJvNkgN6hiWEsWIEdNzNMwyGVBBp7a4zV8660v
zH0cKWWJ7wZKXcRKXWoduSqiBUnkyKJcelO8Ifium12EsyN/hLXqhxOPRRSm
t3ENfcKR6yq6TK8b6KgzDevFqGDyFiwxMgBZMUGc0gDMZ63hU5RsKmEPCwqT
YIheXAxTUDILB/HrYcIYG+BHlqm0AFpBkRlYPdXAaAXGMymkFbtKyFxLvhLN
xrMOtNyEmgsxqcCR1xm/8mFMCyEaLUWHc3SXICSQP9ugZCyzkIDgsIpQJ7mM
b6W4UsmCDdU2nxBXUkBLzrLALdYM+JUWYsCDhe+Sgl4k81z3kBQj0J3vYWkp
em91D7F1IM1IUQUyVJbuULaEWCEVcm/WGQYaU2NFyUockoIHNfqopWSm6hsS
kx9CjFFAAdkJbhTM45lkKVf2UO8L31bON8iVikrGKM0bcNuS6nYsWbOezPJ8
bAGfnuxER6KmmdczDZB+gFcjWvDigtaA4+Aul3j6kAtHsLUgB8+RCQodlFaT
JLNfPf1peJtuifl4e4MhFS0FaLOAA5jyyeYbRMJBYsqsFTQqebpWhtruGvtZ
e9sYCWLNnGXdsd0yOLzyCZVqszCF2fDEFBJTDNF1yrBqm2DOpacTuFjTHm2Z
wm+aaCdBpPoVbg7WJ2qKySs2WpZeujwdlEKm2L3pB4i7KA8i7VDk2xjLw/jT
sC1UKNRPGXqRPIMBKfku7Dx3UGH4/sTWc6Hvc3Kic/SzgJR/GzKYwMtEDdfj
Pdb87J1s+F7Li+ybZqqAlp8xAUPL116CA3ZAZCj9EAgxLa17qn6n5164NlCN
YufYl1gXmR3vkot4w0N+Yml+DLEJfPTReEvWm2zsW2Zt9jWNU44xsg5ejkWK
ozhxhtwtGBOP9WFauyfugvywJXYdWMOEknKstnmlWtDyLHWDjIqkY2AXV2Re
JruSNTaPpgkqKznVtKHdZIAEYhoyPGzuUeC69TGWeke0xz2gSsvqCV9/1Axb
vFlktWwBZupiy/2EABatQVcIpriyaWjcfO773gaZUlfyLmmuz0jCMTUrEHAK
JDkyJq+Jq8ukNJB3ECPxNNGZLsj5MEkqEnvTMMJ6bZI0lmBK9VkpvBbeBbUV
mKekuP7h5J1Xj0hneXQS+ZIfVU2TuytEeuLo89FoScV3gI9RcH0tbUwrg29d
C87+I5t8r5l77h6ZZaNGlJe+jx4VyUaWc6DmvZYA+XsSK8ILA9xa/MyVl/hR
Vo1H2RwISVhiUmZghMY4kYPnZ85JzsREO1SLMk7a8IsROe/DzArtWC/kVLtY
T5Pr9KVsL4+DSAkSxMSiwkcUmBxJ4oN/nvwyzn4P/ZEGV3GuJMJyxBJlWTPk
bfe5z719MhW1rIeC3jgzUwuhkKoWEXv57uW5E1dzZz/jYTUzL3LfD/bZ6kca
IOZ/ljyf7PgO4Raia/BPiKmIQsyFZNxkbYLtaimmbL/MCXeP3T2Rbh9St1mO
DtdipUASnAJ1Uh885lZ1tuS4JHaHeB8BZEmrj/6/mcxjN5kJlnxkC1xgbESG
DkcfTQz4Og1Fxo5uKPx8RnKLKIllUi2lwFmR4ApxBOVe7xHpgV6YEsr3UT0H
LiVSJLk4tETJgJ8wwREsJpy1pGyllClWutM7WcPBXhEahm+uljZUbBGNqIVV
CF1buXKttGQabJ/lJ4tKYWc0iMXDHFhTnG2bHtrgrVNKpUzJraGPxxWZ2VOX
sDJoNV6kP4iEsMWm320BCusJVAEibMNYocMzZptBZ7f/oL/TGdRGPj4hdFqt
B0xRLNzS3nTXQFWSirU+7rCj9TZzOEE0ACe0WcexN4ADYKvAPMcgiA2LmC8R
B/Ahv0x7x8critk/q3K0hdWmWoi4ixAukH3ioohX3JvFI4IEUVihmB6T7uq+
bKAW666sXXNBAhJnyjH+710/CE4C62zBTZxSTFDWZG5tzjhEaIOke4khHCZe
HoWa882RsY8ZozUM1tllGQrmbbYwMSEmf57B5GLKTWgc/qLf72/36atWdwad
PGvoJ7XBS1ko2Z+83roCWR1gpwM9/GhoJDOhHaPke0p0gcIhp2VLMlUGmuwz
/F6Rp420vmxqQjUX7SNBs9wnr/ECg8mInXGzDG0ntcmnKQJ66hrb9Mb+Sots
IG53IrS+7K0MidNRd9Da0BmQD9nMYXfnyzmo2jNQJpXPwvoMOpSLtTOQ0Cx8
0SF0OwPeKXdKfuJmPw004aQUEN7iaSoHcAN2jzgVkAieFUY/G2upR5Rm1XIF
sT2ZCIS3u/Y6LYItxqtkM7hJhuP4etAlWLMEzJO71iUmI83Cz8jjhp269aq5
94z513/9V5sqG//+FHwypsNdd/ZN535ByVPuw0dkZPc73ZZn48WCnoX/rnmo
imdX+kh5vwS5OhnDv9P7neDJvwTD+9M+reg3HYSldv7CY39lzzbuJA+0zsir
fNHj7AT1lLgcUhRXyuPwz3ffeXZeYVGat9qLa65FQEkzIjCy5kPQ8WrK/laY
7ST9LDFkYreQC6IUnkIzgbVZPxNqDmkRHkQAYPmVs+B91Lf/nSZRYoaIdTPw
Mr4zuwbleoA26n0k/IGMgJUFCyAPC1Vh+4REHC2s+Z2MAffFZSKNoGmAs/yF
1Xd1nAfZyk9VZ8vluvNvk0KcBgyXdU7pJR5fY35z7AZ5ubJ050ol/w/GU6CM
NuZYP3rRWxUUOtjmZNPtKeyextQPJAc/L14b6w0z2ftPOwlJ5cO0rIUsHZSN
HHLEmvwI6TV+2UirfmDS/FkaZ5yxrpH9jqPBySFGuc4YpmzHucJh+Fw7+cyJ
XXqEOcBqvXzie8siBW4unn5eB05IqOZ0svoXfM2JUOfJuSBmiHww6Agwsjef
xB0ClAfhrXLK6nElDMGNo3rG9nuwZq8OFJfEsTCcHYGXj00BaSF1nfs6hnCe
dxqGAhVwEDbvb89ugD1DanmTHGy0BdwbF/UGLScyFmnoTLhyJupp/DeQQWRk
ruUU6Kw3o/aGCTxfMP5Ep4vCMpa2uNtE9fjLPClojfU4dQd79j2y0unBLD1b
oTIeHiTCLyQkhs8Dtvzk0e6TT+q0Cism/HxzVfYpPMITxLnOlMVuE6rb4zQ4
UwG1tEzUJs9mX569/xnZS9aPqF4zCg1Z67OwaiYT8qDZRJGyKRoIwOBKqR7j
vFWeRd9vYXFZxGPNnIljpvPEdd2B/6DEoU4QheJtK3JngunsZBkyn1ncbdeB
Qscz4ltZvWCXpV9OLkUGNknRw6lcac3DLeghdOkrDxZBcSIjYJx1afv8eXrc
6WtYCWWfokM447gTuRXYjAX3nKDBcSMbIo0laz+B9yDQ/AYYBFesZJA2/TEL
v3ceqeMSt4C5byjp4ED7Gbg4H1uBCNmzcJYVKRlN0dsL+fNUPQmXp/R36D0U
WD3u+4AvPpit41m167PAcjBpvPbqtA+o1L/g0xiZTROWyxNV6aah30ZSc7yq
89ViVC7F350cRVy8oLzzpakDXc7rNyaxVjFG9ixvKlsuS70qhUGoMXff59Et
DbVSC9pK1FEr4VzkqoU2HIMsrd+3SH6mGEU9NnQ59PRY396FlzWCcY2WI9R7
YIEVF/2nFwjzxCDiT1u/Qchnb0JpHIw6Kbd1NOohoXFQVhM/6AAaJ6AaXhux
JJLmK/3oJDJeXBg2ZX0O1JamePnVzTEro7YcwpVkNEoFTAgJXYpxkCWHs8V7
0PJCLxCJBNp8ojmUlltBg93hy5PTly8OztHGxFcsJoz2tOkPZRLcvWQ+W3el
2pOOdAh8zeAVrxwhPMEtCaQ9hQPt0sQvSVJBXYdijkkux8XkW0/TG4ZAc0Jr
AHnBgbPA2FJp0xoaiHuS8Y5Lo+IPhSuVsln7543whQIn+SqfcG5s4AM4H61p
6mGQSASZWs/Lh3+pgTYlkezRhNNFMXegnu/DmUo+9xfThWjioxRdZ/OknN7n
JemQMcqJRqrSZLXr0LI1zs5E3QOF9TSv2GBTV5GRDRAs8Zf00VWef798kF7n
0+JZ/F/CRf6miTUPqYJaedli1sUF1FgTZhQqulldrSHCE300ROQ7SLabd75N
yve2n9I8m7XbH7L5zdbm+9I8oTs2iesYcaHVaBSB2mLd9aO9W5K4BDlcWAwL
U7e0JLcU+/o/aMIWMjGFxeYo589d82l4jhpnjGcJFSFblkCjoI6nEiqHO9kS
XV7igcoLKsEBU8ULdImxTXXqpajDyahCoHh7jqwznF3hmsGr4vJV3KnAdoiP
iNsbiZegxfAmWyEpEjYgyM6j3fHowc54PHr45MH44YP48c7ubvIsGQ7jx6P4
yZOdby/hnYoqk/tLEhjnocF3XkSzncpWWPFpO+xZ5dx+9bnqeExB9o4kwmDB
1Tji//51XWoaCXIUIQYQRZOzIL8Cvb8FC/3jwfFbq3Haglz1VMvQQD9YGN3l
o3E4dqxPKcaleimDWhkQVWOtrwkxJTiPgCQkNxwK4O5F1OoSCZDzE4/ZpAhG
tS26ZsO0j3QdXi5jqqLCCMdL4J4uLQmNPiSfJ6Odpw/39h73xs/i3R5QzuPe
cAIfR8loZ/Tswd4o2dn1VyfHYlYem19/jig0AB7XGmqucoq/oY8fPHo6fLL7
dOfheBI/jYc7j5+NJjuPkvHucCcZ78Xfxov0Ji2TfjYLdklEqjsNRFy6/okV
VaZ9TI/2ngzHj4aPxo+fPkv2Rg/24uTZk4ejx3t7zyaTJ08f1cZkyZ7W5pBj
cd/Vjpd8HSQO4LWsHYBgJIeYeh4UWr8XnvlXdLNuDdZ3+yafZuYwTzoNHnpO
3jrXn9xPJALHLoqFXT5dI64iwrH4TqIuS1J1tTdR/JcHnhlY3j0INpgKVYnx
sxGDbcu1IeLzUrIDNWNRJB8Qiae2wKAkwq/an+XiqLWHcfh4MheYpsBGpPlR
4EF4bZDRBrE/pGFKCbjWDDOuMF9QjY1DjGsjjfxUXUdi8Hf9cZRwPUIdWfns
mkmCc7GzxYE9hyVa6eS6IjGdPRAS6HxwcGTKVYl2XVoeEbWcwYBWq7znytL4
aXnLBNPMY8psQgSr7Jdy6TSqB1aO8kXi3AKKQlDhcuqEZs8mMKPRcVLZDVne
sbaGv0SwDTLcyLgBS/UD44BRwNs/r6jgw01c2NQM+ItVlG1+QUluL6WMrEnc
7knfP2a+8cg/aadtDnMtxGgd5zWnuQY3+u/TsdAX604HhV6pFReNIjEFjvIb
AwNDnmo0BLtUwxgNGHESz2dplugdKP5baKQecGIJ1WNvcBhSIdUtBJpfggwQ
sfnE+4nimxVcS3AXvjExyJrCB6R414fzF/wsI78/ZOlnkyzy0ZSXJgf2ypUv
ua5yWYKgOrbsSG9bl/2LhsDJkeUG8hJFLXm9cBHQ7jJTvsA6vyy/lYHJlBSP
ppTQYbHiCx2pDUuMWBQSRtQjV7BgGE7obZLJBDOPwKXOqCW480up3MdIU7Qr
81qVdpF9GYftfGo2gC5IVBfoAWea1wJpYttjjRaREM5BVgcbOCd4jFUGep4r
vQrqK9Ko8dIesPc1eCB0mM6s/RmaK8up/6isLrUmgnTglCR35CJOiRm+Z0f+
sqywYpUdqTW5x+Oxc8JMlpzF3lhkpL1MnJW0VNgXcRiNc58WCaaoWQkL0JrV
xKh4gfetNIzQy7NE3B5sT2Xkpmykf5Frv3RhZRyDFPiLBDbM8D9uBt/3zLN9
1/Hev2/HtsSH15jslk8+MpgH6wczoAt10PV7Zm39q/pe1/OuV9nZWbG5HTIH
30APmNM1FqNp3dSAW46B9kvEgPHy4WHUDHo8huQG+ZEFKzq/HpekEiU3TDWM
4QM4DLyIuPwYh0KNZapEoPDTz1ipOrwTkeRwrB85pp7oDycZIo/sEhLaUZUE
R7jecfUsFMH+aLAMBXQklbdftFQT/WShmd3AO6wj8Bx7sqBeJj2szC6rBCPK
5bbVEpFti+p5FxPxENHZR6G924T5EEYy6DDyPPZMeJTxaeFwrTalo7CLnPRD
5GfOExKvZrlYVtE1DPQiBidir9e7/R2UgWvkREZzh+6gTGZUS4qrfzvkiQuv
D+nzI6cA2tdAwCAhTDnVoLP4hnkVNAEj2f2nyAS2cfWJEuzQLhS5evQ8YqyC
TMJ/0wfR2Tf7fpyPnlhcGNs0AzbIdMRuECsRMBm2Q95Ki3Wh3KMTdy3Uilvr
SZSrpXBlDmpiAJBaTBhqgYwMfrrH79wjN84BJ3FByVSBUAP+fSC3vq1gLqg7
q9sUvgSm9zm1MeGkqTgwBQ2RL1XC7NC9UOQ3JQVPSJ9441Wfv6ZPejOUIwLR
gZciy30xy51a4iqiORsyUy/TihrCyHJ2c6+yEcpAPYlev5Gk2CnDilyrY0UL
YTOJZB+Lh8DagGZjlKIo3oZhHs5nInMTEZWT2lAz7NDnbPgLVHEQh5HYsONg
lqGwCsPjkZAgZpCByDFsDQ6ypT51LJqg51JnhPjxtBj3ODJZMdjkRUxGS3Fe
hxJbKyzFSmrLIvW1ACRAcVAHVaICmJwME56LPGDZUMuVXbOczMgUkmz4akSQ
Gb3g9FHTRGNgFIUz5Yvp3CiICk/IEFRJnCr0z8w85E+9mklhfMZG/tosxfTv
4bPqc1ZMoBQ5lfUPPAOwEDmZVnGzgOlfMQIJpz/LLzHQmt6yCF3EA8QUfoTA
T5hAP2RFCxfs18qKqDVce//BGgeiSSdrWUk8HihcCD/0bOoCgu+pGWAMW0GX
C2kNqD9YznCD7mnbBvsYugLX4LtMUkpJMfA8C9bTtkPj9MbSY1Vo/VveOgUY
rI0LFTxp2RavEe/LZDmboGdZ+HF7cbS2tcRMQ+gTQ3TZIKyUgqlrQNPT1LPH
rw56HlqR6VTNtXzZLzk8u8aLrIXXy1zDt4aHbBvUQHZucKFTqjZGj5vncizF
NkI2FQaG+ydoIBoQXgnJWKJr1FFEfLItpvdeaf4U+PD+4hBtf4dlqM0wXAmP
Ysr0SxIo/KJZ4tf5JLzLeNOUgZL2ZfFWxsswjeeY+Bs0YC9MpR/Ei28SSlAn
bQold+HLInj16M6mKxKLbtm6YU0Uuy/2s0FRrQn4AoyFCd/XhP3gGD4xnERG
+L6GGglnvp3vhzZIcye+b3k+z//ubB+X4xgRIcEC/i1sE1u0rCqsHCVGBJw5
PsX8FFO79NfyXGaSymGlOTxbXntr2C0Q4cwkY04kJqyy5U2f8NffgV542223
IUuP9JqFmXsAhAD4TVdG6EBfdw7Q2vI/tmRuqb1VOm9K5l2Wd3FPYXEm5V0F
8twz0Xm9sfivYdfM1PH8UvujxUaBU9JM/3sLnOdkDJu5IIIaZB4DA/A/o4Vd
Io/aeKc05++3GHPQx+hWCjy4r8twHzELAx/Fb18ZqOoyQmRjVs84o+lv6MQm
IXwP836H+YjdZsuChoXWkIqCoIW6ZQBjyqmRxQwL4eEuNe2N+2u8DR8It4FK
jRCw5G3dBP4armzqZ46ipY3jPqkN6K8bZJlA0IhLMgGzyQu8Q9vL6Um1dAlk
jWx6j3XD+fXZ8De3+vfMi0+Z03c35BC/w1DqOdTFkYZJD8l9JkfYC//1o+kE
9xLdgnv5G8oUed5fzcN/6pH02PMCh9dNUOtIwYNlWxsOQbilQUaaAoKRwyoC
wL20LFDgtDmXrF0x18yaUk6ciJ5WH10bdLtsTk9PCFAPEniD7MHLT0/CAlpF
sJGNe84nYxRnyCCQbH1xn/N4a5YzYaK3Z7t3tUqwUXvWOGEg6V0RgzWwqUdr
x+dlE7ahBZaXiSEt0jV0blduuqs5h11wp34TBpbGkqTR2jV5UOvnF/iVJf1M
gskmERe9zOwdKYV+seiZWLwx9j0uxsxOWr2uY36CbeP++SNb0UqzlblzwW7a
Ysn8BV+rJe+n4AuOEx0uW/Po0ZIKmBtvTqBsdAzZOH++7/UqltQtPg6Bdtu6
BhTb62Pfbhva2t9xY4io4Ykst0PzUu/ldx0omqDbhto2UO1HBUpNXtU2Sk3w
z3WPyORNwdVfPcDa8CKzYYDN7G0KEKckSO2P0GF0efxrz9nanvjYukyIYdbM
LI9sNNAN4TUU5i0Zbhrt1+q32jIaxrMwtXRYKwKidQ7bMkEtM5fCt6XQPEoE
W3yStmteN2DnfkyLi6/2BQPM/oS+jZTS7VF2IvQd3ASMQdiLMFV3Xc4kJzI3
Tf50TpCqI1ozHhFGwj0IUbNHnhK95gqXrRUW05bmUqE8FSaORHbEtuRWEsDs
TVyYeMhxq7xQkr8dXf14RaXZMP+shY5BFLUVElzLcxNriWNdjqB4MkqSIEkH
3FBc/ZSnlXOQJlzlRMtfo8LQOmx2SakLUhD3pMv8LIjxSBATOSWQ964QuMdy
zENCyfRpNuzRoUCpLCzKEwXDdX5LLqhAmVMsDtrLPlTb01Ba3CgQr0fyRMp9
6Ila+dGQSXQ5PRMJWsqlbB6jW3n+5mgkpdCNA2D/iXdcXK4ZTtfXemneCQQe
BOyFWPCG3e//j0hwf30CiBWIwKmrlOKV4TE19uKMX5zdlKX0e2evD05fXhy8
ePHy5Pzl4T3/y8OXL94evcMvN8OM4Y1RvkC3tSXLWtKz2lis3idwTmZ9ASuk
VEI+vqoVX/Yf0nPwgBevZI1cfloAK/Mj5mScLIR2xe0QNOVchL68G71y5i9M
yRq8ItZsJEDOXBdYamaMRImsWZuSC3s+VX12nIxmjEtg3tmmJ0YeCrxK5CAX
Vz7DLV1DFA1YcZEk0rvO0jmI2QViGNOqOW7buBu2Nz477kguXH5WYSSKH2+g
zcNWyP6HaaYiGMFyIbm6YZBoVsLAOTK+NdaX7j8drAwvjloGZ1oHF5aQcXRJ
mYmQq4roJpV8YsTXSmKKbGVTCuu2NKxoPJAi51uOOzV+0cUi7NKs6TJa02UU
JCgMk+d7BpoGo3dZQKIGT+M6PC3XH0XVeQotX/9FeplmWu7H356+WR8rK5QY
Bn5HLaMvg0hTHCdXJ4CxgJZgwyNcrFedP4g+i01TtJSVJw/YUKw1aRr+3nUS
AHlMLPoaYUzdqME5JFfbrVKklnOxtgyNsfeEZqErgriORZOLS7HmYGGbXUd5
UkQIbw5Nnahigp9v2skjInqwgVhzOVausbEeW5I3sV0OoKzE9faTTZf4aes3
mEkwXqQ9lTNW286VEwtcRDSPfTyobLX9Zx5Dj/IQgiDx+wH53ab1EPefdj71
XToxBfRQMID6HdVgjEekoDIUAunqR3ts6bch6321+jqkUdVYQxCbFyrI0ljt
23/Sf6Fx7C9+PLqXD8YhyHwImpFw91FSZF2H+fYxZ8j2ShDI8aCVUo6AOLlg
ZQVMUiaaY8yOy8Oaec67ekQwRWjoojGeuNswEWJORNE+hvoLruQDIbd6p33f
yT6w4ousYTLehzeBVI8mDI2gyPSy3UXdthcsl9Kg1ffsi6dBMoVWURSLNPHr
NU90N8g4UbVNLXCAcyMcbbo5ZrTrFJulBvfz734b7YgTs3V2a1y78ULbXVGp
TU5/EotFd9WKb9SO0kiz6I3bQTzElJwTtrHug5daVrZf3wlf3068tiXrKpZF
4DTMsiJTG8dr43NLRm0xFFAFY8z4aTTlZ0C6si5EvwJErKY2RICziAIp7q0h
RYVyrLsBiLdm5VIwanUTplOObUWD0AhMN/nxqwPSiWFQsApu6hYxEsDHZsm1
XLcpRgKQ55q4m2hSZB592G8/lcsiHdTM6SgSBScT20rRHE/nS4Bt5GNffxJF
Qzx9f/Lq6N2hPYbxJWb/oClxkMJ6AFmXo01vJAAkVZ8fur8ymx/HL/U7+Od0
/PtBG75g7QixhcYgq3zfS4Mr9w86DX/fuIzuU5c0jmbSNevnagPGhUNCC09E
58wMDsSGz0nrhSMMRMVlAvGs9U3mElnWkQ9R9WWsNp1MZLE10lDbfRRcYG2M
jS/TfvSo7wOZ0/ZbU2+aYPVFvBPKihTiYV+v529Z7YfNy+9NfptaDLvNmt7s
diNhsjfU23Wvi9/vf7uZCgYOIR3LtFILAQENcppjqUfN7vE8LtMR+Xi7OPAL
B1G5ID5ry7m1Qu1Bwk8EToSTVMgEM3ibrMD6mIIjMmZjMpbiI4Rry8qTVVfW
clsqZDl/dbCevv/EKpHiF5PSqbOZERyuoqCsyOtFKnvBYC1JZNW5znZcTsjo
BblrvSbeMBdTZjG6nF4pYsOQpFciMaCSEqEfTt+2FBNqSghRrZqbF2OHbZQW
A3pX3oH/e7/KLQABQ9gHbK20d7rkvJd7XKi8dFcWifyksJflkiSzprAhoBfi
CYypwc1fEwcn9VWtQT52Jg0plqGWY1AbhJfNE7yM03LOpW1Y/LJGtPdI6mav
vxP9NvZZ2wUKK79lBA77DOkGL/XKT7DgcQVSyYxLJEel1VjlX14NGD+c0+4b
ElNDyeyDUsxBq/7rZJaWVCZcfhxDUcd9h0MkY55UX1GwAKqHzGRNnDm2f5Ws
tRFTqlexYlsjalSTUpuSaQMeGeQGV0egxISy5UDjRru+2C5k9LD/sL+HLMSh
LLnkmisNyWEjTkw3g8+9m5sbrNA27y2LmZT1HBDAhgrOo2smiyzsRvtU9NcW
EQTp9UPQdq9sIlDn3uMrroz8SvWLZcGiJMrJ26DP/jNTIxXt5PSweNw6v49I
3q+vE67x/d3+bvQaE42aRr6U6BAY7775iDfHziPg4tdmb2fvkdl9uL+zA/9n
vjs+j3zD876PgbzfuibRYYqp9vaBAx309h49/ia/ejz/w4OPf/zy/ehpNnxS
3n9T7a1+3F1+/2S8lz394y9PxtPZgz/slLufr76xnb1Nsstqum92d3Yju0S9
o2yxpMg9UHJ2v9nqfMvXS8d0vuUakJR7znRG0sqYhgJfIPK6s/07eJNRAeNv
dp882Hm6+2hvZ+d37IlOx990lMn7a/Qb+G23gw/Fs0t4pIwRhg0T67iB7fOA
9ofHe+UPe/HD/Pjp4uPo4R+eFs/+OHw6/MOTeO/69e7V6bPP5zurNw+WLx/e
vH80++Hx8I+7I5TC9op3D345fFidPpq++AZ2mbjCBe1vk2n8l4g9jBcw4rYB
w+/w1Dfz1QVfh/RS9M/3HeX8nnEBSu5K5qI5LrWGbHuSycgaw1TXtcMZuMt2
TcE3aymBu1mC1fBqYhfML0vgnnRRjynxEYNntBMY98AZpSnAEBO7YjfBGlmg
psbvcuXqNag14R2bHEpwO1a1qmW2dJOzl0ceRkZj5aBxy2KsvX7Q3NGBdw10
IwFPOHgPrHxuayBYHqyAsSO1SdnCXozNUVmC6/uW4oEUGbF+uQsyjjP1Equi
zYfTYd5/z3YYvsm8DKtetHJUS0YvS07cCMgZU1pjlu0O3xEXnKFp33SeTh6M
H2CukwlmPXk4fPik9yx5kPSexZPHo53xw3j8dEjptDkPGZ0IfO85Xe38C8eD
lxcptvhgZyf6C/dXT59NVOQPgA1BmcQNqrgAtDPmmn+8DpnUPMQtLqtiOeJk
pymm/UycklMLpzeS/flKVFxCJZXtjsVQDxRJzoodLjTWS3AZEZKU5DAXR85I
CU6Qua3Hxq2OaDA24wcfHR4iHLuEYvRd8D4J9WhlnMDrU2/FeG+7tooIDRoD
fGvXeP0ucmC1RcKFCzn1Hq5JbV+mnJEjZWcslSxPE0pvkiU39U2kc475OUn1
sQESfLvSwOZY9rWQ4/OyKPLCHp+y7fyIFN+aDUwOCpXlVBb5EIiuXt7FD+X3
nbCZEwhNQkMh7mzZhJ4WoGv8FYldhnMhI+yYNQROZdAQqu01zFbKQa2JQdd9
xcx70I3sN8SL8JFl5gB1+hzHny4zi2G7cHeVn3LtEAOcCFtwYAad0DPbGYSu
KjWfsj9Nn/7wjv4LTzf8Fq6GJ6MV9BX18tY6YE+Ql+KmpeoZWt+zFSeqKJLr
/MrH68aRMzwmk0miKBLQFXNybBQc0KUnlZZg23pnGIGC2lwrr3CL9gEjxPC5
6IwgLbW4ZErxg1joIqVgYuHUcTTonL7kFXjx+uDddy8vTl6eHh+dnR29f9cZ
ZAF2Q5F5KuJSPnm4tSOel6px4QahTs75hTCHN+WEkYwwWvtBgt8j/VxLBnPe
YgJUUHVbh8gAgPHecDQDuilxVdIQyMHNcBXvikpycgkIi3gifzRHzInGAhsF
/aivi/P4y83QQVjAy7PzC1nKjpC6XdoP7w7f1ymXK8ZIWvylF7DZxuSx7PMy
lhqNTT+kTQgVEdMK1HwYCqvntUXkldV4Ec2wUNtac8vWRnfaWrNma8OT9as3
OZJNNr96k632JptMRg3PBrNeI8WwU22kZl/BFeHIaaqDKnKaQ2jUanMCXR0d
vDswoMXgykskM108HzGO63tKgIvRJSoNemVHzwPFUS5rtft6tXvlauuELZYd
qVBcrMyWExrQk4AePx4zXjOPnjx99Gmb4nNwIOVyMkk/75t8RF6GF+xXwCur
gLEkxb45enmOeU9rOf4UR7RVbu+LQYY8JuawiCcV5pgYkTiBCW3VhXEq/nm/
LKl5d/+AFujN2QupqcrRTKcym/rCUC7vjQtTa+muC/Ps0aMHsjCEzEHvJa3L
gc1CjHVh0Y41Nh9QKdqXkkW0OpTdSKp3gd5KSRnMB5AkZ+5bnKtb5Bcti3ya
UA6QEUHID12SRq5dc2ADF+roLTR+xDaEBlcsFD5KKX5jeiCF83Mds3VG2KOu
9axv79tiYy4Zl1e5hLeNGzKcYu5bNbl0xN9qTTCSI5Kc6lzXBNrtkedrpkVE
bGYkHZsAPGBsz7mwWteCk2BwWmFNEjDKOUxLL1E0O+yaIErRfvqwqBTDto9e
sjJxPfOp9xbF6/c14WRcP4xB1nrAGn+JVJAE9PcyW87ND5TysWMsFU607igs
rssHyaOYxcNktmYQWPm5h9GR5LimJ21KNjtzrbcXHqkT54L/e5wr19yvOFwn
6m/jA5Ym1QTNFvvupFHdA/ccG554RX5yT30KHiLD0WfY1hcY9/APcFThaqX8
hN7JTLQaiqSIY68kZwinzFVSxD707JWq2nVA+ZvDz1QIJi+uOttWyWcy4ks8
YFjMBQTEaa0S+Mo6flsnHY+GN9JOmviQiI3kg01GjWNxB/rp35V+7rvYzgZh
/IdsvyyYKNscP3NTY9RNLsJ0y4h/sYSWohHCL//0TfBX+7jpD1MLmT97W0kf
7Qzue8M3LX9//rv0Lgn7pUkbmeEtAEVz4gJ5NVSk9z/3gr/ax01//LqI1xt7
H67Ey8eeH37j79O7+FaYx7reOd0d/8jxDUj95J7xVv5v6R1JB/VLrFmTMpus
S6bneOXSiZbseWWCEUQz/Hcs0SYauqYuFy2hVVMGjvOSsl3lRQVyMszoBqOW
BFDDqd1j1ersytOhxzGoF0tcXRjofU0+LXK4UZTHJJFaGrVscob8ZKiRYUMM
pI0UOT+fxD1JBjIOwD4YyUEd+znUfIoQhWgIbNaqzrpI/nCi+nBo0S5GcXYR
ZAsoS8KxUo6jvCCRyl+GiEYvmDYNS+kGp4FLUdgW7dvGpa4gVYpuBlLsvDl4
lcEZOypOX854QZBLW7iW1JlXy4IekKR1STMxri7B+oHFkYJ2XbpVDTOHmxCP
BNIaW5qqlTakL1V5ZO0gGBhZ0vbTNbqUJA9c9Eogphjc40WRJrTKkqrOYi9d
gCkcgN8ofDaK2NB/+vLF++Pjl+8OXx4qBlBcIxIBBJTZkXc6DhtMGZWpCtZK
Do2/mioOy6dVvpSwdoECDQVHKmlDMOMe5RfOZsgo8HHJ8JylI+YRpNjybf02
uYxHK7UdswNE6iTP+CdJVWflcLE4hYWLKOVo0AZG/tOaaokPWnmElmHO3bIt
qZ4tqFUzX/WjIz8NnsAJUPeWpK2s2SdUSdZz44vj3hbcJiuuhxA4ABV/UDM2
Dxw8Qc3OZDEX+yjFKHFyHqxrEvi9wphLVKaee6BFv71E45bhVE1SdRrgLDJk
oJje6hIN2Gj34WC/YbLKWWBLC2tzRwhS1BjdMuMyY3Bmp2i+npVitZIrm1n3
O1ajr5PgB6TIvd3dZ5/M8yIeZwgIOeubzk9YpIbwHRYFwfo5cb4jcQtEpx4Y
8i0WaSw/bSmkgzJsFLD7wB1U7ro/zkf3p9V8dr+YjLDb7U43Oo6L0dTsPnv2
pM/jefDs6WMYT1LAcMre2wSmfQ4iLYUHkaJz2mfnYFySu6Vr3vajzk8fspQS
plijzJEDvG19OD0Cteg7jJhNR+ZsBZT2OfqKweKYYLDmTZwtMaJ6b2fnEY+W
S4sdLkGURF0RB2OOcQmJOl5+BsGstPl4PyZDNOOABAw3RDKOBMEmjEkkSvh4
y8h0VNj3fVzDN0s4/zAmXUJ2I76GcwcDOuyDVoAYpc5P5z7KxAT4OfMKfZKo
K3zaiu7UO3aCa/IeuPwQFnlvZ3dP+n/yaPfRJ/MGuBLwv2PYPKSuGSa/eAMf
zuKrdL4s4q55h6rKT+QAwaVxjuOtNx/Ptr9if7BDHMtxjHuz+8iN40kwDq8z
qsP05uP327fNt9bPk5Z+nu482MN+ymRSlnhnnUFfb9NleR3HOM8j6vrlmDhh
78US+DrQwWVaxTOHDDAHs0u816Zzs/VyfHh28FUjwyGEFLqr1PB098nDT3BA
0yEM5TnS5sF8mF4ukQ9j1u0FsB3CnF2X5m1+Ix/EIIfHNMK1+ojs4I6EiT16
y2QH8hjJAi4SZPrTeN7lk+JbJ9cf4jLCU1x+DVVgf94wnkUOkGCew3tztBkd
wN6c4kVZIHXyxQpSabbqeudYoA1us7yVqHIMpGisAXaDnb9KhoXsyN5DWQhS
Uc1ZlSziLLlCjgbkkk8mwMRzR6iiA++bA85QcqqGvFhrsaiWfAgr8TXEgv1v
67rsPewQlO6A8H/pZ3Owb44xlqM3iVGAq2XZITdo3LSPe0h2v1xTkFsP4YaR
9Sqz6JNWXIsO1R0WPOeYdUeco7UasZS2GKVPhmE4tH7dSYJyXTuwJPDVRp5f
r7QRea67mkKQ25hTrRXb6qbnQnN5lhcUbOdwEE1fDyEyOQlVpMuRUmlcNX96
+S7RhuL7Gt0xQW2CMOiRRROu12W66jlpg9pj4gMrwcXi4jdCCTU1AmUTlmZU
orskUaewcg7JzWxFYX0otY4czGCh1W/avEKKsgTaiLgmwwyDKWg+9GiNNLQs
wHLRjg5EkdtTNUSPtMvV6NgFWHK7qOHmlMchYv1sOb9t3EwDbYPtM1rVjoeI
TYMW+d0URENK2kvJxEMJWSLlaNZ0ZlgRIjXATyQn+CyUlRkTQoGkREb1yMwm
/LMeL9euiKPU7/sCbeGPQN/fh0E48GvJYbKaFvynM654hxWeHFv1yuD103yb
oDWXRRDQHP3EeT4+bf1GatdSRI/PfiQXewI/IwMnpcBxuuf7BiQAEu3rGVSk
vg4Lz/TQSwnkAT0i80MBJR7vWisp0+HTws2N0nWa1CYFrSus+7ip6qNARRvV
mJ2UA9v1Wg4YeSGZACzWBK2jDm/NCOugHF571z4iC4fZ2Tc/kf/gT+JF6FxV
K0SevP/+hDBW9N2ouMbvXo73Hj3afea+v0rH+H2zdwZO2uc+41O7u7/8ePDj
959fFJMfzi6enK8+/uH1+8sn09H1SbxIj2fFzVEcn4xefzjNO/TiX+B/P62D
dMEm4t7ycdC8YVucE2o7ir6j0OrN2d1ET7wVWUuVBcXtVEPVtmEwBVj7qki7
Zvcxym94Jz82uw/2Hzy5HViLE7Q/K54Weic87f7bq8Xr1av3PwyfH558Hj35
cfj68P3Hd18Orp8+/eXj8ofJ23eTh+cfJs8+5E8RTEr7bEs44S7M4yJNvm0b
N0PqEHdJe4o1DFbxfMZfu3wJ+ONdypbxe1RkC19JSIlPs2+bxMJP8vd3erRe
6QtfOpiBylKZl/Ku3+adntTyWvgEl8/Cr/1AW/wFK+7YBSFzH3zLR8euHIXN
Cu1LWWz7EDpOi7S5vvSLH3mDj0wn6XIKCtyXm2xZPHs6fnDzc3ozLdwLXr5W
PMcd9A+SgwiTonY+2UP0FzhELRhgV799SPpBSWF2hHOsF3twYrYDs0cOzP6t
bapHUFhWjr8eyG5B3fscHRBAu/eNcrs26vUOaVTHgHvn5yf+qkdOs09wRDqN
scPjd0aXE6zcAct/QqMOXKnzxSf+QbDl6xgkP0TY8kR4a32jkMnx/UubxAKA
LxIIUzZbVm/dJsRRkY+XIwEV6QwlRgwzDknEgdny4xJ+3a7VMfpfidAPoPm1
FbzD+oWr14Dl/+S21+55bYnhKvmBTLd8mTiRYUuz721TvIvYdykLk6RPEPOh
u0l2+2gisgkGLCBCUO2NBAP1fHZhGra9PmibmvDNCRd8+Rs/ak876nFHv19z
/WOQuo5vQIs74DENaptooy5Rkpqk4mqGN7BbSkKn/trBFTai+GL6yllqVFzB
KNzTxLIXtoaH7Mcuja6AdQlr7C0Iw5imXrKnYWBOY9CxX31GIPickOhRXza5
1ncrxhqJii032Le44PWguXPGpIPA2djiP08YgYcJcNRDLk56esorEhQcSoOR
cjZwD3O3kMZVzCP7tlh3PJhfV9SZkgOvuS/RX2Jx9aCeAYuh0UkWIKgKGCeZ
qzhAk1MS2xGyKiqJDWVbQN4+8CVSq3tqy5p7SFvmQ4Xg7dJVMcJ7NOICnKij
sveNA8nypY+ycwnaeFqcVqU5Jk8HeLHfdFUhFNnP1Nz0ZVEoJjo3ehjfoZmc
1aWliKiotbxkzAo16gSa/uXI+e1sEImXyjhipaHLNQOyPFvNsfow+yW+e3ne
dYUE3nw8c4m7rC1WvGiRUhKu8pUXN4KF67xMF/lkQnxeMSN+lFsUjzlLTC1f
gKgn+34Cr30zcJ48zFsbm2kITaJ6X4pw1NQ9sFiRsctVK3DS3KygP/HkcWdk
7LWpzhXgAiPXLGW228goAMdPmFOb4eZ8v8tiRr0CWbrs+m9tch2PO3n98G7j
umoadMmjAOr0NEHQioSwW949QCcQS3RbtHAJ+9D0At7mR/HJWovEM7akvVjQ
dpS08OhEgSbb8g4axPQ9BONmPUnobijBrTyklin3JPFmihoWNjigWgTb695A
2Rkxnl1OiENB9pMivpxzRo1ggcdhHuVWWqJ+/FKTErWk5XI9fVaI2knkXslb
Kl6dGM8w4ehOZXWhNKsSO6WYxPYZyeSyaRjLzM/3dhsKirwyDvUOz8Kw25Gn
/tL9mp72/J72Hz58+OBu3e3dsTvobffZXn/38dM+qLj7T3ee7tytgwe2A/ov
ah5/sVoS8TzclA7cqvji6RlGUPID9hbEH/r9fmedvu9zeKCd94xwxUoSs5IM
ONaglhd68il12jSnlMPZysZyKTyWXuYYI035AkfnQgE6z/P86gIZ8YVY5fED
/M6snX85EbGLP5Gx4aIbcczcxQfYtguxujmeM07jS1KRYgeY5ZzVsxjlE2Lp
lAZpUZXKsNNCQvjhSp+mi5LCjmNzuURYDQXBu9kLANSfBi3QBS6JHTAXi8Oq
gxSFSYMtL4jZeTlwDfpCFLGBXNyi7NREWVYYn8iOaw0jixmg6jL0lgn6hOlM
38QrsZWOQR5cokVO5RW8EKwRPsjgK3waI+TjkkO84A5tmoTvuax4ToQoYSQj
X/K6cCkWyEx+gWMGCkD1z1ojQ8MR530N1tSImRzFbUJZE7Zz5vUlSE8FfiJn
jGzihsT4Met8a9AxLzXrpyA+PTMrZqwFBhlTJWsH0g4ow6YDkELaoyIv/fqS
uInWIKyUDRsvdlVGpYkoEExXkx846SYiVBKpjA7hxjORefGaZNdJlkptS4Uf
FFRHBNgYzOxLItm+NBASqN3NTlfRT+2L/dpGbNpsOZnlRZ8vhX9qYOL+Kfqz
CWeFMLs/m/offtfjAvH75gND8v7sN9Kzw4LL4hOi/OybLb26H/UfjR6DHxW3
7/1ok4OX7rGdfv+3a9q4bungun1ojS//iRdEXZE6YPpSVnjTVFvaYyAi8CSH
HUeh8uKCVvjiYt8D1Arp0aJjGXl4pAzx98iX6G3dAmzgQGVCHbbKhsKf5MwF
bdCQTv3Dg6MCThlQCNeOL4PCqcQs+y0P2537khS5fVxPWdsbjqCpximpRH4u
eFlx5unSUHRgpxnUs3aHhmCkPl8IoI1ylCOPC2kqHR0q4xzt2gWXYhlk6xHL
TQt/sKnFsEIu6Dk1NuEmgQlBiV8uizKxZTzm6K+j9eMgtzB4SJRMNhgI8Ywj
mrdko+HkXQS0Zq6GY7A8osG3NvKM+nFY81yPe0IHgMdHOIN4yFtITap9Z41F
3nc4oaPDjdxFz/z/6jiDWxGtKLZh0E2G2Pbc2jNsZ4zH8Fytd3gUKZ+OHFK3
DfQSLQm+oMvKa6THcytIc75Nr+CK4Ru1UBi/2Ao9xytGg0H7gcOMye2vA2KD
Alw1nlKB7+suaAsaw+S9K8m75aU1bMROzVaP9vYk4CbB2eKDLhcsCR1ymETc
8A48jmiYMhFz3mb24AZO6MhLUZRJ5iK4oJ25glIsEYpXt0ITDAaSRIRxf74U
4bIKbT44Ov7bDo4EaSEFKfELa+Gv5Du2m+qtzN9xIoM7HRLvllUW65+R1juS
5hEekvY+NhwSb3aNcyIY79hl6N9KJ3ZBmPq9pVj3/kiThePzvEybr1ZODe3E
OXyPc23Aax+yFBT4rgExeNyr8t7l0hPE/aXT/WXXq9UW6e/2U5Lp61jr2G81
zhrSNuKJRiyN194EpSAfpS6NJKjJFFSBp4ymGysAm/wIdMRUE+JDdmJraDaO
WeyDA+6Vzv9PUU/ZmLExl0tRHsL8VP6tqEUJXCpRuSDpSEZel1T2uwXx0pbW
yxT5LBHpGJOEe2rwHCsgsvU+raRIJ1KBoMntnGv6cET3PvUfZNqq373OvGIW
CUURFBJUIPUQfYWz7NcDx0QRpqwbsxkwroLhzISizjFj6jSGb+GrvhQjzS5n
SeRZpQsEvqJCYWfipRsWzH1z0aUsgWQE+501LmENEXFNlVzroGtKSTXrxVBS
mcORZqkmGSqzUGw/t+sIvbBFGvPWBOnxOR4vFQt9xkAxabVvY77sX5PX1Lia
yuj4dxJIET7Lc09tOYLebn3qrj0C316kAnP2vm88lRDOahwwh7anGMO/+Slm
d1wi4jCNZ/ll21OL+jK0trXQImwbnwoCDNY+1e/3Tf3v16xq66u2H0Fl3vKG
66ntX+s6b1VLW74L+2rVNde91TKINp3RU5r5kj8NMp5/Eo30hceK8Ut/tL++
r7p0zn31jAd8NfW+SDRRDIkdC70VJJxuvmVTt//pL15fCjdr7gK/VSO2P/tH
ozRtb7XPm2YblEoI32q2xB/duHt8e9zxLcbDIBCgOcL1bzVne9tbt+1y+1ub
/+70Vov54w5v3anp67vP9bbOWaWVC4qo9dah/Kpeeq4U3N0mjK9okTlz91fo
uIg3uGd9CuWmV4KQ5Lv1EmZyv9MrbZfChlfutMjuXcnEZW+DNvVF9BdNl1xq
I2ue7FFF4WCocm6xjHfjSzjMtS/rZ7W9o/WakpUnUAtR0UL0DgQla/Ixr34W
qEfeRYDvvdeiRjZo2L4n6hSTPitIrjyDLS+yIBfsBvRoyXYMlmuwGclZ4of9
pxMbBKoQA0ofJq+yPEHvosNCUwOpxKp1BsqGWeJVkcKPiCMvYtYPrPXDCjTB
KvjQoZzDHx3+hNsPSooEFlW34oEMKw51e30xJJcSKXmFjFvUKbPIYTArzqdE
6BAvAOJCL/oLrnoT17JBSZRELRPWWhNE29lrvxzwkIRdrRV9GmEWm63+d+jb
tnzHP99XQIaBcuPj9KCmEd/kImj9a2cq9FOQ02vd5HhWZ0EOhuZzvd7v/9zU
bdeJLS1/a/kZZZO0Q9y8yOvEvw1vmHkyTmkLLB0779EdG7kOJMGNb6ydplfR
bv3bTpA2W6ykb/OU/Ro1IA98Zd9BVbvQUue6DmXkxpcIUA++rOIqMJFvPDme
WQ+1/MzfDbvIa22UdlHW9bThwnLkFbBcj+ospHWTHZtoToF3YZmA0FXm+8Vz
DftSowg+pNcF0RJxcl4JS17UFdokNHngFl/kXbz6u3LVbwe3ztHY2QR9m3pY
iLBWTE7uFUdYwbUi++P/brb8SjPdNh3XtBTx2W5cYGQiXXEiQ3tpbSHosGvr
JIwwieg4hn8l1ai/XbOatqwyIwfZyuon++Q3la7DrrXk3Rba0Ltw5eXLRdcz
nG27l5H+1+5vcN/wO5W4XF4sCzLJ83kJaqttubzPUoety8lK0aqMxKzJR8/I
EcD0fCDvYNuyrbYVS2hSJQFj5/CdQ27UvaL1OwinTsl86bkTHgXRwU2c2ttf
zN7DVWOq65wr3A2GLIj7kfLHkq13a4ZlBbf74XO2bpv3oHBA/8kG9/CCMtlu
jK+yhEONtLtlmFbY4UK2dkTLSPWDsY6FQ14Z46OOdXasZvGl8xqz/VBLNrDU
pUMqW6yFazh1yDC9G0H+PpSBsaxpfvqaNutOz3Vttty2G550Wb5ue3KZjutf
/00z2tzOGntby3MbgR/Bc4R7qH2HVJUCSyFpI81a3mvHfbQM041ys0hKQ645
iC0aROi3OY9f148D1YhFQqxaNjEXf31rPyp82DfWrbH3t3ls7p3WdigteptJ
9palr1lejwLr3S3TDBcOOY9nxrnt3fXCjPrlkRvcK0O3/Fe54d1ZJY11OZv5
Nxt76tM1UkUNJOc8dWsuA2JddGDWudWpmK99lPcrxOhYnI19qnbawseVdZdW
acy9DM2w/KqZ/saVVo0kF7bcoe03B+IXDUEm2WgwTLi2EUmEmiQtdKxpfAG+
zoFWKAZ4l4styWVB91FdhfX9lA1M5cHJEadUZg/tzLsTI4qbcFAdrpH3WSbH
idNUSBRAu6JzbxJO2YUJ2DACn92PiGK6IUuF8+XdBjG4g/iOhwTlApfmsBXj
F2gzjLsRiIFVWdb3IT86HI5TSuzyX6dx4+cNVru63vyVxjSdMR2z0yOqrCgF
wFoqa34lJK/2olu19kNd01UYbVATmE/vKKtToTDSAMpamTBB4ErWEn6ERSYM
RaOatVp4NrlO82UZaY5zYTiY4tP4+Vb0dM2TmGsOJK624nWa3ESKcovZzQ5H
FStwOhmYYFCXuUTSYgqeWVxi2YrZjHO427qSPF50aFLai7EkzFZG2EOr4Hdp
9Xo5RK6RlylGL/Q1gJFmsfMQFvYFIclTLePNjnxBnUNzDkdPKL+68z0iu45z
aiNLPE4x7wUDACoOmfmsoETb9QN48BV8P/YfRE2vqDANFQiyFDs6BKq84uUa
wrUA3AqN/fXG9pARMxgZIduy2xeel9x/ehfp/QgTtWLQKwxgmXH8W9eHR/g4
B1ukspbGUnvVWneEBT97zXj70upDtrxhP+xYCpQgQXvVRdNM01az+K811pnd
V58jP6Cckm3H1xzGEHPtd1vLjgdPnc4l/UcRKmUSCrVwaf3CurFd2WMXJ1kv
fSZpKWzRovtSbUUN0m6RkJgxvHJNuShrdSfopUuhERk/iQaBWqAhjGszlCfM
S7Bjs3ngJUkRXgRuxaoBhkLjXDL9WhQZjvKDnCFKiJnPc7i/sKBJDcLDEPkN
tOCyFyea/o3S5jXT/eM7TKpjG6Atob+STbJRhw1zBHJirsc7j7kG4sEI43Zn
yfiS7SJR9H6JZUaSBdXYgfbl/GDIaoLAJxzRZW55W5JTDXbEeIFAwOjcJMJD
iFGeN1QdiwoAD5NRTllv6vldkAgpHxrd+ywKLTHFyw20I4yQBoJYTRPPFtMY
hBNMuM7FYLfNdyDe5eZgiBUBTzGbHnBFTr3QjV7ns0uY9UGGAgXmvDmMQZaB
z1X+b/+ta14D652uYnMAbAH48Aqzen2/BDJ6Hi/hOohghQuMGxkvzZtk2YX3
xpSu9iUw7JU29h3wtbgY869xll6Z1/GqiBdJBe2Zj/E07UaH6TytitRcYzmf
BNnEi2kBzChfTDH5ypf8Ult7g3kGp3kXs+rBpL+HAaQVRvRd4XDwHSBX8z0O
HC+sU1wR+JjO58kM83KVZTrPzdsY6xHFXTgic1jjtyDbwfJEb4BdA4tNkGPi
cr2Jr4DFH+flKB1dpdgnGoxgBu8LWMUYG/hhBgf1NMeEZ17/Z6MpTOhL13zM
859hX86SHJOR5Zd4AZ8t8rzQGdLTiyL+edSNTqio2tmXBKg2xcczc471l3Gr
zHPYoXF6VZmPySUOnujuTQ4HHHbf/MsSKPZjItREccuz9Cpx1HFU0n8OihzT
5n0H3WICkhhrBMEEsyqB2f/1vxcZ+bTGuMbmsEhWtIbwAauswuzTKoadeL0E
Ev8uz7789b/Nki+wmMMiHsOUomO4a6YpEACs/xITA8afSXB5y/zubY65gszb
5WWWXP71/0SaOINZgDQPHAumPk3gAHcjpD6Y+klBsTwwy+c/08hgUdPkr//H
zIa1phY5TqUyMPUjOQTbL5To/bUULF4lcVGidWfFsrIcU0LjUUFsrb2pd/4Y
U3DmC4LxstAMx9GudrjQKHSwiDX3xhkMsBtxkCZey2/gUumdA0+EVTsY/bIE
Ir9GuoznywTP6SRG3gOf0+xLNwJyh4UCyaGE7cQjCNQKTHMWX8uRNK+SGaZf
+ut/n2ISwHiUJj+b58WX5N/+ryyNr/Ck5bB5L0DwKeAQfQfdZUaP8fdJBjSG
uSRjaPTf/mt8Y158WQ6xEyB2OIAZKCvQxjESBIzu8N5ZOsPRvl1exeUXc7is
ruDTSYJb+iopgF6Q2E4TIFL4AhgHMo3vZzHM1RLTKR5FGEh2uZxB1y+vY/Nd
AroTfniNyaxWQGr5mJI/wghS6Pd1DOwLpoL79TpZoXCByX1eo4CRX5dXK/1c
ZCkOGLPOp1kM85svcIWKyyVOFukLqY151vezHA+sI+EMJFj/lFqecgytIQsp
yyy9hFM/wyTI0OLbGFVxHA1Q8DQH6noLmioM5gR4JzAQeDHF95FlpLRnx/EV
CCPZVY7DgAEex1m+xAMHqucxnHeqmfNHEFsv4SOcxd4fpzHs2otiBdcJnFtM
rgiCGwxyGXejH3NkC8dAk6lbq+O//t+YMt/jXfab07icw7CPl5nu6b/9V+Bs
XxLgrzcl8rs3MSwfDP8GGvoehFz+9ggE3okhZjUB3n2AyZH5GMN3RYx0BVsO
Ggae+qJLt8ssJyYJz2E5WGblpzneRrCAQH0xUPgSuD8sJVwxsKIlHvcExIxs
iNTAyz5CVpqCnh7TSKLzFNo9q5KUHnjRP+yb8/QmxoRPMKqfeVAfcBTER87z
OZzaLyCxo+QWgcpGiQai/xdjmui31kkBAA==

-->

</rfc>