IETF-OCM.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.39 (Ruby 3.2.11) -->


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

]>


<rfc ipr="trust200902" docName="draft-ietf-ocm-open-cloud-mesh-06" 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="July" day="19"/>

    <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>Discoverable Server</strong> - A server that tries to supply information in
OCM API Discovery.</t>
  <t><strong>Discovering Server</strong> - A server that tries to obtain 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.org"</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 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 Acceptance Response</strong> - HTTP response to the Invite
Acceptance Request.</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> - An Invite Token and the FQDN of an Invite Sender
OCM Server joined by an <spanx style="verb">@</spanx>-sign, then encoded using base64url (the
URL- and filename-safe alphabet defined in [RFC4648], Section 5) with
padding omitted.</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'/>
"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@cloud.example.org</spanx>.
"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).
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 Notification</strong> - A message from the Receiving Server to the
Sending Server or vice versa, using the OCM Notifications endpoint.</t>
  <t><strong>OCM Server</strong> - A server that has the OCM Provider function.</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 ("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>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 MUST 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>
</list></t>

<t>When HTTP Message Signatures are available, the Invite Acceptance
Request MUST be signed and verified as described in <xref target="http-message-signatures">HTTP Message
Signatures</xref>.  As the Invite flow establishes
the trust that later exchanges rely on, implementations SHOULD NOT use
it unless signing is available.</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>Before processing the Invite Acceptance Request and sending the Invite
Acceptance Response, the Invite Sender OCM Server SHOULD apply its own
policies for trusting the Invite Receiver OCM Server.  Any HTTP
Signature on the request is verified as described in <xref target="http-message-signatures">HTTP Message
Signatures</xref>.</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>
The token and the provider’s FQDN, joined by an <spanx style="verb">@</spanx> sign and then
encoded using base64url (the URL- and filename-safe alphabet defined
in [RFC4648], Section 5) with padding omitted.  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 base64url-encoded becomes
<spanx style="verb">YTU1YTk2NmUtMTVjMS00Y2I5LWEzOWQtNGU0YzU0Mzk5YmFmQGNsb3VkLmV4YW1wbGUu
b3Jn</spanx>.  <vspace blankLines='1'/>
When parsing an invite string, implementors MUST base64url-decode it
(accepting the string whether or not padding is present), 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 5.
Step 4: If not, fail.  Implementations MAY fallback to HTTP instead
of HTTPS in testing setups and retry steps 2-3, in particular when
an optional port is given in the address.
Step 5: 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.4.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, such as file, calendar,
contact, etc.  Implementations MUST offer support for at least one
resource type: <spanx style="verb">file</spanx> is the commonly supported one, and
other values are to be registered in the "OCM Resource Types"
registry (see <xref target="iana-considerations">IANA Considerations</xref>).
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> or any
other value registered in the "OCM Share Types" registry
(see <xref target="iana-considerations">IANA Considerations</xref>).
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/",
          "webdav-receive": { "uri": "absolute" },
          "webapp": {},
          "webapp-receive": { "targets": ["blank", "iframe"] },
          "talk": "/apps/spreed/api/"
        }
]]></artwork></figure>
      <vspace blankLines='1'/>
The <spanx style="verb">protocols</spanx> object distinguishes a server's role for each
protocol: a property named after the protocol (e.g. <spanx style="verb">webdav</spanx>,
<spanx style="verb">webapp</spanx>, <spanx style="verb">ssh</spanx>) advertises support for acting as a Sending
Server, while a property suffixed with <spanx style="verb">-receive</spanx> (e.g.
<spanx style="verb">webdav-receive</spanx>, <spanx style="verb">webapp-receive</spanx>, <spanx style="verb">ssh-receive</spanx>) advertises
support for acting as a Receiving Server.      <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).
- webdav-receive (object) - Advertised by implementations that
  support receiving WebDAV shares.  It contains a <spanx style="verb">uri</spanx> property
  whose value MUST be either <spanx style="verb">"absolute"</spanx> or <spanx style="verb">"relative"</spanx>,
  signalling the URI format this endpoint accepts.  Note that
  older implementations MAY not support this property.
- webapp (object) - Advertised, as an empty object, by
  implementations that support sending WebApp shares.
- webapp-receive (object) - Advertised by implementations that
  support receiving WebApp shares.  It contains a <spanx style="verb">targets</spanx>
  array listing the ways this endpoint is able to present a
  WebApp share to the user.  A subset of:
  - <spanx style="verb">blank</spanx> - the endpoint can open the URI in a top-level
    browsing context, such as a new window or tab, or a full page
    navigation in the current window.
  - <spanx style="verb">iframe</spanx> - the endpoint can embed the URI in an iframe
    within its own UI, when the Sending Server allows framing
    by this receiver.
- 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.
- ssh-receive (object) - Advertised, as an empty object, by
  implementations that support receiving SSH shares.
- Any additional protocol supported for this Resource type SHOULD be
  advertised here, where the value MAY correspond to a top-level
  URI to be used for that protocol.  Similarly, additional receiving
  capabilities for custom protocols SHOULD be advertised using a
  <spanx style="verb">-receive</spanx> suffixed property.  Additional protocols are to be
  registered in the "OCM Protocols" registry (see
  <xref target="iana-considerations">IANA Considerations</xref>).</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", "protocol-object"]</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 supports the
OCM code flow via an [RFC6749]-compliant token endpoint.  When this
OCM Server acts as Sending Server, it hosts <spanx style="verb">tokenEndPoint</spanx>.  When it
acts as Receiving Server, it can honor inbound shares that require
token exchange.</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">"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">["must-use-http-sig"]</spanx>.  The array MAY include
for instance:
  <list style="symbols">
      <t><spanx style="verb">"must-use-http-sig"</spanx> - to indicate that API requests
without http signatures will be rejected.</t>
      <t><spanx style="verb">"must-exchange-token"</spanx> - to indicate that when this OCM Server
acts as Receiving Server, it requires the code flow for all inbound
shares.  Shares that do not include <spanx style="verb">must-exchange-token</spanx> in
the requirements of each protocol offered for access will be
rejected.  An
OCM Server advertising this criterium MUST also expose the
<spanx style="verb">exchange-token</spanx> capability.  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">"must-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>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 hosted by
this OCM Server.  When this OCM Server acts as Sending Server, the
Receiving Server POSTs here to exchange a <spanx style="verb">sharedSecret</spanx> 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="http-message-signatures"><name>HTTP Message Signatures</name>

<t>A number of OCM API requests are signed "using httpsig [RFC9421]", as
described in the respective sections.  This section specifies the
normative requirements for producing and verifying those signatures.
Appendix B contains a complete example.</t>

<t>Public keys for signature verification are published in the format
specified by [RFC7517] at the signer's <spanx style="verb">/.well-known/jwks.json</spanx>
endpoint, if the <spanx style="verb">http-sig</spanx> capability is included in the
<xref target="ocm-api-discovery">Discovery</xref> response.</t>

<section anchor="applicability"><name>Applicability</name>

<t>Support for HTTP Message Signatures is negotiated through the
<spanx style="verb">http-sig</spanx> capability in the <xref target="ocm-api-discovery">Discovery</xref> response.
The following rules let deployments adopt signing incrementally while
remaining interoperable:</t>

<t><list style="symbols">
  <t>A Server that implements HTTP Message Signatures MUST use them when
interacting with another Server that advertises the <spanx style="verb">http-sig</spanx>
capability.</t>
  <t>Such a Server MAY nonetheless continue to interact, without signing,
with a Server that does not advertise the <spanx style="verb">http-sig</spanx> capability, for
backwards compatibility.</t>
  <t>A Server that implements HTTP Message Signatures MUST verify any
signature present on a request it receives, as specified below.</t>
  <t>A Server MAY accept an unsigned request from a Server that does not
advertise the <spanx style="verb">http-sig</spanx> capability; a Server that advertises the
<spanx style="verb">must-use-http-sig</spanx> criterion MUST reject unsigned requests.</t>
  <t>A Server that does not implement HTTP Message Signatures operates
without them.</t>
</list></t>

<t>Because the <xref target="invite-acceptance-request-details">Invite Acceptance
Request</xref> and <xref target="request-for-a-share">Request for a
Share</xref> establish the trust that later exchanges
rely on, implementations SHOULD NOT use those features unless HTTP
Message Signatures are available.</t>

</section>
<section anchor="signing-requirements"><name>Signing Requirements</name>

<t>A signed request MUST cover at least the following Signature-Input
components:</t>

<t><list style="symbols">
  <t>"@method"             - HTTP method</t>
  <t>"@target-uri"         - full request URI (scheme, authority,
                        path, query)</t>
  <t>"content-digest"      - [RFC9530] digest of the body</t>
  <t>"content-length"      - message size</t>
</list></t>

<t>The Signature-Input parameters MUST include <spanx style="verb">created</spanx>.  Freshness and
replay protection are anchored on <spanx style="verb">created</spanx> (see Verification
Requirements).</t>

<t>A signed request SHOULD additionally cover the <spanx style="verb">date</spanx> component when a
<spanx style="verb">Date</spanx> header is present.</t>

<t>The <spanx style="verb">content-digest</spanx> component binds the request body to the signature,
protecting it against modification in transit.  Its value MUST use a
hash algorithm from the IANA "Hash Algorithms for HTTP Digest Fields"
registry [IANA-DIGEST-ALG]; implementations MUST support <spanx style="verb">sha-256</spanx>.</t>

<t>A request signed in the context of OCM MUST carry the signature
parameter <spanx style="verb">tag="ocm"</spanx> (see Section 2.3 of [RFC9421]).  Unlike the
signature label, which is a dictionary key that is not covered by the
signature and MAY be rewritten in transit, the <spanx style="verb">tag</spanx> parameter is part
of the signature base and is therefore integrity-protected.</t>

<t>A request MUST include one and only one signature carrying
<spanx style="verb">tag="ocm"</spanx>.  The signature label MAY be any value; it is not
significant to OCM processing.</t>

<t>The signature MUST use an asymmetric algorithm from the IANA "HTTP
Signature Algorithms" registry [IANA-SIG-ALG]; <spanx style="verb">ed25519</spanx> [RFC8032] is
RECOMMENDED.  A symmetric algorithm, such as the HMAC-based
<spanx style="verb">hmac-sha256</spanx>, MUST NOT be used, as the Receiving Server would not be
able to verify the signature without prior access to the shared secret.</t>

</section>
<section anchor="verification-requirements"><name>Verification Requirements</name>

<t>Verifiers MUST reject signatures that omit any of the mandatory
components listed under Signing Requirements or the <spanx style="verb">created</spanx>
parameter, and MUST reject signatures whose <spanx style="verb">created</spanx> value is more
than a small implementation-defined skew tolerance in the future, or
older than the verifier's freshness window.</t>

<t>A <spanx style="verb">Content-Digest</spanx> header value carrying multiple algorithms MUST have
every recognised digest match the body; a single match alongside a
recognised mismatch MUST be treated as an integrity failure.</t>

<t>Verifiers MUST identify the OCM signature by its <spanx style="verb">tag="ocm"</spanx>
parameter, examining the parameters of each member of the
<spanx style="verb">Signature-Input</spanx> field and disregarding the dictionary labels.
Verifiers MUST verify only that signature.  If more than one signature
carries <spanx style="verb">tag="ocm"</spanx>, the entire message MUST be rejected.  A request
that carries no signature with <spanx style="verb">tag="ocm"</spanx> is unsigned and is handled
as described in Applicability (accepted only at the receiver's
discretion, or rejected when the receiver advertises
<spanx style="verb">must-use-http-sig</spanx>).  Signatures without <spanx style="verb">tag="ocm"</spanx> MAY coexist (e.g.
proxy-attached signatures) but verifiers MUST NOT process them as part
of OCM signature processing.</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>

<t>Before constructing the notification, the Sending Server MUST query
the Receiving Server's OCM API Discovery endpoint.  If the Receiving
Server advertises <spanx style="verb">must-exchange-token</spanx> in its <spanx style="verb">criteria</spanx> and the
Sending Server exposes the <spanx style="verb">exchange-token</spanx> capability with a
<spanx style="verb">tokenEndPoint</spanx>, the Sending Server MUST include <spanx style="verb">must-exchange-token</spanx>
in the requirements of each protocol offered for access and MUST NOT
fall back to legacy shared-secret access.  If the Receiving
Server advertises <spanx style="verb">must-exchange-token</spanx> but the Sending Server does
not expose the <spanx style="verb">exchange-token</spanx> capability or does not have a
<spanx style="verb">tokenEndPoint</spanx>, the Sending Server MUST NOT create the share, 
as the Receiving Server would reject any notification that lacks 
the code-flow requirement.
If the Receiving Server does not advertise <spanx style="verb">must-exchange-token</spanx> in its
<spanx style="verb">criteria</spanx>, the Sending Server MAY still include <spanx style="verb">must-exchange-token</spanx>
voluntarily.</t>

<t>The Sending Server SHOULD NOT create a share for a combination of
resource type, share type, and protocol that the Receiving Server does
not advertise in its Discovery response.  Specifically, for the
share's <spanx style="verb">resourceType</spanx> and <spanx style="verb">shareType</spanx>, and for each protocol offered
in the <spanx style="verb">protocol</spanx> object, the Receiving Server's <spanx style="verb">resourceTypes</spanx> array
SHOULD contain an entry whose <spanx style="verb">name</spanx> equals the <spanx style="verb">resourceType</spanx>, whose
<spanx style="verb">shareTypes</spanx> array contains the <spanx style="verb">shareType</spanx>, and whose <spanx style="verb">protocols</spanx>
object contains that protocol's <spanx style="verb">-receive</spanx> property.  Each such
combination corresponds to an entry in the "OCM Share Payloads"
registry (see <xref target="iana-considerations">IANA Considerations</xref>).
For backwards compatibility reasons, the Sending Server MAY still send
a share with the <spanx style="verb">file, user, webdav</spanx> combination if the Receiving
server does not advertise it, as it MAY be assumed to be supported.</t>

<t>When the notification includes <spanx style="verb">protocol.webapp</spanx>, the Sending Server
MUST expose the <spanx style="verb">exchange-token</spanx> capability and a <spanx style="verb">tokenEndPoint</spanx>,
because WebApp access requires the Receiving Server to exchange
<spanx style="verb">protocol.webapp.sharedSecret</spanx> before presenting the WebApp to the
browser.  If the Sending Server cannot offer this code flow, it MUST NOT
include <spanx style="verb">protocol.webapp</spanx> in the notification.  A Sending Server MAY
serve Web apps either from the same hosting infrastructure or from
external servers in the same organization: to facilitate the integration
of external servers, the RECOMMENDED reference implementation is
described in [OCM-IP].</t>

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

<t><list style="symbols">
  <t>REQUIRED shareWith (string)
OCM Address of the user or group 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@cloud.example.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@cloud.example.org"</t>
  <t>REQUIRED sender (string) -
OCM Address of the user that wants to share
the Resource.
Example: "527bd5b5d689e2c32ae974c6229ff785@cloud.example.org"</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" or "group", 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, or a group of users at the
Receiving Server.  Other values MAY be used provided they are
registered in the "OCM Share Types" registry (see
<xref target="iana-considerations">IANA Considerations</xref>); for example, [OCM-MLS]
registers the "federation" share type for a group of users that
spans multiple OCM Servers.
The Sending Server SHOULD only use a <spanx style="verb">shareType</spanx> that the Receiving
Server advertises for the share's <spanx style="verb">resourceType</spanx> in its Discovery
response, i.e. one listed in the <spanx style="verb">shareTypes</spanx> array of the matching
<spanx style="verb">resourceTypes</spanx> entry (see
<xref target="share-creation-notification">Share Creation Notification</xref>).</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.
Registered values are listed in the "OCM Resource Types" registry
(see <xref target="iana-considerations">IANA Considerations</xref>).</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:
  <list style="symbols">
      <t><spanx style="verb">webdav</spanx>, to access the data via HTTP WebDAV.</t>
      <t><spanx style="verb">webapp</spanx>, to access remote web applications.</t>
      <t><spanx style="verb">ssh</spanx>, to access the data via a public/private key pair.
Other custom protocols might be added in the future.
Registered protocol values are listed in the "OCM Protocols"
registry, and the valid resource-type/share-type/protocol
combinations in the "OCM Share Payloads" registry (see
<xref target="iana-considerations">IANA Considerations</xref>).
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>
    </list></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 MAY be relative,
such as a key or a UUID, in which case the prefix exposed by the
<spanx style="verb">/.well-known/ocm</spanx> endpoint MUST be used to access the Resource,
or it MAY be absolute, including a hostname.  In all cases, for a
<spanx style="verb">folder</spanx> Resource, the composed URI acts as the root path, such
that other files located within it MUST be accessible by
appending their relative path to that URI.</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-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 Sending Server exposes the
<spanx style="verb">exchange-token</spanx> capability and <spanx style="verb">tokenEndPoint</spanx>, and MUST be
included when the Receiving Server advertises <spanx style="verb">must-exchange-token</spanx>
in criteria.</t>
          <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>
        </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 a web application available at the Sending
Server.  The URI MUST be absolute, including a hostname.  In
case the underlying Resource is a folder, the URI MUST act as a
root path, such that files located within the folder are made
accessible in the web app by appending their relative path to
the URI.</t>
      <t>REQUIRED targets (array of strings) - How the recipient SHOULD
present the URI to the user.  The <spanx style="verb">targets</spanx> array MUST NOT be
empty.  A subset of:
      <list style="symbols">
          <t><spanx style="verb">blank</spanx> signals the recipient to open the URI in a top-level
browsing context chosen by the receiver, such as a new window or
tab, or a full page navigation in the current window.</t>
          <t><spanx style="verb">iframe</spanx> signals the recipient to embed the URI in an iframe
within its own UI, when the Sending Server allows framing by
this receiver.
A Sending Server MUST NOT offer a target that the recipient did
not advertise in its <spanx style="verb">webapp-receive</spanx> discovery property.</t>
        </list></t>
      <t>REQUIRED permissions (array of strings) -
The permissions granted to the sharee.  MUST NOT be empty.
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>
          <t><spanx style="verb">share</spanx> allows re-share rights on the Resource.  This only
applies to web apps that provide a mechanism for re-sharing.</t>
        </list></t>
      <t>REQUIRED requirements (array of strings) -
The requirements that the sharee MUST fulfill to
access the Resource.  The requirements MUST at least include
<spanx style="verb">must-exchange-token</spanx>.  If multiple protocols are present in the
share payload, the requirements for the different protocols MUST
agree.  For example, if a webapp share is sent in the same payload
as a webdav share, both protocols MUST carry the same
requirements, and both requirement arrays MUST include
<spanx style="verb">must-exchange-token</spanx>.</t>
      <t>REQUIRED sharedSecret (string)
A secret for accessing the remote web app.  To give access to the
remote app, the receiver MUST first exchange this value at the
Sending Server's {tokenEndPoint} using the Code Flow, then perform
an HTTP POST request to the given <spanx style="verb">uri</spanx> with the resulting bearer
token in a form field named <spanx style="verb">access_token</spanx> (see
<xref target="resource-access">Resource Access</xref>).  The shared secret MUST NOT
be exposed to the browser and MUST NOT appear in any URI.</t>
      <t>OPTIONAL appName (string)
A human-friendly name of the web application, to be used in user
interfaces when referring to this Share.</t>
      <t>OPTIONAL appIconHint (string)
A string in the form of a media type (MIME type) that describes the
share as a whole, primarily intended as a way for the receiving
server to select an appropriate local icon for the share.  This is
display metadata and MUST NOT be interpreted as fetchable or
executable content.  It does not need to appear in <spanx style="verb">mediaTypes</spanx>, but
SHOULD describe the primary shared resource. [RFC6838]</t>
      <t>OPTIONAL mediaTypes (array of strings)
An array of media types (MIME types) the webapp server can handle.
This can be any media type entries from the IANA Media Type
registry.  The receiver MAY use this as a hint for UI or routing
decisions, and MAY ignore values it does not understand.  Unlike
<spanx style="verb">appIconHint</spanx>, this describes formats the webapp can open rather
than the share-level icon hint. [RFC6838]</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="request-for-a-share"><name>Request for a Share</name>

<t>If the Receiving Party knows of a resource that has not yet
been shared, the Receiving Party MAY request that it be shared.
Such a Request for a Share MUST be an HTTP POST request</t>

<t><list style="symbols">
  <t>to the <spanx style="verb">/request-share</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>
</list></t>

<t>When HTTP Message Signatures are available, the Request for a Share
MUST be signed and verified as described in <xref target="http-message-signatures">HTTP Message
Signatures</xref>.  As requesting access to a
restricted resource relies on authenticating the requester,
implementations SHOULD NOT use this feature unless signing is
available.</t>

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

<t><list style="symbols">
  <t>REQUIRED owner (string)
OCM Address of the user who will be requested to share the resource.</t>
  <t>REQUIRED shareWith (string)
OCM Address of the user or group that wants to receive a share of
the resource.
Example: "51dc30ddc473d43a6011e9ebba6ca770@cloud.example.org"</t>
  <t>REQUIRED share (string)
A unique identifier for the resource.
Example: 1234567890abcdef or https://cloud.example.org/files/data.txt</t>
</list></t>

<t>Any HTTP Signature on the Request for a Share is verified as described
in <xref target="http-message-signatures">HTTP Message Signatures</xref> before the
Sending Server acts on it.</t>

<t>After receiving a request for a Share, the Sending Party MAY
send a Share Creation Notification to the Receiving Party
using the OCM address in the shareWith field.</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-3"><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'
Registered values are listed in the "OCM Notification Types"
registry (see <xref target="iana-considerations">IANA Considerations</xref>).</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 inspected at step 1 exposes the <spanx style="verb">exchange-token</spanx>
 capability with a <spanx style="verb">tokenEndPoint</spanx>, the receiver MAY attempt 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>
  <t>For the specific case where <spanx style="verb">protocol.webapp</spanx> is available and the
receiver wants to use it, the receiver MUST present the web app to
the user by opening <spanx style="verb">protocol.webapp.uri</spanx> using a target selected
from the intersection of <spanx style="verb">protocol.webapp.targets</spanx> and the targets
advertised in the receiver's <spanx style="verb">webapp-receive</spanx> discovery property.
If this intersection is empty, the receiver MUST treat the <spanx style="verb">webapp</spanx>
option as unusable for this Share.  If the selected target is
<spanx style="verb">blank</spanx>, the receiver MAY use <spanx style="verb">_blank</spanx> or <spanx style="verb">_top</spanx> according to its
local presentation policy.  The receiver MUST inspect
<spanx style="verb">protocol.webapp.requirements</spanx>: 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.  The receiver MUST NOT place the
<spanx style="verb">protocol.webapp.sharedSecret</spanx> in the URI and MUST NOT expose it to
the browser.  Instead, the receiver MUST first exchange it at the
Sending Server's {tokenEndPoint} using the Code Flow, then deliver
the resulting bearer token to the web app via an HTTP POST to
<spanx style="verb">protocol.webapp.uri</spanx> with the token carried in a form field named
<spanx style="verb">access_token</spanx> along with another form field named
<spanx style="verb">expired_session_redirect_uri</spanx>.  The
<spanx style="verb">expired_session_redirect_uri</spanx> value MUST be an absolute HTTPS URI
controlled by the Receiving Server.  The Sending WebApp MAY navigate
the browser to this URI when the posted session expires so that the
Receiving Server can restart access and obtain a fresh token; it
MUST NOT place the shared secret or access token in that URI.
Sending WebApps that do not support session refresh MAY ignore this
field.  This is typically achieved with an auto-submitting
HTML form whose <spanx style="verb">target</spanx> attribute selects the chosen
presentation (e.g. an iframe name, <spanx style="verb">_blank</spanx>, or <spanx style="verb">_top</spanx>).</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="ed25519";
  tag="ocm"
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 anchor="decision-table"><name>Decision Table</name>

<t>The directional contract depends first on whether the share is strict.
For strict shares, the Receiving Server's advertised behavior determines
whether the Sending Server can require code flow.  For non-strict
shares, the Sending Server's advertised behavior determines whether
token exchange is available in addition to legacy access.</t>

<t><list style="numbers" type="1">
  <t>If the Sending Server includes <spanx style="verb">must-exchange-token</spanx> in
<spanx style="verb">protocol.webdav.requirements</spanx> and the Receiving Server exposes the
<spanx style="verb">exchange-token</spanx> capability, strict token exchange is required
before the Resource is accessed.</t>
  <t>If the Sending Server includes <spanx style="verb">must-exchange-token</spanx> and the
Receiving Server does not expose the <spanx style="verb">exchange-token</spanx> capability,
the Sending Server SHOULD NOT include that requirement, because the
Receiving Server may be unable to complete the exchange.</t>
  <t>If the Sending Server omits <spanx style="verb">must-exchange-token</spanx> and exposes the
<spanx style="verb">exchange-token</spanx> capability with a <spanx style="verb">tokenEndPoint</spanx>, the Receiving
Server MAY attempt token exchange first and MUST fall back to legacy
shared-secret access if that exchange fails.</t>
  <t>If the Sending Server omits <spanx style="verb">must-exchange-token</spanx> and does not
expose the <spanx style="verb">exchange-token</spanx> capability, only legacy shared-secret
access is available.</t>
</list></t>

<t>The following examples illustrate typical end-to-end outcomes:</t>

<t><list style="numbers" type="1">
  <t>Strict required code flow: Provider A acts as Sending Server and
exposes the <spanx style="verb">exchange-token</spanx> capability with a <spanx style="verb">tokenEndPoint</spanx>.
Provider B acts as Receiving Server and advertises both
<spanx style="verb">exchange-token</spanx> and <spanx style="verb">must-exchange-token</spanx>.  After discovering B's
<spanx style="verb">must-exchange-token</spanx> criteria, A MUST include <spanx style="verb">must-exchange-token</spanx>
in <spanx style="verb">protocol.webdav.requirements</spanx>.  B MUST exchange the
<spanx style="verb">sharedSecret</spanx> at A's <spanx style="verb">tokenEndPoint</spanx> and then use only the bearer
token to access the Resource.</t>
  <t>Optional exchange with fallback: Provider A acts as Sending Server
and exposes the <spanx style="verb">exchange-token</spanx> capability with a <spanx style="verb">tokenEndPoint</spanx>.
Provider B does not advertise <spanx style="verb">must-exchange-token</spanx>, so A sends a
share without <spanx style="verb">must-exchange-token</spanx>.  When B later accesses the
Resource, it MAY attempt the token exchange at A's <spanx style="verb">tokenEndPoint</spanx>,
but if that exchange fails it MUST fall back to the legacy
<spanx style="verb">sharedSecret</spanx>.</t>
  <t>Legacy share to a code-flow-capable peer: Provider A does not
expose the <spanx style="verb">exchange-token</spanx> capability.  Provider B does expose
<spanx style="verb">exchange-token</spanx>, so B is capable of honoring strict inbound shares
from other peers.  Because A does not advertise a <spanx style="verb">tokenEndPoint</spanx>,
A can only send a legacy share and B can only use legacy
shared-secret access for that share.</t>
  <t>Asymmetric role behavior: Provider A exposes <spanx style="verb">exchange-token</spanx> and
<spanx style="verb">must-exchange-token</spanx>, so it can require code flow for inbound
shares when it acts as Receiving Server.  When A later acts as
Sending Server toward Provider B, and B does not advertise
<spanx style="verb">must-exchange-token</spanx>, A MAY omit <spanx style="verb">must-exchange-token</spanx>.  B may then
attempt token exchange against A's <spanx style="verb">tokenEndPoint</spanx> or fall back to
legacy access.  A therefore accepts strict inbound shares while
still choosing a legacy-compatible outbound share.</t>
</list></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>

<t>[RFC Editor: please replace all occurrences of "RFC XXXX" with the
RFC number assigned to this document and remove this note.]</t>

<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 [RFC8615]):</t>

<dl>
  <dt>URI suffix:</dt>
  <dd>
    <t>ocm</t>
  </dd>
  <dt>Change controller:</dt>
  <dd>
    <t>IETF</t>
  </dd>
  <dt>Specification document(s):</dt>
  <dd>
    <t>RFC XXXX (this document)</t>
  </dd>
  <dt>Status:</dt>
  <dd>
    <t>permanent</t>
  </dd>
  <dt>Related information:</dt>
  <dd>
    <t>N/A</t>
  </dd>
</dl>

</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]):</t>

<dl>
  <dt>Type Name:</dt>
  <dd>
    <t>ocmAddress</t>
  </dd>
  <dt>Intended Usage:</dt>
  <dd>
    <t>common</t>
  </dd>
  <dt>Since Version:</dt>
  <dd>
    <t>1.0</t>
  </dd>
  <dt>Until Version:</dt>
  <dd>
    <t>N/A</t>
  </dd>
  <dt>Change Controller:</dt>
  <dd>
    <t>IETF</t>
  </dd>
  <dt>Reference or Description:</dt>
  <dd>
    <t>An object representing an OCM address.  The object contains:
</t>

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

    <t>See RFC XXXX, <xref target="jscontact-types-registry"></xref>.</t>
  </dd>
</dl>

</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]):</t>

<dl>
  <dt>Property Name:</dt>
  <dd>
    <t>ietf.org:ocmAddresses</t>
  </dd>
  <dt>Property Type:</dt>
  <dd>
    <t>String[ocmAddress]</t>
  </dd>
  <dt>Property Context:</dt>
  <dd>
    <t>Card</t>
  </dd>
  <dt>Intended Usage:</dt>
  <dd>
    <t>common</t>
  </dd>
  <dt>Since Version:</dt>
  <dd>
    <t>1.0</t>
  </dd>
  <dt>Until Version:</dt>
  <dd>
    <t>N/A</t>
  </dd>
  <dt>Change Controller:</dt>
  <dd>
    <t>IETF</t>
  </dd>
  <dt>Reference or Description:</dt>
  <dd>
    <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.
See RFC XXXX, <xref target="jscontact-properties-registry"></xref>.</t>
  </dd>
</dl>

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

<t>The following entry is to be registered in the "JSContact Enum
Values" registry (using the template from [RFC9553]):</t>

<dl>
  <dt>Property Name:</dt>
  <dd>
    <t>ietf.org:ocmAddresses/source</t>
  </dd>
  <dt>Context:</dt>
  <dd>
    <t>Card</t>
  </dd>
  <dt>Since Version:</dt>
  <dd>
    <t>1.0</t>
  </dd>
  <dt>Until Version:</dt>
  <dd>
    <t>N/A</t>
  </dd>
  <dt>Change Controller:</dt>
  <dd>
    <t>IETF</t>
  </dd>
  <dt>Reference or Description:</dt>
  <dd>
    <t>Values indicating how an OCM address was established.  See
RFC XXXX, <xref target="jscontact-enum-values-subregistry"></xref>.</t>
  </dd>
</dl>

<section anchor="jscontact-enum-values-subregistry"><name>JSContact Enum Values Subregistry</name>

<t>IANA will create a subregistry for "ietf.org:ocmAddresses/source"
(Context: Card) in accordance with [RFC9553], Section 3.7.2.  All
entries in the initial contents below have a Since Version of 1.0,
no Until Version, and IETF as the Change Controller.  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="open-cloud-mesh-parameters-registry-group"><name>Open Cloud Mesh Parameters Registry Group</name>

<t>IANA is requested to create a new registry group titled "Open Cloud
Mesh (OCM) Parameters", containing the registries defined in the
following subsections.  Unless stated otherwise, the registration
policy for each registry in this group is "Specification Required"
[RFC8126].  The Designated Expert SHOULD verify that a requested entry
is documented in a stable, publicly available specification and that it
does not duplicate an existing entry.</t>

</section>
<section anchor="ocm-resource-types-registry"><name>OCM Resource Types Registry</name>

<t>IANA is requested to create the "OCM Resource Types" registry in the
"Open Cloud Mesh (OCM) Parameters" group.  This registry records the
resource type values used both in the "resourceType" field of a
<xref target="share-creation-notification">Share Creation Notification</xref> and in the
"name" field of each entry in the "resourceTypes" array advertised by
the <xref target="ocm-api-discovery">OCM API Discovery</xref> endpoint.</t>

<t>Registration Policy: Specification Required [RFC8126]</t>

<t>Initial Contents:</t>

<figure><artwork><![CDATA[
   +===============+=====================+===============+
   | Resource Type | Description         | Reference     |
   +===============+=====================+===============+
   | file          | A single file       | This document |
   | folder        | A folder/collection | This document |
   +===============+=====================+===============+
]]></artwork></figure>

</section>
<section anchor="ocm-protocols-registry"><name>OCM Protocols Registry</name>

<t>IANA is requested to create the "OCM Protocols" registry in the "Open
Cloud Mesh (OCM) Parameters" group.  Each entry records a protocol
property name that MAY appear in the "protocols" object advertised by
the <xref target="ocm-api-discovery">OCM API Discovery</xref> endpoint or in the
"protocol" object of a
<xref target="share-creation-notification">Share Creation Notification</xref>.</t>

<t>A property whose "Role" is "send" (e.g. "webdav") advertises support
for the Sending Server role in Discovery and is the value used in the
share "protocol" object.  Its "-receive" suffixed counterpart (e.g.
"webdav-receive"), whose "Role" is "receive", advertises support for
the Receiving Server role in Discovery.  Which protocols MAY be used
for a given resource type and share type is governed by the
<xref target="ocm-share-payloads-registry">OCM Share Payloads</xref> registry.</t>

<t>Registration Policy: Specification Required [RFC8126]</t>

<t>Initial Contents:</t>

<figure><artwork><![CDATA[
   +================+=========+===============+
   | Property       | Role    | Reference     |
   +================+=========+===============+
   | webdav         | send    | This document |
   | webdav-receive | receive | This document |
   | webapp         | send    | This document |
   | webapp-receive | receive | This document |
   | ssh            | send    | This document |
   | ssh-receive    | receive | This document |
   +================+=========+===============+
]]></artwork></figure>

</section>
<section anchor="ocm-share-types-registry"><name>OCM Share Types Registry</name>

<t>IANA is requested to create the "OCM Share Types" registry in the
"Open Cloud Mesh (OCM) Parameters" group.  Each entry records a share
type that MAY appear in the "shareTypes" array advertised by the
<xref target="ocm-api-discovery">OCM API Discovery</xref> endpoint or in the "shareType"
field of a <xref target="share-creation-notification">Share Creation Notification</xref>.
This document registers only the "user" and "group" share types; other
specifications MAY register additional share types in this registry.
The "federation" share type, for example, is registered by [OCM-MLS].</t>

<t>Registration Policy: Specification Required [RFC8126]</t>

<t>Initial Contents:</t>

<figure><artwork><![CDATA[
   +============+===============+
   | Share Type | Reference     |
   +============+===============+
   | user       | This document |
   | group      | This document |
   +============+===============+
]]></artwork></figure>

</section>
<section anchor="ocm-share-payloads-registry"><name>OCM Share Payloads Registry</name>

<t>IANA is requested to create the "OCM Share Payloads" registry in the
"Open Cloud Mesh (OCM) Parameters" group.  Whereas the "OCM Resource
Types", "OCM Share Types", and "OCM Protocols" registries record the
identifiers advertised in Discovery, this registry records the
wire format of the share payload itself: each entry binds a meaningful
combination of resource type, share type, and one or more protocols to
the document that completely specifies the wire format of the
<xref target="share-creation-notification">Share Creation Notification</xref> for that
combination.  Two implementations may agree on the Discovery
identifiers and still fail to interoperate if the fields and structure
of the payload are left unspecified; this registry is where that wire
format is pinned down.</t>

<t>Every value in the "Resource Type", "Share Type", and "Protocols"
columns MUST already appear in the corresponding "OCM Resource Types",
"OCM Share Types", or "OCM Protocols" registry.  For each entry,
the Designated Expert MUST verify that the referenced specification
completely specifies the wire format of the share payload for the
combination, including every required and optional field and the full
shape of the "protocol" details object.</t>

<t>The registered combinations are a constrained subset, not the full
Cartesian product of those three registries, even though for the
initial content the subset and the Cartesian product correspond.
However, in other cases beyond file sharing, a protocol may only be
meaningful for certain resource types.  A calendar event, for example,
is usually shared over CalDAV or JMAP, not over ssh.  Other
specifications MAY register additional combinations, including ones
that extend an already-registered protocol to a new resource type or
share type; doing so does not modify that protocol's own registration.
The federation combinations are registered in this way by [OCM-MLS].
If someone wants to specify how to share calendar events over ssh in an
interoperable way, they can do so using this very mechanism.</t>

<t>Registration Policy: Specification Required [RFC8126]</t>

<t>Initial Contents:</t>

<figure><artwork><![CDATA[
   +===============+============+=====================+===============+
   | Resource Type | Share Type | Protocols           | Reference     |
   +===============+============+=====================+===============+
   | file          | user       | webdav, webapp, ssh | This document |
   | file          | group      | webdav, webapp, ssh | This document |
   | folder        | user       | webdav, webapp, ssh | This document |
   | folder        | group      | webdav, webapp, ssh | This document |
   +===============+============+=====================+===============+
]]></artwork></figure>

</section>
<section anchor="ocm-notification-types-registry"><name>OCM Notification Types Registry</name>

<t>IANA is requested to create the "OCM Notification Types" registry in
the "Open Cloud Mesh (OCM) Parameters" group.  This registry records
the values that MAY appear in the "notificationType" field of an OCM
notification sent to the "/notifications" endpoint (see
<xref target="share-acceptance-notification">Share Acceptance Notification</xref>).</t>

<t>The "Scope" field indicates whether the notification refers to a Share,
in which case the "providerId" field is REQUIRED, or to a Group.  The
"Status" field is one of "active" or "experimental".</t>

<t>Registration Policy: Specification Required [RFC8126]</t>

<t>Initial Contents:</t>

<figure><artwork><![CDATA[
   +===========================+=======+==============+===============+
   | Notification Type         | Scope | Status       | Reference     |
   +===========================+=======+==============+===============+
   | SHARE_ACCEPTED            | Share | active       | This document |
   | SHARE_DECLINED            | Share | active       | This document |
   | SHARE_UNSHARED            | Share | active       | This document |
   | REQUEST_RESHARE           | Share | experimental | This document |
   | RESHARE_UNDO              | Share | experimental | This document |
   | RESHARE_CHANGE_PERMISSION | Share | experimental | This document |
   +===========================+=======+==============+===============+
]]></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">must-use-mfa</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.  Where signatures are used,
they MUST follow the requirements in
<xref target="http-message-signatures">HTTP Message Signatures</xref>.</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="copying-conditions"><name>Copying conditions</name>

<t>The author(s) agree to grant third parties the irrevocable right to
copy, use and distribute the work, with or without modification, in
any medium, without royalty, provided that, unless separate permission
is granted, redistributed modified works do not contain misleading
author, version, name of work, or endorsement information.</t>

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

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

<t>[IANA-DIGEST-ALG] IANA, "<eref target="https://www.iana.org/assignments/http-digest-hash-alg/http-digest-hash-alg.xhtml">Hash Algorithms for HTTP Digest Fields</eref>".</t>

<t>[IANA-SIG-ALG] IANA, "<eref target="https://www.iana.org/assignments/http-message-signature/http-message-signature.xhtml#signature-algorithms">HTTP Signature Algorithms</eref>".</t>

<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>[RFC4648] Josefsson, S. "<eref target="https://datatracker.ietf.org/doc/html/rfc4648">The Base16, Base32, and Base64 Data
Encodings</eref>", October
2006.</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>[RFC6838] Freed, N., Klensin, J., Hansen, T. "<eref target="https://datatracker.ietf.org/html/rfc6838">Media Type
Specifications and Registration Procedures
</eref>", January 2013.</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>[RFC8126] Cotton, M., Leiba, B. and Narten, T. "<eref target="https://datatracker.ietf.org/doc/html/rfc8126">Guidelines for
Writing an IANA Considerations Section in RFCs</eref>", June 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>[RFC9530] Polli, R., Marwood, D., "<eref target="https://datatracker.ietf.org/doc/html/rfc9530">Digest Fields</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 anchor="informative-references"><name>Informative References</name>

<t>[OCM-IP] Nordin, M., Lo Presti, G., and Baghbani, M. "<eref target="https://datatracker.ietf.org/doc/draft-nordin-ocm-integration-protocol/">Open Cloud Mesh
Integration
Protocol</eref>",
Work in Progress, Internet-Draft.</t>

<t>[OCM-MLS] Nordin, M., Lo Presti, G., and Baghbani, M. "<eref target="https://datatracker.ietf.org/doc/draft-nordin-ocm-mls-federated-groups/">Federated Groups
in Open Cloud Mesh using Messaging Layer
Security</eref>",
Work in Progress, Internet-Draft.</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">must-use-mfa</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">must-use-mfa</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]:
"content-length": [body-length]
"date": [date]
"@signature-params": ("@method" "@target-uri" "content-digest"
    "content-length" "date");
    created=[timestamp];
    keyid="sender.example.org#key1";
    alg="ed25519";
    tag="ocm"
</sourcecode>

<t>Sign this base using for example Ed25519 ([RFC8032]) to produce the
signature, and then add headers (line breaks for display purposes
only).  Note that the dictionary label (<spanx style="verb">sig1</spanx> below) is arbitrary; the
signature is marked as belonging to OCM by its <spanx style="verb">tag="ocm"</spanx> parameter,
which is part of the signature base above:</t>

<sourcecode type="http">
Content-Digest: sha-256=:[digest-value]:
Content-Length: [body-length]
Date: [date]
Signature-Input: sig1=("@method" "@target-uri" "content-digest"
    "content-length" "date");
  created=[timestamp];
  keyid="sender.example.org#key1";
  alg="ed25519";
  tag="ocm"
Signature: sig1=:[signature-value]=:
</sourcecode>

<t>The covered components, the <spanx style="verb">created</spanx> parameter, the single <spanx style="verb">ocm</spanx>
tag, and the prohibition on symmetric algorithms shown here are
normative; see <xref target="http-message-signatures">HTTP Message Signatures</xref> for
the full requirements.</t>

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

<t>The normative verification requirements are specified in
<xref target="http-message-signatures">HTTP Message Signatures</xref>.  The following
illustrates the procedure 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>Locate the unique signature carrying the <spanx style="verb">tag="ocm"</spanx> parameter in
the <spanx style="verb">Signature-Input</spanx> header, disregarding its dictionary label
(here <spanx style="verb">sig1</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.example.org",
        "displayName": "OCM Server 1"
      },
      {
        "url": "https://ocm-server.example.com:4443",
        "displayName": "OCM Server 2"
      },
      {
        "url": "http://192.168.1.1:8080",
        "displayName": "OCM Server 3"
      }
    ]
  },
  "protected": {"alg": "ES256"},
  "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            |
            | - tokenEndPoint       |
            | - ...                 |
            +-----------------------+
                   |
                   | exposes
                   |
         +---------+---------+----------------------+
         |                   |                      |
         v                   v                      |
+------------------+  +------------------+          |
| ResourceTypes[]  |  | Capabilities[]   |          |
+------------------+  +------------------+          |
| - name           |  | - enforce-mfa    |          |
| - shareTypes[]   |  | - exchange-token |          |
| - protocols{}    |  | - http-sig       |          |
| - ...            |  | - invites        |          |
+------------------+  | - notifications  |          |
       |              | - protocol-object|          |
       |              | - ...            |          |
       |              +------------------+          |
       |                                            |
       |                           +----------------+
       |                           |
       |                           v
       |              +--------------------------+
       |              |    Criteria[]            |
       |              +--------------------------+
       |              | - allowlist              |
       |              | - denylist               |
       |              | - must-use-http-sig      |
       |              | - must-invite            |
       |              | - must-exchange-token    |
       |              | - ...                    |
       |              +--------------------------+
       |
       | supports
       v
+------------------+
|   Protocols      |
+------------------+
| - ssh            |
| - ssh-receive    |
| - webapp         |
| - webapp-receive |
| - webdav         |
| - webdav-receive |
| - ...            |
+------------------+
]]></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>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, etc.)</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-06"><name>Version 06</name>
<t><list style="symbols">
  <t>Introduced IANA Registries for resource types, protocols, share
types, and share payloads, and populated them with all relevant
values defined in this document.</t>
  <t>Moved the <spanx style="verb">federation</spanx> share type definition along with the
corresponding share payload description to the [OCM-MLS] Draft.</t>
  <t>Improved the http-sig related text, and promoted it from an
appendix to a normative section. In addition, made the use of
http-sig a MUST for implementations that offer it as capability.</t>
  <t>Sorted the Terms and removed duplicates.</t>
  <t>Addressed the IANA early review: added the Status field to the
Well-Known URI registration, added section references to the
JSContact registrations, moved the creation of the JSContact enum
values subregistry to a dedicated subsection, and reformatted the
registration templates so each field renders on its own line.</t>
</list></t>

</section>
<section anchor="version-05"><name>Version 05</name>
<t><list style="symbols">
  <t>Introduced a <spanx style="verb">/request-share</spanx> endpoint to request a user of an
OCM server to share a resource.</t>
  <t>Refactored the <spanx style="verb">webapp</spanx> protocol to align it to the new security
standard, by means of POST requests and the Code Flow.</t>
  <t>Introduced new <spanx style="verb">&lt;protocol&gt;-receive</spanx> protocols in the Discovery
endpoint, to signal the ability to receive an OCM share carrying
that protocol.</t>
  <t>Introduced new Internet-Draft specifications to cover optional
parts of the protocol related to webapp integrations and federated
groups.</t>
  <t>Renamed some requirements and criteria to improve consistency.</t>
  <t>On a Share Creation Notification, made the <spanx style="verb">sharedSecret</spanx>
a required parameter for all protocol payloads that specify it.</t>
  <t>Fixed all example URIs to use <spanx style="verb">example.org</spanx> across the spec.</t>
  <t>Improved the JWKS-related text and fixed obsoleted references.</t>
  <t>Removed the already deprecated <spanx style="verb">/ocm-provider</spanx> endpoint and the
draft-cavage public key advertisement in the OCM Discovery endpoint
as all known implementations have migrated to the recommended
alternatives.</t>
</list></t>

</section>
<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, Thibault Meunier,
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, Enrique Pérez Arnaud, 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>

<t>Work on this document has been partially funded over the years by
multiple projects and funding agencies:</t>

<t><list style="symbols">
  <t>The <eref target="https://cs3mesh4eosc.eu/">CS3MESH4EOSC</eref> project "Interactive and agile/responsive
sharing mesh of storage, data and applications for EOSC", whose key
result was <eref target="https://cs3mesh4eosc.eu/science-mesh">Science Mesh</eref>, received funding from the
European Union's Horizon 2020 research and innovation programme under
Grant Agreement no. <eref target="https://cordis.europa.eu/project/id/863353">863353</eref>.</t>
  <t><eref target="https://www.nlnet.nl/">NLnet</eref> through the <eref target="https://www.nlnet.nl/core">NGI0 Core Fund</eref>, with
financial support from the European Commission's
<eref target="https://ngi.eu/">Next Generation Internet</eref> programme under grant agreement
No. <eref target="https://cordis.europa.eu/project/id/101092990">101092990</eref>.</t>
  <t>The <eref target="https://www.eosc-data-commons.eu/">EOSC Data Commons</eref> project "Services for inter- and
cross-disciplinary data discovery, access, sharing and reuse in the
EOSC Federation", received funding from the European Union under Grant
Agreement no. <eref target="https://cordis.europa.eu/project/id/101188179">101188179</eref>.</t>
  <t><eref target="https://www.sovereign.tech/">Sovereign Tech Agency</eref> through the <eref target="https://www.sovereign.tech/programs/fund">Tech Fund</eref>, with
a specific <eref target="https://www.sovereign.tech/tech/open-cloud-mesh">project</eref>.</t>
</list></t>

</section>


  </middle>

  <back>








  </back>

<!-- ##markdown-source:
H4sIAAAAAAAAA9y9+3LbVrYn/P9+ChRTNZZ6SOrqm3LSX2RLtpVYttuy48lx
uUyQBEVEJMAGQMlMn+6a15jXmyf51nVfAJCSnUzPV5/rnI5IAvu69trr+lu9
Xs9UaTVLjqJ7rxdJFj2d5ctxdJ6U03tmnI+yeA4/jYt4UvXSpJr08tG8l8OD
vRE+2JvDg73dB2YUV8llXqyOorIaG5MuiqOoKpZltb+7+3h338RFEh9Fx4vF
LIVH0zwrozgbR2+TeNZ7l84Tc5WsbvJifBSdZVVSZEnVO8FOjSkrePBzPMsz
GMgqKeELaGsOD56+e2ZMvKymeXFkoqgXpVl5FD3vRy/z6E2RlFUK30YRT+F5
uiyTxSKp/ZgXl3GW/k5DOoqenr59RV8n8zidHUWX8lJ/li/onR9HMLb+aEoP
LYv0KJpW1aI82tmRH3b0SeNGdN5/0o/GSfRTnl16IzpPR9M0mQW/hMN5k2fj
pIgu8mUxSvxxzfnVHxf0QEm/9+Hd5rCCJ0b5PBhW9CS+nA6hQ39U8XSchj/c
dVD45h8e0isggjQLl+kq8b8Oh3Px/tXpO38YV3GW/1gugYL6ZdKyT/k46Zfz
fIYPQFM7c2zfmF6vF8VDoK14BERXOwrR1uun59tRCkQblUlxDfOfJDAJGkO0
KPIqH+WzqJrGFT4ERDOOqtxkeZVOVvDO22SUpNdpdhm9iYtqxQ9W02QVTePr
JBom0NtlEQPlj6N4NErKEl6PyhzOxdtEViqKzip4vIzKdJ7O4iKt0qSMbtJq
GvEZkCWJJrP8Bp5ajuCH0rw+hh+78Fd0k8xm9F98pcxHaTyDVefDZudgX4yO
RxUMuVq9WQ4NHlVa3r4xx9EoLxKcYzSK4X/ySQSLg9O+mcI0YvyliLaS/mW/
Gx3DcYdHsuhiVVbJPDrehu7LKZxinN8UuAK8UMgU9aU4mqSzZFvmBos4hQb9
Vp/kQ2jTSJtP+Ml8CUsKa1hOkqLApYbXXNNpVSazCdAOfPX3ZUoPYDOwS7P8
EtYBF1wHCbP8MIUhQBMwrXKUZLDcOU4xnc2WSCOwNElX5z1OyvQyoy2H1Vss
8qKKYjMs8hgPCgzpklaJ1hqoC5lfFz6NZssxDmMIA4dJRjPY14pbwfkbnUzZ
b9LjFHZkBtvvtwlLMltFywU2gHNf5PArbkqBE0FKCokQp5NN8mIOfcLw4JG0
8KgPm/CID8hhGc8sOeqDuD7LYQlrmmQVdD+Ps/gSGhyuIt43S1hdS5IfkuHJ
8S99PnPzdAwzMeY7ZPxFPl7SZJozvolxuED08Qy6GeUZToZHDpu3v7t3ny4U
PCB0nMbJYpavkrEpYaUTfOABzAJ3zD6SzhezZJ7QqYPxlgmcazgTi1lc4bL4
m2TwZniSf+lGr5IvFV19sP0wxKf8Z36jf+EgLpIYdxBm+A4W8TKHRt0pgaWF
NblOxwkxk9GyAEoqR/EsHs4Sfn8yS76k8MnA/hQx0BssCjwWwajkDVgCPD24
mfgCrC+8niNdwjdw3JTu6ZY1xDVwxjfU6zhf4Bp3meoS6IDof4qbCiQLDBF7
qfJCJkDnHd6Mw1nM4ys8V8iPYB1pcHhI6bcx00+RXk4rA6cou4TFf4enCXko
Xl7XvOi8FDSPGh9VZgzP38QrQ/MGdkTzRYYH+yaiBOx1BbypjCZFPqd+7Tjw
AzNs7BZXx8Dzw2QaIzOYuIeRwoXTwHTgBAMzlhMkj9nR4eynuDfAHbn/eTKC
A5mWcx75LKlKGQLQaQZLGeV4ZYBYAHuM7A/odAknxcBGsjA0TRcsECFbBV6G
zJVfpZMNM7Ev4w8VzAVmUd3Apho+uLDjC3wcrhPcIpl0Hw/WuwSImbcSpKwI
xawy6py/v3jX6fJ/o1ev6e+3p397f/b29AT/vnhx/PKl/cPIExcvXr9/eeL+
cm8+fX1+fvrqhF+Gb6PgK9M5P/61w+Tdef3m3dnrV8cvO0x3yELz0RJPYoQ3
Asx2mDBrA1mK7sTSAJMdFekQPsA7T56+ifYOo49vnz3d39t7/In+erT38PAT
XULcDbFD+mjoqo1BkIsLfB1YCNxdC9g+ZEt4OKZwgCPklMj6EyCoSZoR1wSy
nsF9igRKPGdRwRtyg84TOEFZLwNeQRcC7AGw6yTDYwf3Cm1uMrbvMXnSfUzj
ffDwEEZOV+usTIhPHxnzl+jz55O0HCHFIEcAZoI7+fkzyEjHKnyw/FCkSal3
DkyVmTlTJIlKSAfHb84ibW7VD1rHOd3eeD6Es5XdufFnViySRi+LHK4kYRxv
mPHh2cROSPjxTgU0O1/iNcOqAx/1yyIhCQIEbBrJIgeZAgeHDMe7//AEQwNu
ABFQHBLSJB6lMzyqzHFiGHJB7G1F0wcBRYb+t5NXNOhnS7xi/gbjSCcpvHSS
z7HjVyCO2kssGnToFugnX2JkfyhKdgbc0BlyhgRuTNz2GG+f5zBJ4NrUuvzt
mJU8ztczrn8O02j7AVeQN6wre65ijjz5Lr9CCcyKetIObdV4XOB9LcxMXrhI
UBTvRslkwrwD5h0jvcN+VNI4NBI87Q1DLqSM+PcFSXNPQTejxX+Fsq/V9e4w
p3Vr9xZli7JicgKCG+HpXbt40B70JMOTC2Dd8G9ZRWhHRebNq6idB+sIb9dX
8lvWEZqpr+Q3r2MJmlfJRPji3bs3dGXgN2GbJmpZ/aBRu8d3IWuZLHexgZa6
OJzljNZKpJGR9gPLHWdueLRBwYhAQixB7KSBvF5WvXzSGyLzmPP3qpA1L1Fo
Ta7RaAFCccoCkxUZZCDSyzPYzi6/CZIoiV61QUVbIGZBi/DgNjXUWIh7pU9I
wSR0L2kWeFkvSEwvrNhuu+uiNJZVzJ2ApYFyoxx5Q7veYtsuhOVP89lYeoiF
xId5fgWN0soNV+3kDit6M02BH6oA1sZd8ErHw0+XOrSejIPR8UO1OetZ+MYZ
N4jrD81XmeQts7XLfMt8K7x4mZtlNZYjBIMXUUDzMgSZsfCM30A4lRstiwY/
DnqohHaxgSwCGSSHjmE2pGCCmv7gcFnMoi0+g+/fvuyxogFaClpZemU8gcHO
FtMYjoOIPyRpoaBy+ODw0acu9Ev3bHSf9W1oZwHTI4UDFNeqNk+aksgAwNHG
vSrvXS5xpUtaAV7plgMG7V4mGd7ha3bCXwScxCzNrnCuWQqsCi6wdlbTdvC8
L2iklsZKNWMAX2YBphNXHVxon89GRFL+vSC8wTMToVCO3Ft1bu2hQDMHyPnI
gWb5KLZ3RG1y0CVra6iYglrSb3YK4jNoLnjfwMae4XUFStk4T+hrlrHK0RQU
XUtgbhSgxK101NACtIddg8wKWwbsEXjgkSEbWhSh4VcPyw9+E50fOzST6GPU
OerQKD/hSx33TIfUPpxKDHvUJcNRDw55mZLc/P7ds94joQu2c6V4vMsEuAGR
gb1UqB8hihkqrti5EJG/va6RRV6WqEsjWdBazPGSQYX1RzoxxORjfFlnB9d4
H4bB1ixcFbJ8WUbB6h9t2ozYlfIBfWCWXiH1DTJQELJ+BnpLmv/oiYk/NgTH
AdJSB+emC3X2BpqpyBwBZzlewM1IC4EHD8Zb/n2JQsIQ9ugqQY2EXrk+RCLQ
YYJanOOphNM8SufQEArwXaRotLhdglgCCseYjKxIM75+Bc3guT94/OjBJ7v/
tPQ/QDc9HdkO9akd7mCrPWzOyMkICBfNRKMcVOsM1bxRjFq4vZf5lKBsTo/C
N0uy3aJcNFYFgy9Xq2+gMoEmqG3/IMrJIZ0W2h/7ihSbXKNLoLiMZ0NaogyS
SAX6vk5jeuwDiH69nzPUC0m5fLB3/xNsN+hug50+yoW9K/xxB47FwB1KFJ5k
PVSv1uOFk4PXPc7ja0/Ef2RGSFDJdTxbMldYFPkiYdkELwW4aOY5iRxqi4Pt
n1S+fUG0VbISiBG1ISDiZ1+yFFatEpM9cc5qGAjVJGSLwMrfw1ahLhWh4BR3
5erRcxnKsPAimVbcSNbqoVNP+lbtMZosM1b56P2aXVMaWaCLAe5D0T8LkSxu
pmTHDY3tfF37Bk/4AO9dTulLksi/V7s7PtoRsdgZU3eit39/04GGYKNJxe+9
Pz9ukVqal1B9geuyCi4Du7dYEgQy2KhqeSJol16LVbOjRQBuSB/IN0E6PpnJ
dQzhrUdCyIoYQAoixfwWPc/2VyJHAaIjfW2Wwhp0WRtydvmgQ1hSNTxP2WfT
2AhpTTwAbEJm6eTx3qNP28qERXKkNkqP3PnQ2GaFSGwvYpG1AkdI29qE9y7J
qmkyIsv+OK7iKLRGOGnRGspJ18BGhfg2+wCOxA2C7U5AXGWJAQeJqjQqwfhZ
TnmXrKfUfQSEiVdsUo142DoVX1k75mWnFybxKAlGbo/+hV1L8VrlLWtDCtF1
YpVobCnTFSANDjgvcgskm3BEzePaOKfq2eJrgpvTxsr6kZS9fH2TkcSR1W1t
teOIh7XtQIbzW38cUYkoQ66x1aEt40c7OJvOaVYVCewNqNnP8LeLVTZiJ8GU
FYWt02cXF9v2nSKfJXJwhShLzykDkt0WkGjyBcQaUmDUgA/XatSBA9KRd6v4
Ss42Xv9luB+WqZFqgJbSGj3Q8blkgikbBCHkgMoE9Bn4Hi+8WUTir63twvoB
xkP04emW8/SqZI6m04BB2PWm5nkYdgtqI1jTO7IJuE6hu428lGXABd7ARYor
5zFXIRZ8XWkYLZOgsC+RBCoV6WGL1HQZo9WxFJFcFAMU2Xhm5CzhqdoZfo87
jnbMeFbmbF/mB4CB5gXpT3i4kAHhVkZIaiDDZ9I3nCAcjTdUO1NL16jDWSuL
LIecdNsszgY5nRjx6hwgzQJbUoxGUpzSZDmLauyH2RmqsurYhfGUepVv2IxA
NkBlUs5jwTexJVLSG7jL0hdYvCunlGGze755JfHvNFf0Q8maWLchH6KxP2I0
Dauui46dHjwyJqGTlZruugvG8ta8aF1ZVFqS2aImifErSwqjwOgYtFTSXePd
mnrC6bLxWIg/7DdJMU9LPHus/6qLq2e1Vrq0Y/JoqMhk5b/6eHJWw+b5WCRV
6lKX17qSvf7fkiueXLClCsC1AWAsTZFaB7frAQZwlz7Ga6/8kn9m+4lvhxwm
IunENMlAbohS7nPRNE6sNcVeiKP2fWklXOK2nuvT8vc4ago+4eX5Dj0jyTiQ
mP3x2yAUuJZLlJZxy/CdG9Bupiu+9/TsBdPWqyD3DKie26frhbygoyaZD4H8
pikL10Uayj+gk4qDcJgIs2JzT5xJ0AmpXKyIgjKH4pvMTIyvXZ6Ja2W5GJMO
TL7UKp3L7YWEkEVZcuMPVjQy27y0wgJXEljZmJjDzq2l5M0SFKpR9HOyYl0V
FVKynV+kl1lM1yPbGoBHk8UfuLR2oowVFOB5UsUkJKr3iCUlpBu2tZ+kMYah
vH/7EqdTaBgJWmLiRTxE/xXI6kwBH45/fQZH7lIp+gN6DnvH8P+/5sveM+SD
C1ThKFrJac8l+7poHqzwiDS0qtudAtOjknXfGPPdd9EzUb3KZoQGWw1L7BKu
H1A9VU2z5hgScbMEiT2GEeFixpmxYRixio02PmI2kx2aYxMZuvJA1oUrEc1W
bD/AO6bKDd+pYjCKwiZLsSNMyDvrjwun9F2gWxojp8kqm2yQwZXSwC00XqD4
ovwIjlb0GeWN8jOtnamLkGzJi5qqHkUdhN2p6QJaaXMDs+hoz0Qsli1RDaPP
gfzy2Ztgw+lpZ9r4pWXKJHAmZeAGFnHN+D7fhqOXRhC9xcVZTzG4gJZqaCHl
6m1ZGyMrf0RL31hpEvv09DYXnH6XVQlfxcC2mkWDlyEYAdskSPB/64fY6AIZ
EMGZkePFGUZTzfkY0C8lqR42TEXkcr6yys8YHIdmqsiFvpVBWxgfYvtHIqoP
HdmRniLXE9mCyFRJHIU0OrW1R2K4Bxr2HWUmsCP548Gbwl4ibr8j5EdoeyRJ
Khf51biQJ49/Uaib9c7XPQHCw+lxYmjYDtC8FyeHZvbKvzuCsXQlRKBkVyYv
GxuLTYlmT59ymb9917B3IV00bGDrKMNaaEQvcG7cUK8gYTXcsrLrTDJux/iM
qe3FKIFwgEurocURX0BhQj1iO/Rphy+vaA21QNuf1aL5JM+v8ISbz0+ZKMrP
9qh5FMXykaMnWFlg3ceLBc73S3RC1up8+BvGRaEoRxFVorZQrA9saxhXc7nE
kaHa4EL2eFpOBhYZ3o+nUs8u/IKKCUZBUTzUcyL5GREZh0XN0kkyWo1midx9
dUbF4ir0U1SyLjBeCiQtcYp0rRsYeGCBJZrstlplef9aQmhwNHypcHCsdYGD
sJDPrkVjDvXweXzF8XOqU6iqtcZe0/wObrSiIEWIgmjheMQU7VlTjrt2t2uv
W3dtPXjBp3pnYg0PE4YUk/ka1dVuu80ZCVSCqds0IRjWDhBH22RxxDcpRnEA
tTXPisjYrD1VLUGyeNe3WB6ENzVUoHAQ/CUOnryyLMCieAdEn/h2mCOhXg3h
M968cXFhZduWUiJseQ2Gsnfou8su6ZKLTn3ak0NrzJNkkhdJOx1k2t8GVVxV
wPo2kWRG8ouLs2jZLvbEGuUqW15ARdvmw+Moqjvisw8Ybc45GrfhsXmOhExL
Q5GnyOQuMFgPbgjgCig6LpBRJ9ScqRkoaobqcCuDEJItGwZoZsl1MrP30Pa6
eKHaQrBMyyNFj2jZNSEDuVMr0RQDGzO6CcQdGRChzIsFMZb1IjRKrpj1cfRu
CRd8zBJ5JVG6aXtvxJfoMKRFsI9WuKgtmRwxCpfMg9icOCvtrprwLeXwFH/P
8QKgNTLV10zXsirK/Kw6u+Ie6PfVgpgb+T8q2xgQ+4t35y+dYxS4woh5qcGg
ApYwQCcTnZr1OmYEdlA8MWyCV1g0xpf4Pl8wx5k3WtZ58mw1z5flbBVdp8kN
s06r+ItWURNP2QhIQmW2cnkb6j6BKSY6wUSFE+cLdrM1PFu6ZeskIiHavG6a
o1LbT92vBqPMl7MxqiS0OihdqQcOhMBayDJJwxSiYFgjZGkOXgYxGqM7MZPA
iwsNVtaTEI25YAfAbNW1hgUmirY1jNrX0Hz1GkbNNbSXLm2wOJmdg1YTVCQN
xY96x3NnBTRDq06haKMlejb8DIxIiZKPqJ0sLz1dMSQjqcA7tEYu1NYijGLA
LjEi0eNyqGRjCgd5/0mqMn44qNpX2xND6JjV5A8lJ9Mqf1g+AewDneuB+wW3
OdhfkshjtqKAxnqO+zZPYC3HrNS3urx5i5dZSZHCEoLtlBikXtgAGy5fp2Q0
+ifWkrZwV5YfcUPO/z5xUG/AklyUlK2sE28PR98iJqcV6DR0H6dBWERXhBJ3
DECgBZopOArLxkh7R8qgHq1hjCIw4tlxpp2SjkCCSjym8KjHAsO8MzckVjJs
yyTcqoIlK1kSv8TGQG9fzOIVEXLBl3hdznPLCox1k1xBahEswTKj5a1xHnRm
sH41FgUe73OMmPcUx2aImCq4FNNFMWLNqDu0sWu0dCNu1XOaheGmrT0v0UzS
uOxAf5tD505+Iimr8sPUpNEgwNRrPgwRbMzWBT2zsNQeJhyO2Fqss/g6vaQl
ujW6OGJ3w9x679YGu+ttglJXWyh+OmldcK8rq+zh1lmrgYTg6/XUWMDohtih
tcJargnnayJultaQe10Fcr63PXXj+KxnekuBRkdCIGktRhO3a4FBPRK6tW7F
+OqQS4KWN1tKntuiNTy9v2Ynvb7V8utFr4PiE8SsShBP+B4H7tCpgdu2oaOy
C7SUWFB2hd4+GPa3ts9eYmkaOQKNoYmFZn0LJxyYi9mbCboVqTWU9dH7Xq7g
WH2pBe0qzYTnyjSpmZVItiFbzlgzM3fXNKHDs6ZddiG8eQ0f5XqlxB85fIMd
9gz01NE04LizMFa2sTqiVkW4XdAYb+Mgdhn3O7+BODZQ78MA1UEYeu8dSD0D
TQjggU4TzFyFRtAYpF8O8/EqCH6Pfrp4/cplbgWuZ2vhQdekEr5LpRLpGTS2
2bjkaApNPTuKBrhhC9TP1bg2wKQc565Zk/ShHLBfb6/CEzMQd3dwiiL/qya9
UZtsa4cxoaDEd3LzBZUMSDKj/ihhlUOTqR30vNbGhXLn2UltYDqpQK2V2MX0
1qlSqCq2+CowoO34hvt49j2Z9/2oVmpzDXfsUwqK9dukKChUTsynjYlLy/58
BtgYH4aH4vBehF5yCkJdl1SDYjbHcy0vMSaFJAUODCXJo+1cwOoFgf16Ht69
vCDukDHB6/F33jxKQIyvYWk4HbeVZZn6iZb8b+QiMGQOMKrF1EYf/R6N6/HT
1neITdCTyEsKSuZftlHoD7gmpvb7EiEp+iwHcuZpTHGgX9gEhGcXw/5AB6s7
xFzyJkXawtW4zGYUnA+9k2JbulWQNOAN7F2aizkPEZgGSm9+oh7Lj7WbrHn3
iCQsGsVGbtpH5S8bNbwGLvJdZPEoScnC4mLYRM3DwAP0YdMi6mHsBjYH25an
onKAB7yak2MO9ugUdb2UrS71RZqSkmifJn2dQ66rtazMGWphJJZL0AZTXrof
dZ6G/CcYsKEk7QoYVorLdTwr8y65hNURatu2yjvrrWRJBGUlHk2dxRp11Os8
HZtRXqidnbLviUuxe9qctSUA3VWki52bx0lvk/RLMiadFTuzsQFp5gKXqrwb
iaMHGAo8BrM0kyJJelXyBe02i6XiIKD+6A1H9C2yNoGq5FLUyRJLUANGfMxp
28xStxexjwiCn0uC2BCnlOxpKSa/QlSLRb6gwH5qWucYvuncQyjs1plc6Qwb
lI6/ZECOlhxX1SfT0oASCr8J0gTdyczNJebGz6ln1mV9N09xi3ULc03jdb49
u6PKEWhQ2Dha0fR+QQFFQ8BpU3nzm35ooL1JerksBBnBt8u6NZVj6fYhSzDW
5Wr9UvK1b2zrtRx+30oUBNYE/WgaiZHuaIOWpd5KLCGBysfUYJNOcJMpOQO5
pF2u/nrJVsLqrGj7ru1Ccs95oQFhkidJmLVAvY3y+DfLkNJ+TYiUb/99UqST
rtqkg9tlq7WiVfbHRSsexh8QrNbJVdNb5SrNZvw6qcqTSgO5yhxH+7u7bnsx
UHTpLMib1D2Qj42LE+1DS4d3aYntIGT/vI5n6ZjcaXLrAWdLUTLApg5ub6pN
kpFkOjV3OXc2Xcb8Infw+PYOUAWIZ7gbKxs12Lf+twVn+9SEopaV4oxkNoWt
k4l4JN3Nt2+bmGYCPIU2Ma0tsBHjllZ04J0kq0Z3VRhhvf5UYRiIzfMy2fMd
Empz+XhNMD5eQj8sr6RoPaSd7N4mCa/beIaEKtPGVmriXRpGgxKTP1axhT0K
3mkC7v4s9y65kl2WXfgRHY2eBVcPKS0En3055eRNNOISRiFLKRndEopH4Oy4
7H9LMo5VTmbJSHd/jggIDeSyvs+E7mRN3mTwlUAYtufdYmA2gYFZIlQYcOwr
TMqyMp4pGc9jfXmJMOxqsRzMbtrYS+0lUpQcn8q4NAwrmGsYDdnuyVLI4bEc
EKPia1dFSxGkFROJAzFFedFsYg4L5TQpCW61EifIuhRWy/3aMEl2Dzt33m+o
LVpDOl9V6h+xmR5+ZAFRe8IhgX4XytoMG+vlHHJebGMu1tFbMPNTtii3vVEA
Ku84sKwswiH6xz01VndK4dbQ0IJeODkF6AhxeglZKbNL65uAhaALFidB7kn6
yicmY4lJkmCQYubxOLENWBuVnE7KqSWPnaDaUe42u142kGdMTZdLosNXOWkC
0LqETlHQSrmazxOMgUdthIaLeEJ2yzQtwXj+UhlT8y6ouQ8sZ6cQFY6rNEJx
Tc+viDB1v44m2jgYuPqRT65R4dODpg4qOtsuDsanOCVDxKPzCCKikNCVodhv
9agGSRzzUJBmucy8s5c4+YgZT4J8ZZjAVzKEnBfXWiRqOxhjFp7YDw0H8Q6U
oiXrF/e6YIrDMPfLjJLVuLWShO6//EWGo/Iq/Xb0l79I3nIVeHa0+f/9P/+X
Br7UkR7ISKMvUIL6BriHu4I9cOrqeriHBthDFJ1yBjtliIvir7ZWNFzE9+/H
jx88SHp790d7vcPR8HEvPng87h0mh6P7hwePHw/jycDGE0TeytLrzSx5vslH
+XxI66EhGChh36mzlsT7rk2doeNvl66nS0rJIJRtMvj13fu9X99d7b+av6/O
3/3y2/nF7u6v+2f3X344/f31h79Vr56/3/319/e7579f3f91/mz+t+evyuHB
L1cv578c/vph72b4/P0Sc0APfsoGfVwzskMCxZei66Q+mXjMDhVttjTa4Y0T
HB46j6Noi4lbpTZZFpgPnSg4tWgP0t1zoZbbghUCtys1I9IboSookXWRK5Br
XbLCWC+22iw+56AiOOGvsiSNh7nPJ4DCYXzCF3qhKWMHvq9IL7nYxf523dOJ
BP9jwr4mVdG1TH4+Kx9WioUVW4EUkwOAlZL46tPuwGLD1ulj5yZeTf4fauoH
TO+4C0V7FhIRcqzfRzyG6vkXJi9XX7D7htdKLVL8qZbVM8I4IrwWxI0xc2uM
T6IMVjNeOdbtLbeG9tPxbeakDIwYK5wH0KbvwzbCVJtmZb2VKxmVzIbPWIVY
fJa2A6ORoCdiysMljQgGZtrGBGRZXCZVaSP5BRvyeHwdw2AuMdmAM04cmKON
Fh5p8CNCLNTVYwUkVNDXrmE8FZuLO8mXPkSkg6W0XcOyPEsLseVhmjavfiNc
MhqCrHR1Sza/HylO8Y4E+jvN6dLBg90iOK0JFOTzbmh6mOmXjKr2OBXq08vQ
9wJpODSE1D8TVxXCjxRiPQa9ESOJknqUpo0bazbUxbx3Bmdk3/qE1k3VLEws
tyb+JoSy4gKY9YEWaNLLklmgxqNUwSTFAuYcbcLoBOEQzNbOUMiaommZWCob
4WGRG2FFtQRpxipIs57Lbmd5ewgL14Ph9iaYlLctBkl/HjX/NJkW/ZOR4HVO
TJdnnZGpm64y0zYD5Jkqcw+TDO58kfZTUQ28zk2wiEjOXhoFoQ7A3iFbqXeC
It1omudkXTR+SJEKtCI7xxxtPSe0FYIuuJbIaEwIIMwfwyYAbFwBedHlA/de
RrFREibfILMRY226I13bUbUao9LSEuRokygRMBRlu6E4Q1R5480GoUMV1hpi
hBw1MbbDIJcFmatqj9eCmG99Ye4HCxOCazdQNg0rm6n116s4EIAQkn289KZ4
QzHabnYGZ0feFeujCCcei4hOb+Ma+oQj15W5TK8bIXAXmq6N2d7k+1hi+keh
/ss0iNi0tv0pykWVsIcF5cJwHGZcDFNQfgsXx9lDTB+bwklOy7QAWkFRHlg9
4VO3Zj8wKaQVO37I+EyeH0VJWheZ3swnEGJSgSOvM37lw4gNIpo2Zf1zCp+E
wSB/tsnmCIGcgOCwMqgrXca3UlypZMFmd4vzxCjHaGFaFrjFik5rQZLxYOG7
ZDgoknmue0gKG+j097DsA723uocBlCDNCOAxmV1Ldyhb8uiQCrk369oDTa6x
omTzDknBiyf7oDDvU/V0iUMM48hRQAHZCW4UhGxNspRRt9WXxLeV83RyFYGS
A9HmjZjqkjC1l6zxT2Z5PrZRvZ7sREeiZjGoI0iQcoFXI1oW44LWgJMdL5d4
+pALG9hakIPnyASFDkqr4ZI5so50G96mW2IM3zbrrchowUBbChzAlE823yCS
8xMT2FnQqECnrSJquxvZz9rbxnQfa34t6276lsHhlU+hxxYsq4aNyCaamLSX
65Rj5y3in8MLlJjApgXcMoXvmiFtEnbso88frwfUisnHN1qWHn6hDkrj4thZ
6yf+u1QeIu1Q5NuYsMVBxmFbqFCo1zX0iXmGDDI+ODiB3MWDw/dvLNY6fZ9T
SADnt0sk+l9CBhP4zKjhelLPmp+9kw3fK/T3UdSEgGj5GYE1Wr72gCvYI5qh
9EORpmlpnW31Oz33UvKBajRAkj2jdZHZ8S65iDc8ZDVW9CDSYxhpwUcfjcpk
VcrGvsXYYuNpMnqM6ZPwcixSHGEBcFzlghMfELu9tXviLsgPW9AJgDVMCPBh
tc0r1ZISwVI3yKhIOhHs4orM3mTvskbw0TRBZSUnvHnaTQ73wAiNDA+bexS4
bn2Mpd4R7cktqNKKOYKuP2qGLfEsslq2ADN1AAI+4IONPaErBHHOLLyQm8+O
7wWRKXUFfEthXY3k3Co0FHAKJDkycq9JnswEtt87iEa8e3SmC3KKTJKKxN40
TKNfi7THEkypfkKNoYZ3QW0F5ilo5r+8eeXVCtBZnr0xvuTXl6i3Zjgvjj4f
jZYEjA98jBAUanBArQy+dS0Y1Uk2+V4Taf4emYtNI5VP30dPj0DS5ZyNe68F
BeGeJATxwgC3Fq955aFxyqrxKJsDIQlLTN0c5qGJbOR4+o3h55mYaIdqqeRJ
W5iqoVCEED+jPXINOdUe1rriGjop2/HjIB2GBDGxqPARBSZHkvjgPyZ/H2d/
hf5Ig6vY0EuRKbGk0tYMedt97nP/iExFLeuhvmFG3GohFFLVDLGX56fvnLia
O/sZD6sJj8l9Hxyx1Y80QIT6FuhVduOHwSOia/BPGCFiwggSwUFlbYLtaimi
81/mlFyB3d2Xbg+p2ywHSWSCFYzYaBXY55AHwmlBrRxfp6FINBl6lPDzBV31
oleVSbWUeh1FgqebM0v3ewekOnnpWygSmzqGLwFQkigZGm9kwPd5jyguJpy1
QM8SkowViPQa0zS5ZxQOw8y+pQ296UWJaDldQgpWFFsrYEQNTskihw1LYb8y
SJLDHE5znG1HPTR6W/+SCmaCOaKPxxWZkVMHFBq0Gi/SX+RS3WJr6baEUCvR
6p0bthHZe9qz/0aDzl7/sL/bGdRGPn5D4Wm1HhBgWRiMvRw0TLZl3GFH683M
cEpoAE7OsT5gbwDHwImA34xBdhkWMfNdF+FDfpD2js9XhGVwUeVoPqpNVUsF
YQwXiAtxUcQr7s0GJMKlawtpVfSYdFd3SwO1WM9j7WYIgFmc9SPyf+/6yYGS
cGjrR+GUYoplTebWTItDhDZIIJbcymHi4UvUcqkcGftBY7SGwTo7+KVg3q76
B/rSEMZ6BpOMiy4FUtmQCoTebOEyOEY6fdY+TtK2h+BIzQQ9wu5hVwM9+miZ
I7uaGyGp7JyVFYl9iAzbpVdLx7MDyIHuIPla5YD2viPdC2QW5fl8PDt+dYzI
AeR04Jl82voujbO4Nwq+3SYcZtmjYA5khm/g4HLYypH4CDSW/tXrd24tYahs
IELlFK0aYbOyxQvM8SNuyk1yzgEpOj5JU6CpbjH1gefZ32i5zcWBT3TeF9Jy
COkRHCe0D3QG5I2O5kBc8+UclOMZqH/K5mGDBh2C0IXnKON7Vd+edXvCEhdv
iN0MBrr8xg2xfOAjj/zTQNFFpeLfFq+k8ji3Ju4RpxfSkWYt0sfpLZUJ0cK1
kD8bmYn8maRrr9M62+p5eigGN8lwHF8PuhS5LVAJ5ABWHLqI1Q0fi8kNO3Vb
UvP5RdG//vUvQTbnf/8IPkVRh7vuHEWdnYJgc3bgI7LqnU63/dmehNXAO/+I
OssixZfjYZnPllXSif7Z9lq8WODj634LmxS3F3z42BnO4uwKa22lE3Rrdj61
tF/FsyuaALRU7pQg3idj+Dvd6QRP/jNYkH8c0R7+0MFY384/jT0sA7uwAz18
niErcaFR90pm95ShHUu1VH35iCu9IaT5iljv2BNabZE18p247eeTx0sCxDAo
y+lgG31uCIxOGbc+S+UgtiA9H9/XvIobqu3ojaJcTjjNgK6fga75gEdh+/Z2
GMcQbpCMyn70Rydxtu0jbFH78PFn9oLCw8q916WRKl/0GHqkjofNGYNxpRc1
/vPdtp59X+5ZxZX3QAtqSUPSjCgKrPFSAkQ15ZkAecEySoKo2KtEyimFGelM
dJl83nOs68V3RAv/kBHoSjoXpUy/VO/kmb35cVwDOIkDu9vSyA2hgTErVge9
6IMDd2aJew86nO8Cp3CgR4wCU2czFSxQLhQndyAAqj+KQ70TfxaE6d2YpiAd
eS50tgDQ0L01BMprX7uueCVQi1vJMe0y6if+a1tW25kGGcNyHkP7spxBp3/+
xnk9NTZO+N1A3ueL3K+odcPmAn/F0dsggRYS6SKB7lHQmxpb8UokcA2KX8Mr
6kie7kUD4rGaQmB7IJPJQnwduPOkxtrDaFnrsMhvSjUdg+7uxMeY8EpBEB2j
Aw3NJkOpzDFZzmYU8WJbkbR0jhhmIXBZUPoWv993w+WboHW8mOk2DgaMKWv4
uO1IdGpN33t/1l3r0REMQ3xfmStNeMV7UVjMUB5YiWhJ61iXV7CERfRiHg3Q
lXeEtKJbzzYVOyWfbEtqn4LkRwvrpSSb6Y54lqURtKAyzG1YQNQb52b6/iOH
yxH9xcWL2tnCYHoPLtbegk4Us8hMbwMZ2Kb76AlxRxFDE7uu/K+yOnTRYwIf
2gQEQ7FOuUghrDdYzFvN86JhIZ6Wh7vjxl14ah3+87FrqZnRsqwQntYKaF66
khs5hzHqofWuY3tPW4YY2XB6b9k8zUfaWCNrqxPEk7Tp9pK3vk7W9rX3YOIt
+kdYHsd/2lkp1EaTlrWE6uOyeWvgBeajt6wJJzJalwwr8cxgIoym20DmZaQa
iuMgHFbOFbLjpIvI1ys047hHoXIolFoocT4koHRIlBovBsMlqyuYPNYFK3ti
XfEMTqDvi6I+6EiyQW8+iTvE5wL8Db19axmenO8Sm3rJGhBTz58da6wvZ6Uy
fBOvIZux00LqBfd1DOFk7zSMIHCfcygogJMSusmymrkaBT27OxLF6EluH9RH
UgMaESjQBjJ/RZWOSgnMPRWz1kBboshPfbkVzw8XcJpnZP0e5kvksooAF9sc
a6IrGukXRR/ktaJkHpCVvm6VDNefeny4v/dpfaI+uqecAuCcZHqVmEhFMsls
5ROFLT+8v/fwk0ZrhPWcfru5KvuU5eiZ07hAp0104rQmd3fgTCWas2WitnQI
B7FYHdfpAKjHhi5r9OBsyr5inDYKHbEw2Dxfm8/H2Q5Sx86FaXiubL+FxWUR
jxUYHMdMh5GLjQMHQ61avf8aG7+tIatIxLoMmc9u7rbrUsseGsjqlU6VnAQ6
kzxLQn6MTk9rHm5BD2N279azhr5yDKqJJAp1HSixP886f7srMzKRxerenLjE
+olVuQcuE9YKyMg2rQ67SIoWy42XFO/ZQiVKm3BzMSJFUshwSQd8K5VWXxLY
ee9uK7D8G7CsdfeafUCNRhybbusYtE9Ybja0NTedxxaEhREdXPwPAnpQhvqb
M8NVkco732g60OW8fp3NQUzpQQc9y76a15deXnLq1DWoF1WziVYKQQeCBvyY
yIX8wEuO35Q2fqhIfqPM/b7fy13uoxvrWg9yiDdy/gDLzt1WE/ah63WAAotq
bxfezTDOJTyZr/hBy1AHLmEguIMxlw2tyJaIm9EpuiJ0nGRNKCg5vBXlemBt
EaPndcdFYsI8P0sWlINSH6En86D4wLT38SmuBqKNgDiIK9ObEAxWpPE/uj8a
e0CbQqBwfpohbCiFgOO9FEvxDRY4zt6YyMsfx6asN5/aUoS8b26OtoMZJjXo
0k9oZaicAgUg6oKMA6RBLrLjZZSpyqcQLpuZG+NucCtVwF1aimJ4miOiSJC9
iYITbpIhI4aQkoNT5MtOMZvDhC86AnDSgBnYRBAs466nhl0oxNnJ88ZV3/GH
wtWH22zYFhryZAFHPsrDXNgW0CPOR8u1ezG3JHlMbaTB+/9RS1IQdPyzCVtY
mXNRzztw7JMv/cV0ISbfUYqhIvOknO7wknTIl+QkItUPs9otaFkuQ06qRaGn
YKmDTV2ZSDZAcmd+T+9f5fnPy4P0Op8Wj+P/Fi7yD20VUX2qCITXOkFozmcg
KkcSDEy6eV2J8sTouwjRVa3ckTyO+G2lrJ8nqsTRgKPsLpJRkVQD5lrEJuFu
7s0w7RaIH54oeMzILDYTVZvS4VEWlcWI1lJWeLtt9kLvSPMUKLlG8kbQh2yJ
yEla7cO/xei4CB5WhzV56jG9dDJ9B+0oJgAEYB5iMVmFj5YWRFKim5RuWZFy
KBwNHW5BwZycWCegXJIkiszeXa19Y8FtnvimR1LBMDdVF8iYN56GsV4fYHax
lExc36oVV2azIkKrhlrpWo1EqdvmjA9UvAgIgiLM6N7VAZiPNpAHriwq5bxI
e7Y40LYNEuEYkmNGfOHmjLnwXBfr1DGUuJJLYPIcVe7Kp5o1Y+SFufu43gVW
ASxrhxkxmL+6mOUrwZQag/jqMMyyEZMEOWTJ62MKTMCRX+ECQBEXrcUUuHLs
sj8whc5BVa2bM12VEvo351ifyAVqYxIml9Bgv6XfuKe4httYM7P8Jbrg/Hcv
XDMDuR9emmnB8TRbJn6ihkObloXoimTpmhEJTbDC7GDWk1RXivZhiNQNqAwl
HRAgeDfQb1s9PpniIHcnSi33BFxtAUVcgRUyxHqnKSHVzBsEBY9aGWCZCUcK
qgW2L4eJ7rIg39feDjcU7+KGBjBQ8RMmRXNnybUxuLK5mnarXN7kulUliq4S
X5uoODH+STKKNU7141pMQzRw+vCj+FtPRtaTENltYqofNXifLziS9+BtfRa+
7cU9ugq3awUh1iMWmjsiFgofnyQya0EvJECa20AdmcVdCJMIAtDhZqsRioR/
XCdepE5on7Td9M4QaM7YIuec/d/5kfHKO5H/r8f7xz/RU+zq6mHQgPcUuYN0
LGiX3ypHsJsY8cNlUuFo1pz+/j+Ulbss9CJIb2ckeF3jFE1EHe2FLub7B7uf
Iv5BRSoMGPRfmyXZZTW1r2mt8DL9PZHg8nAtfEGbQ7RUG5QamqhVP4MNmmbk
ggYJvEgI2EbyU/U+BSKEybJKY99lR/Mv3t1r/M0kwKD6dmqUq58HwLtLJx2N
TIPIlakXzPLBCX3PiGZeCr0AYw7CZfUbGKaKexzA6GrSlS5X1+iEyeAdxZco
hlB5JCdYpJQNBsyCPPjAWD3nNR6J2ExjdITNLpEupnMXWU5+jM4L/PVYfy3d
bX7Cm84RBx1jXSHk/+idnD0/vXjXO375/NP37Y4HtWii3Nvbv/9gQCuvE5Yd
UN+lZKqK5MjHC6sPhQtiLOWgE/jyhw5FSPKOKzDFfv8Am7FSJabRvs9mKSMO
GneZwKlPZl6CHEJgcs4FdMtZFbE1GUksrcTHeq0gyxM1u0huCgTB8PeEA81x
sANH9goQqbg0rjUqq0s2TCIPQcXBK/wSD3VP6IGCeo9DbuR7TWLK2SOW6beu
9ZyMt3hiwKoti04Jw6uInr535jOaPNEfp8/jhjnQsr7Wj9H2HCEi7oKi1myg
xxA9zFGm541jErw4ey70N0jG+/fv7z0e0LY/2j3Y/4S5uG9Pn74+Pz99dXJ6
wr78Zu/O+Y4jeHF+/LTH5UMH03k8wnsKKbdrwxBdHYZ4TSorm/ORZoaJ0ZAD
kWfCzdaLmKukhpU0pEJHScoiX00+S6vdT/yT5aciQXiWQlYc52nFAXNMdnO0
8yKypnc5RQIERpgIrbehAv5YhusOJaM5rRmCWK4tm2Y2hf6KHIuCUKZhVM7J
hhiwk55A0UTlVXID6zMDSSYbJVaHWnJ9JhBEOXaGmiLXtqzKPQxJ0NtEoyPg
+FicyhNh0MLJeWS2+JmFNYkdk7TWMJNQFoRg/KB5Te5KRtjV6xLlQjwds0R+
iBF6qiR4VOO9PE9L/l1jjypeLgkwsIyAcha4fFNt7xvVWz3mIiG27vD7W4ca
rQuJ9q5otbsyLLJmLw9ql/qAY6eJAkBRg6MK+oC25jFWYi8gy9aGLQeEmBbH
R2jzbNEKI37dhYC7hHq/N6muGKUq9AmoMKLr6ZuFlX8aKd/KLWV57YgGV01a
OsFc+DQ7qsamDmYYaMsKx5MIY7Yp4QqgaVC7hbNOKVQEQ80DdcE21pbqRRC2
qBPbFIfh+QiYyfiT4GgP8vtJLCPw7y+rHiVDo3nCw1ekNLjrcLOQD9pENsYE
tPdZSHLBvfDdJuOvQTwuqakSKw5IS4yRjyDcUjEhKJjAHoiwTkJLHTmxVf1/
tDoCiV8hUibptQF4vf7dsKlZWFGMTAEFywI5Bl7V1pWmrSYlwWxeuDUYQLWs
WFPzvuChXeP9YTalDkMHBlYbYABRtN5DI0YOU4t1WD/njc4pY62SX+maslcj
JjNgXlmkiWUI4DCSEnrjHl/58tYfWcfhshXDxNZXcx6ujavnAemy/+crVhIZ
hVcnqeRTbTaLTiI6oKCSBeUl2TCA6cZGfY/kYfP3om/q6+XPu2bX2kR/xtFf
+/wwcZ+wjTaTy3U+W8LxRxjnfmuqtWfBsOyPQ1E56MjLa0Bki3rmkc1K6QZJ
DhppsGYhTLgQDSwva1+Fu0Tx3wlnUpLoDfWLNmk/T0xiBWySzYDHpPH+jeOh
Z6kRztBe77XeXTlgv7uRJfRAIhKsZKkiJ4cxAI3EM2EWwaC7/Jxx49aGneWf
3qrPqxaLUQ5MmF7mcPDpdxy+C1r0YhUpN4rKqfl77cIxuVKzTqqZFfQmXs3y
ONDRvyEpCNGc1thxJaG2vOUgoO/XKPE6RGZOimNUVUncCIi6Dp9gyrUHFvVp
Bl5T/bQsl3OL0GwDXTSvvX7PRbZYp921vs0eac7NcNXau/FJwQGtsUYzFPOq
BJnLZbCmIKCDpNCOTH2g/dCLOFTQcCtFYIvSmRTkpYBz8m+eTdp2EBR5XGb1
KxKcoIR1uNq9eGtZTldfPCVKf63X1Z+n3cURYgCmTba3RgCC4EUvrWQVFzGL
LYQkzs8ZizescQ7SPb3LCD6/M9ZJS9QW61Asc/rwyKVXUCPyLAewV1QXBTXO
QC9FC0OIXg5Hsnf25lOYcO2SavlkIFqR9VVLYEqtlC8502GylCrI6pjm/d7E
KG9gMjszfvFBy52Ah059o6rxWBhmgiLEBB5ZcgVZY4wajTWUi6awvjr2UhGI
feAy7tzfG48Odsfj0eHDg/HhQfxgd28veZwMh/GDUfzw4W4TV7XjL0aQXgsN
v/KKEtgJbSHzoH0n3X47HIGy8X71pep4kQEiKlPIWrDUGlrt//51XWolGNKu
MdkD5d+LoEQKvb8FC/7r8flLG226bRPEa0XkoYF+sDC612fjcOwx1qhk20SV
h3o+Z166OcjVb6kGWT3OIyAMqXqJEYLuRRQhkkIlNVdS0dY10bgujrUJC9qS
Uf5yGRdApALWeImuWFtZiDOQgxV9ONp9dLi//6A3fhzv9YCCHvSGE/g4Ska7
o8cH+6Nkd89fHSDmIP19wwlCPEx4vKydknBDHxzcfzR8uPdo93A8iR/Fw90H
j0eT3fvJeG+4m4z341uoWOKd7jQewWbwD7DEubUP7f7+w+H4/vD++MGjx8n+
6GA/Th4/PBw92N9/PJk8fHS/fWj2ENBKnTBM/qvaYZOvg0ogvLK14xAM6CSd
p9BE0AsvwFd0s24p1nf7Uz7NopM86TR4KQpjfn8iCLKa4oBcOcEZz7RkX3fb
gnIThlPBkBkPMGZgmfYg2Fi6FVgya6BNAuGhx790Rj/m6O2aiaR4MbOHZxhn
zpYxbSSCAoFVXjq/SEKUk2ORjysBqjRrk1xaE8o1zeVrJMfv/WizLl+C5y8v
PnldM7vsuEpYHU9v0dLY4fQlPbBcYO0Ua4H1qzUZdly0a1NkYyOngy+2tyhF
xiJNePq0IoWtUXLq2hLNVCutpH1QmtBGKYZ0VXGayoW1wlejKY+krt2wwK97
ssF4BntD7fdG8mvPl8Q4DcmeHL8T//CEKWRbLLbzJehhWjg8i36/v21lSv99
Inx9cY3D3pfpMeoLJs9vDCIgkama8RkTIEQeLdEmPp+lWaKXnJgYTdSAUfXy
o966c+ABYYS71AZ/4aMtfINa5bFKUCRSQdHaIikUpAuhYu8nKmOgFEjWVL6L
sZYCoXHiYgHtvH/3lJ9lIMX3WfolShb5aMp7Inj8GvZuFSVXH5mPoNWyaAhc
UF4utdIpeEveqEps4zM9n2wJk/WyxkyKlGNLMlYqZlEB4Ykwk9YiFGHhDIyq
sUA5xAhAzZ1MsPIQiAuMaISO1AlvPfkSKIuF10rhG0PpSaACJFMTuiCbq+jm
pJdqTTtJtiubJgplL22oF7BsEs9vYShcwjwNEceN4jUZiDkLvW/fEG0zd7og
JdjfsEakhmdNX0FIg7Xt1xNayW29iFMieL4lGrmVNrknHrtAQPGi1c6JXcvN
B8blSxoHFGMruwhal1JJD7kLW+b5T+2EUlisVaDcZOf4Q/cVxdUKwJq9n11i
TKnGqS474DlpdFokmlWe07WE9CNpmExYR1a/QAS3i0SSyNj2xK4xIWBfGNJ+
MVqHZO9lFXyv6IOcS87NMDiGzcjpu473/892bD2iXmPCA/xjI4M5WD+YAV3o
YkWTnk301X2v63lPnCHUtU1c4nYohOEGo0OxdLPkzNTDrHHLsdLHEnGxePk4
miNljGoaQ3KDfNgCuNm0KK2cwl6asCw9opDiMEwk1SoEUXksU6VDCD/9BuxI
0co0RgRIDsf6gYtzEP2RdzpwjNolJAQ4Vbsc4XpMxHOxBfujmLtkUEsqb79o
qSb6ycLVdYNEXe84qzNIFtQrLzpM7CrBiHJxFOdCB22L2gjqFP52k6LQ1QAG
Ity4oEPjZVAz4RGiwcLha9g6t8J5ctK4UTJxyW/MgThpPbCQ0rVyvdffNc18
f5IaHOKJxfyQUGgHx+KqdIT0+YErnB0pnnhQ76qcKnZ1fMO8CpqAkez9dxMF
iUAaj0VQbHahyGKv55F8vTwJ/00fWsy+2ffhgvXE4sLYptnNTKZwvi+tJMRk
2I7DVVosCELzmijwMCFJJEgol2RfsGxN7k9rDGqIP0BqMeFK0hGA/fx4j9+5
R/l7DYyPHgri+PtApB0N1VMoMKtGFL7Iq3IMtTHhStI4MM//Z4PAMY1KYEAU
7AGjDOPqy9f0SW+G8lMgMvFSZLkvXrpTazUcagazKZZpRQ0RyBLlMqyyEcp+
PSmCQRlVaIBn2A3X6ljRNCgpQ/w38RBYG9As2b8p8poz7l1umMxNdAKu2UXN
0NhYCl0uyBlCeRc2nsSfZagdwPB4JCSAStwzHcNWjGEJf3Nj0fpjlzojxNRM
i3GPCxwoLiWZ6JPRUozKoaTaihBgJdRlkfpqFxKgQGt43LmGuiTDxOdssCFj
D3Gcr0OQQQmQFOr3789OaGk4wJHkHb4wCY6JvRo2oJHORQOi1eVNWaNh6cqf
2qEKMhQ1gkmvzj0jgEldcbxwCARa9/HGYcQp9IQLeWlKlKcMOtgpdvnOedS4
EJqXRbSUUzErDGsmRxrTEMa8sXchpbSQnDiqQ7RxJZgYww5pX1BbYk7/YXpL
C7vcHEui5f5gGLXN9b0z9V0Wz76HobJmIXU7hf6CrDAgBEIwwuJ5eOldSWww
TGiWX5YM3RA59ztOJC4Y2mflBmxZ8cJhpreyYmoNac9/sMaBadLJWlYajwcK
DYQferYCTFl6dDEGoqPLlbRF1BstZ8Sw2sS2wV7yriT/810uFQOpaoY96b5V
lXUpHKc3Fk5D2PCWt05BvMfGhQqetGyb14j3ZbKcTdBhKvdRCwmsWcvWeIXA
l+hdGNy4TUDEXwUQM3QhsiIpMW0MaqzBVHSM2qoP3CujfwSezn86nJK+rEQa
2ibTVt+jF8PDB/8WD2sj9MSG1Qiqj81wa6kFdMfIGWnHIhb0g+XH63A+iWvr
jlrmcp5oOfjzZ8c9D0yKxbj1i+J2zbpsmgvjMG4GNcwdj0wx6SKwLml49+9W
Y3IRJDlHmPKtRSqvhQwBwiGRm1IhUlGXoQErpSjRIqznJkmQ3MMNSfAul6FI
uz0SlEguuU6TG51FzeVV5/tsRVbTVVy3rgTwzD5dUguBaEB3ri3Vd+t9JrKH
XLYURj1bcQx1m3m08nuQOiJ8BdauNJ5W60VG9huOfY5JfRwnHl+hW02eklWg
CgG3XHBWDGvecQK/1y65vwDtuk26o/Y0f09nHYLt4WpbbD+F1HBx90yVCLG2
hjsKLN8a+Tm/AzhfHZoPy5aVWAB0pa1RBO5axD5ppgW37454fR5a39pp3IrZ
982IfQ6yrgWvrxnMoVvDgSOx0IWvqeioxynDArdGndURUy10/SpAuPQI8E+V
WfzMDqYuFdcaBIb8x4oPYb6GniyYEz7FMg5WrbP72pCDWHBRqUeaw8vYa2+N
CERklYy5RqqIL+ve/DqhR+4oqhLKpEBckyuV32jQjsa1EbBAHM0TvD/Tci5q
b09gXmvb9m8XoRpNMZdVY5GD6onaBQFJPVDvYwgkqLzMooqpR0WMRF05AzUE
AtIWrWXONSloDTCVS6bLZ75XNRVgk9jilJKibbvn0CfpmZsp+Q3EBxYPEhl+
wh79JDtlIP6QWb6iF72vmTeHyZsbVvGrNaQQVtyz8ShtkxJ0SWhZ/imU4bPV
ZbHoBkxb6EYqplihONWESesXa8EDrMu6zr5sIX+kTpGUS+ItyJr5CcovRBIn
CGIbKsn1T4gRk8on8vcV2yRjBkENnAA8/c8iK1uQyo9W2DimByj/Wvwv/Mr2
tib++YlmIdr+MLFWAhm1RBIGsey3apjwez0uBPea6tf1bOkK36ZfE9a6vsqc
UlWlQmR0kM8n8SiRIoMUk1FYW3IqRXSb4zmD+/2Fjxmj9Ce1wz3MWdJGYa2R
u5Jf/Pzs/JT+3GbOpCGAZY0N8AGcUv2KRZHOKQSchpzZ2tQ3wAGVKYQoqaWN
BC1BtaVweBw43IcFQmmQCDiL0hHGm/nRCsrAxTg4lgCcOUjlZKMKdm7I0ZAF
sDLJMaNiVCQWizDDRi76RtKZGY7Zuo21Kq+jggGtFocwcClfOlNs49PVElMU
LotmPngWXNIlHx08+hTunGu45frgLcxccIXbtNLbtXJbSYx4qYMD5TQuT09j
NCoiam//MSaDcGuDrNVzegCHJjyI/ZPOuigsSPQRok2igKnCSL4/o6yvfFkp
CYxBfCLRpWuTjEEkRB+LuGNTbxu4hnXF1VY53Zk5skftFOOclh7FssOh9FfE
olhzGIZqVJkjMQFoJtqbUq6P2651iiB6sf//7Q+w+lKrT6DpD+iylR2lNlic
SXlXN0DuBUR4vbHTQWmSbxdUD6j90WKjmVsUzv/TZu53FGYwc9DeNTBphOvG
/4wWdok8Rsw7hawfb4ofUefuY10xggPf0WXYQe114ONb21cGyhNDna6uEJFM
noQ4kci4lc9RuJa32bKgmg0nJbuAigIo8bo/EgvisUY8g+uLdqkZyXHUbr6S
/Gp0pQgBlwIGtAFab7iyMP6cdkYbx31SG9Cfze5RuFmvQibDivxeE7g8YymG
vL+VKDhja5OuG44+6SN9h7XeuPxmZj9bO+TGVtls+a2JnNKTZHKa42h/d899
Ddy1WpYcCX/XoWCgk4HtwTUD2mePB6dYxGWiAqpfiM0vLCTpouaWdFEvWdTC
z4gk49ezcrW9BpZsvbhdrQ/w1iPpsRe/G0pRfiOMgPZzsirb2nAIzFta7kPr
VzJErUvNxhrnvuXWyxejz6Bq5LaygKQZwYbS7dKH7Trc3V2zXQSy6eW03yQE
q8GhSRi6kEqSMjaycc/5ZEjKDJKtb+VFn01sS7QLE+VGD25vVKBG7FkjTsHe
DqOFAY6j+2vHJ3kdjmn4SVTivje6hl7iCzXdjXwxUi7b8I6hLw3+6jWIpm0c
1Pr5BSG3PE0sJplTlfZlVgNgOhGpB+eOEbZxMWZ20uSDeIXxE9RBmOg18ZAu
jDsXII+PcYOYv+BrYWVcAqRgYtiUQKtJYXhzAmVjyJ01W/F9r1ex1J31A8pp
t21AkpoP/JTx24a29nfcGCJqeCLL7dBcuWJK573TQGFIrUNtG6j2o05Nrbzd
NkpcvuyeD5DBJe6+eoC14ZlowwCbpecVg5cqOLc/QodR8XUbz3Govzymg2/E
H/NTBLLQhSeNRXRHxuVAdKU8b6P9UKwIwOisvtXS4b3SClnDPL/alqG3lbFe
ZopRo94HzmmSUCOUCLb4JKEU53NlYOcaDdo02NhEjr8wbklapVjSAksrY8TS
TcAYhL0IU3XXJVa0pBBh+sLDj9QRrRmPCCPhHoRgE2eeF2nNFS5bKyymZXON
hwS70hJNmpJV7x5LTwP7wylxURdeKMbHIz0fryhEz/5Cs3BKH8FRu5bnEQcQ
EVAKLweCMNoixChJgiQdcEMJrJ4Dp1VEFE5GxxRnjB4jW1rbsOl8LjTwUaAT
LTwJzUCsi9jHeOxdIXCP5YjDSpnjDpKKqt0TTdiKsfHMNDP9SUqakpuKa9ha
mcorxmGa6f48boxhkRw1d31hs1hQGbd1lVSGkKzZ+FDPOOdWcPmt4Y7QwOjO
51f6RkA4W8blPIYtNsAAo0RxEcVM70OVNMyQfwpQCZynPwOqBJppSJ93girh
zOy15Tt8SEbdlOa26/J6SDyCUTOO6jg8H/2+HLIYGkUJNEcORM8DvelT0QFZ
GZqv1XoQrgmF61FQBrZIyEeCjmVP77PGa2oHOIW5Fb4SI4QZvVLBKy1sLYiW
oajUkmEcZkeazbmRrnwAj28c5uJZA8qfkcLsp/u5ShfcmY0iL7zQmz8tz5j7
8EZ7rJmvtvps4RlhW0awt39weP/Bw0ePd+PhaJxMcF7r4bLJRb+DlhJMSwYt
Eq6qmghknW5NvoHuiDZCNnVCju5EyIoPUDXRcyh8Dq85hJc7plKbrhaZQ9f1
BhdCJFgOaZijb7xLrbkg4K/G+VGQhGol3xypEWOBUVoEKYdPW7/WQ4PBxkG1
g4zQjFQAtUNDiShvC2DqorZT0FG3guqAC94TutpmsX9z5RO92zYOgAN3PYnJ
FX5niPpWvelO8FlB3Z1/x9X0/1kMrXZm669PkEwZ9dhfVydWE9UkTBeBSikU
EzbU3Lt4cfz29PPx06enb96dntzzvzw5ffry7BV/eeeMxqBTW9T7j4DFbIYr
gOGO8gWyMHsmQkKvL4S1O8rlw6J3IIrHw3zp1wRpT2P9t/QcPOAVhLR5K37N
RmtzwvDocaJBV3kLOI0LjPftLSYIBIjDVySWkCIBUK8IPQUzzr8yNqgQpeKo
LT4nGc04G8d6ERt2StdKSfVgiIsUV77AX7qGqPgRHGKUA8ju55WGdPHhbty2
cTdsb3x23EYUPn5Wk6cUh6KBWhG2Qv6nWQKyK4wApBIiERwkXtaI+krOn8b6
kv6lg5XhEWhnfXBR6+CkIJ4+bekSzykBAIvpgCIWuwwMqhUCVhyWl4w9525t
RjyQImctizuN/PicIuwyWtOlWdOlMUGpSG6sdgXBojRuGVcP2jQYKui67Xcv
lejxDKqsfhbpZZopVnINYmhtUTChxLB4nGkZfRmU18JxMsIUjOVe5WBWrEfJ
1PmD2FOxaVFTg9gLArZsjfJfJ36QKmCjjjB5r2sanINuxfx2K4ZiJ1pbutbp
84w2QleUST8WSyIGA5DVFPHq9xqObAbGqjCZycooMgOy0zlhSOQedlCS7GPj
kKmxsR5bG5rA1Zgqiaa4rRSIq6ktOrqIkUd4UNlr+B88hh6+jVLMXweRRCAM
AsSFj7uf+jY+qq9pbHS3aii8OiypQAHFZUkiY9/ss6fZgWOp19Hl11WNNUwz
Km5jZ+ve/of+hc6Zf/qF9zxoOJc36SdeRlLXb5QUGa8r2fb8TEtke2Uyj/Gg
lRJtRpxcMuNdGDMTfgD5pRmWXhB1vd4XKXu6aEuBbqu7qJKFV5NXfsGVPNBg
4FqnfT80bWBlJ1nDZHwEbwKpwiakNrpvTYx/216wUMxhj2JYaAvdWi8H/+//
+b94zvWAsW5QCqpqm1qQk8GNcOQXK2DrqkR1nWFtqVUMveAxaaM9zyjaur1y
XWSL1zmsj815KCSTi+1UBHNuR2nEhffajcOzi+QQ7W0EdeV2GsiuzaSQcG/x
Dq/Q5eSOmZYFs9W5Ss5W5BRYlcsDlNaAeGVliIIlAbeaWiwSQudGMt5fQ4ya
Q7LuDiDumpXLQkfbBPNk9RutmWTFDN2QtC7nz47JKguDgqlrQ16qSpA2OUuu
5cJNEfmDgqY57lRgrNHqdNhvP5cUxhg6dFEoCs4mtpWiQ5hOmC2k9f7t2fqz
KArq29dvnp29OrEHUepgYDsMSrI+cbLLGYA3gjSTatQJBmBktsqubwoa/Ec6
/uugLXNy7QixhcYgq/yIawShmUhvIAxb+WvjOtqhLmkc3pbUIy3aEkLDIaGP
wXDg6eBYvMiCg8g8wULcE4F4/uImezH2kORD1LxZpaRDiky2RhrqPTbBFdbG
2vg67Zv7fT+BP22/N/WuCVZfBDyhLCNU7V6vl6pdHYXNy+9Njpta7AYJ5m3r
diNhcjyOt+teF389+nEzFQwcMkAs00ptmgGXBOq6Ep5P4jIdUZRRFwf+2SEG
fCZOy/gSJoqiNogJkPETyejCSWrQHrP4WKOBbZRDcETG7M6MFNm0ZeXJryhr
uc2LqftUX0/fg2/VSInM6JsH/YZkslYqYSDSFqmEF8EXTOpCSe0YeVlKmtfB
O2st26CzYpAkWbrqAK3EDNmUZHNiOIiXCmk70Zhib7WEYT5ptuRyoeTqlC/o
jGsajeeX11oCd02p4fucygJ6I8FQNcyDaVsaKkfB501WHJsRB2GMu74sbbyj
F4FtRQddCF0YjsmT1K2Wi5sI7LNkdmEk6ecqXwwasiw2wiHRsnms/Cxy4E/N
KFxP8G4wLFz3QMyUi2vjFY6tbLrFb7/AaUtvu8Nvvb6FRtff4G0rQdUcKAyx
jYE3IYdTl0QXRJNLSExaeYfFgx7miuN3yMlIKy8X4w+kYowTvM8Kx3jC5Aon
GvvnnJKhfZ+tsPTWQ24NzNwUVxBRRlvL1aBWwnSNwNQjQAVtbzEy2/iz7Oln
Lb77GQfBW3r7c35ZMPZLazKr5HzDfrJgllUFiLltwSxBXqzujGBNU/gD5zgm
td232RhIMi64L5cgORqswM+VbBpy+99qIkIPLLpWPGQVFlJw3bHSD2/I9wKG
0KTyWtaLX33pSgGAHLxDbaphJXOFxdF5FAmPwAvXF3QfcWPZBA0072pwxGia
Jtd66NkIlvfK5RCj1kXdePHu/CXTh+DOMwcdoG5TpEPcSGaukpBOUc74YsAR
+eq2GaNEZV3LYbuOxWKdvBCdQ7PArcXJAxz2cprtZdWsWMFhPCWFTHiI1brc
sikWOdLV5aNcZcNOoXYcjpdssuZTdAN8sRWsXisF6KbZ6sTQELRRWuCNuwru
+L87VW7jz9HlO2BPpWVHGGjj1Spmsah0+iJZ3MheXpZLMow0dX3JeSDy5JQK
vBjXHFCpT2jjsbwQGF5io4FDr5+ey2l2KZy4lTO2flj+9hrlzGi/v2v+Evt6
xWe0FfyFEzA4ZJTU51LT4KANrsOENI6an5/WxN5LRUTCGHVXSd7uGxJTw8bb
N69ylsP81ykqScqSk0xznc+usdKTRaYgR170js64xoqjdVaZRxawgU3KuQYx
2XvC1IxETcNQ4+YiiDb11WocqBTTY8O9Zm11fauZkNFh/7C/r4UOGXeDbwId
iGKVOStZNPjSu7m5wRKs896ymCHE3RhLseEXXDp3mt9kWpXD9Snep2iLCILM
6kMQBK+sq96FNrB+WZoJh3Fy1c5lwTYdNFNtHxnzH0yNVGUAqeYHqj7e+auh
G7e+TrjGO3v9PfMCziBioNUiLgyW4TwC5gzCxe59UKGuo/3d/fvR3uHR7i78
X/T8/J3xnc5HfnLhTuuaGC4JdwQc6BhrV/6QXz2Y/+3gw3/+/vPoUTZ8WO78
VO2vft1b/vxwvJ89+s+/PxxPZwd/2y33vlz9YDt7SYVRj6K93T0Xd8Tl0tDT
W6aXez9suUqwYbXXRlXWDsLddLa/hzeliN4Pew8Pdh/t3d/f3f2eA5HT8Q8d
m7bvrdF38NteBx+KZ5c/dKRcIn1h64K5IR7x0I6G5/vlL/vxYX7+aPFhdPi3
R8Xj/xw+Gv7tYbx//WLv6u3jL+92Vz8dLE8Pb17fn/3yYPifeyM0huwXrw7+
fnJYvb0/ffoD7Dfxh8+000328d8Mh5p+hrG3DR1+h6d+mK8+821NL5n/2HE0
9FcOEA+qYbrYMNHE1oWcGeuVUqOzHc7A6bxrCnX44DOClYiXFAdiYL0Z1pfH
OVYXjwQjhDuBcfsVQaX6HPk3gzWyqFEKm4u3hBPO6sEgzEU2hZVQ+iYxebK2
My+WK9s5ro2XLKFQjRiCpMzGOs4HzR0deBdC10gUvcvzYKlo3A+5sWYOnalz
SIp7l4Ifq1IFMQ2xiywqDdxsq9siLhK+xWjz4ZxEr3+WSi10p/XIDpniaD2Q
YONFm5CizktOfAnI+V//+pf5B5B5xxfnO0dR59HkYHyAxQsmWMbgcHj4sPc4
OUh6j+PJg9Hu+DAePxp2MA6gQ6/QicD3ntAlz7+IHPw5xRYPdnfNP7m/I+GU
GEvT+adUGA71iZSCtxm2UgUHoB2iYdCMaR0yKQiPW+wKq1ynDBPTCNMKJH4W
jm16Cic8txWv8cyxtdReT13zspkNpRSSRObgmzlknsGTNVl94FbHFhAVFH8+
OjxEOHYJQWM7zGyyraG7j6Rzb8V4b1G6Jf2UWiEwhdqFXr+VXNbSgit0epF2
tX2ZUqg/6WZdiX9EaV/AY2oPSy3KzJAO62W924HN4yxDUBY6PqdFkRf2+JRt
50eMaeurtHHilWWRh0B0NohOPCw+grYfipU50TBKaCjEnS2b0NMCdI2/IrHL
cD7LCDvRGgJ/g9gtmLPrNczuwkGtCVBb7FfMvAddY78hXoSPLDOXWaXPMabY
MrPJTJ/dXTWQJbYZSe8I3ZNOHouZHOJDGjM6WNlHX4o9I0f/QeJZ2CW8k4OH
ud4W/20zsNrOHqVyWFMfZtpeY7XgMbLmOSoSxu+lWdlJ3XKuppN4e7M863H/
xu+/YXDZ3LvO0dQcaoEdlooPjS18stQ7lNgDji5or0y12YcLP9d85q1u4oY+
+g3Yc13dquY0NZ5CEtKVCYS6sSSw2CCBr5+rZ8tuzsQH8b9DrbKuzV9eX4tQ
a31J+JJd0K61+68djUBbu8wi6+zDLnVY7OZvXwvM1t+0EF+DGrjJR+yXAbGF
QAJ/cbjdfLKt1NdSxdOlptYqeTLUX+zZOdFJXJJP9RtXwcsGi+668xwq0FZx
lFrRsXqnV6pWNrRBeGo2g6Fxnh+bsjAYBzrtoTyZLyvY90TDhy74/NjoI8uO
jtD7xPruscV0bWble5O8a8XX+p5z8rHt7YntrVWu91AiEf+onc4EPbsVOopj
6lXFx9af3OPwkPYtVbjJLqzDHerQRuwu3sz8YBhPNFjLRZ/wIEKrPlDmMXqO
wiVTtkOgO1qdO4ka8ETtASbM7mzVNTsE2h48PHh27rD/RsNH/uT9v2tJ2C5a
pbksiqIzuiKXVFx7DQlQqtMTDhZz5k/HODVGQSJivSiVRoBK6/YwIyebWyt3
WR/J4nGrkBCYLb/0GISAcWpUUI/WGeHQkqQINu8b+FG/uR/8Yutxo314QjGX
MoZ8Ek1zUCcV8gBNf9kwX2YSVcjnjTyubBrGQaMy8EQuseM2Imgp44nNHDM4
jktiDPgoEegT9wi2ftudwEq0mr75LjguV3NQvGEuUZEjILUIXcFS60FoY0jr
WQytH4e2NsVCNkHz4rkRC7IW+uTWMEsl82NL5vSc3Ki1OGEsLuvteFcWrbkH
myZxzEUJ4HZce/CekBCicQfrrnOJI2plfFgA0js01EwouCJBIE2xyMf2iLKd
CjGSSAoDcKnc0TTPxTbPjfa0nAQS9bLyXu67tKcTRLmmPKfjaNAJs0Q6gzBy
XaMpObxen37/iv4LTzfCmJEerrHKF0dU2Vc046TWAQeGe57tlrLAMVfxJlW8
SK7zKx8+JjYuDjGZTBJNaoaJ5xTnXDCqt9oLaAm2LcvlhGgU3VotFm7R3iNM
OD5nLijDupaBSbUCEZqnSKmihvrgzKDz9pRX4OmL41fPTz+/OX17fnZxcfb6
VWeQBXlkChShJnckakyYMTwvdSuFG4QEyoUKC9pyQrwa5QsJyuFEQNQ7jX4u
/TKj/RooxhvBbeJNaOuQM58Jcw5axKwFXJUaLDc3I2hieT7WouI2AZ8c6Ywg
Kh4U0iUrDX1n5E+xT3UwS+j04t1nWcqOSEx2ad+/Onldp1xGbOMMEbMs1zui
kYpg38plPE7aSDCokkumk8DtaJ3utUXklVX4Mi0zVNva6JatNXfa2mjN1oYn
65s32cgm17HX777J1pskm1yv2LDeQ4Y6pDZS8/fiinD5kFk6AibO1mKXsBUW
6EC6aslNM2Rkik7HaYV344Lj2RAWC338OMR8xAjLIy5W28HH/wf861i/psGv
suV8iNdWKf4CDVaw+YW4ODavhgObkz77Ej9guYyfqcAyxjaoTdxVhqypTmKy
1CDUltKcYYtBSXdnOsXLDC9bXjNch0cP9u5/QtcaDqNcTibplyNzBEswN+Yp
X3Y2sKPAX85O3z0DjhgULtYZb5Xb+IiuV7QVrMc2vEYAP/gMAizHGYZ4Azfn
tCEP1wGfeLVzTEv108VTLhzJCYiSvNhcIilyv2GJai3ddYke379/QEtECYOY
VCErJJnrGO4g2Jzv0UWEv8KlPMfr9oJKLP7ChxZ/wBpJ5n0Gd7n/Lc1Vlvtp
y3K/tZXEgVBOXA1qfOLYonnV81m91Ggxg4eGWNSwMUO0Iw91oq0LyobsWm17
+4jew5akCCvG3Nt0axaSufgU1cr9UV3QHQm0tC5pKX1NOT6IrsHvYs1XFcm1
JiMNSTLNYEhP8hxT77o2SxLG9EEslyIkCQdILXgNy25NKBFx/fTRNktQjkco
q5UCUdZhVuMtg9clw9O7LhiHp0SE07Scap0GzIvw6OwUeET0C6XYerUHKTFD
hCxX2Br6n8XDZLamewK9RfRvWit60sZK8nRlp3FPcRh6CrvRx09b3/1WSvlV
qp1Y9nQw2/3aIXvjsoX+jJPmmvvq4/ZG0wL0yKVJNUHH7pE7e+i4sM+Rix6e
4+X76J765D30lAH68bmnBBH2f/fwwpVPxYu9syp1hGMtmCtn9ypZCcpJMUwr
xEAzfvpBqY6vjoDjduDPm7y46mz7BTUl2RtedcsjbEHy3K3LFt9Yx3z7txCZ
yzlbT2ne4fhTSA3bM43D9mfSmoQOGNMgon8DqchKiduS8AaAJYVsvsGUaJcw
43/NPiWwZj0mC4waDPdq3WZduAfh+KCERYAwHFuCSQDud6LkzqbF7JgtXU1a
y21y+lCUNsF0kMhl96oL8+EwpoP+Q8ySio5nM6PQykITFjSM42BKhmzQ4u7B
VuHRg63qglIbBbvFBgbcFYWfaGwbybTUk9GexGsJ3Pi//xD8q33c9A+rL0b/
5S04fbSUseORRdTy77/+lN5TxpqTJi1Gj0daFPCMpCePkiWIe/+vXvCv9nHT
P35dlK+NvQ9XAegMv/Hn9C6RgMx6XO9c9Zh/ZDC2SpM6vJX/I70j6SCLfI0o
2k8xWg2jjqaodWlEjfLJ6DnCI8npSy3kiY/8KVEC9iQKoFJaYYR2x/VhqI8t
2Mptr6dON6rFskhDfqFaCRryYgwR/3rEWVKEJk44VBVJjTadrus3x9ganG7h
imnbQacCJsGDhz86oebxVuTUDil1j/b2H2g0FhwTitSCnk/RSGNjggklacVK
cuwtHO238fQVDcgnqkMsfsKjRTHS+qcD7VuuWQJ7M9YwOV5yxGDCmmvKsGDU
GV+Izcrx3m24aX/p+ttUd173p1MnqMZm8/pqhLl9H0gdA6KpkQBbRCUJNrLk
Lq2546fFd1zafmw+bggtgyuJAeJH8mvPN01sSwVUngvGwnkNE7mIlNAyBJga
o8L7wQgrsvx9VHSkO8IEkGCtW8NzeENkCwJnK01GliTpTbkroqe33RVr2HXj
KSMXg7f58LntevCuj7V3xNf1ilhl3p2DPq6U6qF7P/wXU5M1hwh7lWB/71X+
ZmeEtypf7q2vfuuALVv1K85/7Rlzperrx4t5qbnT8Tp11KpnK3b4CzYPmkqa
ECeR4rceYGtn4UYi6vwfp20qvioHTNu3zf/R44socS7Hm3NQOm9Bqe8QQ0ej
ZEfSSzrsikaVxTnRFYDax5j3jIbk64LB26kyuyidxuNHwnHIUtSYJUW3wmg0
87EjxjAKOFhSrRNMHKJhGhmmfXa725yW/tZtmQrhrrZaQBuTIScZJpN75Zdc
GUjDiiKDGIUcOlY3EH/EOxQbzKxV3BCR8La+YSN1KVTCuymWa0+Ds6T/7+OF
3nlew4qs6mZ5Xc4s6E5c7/b2pRSWY1jkwl3P30LagC/cX+uex/zBr2nfy9C9
vX2sjuHrB7e1D8/bxumLje1/1Xr6nJgJ75vkHe/VPyTstHJjdjzQmVnHgemR
9dKFO1zfxIG99jvGCVDRH+LA4c6pGaV0gTlkve0Q1+jQ+nQ87lF+z9K7CeTd
UlCOuS0fu85700rwjnWgdN4RazI873fEhURc8brSt/jAyuKq9s5fXnz6NzGg
NSzBEeAdmMyaNnzFsf0gss6z/olbemkeNuXy33be9O0/dOQ+oFNADCqB7mL4
PHWbJ5wtMWuEMNRG+ezSSHxzaIhzYI9hNyTHQMe5STmhEt0Z4r4NKjNijk4y
mxz5WscwpdguKloBFzkWQR7lc/g2VnSG4F7uBtTOEExk7ZvnhV8osspJQLA7
ztH9Eg6LcURM5RLS1hz4H9K3NLrInwkqhzd5IwoCgxGo8KTCyzkXZrAZKI1Q
AAuGl1G6E8pUeHMjqYmbWeFW6WFJMTF1PzoilSYTLFymazD+vranaWlR9zD3
CRbHyOJghmmaZQnXTwUuckoSo2aEMF0GKhWSpCNHpUZHibBGs+U80xKhM3TR
rGo3Rgi71qazd00L3aPpdI3uoWU+LR12iVyaRg8alW/yYNuLsKxxaMEwX0Fg
tZMhwrlPMX6t64SW2cbwEt1rdCffceqjwBQ4FNIXFmPGk9VtbAXL7Jq+Z68I
r3fxlRDqBVwRZK/i8mxdLryhfT0FuR6WLc7w9I2XI5kgxyAiYTtW08V54JZq
8QRmOqG5mReHC8HppJp9OJLomxf5TUKI0KnmoVOQBAj5K0xDI5VawmO6nr5I
Z48u8GFiHPuhcY1g7+O0phNw5NkIQ7XGQJw4lyq8cdH8tSyX5CyVBCxCs34a
z06Of0GC/On8+A0vIP0AwiIG6n6NcODvkU8ieUapWBSKWkmWtBynnrfFdvYU
a8YWTl/vAc3KcdjvIw4JK3MXKTjPx/YwaGP3uOC1b5NkOcWJKU3aqjujkOvE
q5qYcjah+hzI5C2AEC/Uivw3NtQo3JbSLi+XRzWOXQ4Z2lOKh2BE5hhrgNgE
OQ4SWrnE/P9Lhqs/ZMUKJCxntPHVmK81af0h+1YgrbGG1xVNrEu7tM7YVWsn
kOm+pp2a0eybx1Nr59vG86essy+fNnHGv1ZGbUEq9+VUYw11f8AObjwf+jrd
sA7t7tvAyVUbhs8qNDS9G+Lmd5xuSOWZP26sYGBFutj+Hgp123Jbdi4wnrBj
qwlIEmyQchgMkYSF0iuK0DVNhMOOA3O3TZcW6p1B/rCB53Z9QW3gaDDvecay
x/ToikxwKAC5CNt41vk32p1aaPcWr6qwjgYlesef1h7/y4XuvoKVfft4wmjv
0BTEJPVfUhhqszoaBnX/0XY0nvzb26lFCLe24xPP+nZcRHEUtY/na9ppBH1/
VTt/yr4za8VQiWWRcsxTEAALXPcdxtcRRyg42rhEERRLEIh+jt5RKdioSDNk
2mrGHJ/nmC6OdRmB7aBr/CZRjCvhClKwHN116sInWQXHoOA9gvBTk7GptpnU
NXIh1Q6RfLYivRMbYvh+o8VCAqw9Pw8V+SB1jIV5NbDIDy2QuOshCO82Ql8X
yR+OqQ+HFu0zSGSfbfo9Mr2yJPR8UnXzgixi/jIYGr0odFqMrRuEVUhBcW3R
vs09Ehg/RWyTvkFhLt4cUC/JxCnP0TSsY9BrVHiKQ4g0/NI8Wxb0wFwTkk8o
5iGHi/BCqjtrpam1A4uNlgpwErQWVwadDFVWpDVOq69W2pC+VOWu4BVaVkra
fnJ2LFGREHwnqYbHRkyvdmpCq8zXqnEIlrasKsU2CWg/yBcV31VPX5+fn746
AZ4kIJ8S1y3VkYAyO/JOx1UkQFwGE4QU+Kupbij5tMqXUsxZ4IeHYgPi0AQz
xIOT2QJe+LgELWVw29I605WrhrSoDOuf4T6QIUAwUzgwQ1R+l9yJ8tA3lITi
cAU/wU9x8EoWLSTLyZkJZC2Y+wX3ItFh2AYietJOCtNgmwJmUWHuF1VLoDwn
L1HThlPUrFKgdukXXmEHrZWWVpK2gLdugJkmKGmC6CEoDh4c2/FsFg1qeB4D
hwWnyB4ESiIQFKTGMU4iZtgF0EJhcS9OLowtwKTfXqI1guEsT1LFZcFZZMi2
o1l+eYkYIZjUwlV8xHZQEaanwpqgHGYao1tmJV4UaD6ZIkII5pYTDN0Cs6SQ
fbDuLrvMhxZrZrLdD6u2MmoPloGnOqtqNUoLTN4iANGoSC+nBPAJIhAor7gR
lIpOppWh1onHgNWucKnC5nyQym6TpoB6MTlsnozT5bxrHyryVTzDRHVLP3ge
u7YaXoLARFVCmQcpQS4aCiyKMwIDQgQ4HcpYesScLhhQqdeZVteG92dAIMi8
eTW6mpfTZd890D7PBG0r2Ri4vqDbuxQHSXsSwY8v5Vf843US/EAFlnonZ89B
2ukdv3z+ibJagBt9fBEDqz2eXSIPnc6ZQRJRMQiZlJ76tGUUlPDm5qaPhZmo
3hwnrhBH2KEzz3hhvSm02otnl61f9r9Mq/lsGyVxHtfF2fPaoMKSdW54dx5H
g/es+ZrH8p39jOOTvniAwKT39/Yef4qeFPE4QwvbRR9G+DPwR0J6tHiIsKfw
LAkDZ6IRmbdeVYKXcMpmMAEdP2LrIXTLFVyYGty6A4LcDg5op5iMsNvtTtec
xwWoSXuPHz+U8Rw8fvQAxoOO+KLsvUzgTL7rd3mnyL73ts8wEXFJJp9u9LJv
Oh/fZykheFo7yZnDnd96//Zs+yh6jqWT01F0sQIi/WK+YrA4Jhhs9FOcLbG0
9v7u7n0e7eGDw0efop/yMpmUJVI3rR9ygSdwDe096NJ/D/YlHRf+fnAYnUB/
5hTh8GBCX7No2BuO4zUIG8OkMDCOB7Jsh4/3YCAny7JMMG0DVyU67yu1naLB
sCQBB3f0QzJEN4QeZiOI9iI0SIAvfLxlaHZY0PcObuZPS7ibYVC6l4xn9gJu
JxjQST/aIsxyXh+HbhTg6UfP0NaAvME7DRt7x068RYH+9/a1/0cHsCjPgAkD
/3oFVPTzDJcBtukn+PAC2DxiUb7DZToH7haTNhqmbpWCk+kr1AotWt5GQ3aI
MI6QfvYOZIgP7+/dRwLKUHw6h1HhSZwlKx7iRXyVzpdFzKPvfCSwKNw9B7K3
9dOHi+2voCHsEMdyHtM47rtxPAzG4XWG7AC6+Xn7ti2p9fOwpZ9Huwf7tQMD
tJouy+s4xnmeUdenYxJpek+XIBYis05BHzQtPDPaOh2fXBx/1chwCLXdUIIl
Qwhc7FWFQ8NleJmkQxjWE2Y6r9BNoSTzfJkiEHbGgrf5UKjc3ZZUacPyhZN+
1YBhVDRgPl7eaB8efvJG2Pl4PB+ml0sU/+CCfb+Am5wMUNdl9DK/kQ88gAgZ
sMGd/YCM/o6EjD16m2oHgjmSKL/iAkzjeZdZj59xuZ49lwb5c/k1NIz9ecN4
bBzUJPDY0dUcs+GOYffeolZQ4FliLQJU8GzV9RhjW+1iHUaVY62qxhpgN9j5
s2RYCP3sH8pCPL5/sPsJLW6zFC8qHGFxk2N1iROi63Vix60zxobXd3r/4FN0
UYH8liVX3O/LfDIBgS13Z1nyVDCjCg823N4BejXQi2ay4PX0dWO7f7Ctm7F/
2CFJ7UwFubqshp6fszdILVhlQA5ZDkwV60F3o+d9vSovp6Ccp7JZNcM05aRd
Smy8ej/uQEDjIp5UvYy6Jqzp1LXTUzMFXWVwKq7wqEDjl5jdAJyJwB2TqneC
jfRlKujE+sq5PLN5omTsLdFaXDe8s/7D1Il/vYxXiLEt9qpvmel8VvZshmqP
zPjlXWcKgvgxAYWnX6Ljo+gc0f57kxhNHnR7a1VuqhM8IRDy9YBwPprQIEEy
GWm9h7Qyzt6uVeEpdaqSqFXyv1sUovNnx0FtLPQoo73G1Epj1NEL0BLSjjsb
IPUZD3CjtJUzXXc1E1puC9N2xfpftRYJRqWVoHXY22xhUpsgDIRfg5xpJo5f
rrME07Y5wRYRgPJlfRAQx2uRsLlGioUdX2/962qsSVs9DYQgstpjLAigkVBC
zfCGejVr4mqNuCQ1vbA6OlmaONuMLYipRVhAnRn4HKqerXANCscOtGGgd3bI
CzHRozXS6MrSYYJPG4w46t2ecU4sr3a5Gh27QqjcLtqEc0LlM2zRXM5vGzfT
QNtgJRrRjoeITYuL8rsgdVyn+DPhAYbWHaloSbOmM8OmQzKcebEMtpDOohDI
WCr4SmRUr6DaxImv17VsN12jxcoH6bC1awIL+RFFhylKfsnlbGWfzMeLUYqk
gmzR8b2SvwSNd9pP8+3I4+M27OTjGVmIsdQy/cGV93z2I3CKCfyMUgAZtByn
e3IUgdBLZql6mXkpYM9GCXroVFyRWJXeL9kpdTNtgDsdPtLW4WAHyGqCJSeV
XkrD2VSS1QzMZqd/g/IUmrGznd9urso+F/+2mPJkVLQhX5jpYAV72K4XcsAo
yYoJwELRYrqvK8zApRh8oPA1XfuAzTjMzlH0kTLt/2HYP9S5qlYITPv65zed
rn43Kq7xu1MBSrffX6Vj/L7ZOyOs2+e+4FN7e3//9fjXn788LSa/XHx++G71
4W8vXl8+nI6u38SL9HxW3JzF8ZvRi/dv8w69+E/430/rEJ9hE3Fv+ThI+QIs
4Ygj2TbmOWUPbKx4rzbOWyH4d+Au3hFUhhr8fhtEuyDwPytAeNh7gCoLylgP
or2Do4OHtyPw4wTtzwq8D70T8P7Ry6vFi9Wz178Mn5y8+TJ6+OvwxcnrD69+
P75+9OjvH5a/TF6+mhy+ez95/D5/hFjztM809A/AF3EX5nGRJj+2jZsRtykV
DfcUiLK/iucz/tpzhcOPD0e7jw739x/0xo/jvd4e4nsPEekblnB39Phgf5Ts
8u53gPoSAjpOyACdZj82iYWf5O/v9Cg1esL1FF7JeI9nQwwNPJV3/Tbv9KQN
Tz+SsHH6Osj8g18w9MUuCMfvHcnRsStH5W2F9jX358idLyxn0Fhf+sVHHsRH
ppN0Ob3Ji99vsmXx+NH44Oa39GZauBec1ZfOcQfjygghAbEzO5/sIfonHKKW
EgHWxkh19Lh4c8Yxqnir+EXFnK7mql4YV/XiR2euJKR8Nll9fcULW/3hiMuI
BDUgjiLldm3U6x1SUy8W4Z2fj2L6pYiXT0fu0RlVp8BlxFrS8vGT4TIT8C3+
Fz42Zgq/3bloBZNErUe/koWrZfERXRtwOc8Xn/gHKWexjtXyQ41yFn5BixoF
IPfki512nyULX9YQbh9tWRvQNmGMUbCnwIjpYnQdNGo8Hmvdk2jLr47SRhLk
HNv2Sz3SxQj6BAVWggbBoDBbA6zBMWDQg226ExUw5PtwJPgb8Lgrci3R89ml
EDFe8cMV1aQY2GXxyk50DasAGE+NeXEaExweE6qMu4mI1/LuOu3VC6OElMe3
iNBdvV7KV1ZLuZXw1pDdHYjuayqofHSHh9cArqgWvqShGahm5QinJdBqAxml
v2WyQ5SmO4BeBwb6t9SIxDpNh4y1jpFpFkzUeVW4zE+k4RAmUxvI96ArJdE3
+JRtJiSGYgdOava+/kKedZZcnHy69Va42javgh0HR7r7Qov1eVP4hpUev9ED
zmqBK+bsgKzrZbngDElUAJZMy2B/KA6Z3b9Omtrro/OCigDI+4yWJYVfLLTd
gOlqYMP26CRHkS3XgOcBQZOfJRVr5pETsFkAjvz6stpRjzv66xoRGCF9X+Yj
jbRcZilWCHGnHIvPrBQgopVRCEgY/V47mVpTuIusrkguY75CkefUmRo2scWF
W4m5bSPgrS7cgI7egBdrXSdE5pNUaB3ewCaBaEZTO/wrbCTIBHGeA9UlsPrw
28Te/W1Mz+6Zbo0FIMIu3UElLZRjx5uDjsuAWJ1QgYVtf9FwE7/v1voo7uzS
CjJAlF5W7q7io4ZFL2KLmirpXsY8s+geEv5KTykEpTcEZjBY786W35uViOGf
TdJibuzbYr/3knq6Ymsoueop9yX3WyyRS2gEgMXQGmM2HUitI5yFUXGNY4Q+
nk3sCNlOJIlRsi2Yle6ri9YwZHO9qLI7ImRzy8yEMOGgZCMYZyzNEkMyNhmQ
OJiMy8Fh1rhfspcDu6RCaQS7cplmzTF5CvrTo2bkFabSU5wFilSwjs3QLCqo
iFEzhKUvIU82QktNpIYkbxRdnDLPvsBJPEKFXY/8mQtDswWgOISJw7RYo+9K
+dM8W83zZSkBL89P32G+ijC9nz5cuFhH6xuUoDCjlISrfOXVfJojRKsDXMkn
E5KT7KXl1aoz8ZiTvnKxGCjdsu0AuO1fbETyUTRwgWmDqAfDnIYIexTHoZAD
M4rgI5Q2E9nl4rlblNnmZgX9SWAad0bOR84dhmYVfw1GPib4jmFiu0Wktkmw
S9Zs5+HuEOKd5M8dEZig1/OymFGvXuXW929fKnbcyuNOXj+827iuR/RLz1YV
KEdTuFOPtAq8vVQQ+lrUrS1auISDs1SA3eZH8clai8QztqS9WDAiC3I1vlFo
s215h8qjynsx1aIZM5RjRCAR8pCajd2TxJup9qewwQGqQYPtdW+gYovhOt0I
jiamjSKudxFfIvnWF3jstOa1tKRQmbRzbpmN2Np8Y5MQtVOXvWRp0HVRBPGs
ho7uVJEWSrP2KmexIp16RgqzbBrBPfCG120H8sI4NAl4xr+9jjz1/5Z2Lc1t
JMn53r+iQz5I8gCgNNLOSrJjIyjqQT04UpCSx16GTBaBJtAi2E2jAVKkNZf9
Ixt78MF/YA8O3xTzv5xfPurRaIAcGYcZEah3ZWVlZmV++Wvve/qhq/DJw4cP
H9yssx9v2Bn1df/xj4P7Pz0a3B/cf/Lo3qN7N+vgge+A/w+TwK/efMH8Dhty
i25Utu/tkZ5ySwr4GxA/DAaDW6sMcTF3J7p5J/gqpyTOTxu2rHpLN9GJnnrQ
O4O+FwyJbjnYDJyFK0tuMH3wzOjYHBho2dO6PjkAEz7Q50/8Qb8LW5dfDFVf
/mIr4EEvk1x3Bx9p0w7aci/JZ27MtgsXIF4lLGfqIJtkEvVaCbK9846IkoSX
rvNJedZw4lCXj+FnIDkEwuxV/I+nwQt0oPGwMmCB8z+GGyekRh5sc8CMTise
UcUcL93mfAwO7iEI7e2gmdc+1NHSvzmRPCVYdQMptwr4cln4nUEqkCy44Jw2
KqvgMvCvY7yBNgfl0awxNxKVrkHeS5mz8OyZypKSoDmSug5CBiJ+vzrAmIkC
2MnRnglSi64GAMVrmuv7FXQARgTmgNlp1JcCRRokKbhi5lMvywRNl5Abgw95
Y6CJikUavX9A4SPmKO++AVM4oQyf0Fd81N1wVjdQCo75oX3Om+hfaoyyaeP1
wUOQ+lQMSKZr6YuDZJOxgz2bWwLqn8xE5yVrUp0XFRK/8fOdug1yVFRG7JJm
diUySchlQ9QeZmerKNo2h43xQ5RvZAznPchcejKbg4FcCD8s4QT+kH3N01kh
ZOhr3v7gu37OsumT/KPEC36NG+n7YdFF8QkhLL5mR6/hR/vHUo/Jj4YxHf2Y
2yybUOzeYPCPK9o4z5c/591DW/ryB1kQ8/mwAfOXusLrptrRnoYr/kOEaAyB
8uCAV/jg4EkUxaWkx4t+MamxCU2egEeDL3Ft2wI0sGnyoA3b5ELlT3rmkjZ4
SLvx4cGoiFMmFCK2vSbBmmBmOego7HfuqpjVvridsq4agaDBhkUdwhO3EbWu
uPB0bSjb9NP0VxfngveHhmNcY76QROnoUc4iLiTZrPyuq83Hr11yKfI1MVKO
kam1rIM/WHYDrAN0nBabCJOgNciYXy5mTRE8xfGQzusn0AUpzL0qmPMEkiHj
eWs+eSilpaTvFa6GMXgescS31vKM9nFYUa4vPcGmGvGR4hS4HSlvYRWp9Z23
YEXfYUKvnoVyXf3qj/8eOEMEUnF0ma2t3MUQu8qtPMN+xjiGH8yuy278sNPr
IQ3bwJV4SVDBllXWyI7nnWij3fQuV8GKoUYLzd1M/awnoJysGA8GtoPg6623
vw1IjAl01UQKBerbLlgLhrof1SUxI6q0go34qenNmuxJwk2SszVQHzm+YFno
0MOk4kZ04DGiozLOiiquFYl3SBbEh5LdD+SCDqYKhHcM2SBpW2GZmhJJIkOu
iliK8P4e1xwcG/91B0fzC4CCjPiVtchX+p0Yc+1Wlu8kw9SNDkl0yxqLjc9I
5x3J80gPSXcfaw5JNLulc6LhiiH6nOj/2C+IUH+0FKvqGyARl5dlWn+1Noa4
otSGepIjm6p9ZHt1LycxmLNLjheRIB4vne2v+ER4bZE/15+Syqojnihu1VVL
0jYc/YYijbdqklJQD8WCqcFtjoGmccp4us5iCfmFiY+YaUJyyHx6tOVj5mKv
ndtNcMxBqBYC09hKO16o8oBEABo22boVl2Dt7ILkI5lFXTIscIcrmgQcdOBe
qnQMsJNIDT7luDG23Jcc6wqIG6ICDYz0c27pwxnf+/pC6meyfPdGAC+c4Q8M
TeJjkbmHCCpWOJullKaqCHO2bHsLwjsUh+bVVb/4MnH0LX2lOrS8v2WRSXqG
QBFoFH4qIXmCxY8ur7r4WGeKtv1P3rJ0VH9p4d73+G1uLvRh7Qagbt79efKI
Fmd9DblFJZtRDLXDMOClmucrceHUVgceWMF/lplNi62ZkI7P+0SMiHleKHUn
UPTdzlI37ZEY91lpCQFW9kgyEHtAjhLu0FVKIkPXlxJ+J2Aez0o3rcddpc7a
y9DZVhKQurLUYDDI25/vWa/Oqr4f9YS+pkboqetfqzrv1Dg7vkv76lQjV9Xq
GESXOhjpw3J/78aY46pMf823Ii6LL+PRfn9fbcFb+urnkbN53u6LpQ4PW2pj
4VpJCszlWh6S8D9/jfoyF8/lXZBaLWL7GhN9k3fV6p43zzZGxWnVWm5J/gzj
7svFcMNay+O+rtZ1+9Vda/3nRrU6bBQ3qHWjps9vPtfrOhe9Uy8Rprtrh/Jd
vfTFAMEPdTeaMKqQXnW5XGNtFR9YkJ6Aa6skCVVuVqV1Mq+p0sXe11S50SKH
ugpc7vl6l46hSkYLra37ZAtDaiFT25cJ/DR/2cbIjr4MQNj2ZYLWHX3ZKtk+
6t3jXK0NeZEBmoZJD6pbICJAVozEBRXeRAWKbgTU8ynOPcaNr6cqk5wcUYIi
dyY2x7P0wFL0atftRmwVIrqgGc2nFyeSKo89Zom5EDAAk1YVwYLr4lHCElaa
UGowZc2S6eHFrKQfEcQxc6IDeAtHkqQjMX6GhUvBK0Ur8teRuLUzWDfL5LIE
HZpPrsllGOmBnTiiIKIDu7gPMn5rca1Upxpp1ErzutJa0HUCu68IHJW0q5Wi
zFKo0noD/Q369i3f8BOb9VmHb9YW54KWtH6dNb/z081a+KcEl27V5GRWe0kK
qeVy/f6fvi6roavEkI7PSq5GEnA580Ncv8irxLk1NRj3hLfA03F46LlhI+eJ
ZLe2xspphiiHNbUjYM87ok/flSnHrpkkFfzOvmPmkadGtdB1KvMufYkgj+TL
uZsn1uy1JyeywHFWjXg3/CKvNCf6RVnV05p7J5BXcn9EVOf9kteZnA2mhi1K
gsPkodiTV634Cbu20EkzX6CQcX2mJebkshKevLgrxvpR9OY7BjRKd72hjd5N
Lo9Xo2C+i83fPgUMn26XOs3qvRIIK7lWdH8Sn+A7cZhor0tn7ZLE7i5dYGzN
vBTEan9p3YFvYE8RV3se37eXF/Ph4G7LwNmxyuLgJwbROJO91DS6Trselmf8
SH0H5u6eoJkmHRrlr9zZ5KaROnN9F9nipNhzPSlaQ3bijhl6AUFVCZDNqACS
+IidS+2qZuBLo+RNrYO2dUN9K57EZNtKRJ6izjNpNFSR/NojBlrCEVC56b2M
gingwpX+3lfb9NHl0lRXvYBINwj40TdC2HXFIHtnWtOu3h2k5VTKTAoq74tL
LvGNKKRZjLuoKrINN9L9diJUIq8ibBCHS0sj8NkjG4sEjIsjjr1+y+tn5cbh
abenidZI4uTXLnBIG1LTYdFbwaNTVhndBfr52CQGrWVD0u9ps/0yuarNjnt2
TckoN+41JRflqP31/2tG69tZYTnrKLfWOyMpx84Jre8YxI2YCcsZmuY7/XQ7
Z3QMM4xyvTDKQ2694nqXDaXf5Xl8Xz/B80UtEmqf8hlF5etr+zGxw9dYtcbR
Z/3YQp3OdsqmWXQaV69Z+pYN9VVih7tmmunCgfNEZpzr6q4WY+zxHNzgdpO+
nf+ut/JwVlnlRBxRdLPJc3q5Qp5oebKF57QVlwGzLj4wq96+7zTK5bmo7Ffq
SOOdYXyp1mlLixvrbry6SL8E57/c66Q8YktQ/SEW07pvDjgZ5uzXKFr/UcGe
5CILGihv+vplAQCoLjF0EAOiy6W0+ywkwmorr/Fj4pLj4+b7V5xVWZ9Rp9Gd
mHFgQ/CnkVQlX3RyAtRr4qF6nJsL7UUhELEA/AV+hbwRwtXogmMNwnvbdX4A
NxDccUggF4QEnJ2OeIkeI84x6gcQI4bf1FkmqCN++c9Lt/TzGqtdW2P+ndYw
mzEfs91XoCv2tYdY410iV2gY1/rNtSqGVes+1C0tRVwCWqLy7g2ldAZCZdmf
0U/Lxh44zU1WMX+kiIhMiBXDU7TOhg7deVkvmkwhQs2Nj3OLxwBHdrqQyoVr
F4aujxaKi8xc0Zy8hdNRJV53FGRg9lUa1xrCCxS0qWvmmNN0oNGikt5Hx4tH
RwaNGbl5cC8E7BPMei/L+fbiCFyjbkqEF/iITJ7FvZ9oYV8hFzpCnEcCCrcb
snLhLKYGvF4w3mkWLKJL/SVkq7Ssk/LdWX22mKprXnGqwEgcKTotzh1HYmhC
hiQndQSrDj67w8vDQX5x1E+UHjM8ZVPzNS2gBdlkeSt7U5r2aBRl29X9DrhZ
ii9Fy3Sq8DMcIGcPB+zaiC+LLwplQ6WgJ/DuijkSopezkAHJeOOf6e2pHfzS
8uv0JGCKgzWZAVJ936EzVOjZUhovfrs3T3pcNsEHABPYE4Msmv1QzE4bVS6E
7HyGa7nT1LleSjNVFG42vVQifmLe2ZPCsiBISKvi4eR5DKtHnCTOydPTynYG
vTtaE6p7KLikJpHTqd8BczIyThGqFNXiNJBUszjyKUB47alvnugo8p8wxwhx
LNFVyvKkd9piWm/xU6slaZdMesYGAEZhV89ZhotonbQ/pCfN5YcbGjAomVoP
Q6YQDgSRsFNx1hcY7iyPQcl9ziHnTyh2jvgwI13ZURHDzGGacWkKKITSMzcO
h1TYNuoEMY7EPYGbf8l8jC0LjAzjUbJ9TizD1R6k00OTh/9snf7JXm3COBrj
VCHVXO5XoMezY1AxcZZW+CFeGHn+MYR2TbskEcxgRXFGqI5BpbhxeSvdFYJf
OIDE8ppRixDsOrMWOM1io+9aEbyTBmGaEzQ1Ilh2skEQekeShSANbgcOlj4V
cXI9YTgMUoIo42rIx/jdNTA/Efc4jBFWEK/nQva2ENzNr1DEjv3cjHvLYlqi
q5K54AvOpoziBpsBYEwD2z+Mws8OLeSDrZNAf2kzUYBS9WMGqvHd6KFGkGMh
D0jGH2T5AguwPH0jyMRypDkesG/GxOhMKcHSGgjq4NCdw2oSxdd7ACwF+fYK
RfDXstawkg0vAsfaLzFidms7LcczIxG5/+nmPgWvAEG4KYeA4Q5oWpziIU1z
i0OwSsU/Vw84DdeioYUANHaPb3utZfzKEm4Zvj5LILkpg5M40y9LXT/wOxwV
BPOZzRlDnWQrHPgjkhRPhGCPSFUjDQIP8O3GfpSLRDfrQCWwg8i7LC59Pz2r
x4tqqDw/ciuM/QPtumhnMrFOozTd+d7etsSpNd5E2UBGA5ZIi0kcyo+QMQ9D
wnNa8yZoSLOICFn4+5LFCEkofezOJfzP5UO81BYz3ysGn5yFWWonTeQREWHY
d8AM2D3d4oAtYLdFlMcROGumSR1ucAPhNIRFgnwJSIJ8BY6GX0WELARMOAhU
ARWOnUGpIcSC54z1HCFGeng66K0cFT0KUg3CyW2US5HXGOVHFWs5JwrJVaRS
lleIxUpcX1M+00ELkXBgKOMME7+MgYw6Qqkjz+EUx0N53BAIqHGcLZIRCFzx
Twx1jgDRIRjDtBiNhbdn2bvFjPa1OMM20ZGu9PgA5qGAwzBGNK69ulHU6Jh9
o+fOxLYMZxBixgVnRK0XU+j4w5phHNuAhSBCxrRmVVysEwtgFl5QO84SltFA
EONA7Ohs4o4KQKROSe8DplwO7Og63zwCmPQuQNuJ3wmWWC/brqdjmvVmBR0f
F/YzRxyX/p7Xv/2tl2+TNjS5dPkmcQVSjS6BdfxmQWT01C2AO0QrPEO85WiR
vy4WPao34oxFz0mHurTGXhJbYzEEv7qqPMm33eXMnRVzai//xU3KXvasPC1J
VSFhr8q3C7CJrcmMeFF9NgGa4FU9ttZeA1d/UvcA3k6TfkMDIGltOClOMBzU
QWbPNxg4dMhdrAj9WRLLngI4uGnK0zp/605dVbkeHZFTWuO3BQl6VS97Tdya
OGwBhonleu1OSOvaqZthOTwp0SdkAZrBO7rupg4N/MuUDupuDRjoqP+94YQm
dNXLf6nrz7Qve0UNtOR6DJ1476xGloqo9NnMfR72svd8j+9dFUS1AHVGzjLS
PMC6evlT2qFReTInmXyMwTPdvSbhBruf/+uCKPaXQqmJsT6m5UkRqONVw//b
nNWAPn9J3QJRz+XPiilNkGQemv23v88q9hMZYY1JZSoueQ3pD9pAzL5klKLt
BZH4y7q6+va3aXFFi3k0cyOaUrZDV82kJAKg9V8A3N19YVvCW+F3b2uAX+Zv
F+OqGH/7L9AEqfFHDBiwUyyqEjS1R/Oa1eBhtBiTgo50j+mR0fBLlcmefuax
0jKXxbe/Tj04RGkxWPChl5wDJhB2sJXs3bkm2bsktQj4W0hlwrmf5eCyAHCE
kJWyOq+n50ExHyEJRX3GATFi2UIeIFv/dOkhYIjceRqNMxkg0vhZ7tXXdM30
PxCXpHXcHP7Hgsj+HJTqThcFTu6xAzeiv8vqqpfRAYBMSUeUNhiHkuiX2OjU
neshzV8UUyCMfvv7BGDpblgWn/Ons6vit/+pSneCs1fTdm45kjzoWL2k7qrc
DvabAvmZkSHAUaO//cVd5FtXiyN0QuRPR7IiOZ7a2AGJ0Oie3d4rpxjt28WJ
a67yZ4v5Cf31vsCWvihIdy9BfhCeaXmQ3Apb/mbqaK6evHZxOGkg1Xgxpa6f
n7v8ZTEbF/hjG3itl0R89Ygh/WkEpLwRRyGGRlPBfm0XlxA3gF+5DZGjPm9O
Lu3vWVViwEgCXFaO5nd6hhWajReYLOirlxkXezOtcYQDUVf1dBqfW89ldqg1
MJWmqcox8YEpMmNRi28d7OUYDVHwpCbqelvMahrMewc0rxOqCJpnJlLynu24
ExJPqpMaw6AB7riqXuAIzunfxAEa8MY/TwpG7KbT2f/zxNGubc0uG6Sxwz4Q
ZyKVYrJwvezfajCKHaLJMqzVzrf/pRKziJv5b3Zdc0rD3llUtqe//YV43VVB
HPeiAQd87Wj5aPgX1NCbcq7fPq9mbPh7/+2/Z8QQNkkiXtDhflU35bFwtWMq
tYncP3K66buZA7kRJRTULbGHWY+voWnN3JTKzZ3y/Gy3xrXFmzYlnckt6Jrg
DohwaLjEBQqSR6ojEInsxhA8tyR9wvEAsw8ltbs3L0ousDV4Nsg/lBduJqP6
LIP6iFEwe/lQn9JhvirOaoh4Altet2xZjDHEvIEvZcY9Iml35LELPFs5ugwI
PyQqShgxq0gLMWPRga7oWCIDZp8DU/a39h7sPN/bfvj83d7Wp/1h8wDow5+s
dn7rlb4LW3iLG5fTYkOBsfDIrCmqkS9two58JJE58GB+aVCRZeoVZrAl9HUL
0Ayw1gOUi5oDZ0agpSEjM2L8p/0IEvlTLzyy23wMKSF7voDg7TgnQ13dbnAA
y6uagWXvQV5mGAd96a7qc439ATq8ows7X3AE2EvOaLWJBFe88FU9yPcf/fTg
wR8e0NoA7LPp2xINaAX3f35bFfNP+9UU/0seOfZ/fvnqHomKxOJfUONapk+N
FJ8ke1V2THyBdoMOk9c8DPjBT2eLNEABML3dZPs/Q+V9KbFmGL/ZJqj1cfmp
PR1N0OVsOtnPmM79e/fvPf7x8eN7fkakAPNsmB6wN5wsgbumHfu0X5BUMhpG
NKHitmwmOw70JZoMUnUfgVdEgSXjuDER+Fx8PVVYepbYXJUjTcbEG4n+XwTk
mzWbnqebrpPmPcxae0iTvv/o0f0/PvaT1knxLu5xnBhMXB+I/9D+w3JCtDd3
rT3ln2U76cc+BmSb6fyVn+/rQkkhWd3MH60A0qrfPMRQBsViI0uofXU5LQWo
wkmmtBdKI8kWf0f/3chisltRBr9lTEChAP0lI2oRfTQo/oEK0RY4lNVJb5Sj
DTkxWUxfN6voaTMzokvHjC/7IKn+UIgzGeRSlWu6EorIeJ/TfhojiMGcdnwj
8xu5thj/hwiy6rPGp/vjCWVtXT26zQaKEnPu9xnNLfs/ngwjG1nFAQA=

-->

</rfc>