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.43 (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-07" 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="September" day="01"/>

    <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 keys (JWK Set [RFC7517]) used for
HTTP Message 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 keys the Receiving Server will use for HTTP Message
Signatures (if any), published as a JWK Set at the URL given by the
<spanx style="verb">jwksUri</spanx> field</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'.
For a navigation index of discovery fields, capabilities, and related
informative aids, see <xref target="appendix-e-navigation-index">Appendix E: Navigation
Index</xref>.</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.5.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 the public keys
for signature verification, in the format specified by [RFC7517],
at the URL given by the <spanx style="verb">jwksUri</spanx> field.</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.
Informative: The string <spanx style="verb">must-exchange-token</spanx> also appears in
<spanx style="verb">protocol.*.requirements[]</spanx> on outbound shares.  The binding between
receiver <spanx style="verb">criteria[]</spanx> and sender <spanx style="verb">requirements[]</spanx> is defined in
<xref target="share-creation-notification">Share Creation Notification</xref>.</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: jwksUri (string) - URL of a JWK Set document [RFC7517]
containing the public keys this OCM Server uses for HTTP Message
Signatures.  The URL MUST use HTTPS and is discovered from this field.
It MAY refer to a different host, not necessarily to the same OCM
Server; it is not a fixed path in the OCM API.  Implementations that
advertise the <spanx style="verb">"http-sig"</spanx> capability MUST provide this URL as well.
As with the Discovery Process, implementations MAY fallback to HTTP
instead of HTTPS in testing setups.
Example: <spanx style="verb">"https://cloud.example.org/ocm/jwks"</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 distributed as follows:
an OCM Server that advertises the <spanx style="verb">http-sig</spanx> capability MUST
publish its public keys as a JWK Set [RFC7517] at the URL
advertised in the <spanx style="verb">jwksUri</spanx> field of its
<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 the <xref target="notifications">Request_Share
Notification</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 parameters MUST include <spanx style="verb">created</spanx> and <spanx style="verb">keyid</spanx>.
Freshness is anchored on <spanx style="verb">created</spanx> (see Verification Requirements);
<spanx style="verb">created</spanx> bounds how long a captured signature stays acceptable, but
does not by itself detect replay within that window (see Section
7.2.2 of [RFC9421]).  The <spanx style="verb">keyid</spanx> value MUST be equal to the
<spanx style="verb">kid</spanx> value of the corresponding key in the signer's JWK Set (see
<xref target="keys-and-algorithms">Keys and Algorithms</xref>).</t>

<t>The <spanx style="verb">Date</spanx> header is deliberately not covered by the signature:
intermediaries sometimes rewrite it (see Section 6.6.1 of [RFC9110]),
which would make signatures fragile, and the <spanx style="verb">created</spanx> signature
parameter already conveys the message's creation time (see
Section 7.2.4 of [RFC9421]).</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 algorithm is determined by the signing key material;
see <xref target="keys-and-algorithms">Keys and Algorithms</xref>.</t>

</section>
<section anchor="keys-and-algorithms"><name>Keys and Algorithms</name>

<t>Each key published in the signer's JWK Set MUST include the <spanx style="verb">kid</spanx>
and <spanx style="verb">alg</spanx> parameters [RFC7517].  The JWK <spanx style="verb">alg</spanx> value MUST identify
an asymmetric signature algorithm registered in the IANA "JSON Web
Signature and Encryption Algorithms" registry [RFC7518], and SHOULD
be a fully-specified algorithm [RFC9864]; <spanx style="verb">Ed25519</spanx> ([RFC8032],
[RFC9864]) is RECOMMENDED.</t>

<t>The signature algorithm is derived from the key material rather
than declared by the message: signers and verifiers MUST determine
the algorithm from the <spanx style="verb">alg</spanx> parameter of the JWK identified by the
<spanx style="verb">keyid</spanx> signature parameter, and apply it to the signature base as
specified in Section 3.3.7 of [RFC9421].</t>

<t>This way, implementations are neither restricted to the algorithms
listed in the IANA "HTTP Signature Algorithms" registry
(Section 6.2 of [RFC9421]), nor is an update to this document
needed as new algorithms, for example post-quantum ones, are
registered for JOSE: as noted in that section, an application is
free to use any algorithm provided the signer and verifier can
agree on it in a secure and deterministic fashion, and the JWK
<spanx style="verb">alg</spanx> parameter provides that agreement.</t>

<t>The JWS algorithm <spanx style="verb">none</spanx> and symmetric MAC algorithms, such as
<spanx style="verb">HS256</spanx>, MUST NOT be used: the former provides no protection, while
the latter would require the verifier to have prior access to a
shared secret.</t>

<t>The <spanx style="verb">alg</spanx> signature parameter is OPTIONAL: the algorithm is always
determined by the JWK, as described above.  Note that this
parameter takes its values from a different registry than the JWK
<spanx style="verb">alg</spanx> value.  If the parameter is present, the algorithm it names
in the IANA "HTTP Signature Algorithms" registry [IANA-SIG-ALG]
MUST denote the same algorithm as the JWK <spanx style="verb">alg</spanx> value, for
example, <spanx style="verb">ed25519</spanx> for a JWK with <spanx style="verb">alg</spanx> <spanx style="verb">Ed25519</spanx>, and verifiers
MUST reject the signature otherwise
(see Section 7 of [RFC9421] on algorithm confusion and substitution
attacks).  When the JWK algorithm has no counterpart in that
registry, the <spanx style="verb">alg</spanx> signature parameter MUST be omitted.</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> or
<spanx style="verb">keyid</spanx> parameters, 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 reject a signature if the signer's JWK Set contains
no key whose <spanx style="verb">kid</spanx> equals the <spanx style="verb">keyid</spanx> parameter, if the JWK
identified by <spanx style="verb">keyid</spanx> does not carry an acceptable <spanx style="verb">alg</spanx> value (see
<xref target="keys-and-algorithms">Keys and Algorithms</xref>), or if an <spanx style="verb">alg</spanx>
signature parameter is present and does not correspond to the
algorithm derived from that JWK.</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>

<t>After successful signature verification, the verifier SHOULD confirm
that the payload is consistent with the signer, i.e. that the
actions implied by the payload were initiated on behalf of the
origin of the request.</t>

</section>
<section anchor="signing-direction-index"><name>Signing Direction Index</name>

<t>This subsection is informative.  HTTP Message Signatures apply only
when the peer advertises the <spanx style="verb">http-sig</spanx> capability; a
<spanx style="verb">must-use-http-sig</spanx> criterion makes signing mandatory for inbound
traffic.  When signing is in play, the signer and verifier roles are:</t>

<t><list style="symbols">
  <t><strong>Share Creation Notification</strong> (<spanx style="verb">POST /shares</spanx>) - the Sending
Server signs; the Receiving Server verifies.  See
<xref target="share-creation-notification">Share Creation Notification</xref>,
<xref target="decision-to-discard">Decision to Discard</xref>, and <xref target="http-message-signatures">HTTP Message
Signatures</xref>.</t>
  <t><strong>Token Request</strong> (<spanx style="verb">POST {tokenEndPoint}</spanx>) - the Receiving Server
signs; the Sending Server verifies.  See <xref target="token-request">Token
Request</xref>, <xref target="token-response">Token Response</xref>, and
<xref target="http-message-signatures">HTTP Message Signatures</xref>.</t>
  <t><strong>Invite Acceptance</strong> (<spanx style="verb">POST /invite-accepted</spanx>) - the Invite Receiver
signs; the Invite Sender verifies.  See <xref target="invite-flow">Invite Flow</xref>
and <xref target="http-message-signatures">HTTP Message Signatures</xref>.</t>
  <t><strong>Share Acceptance Notification</strong> (<spanx style="verb">POST /notifications</spanx>) - the
Receiving Server signs; the Sending Server verifies.  See
<xref target="notifications"></xref> and
<xref target="http-message-signatures">HTTP Message Signatures</xref>.</t>
  <t><strong>Sender-initiated Notification</strong> (<spanx style="verb">POST /notifications</spanx>) - the
Sending Server SHOULD sign; the Receiving Server verifies.  See
<xref target="notifications"></xref> and
<xref target="http-message-signatures">HTTP Message Signatures</xref>.</t>
</list></t>

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

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

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

<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>OPTIONAL encryption (object)
Optional JSON object with encryption information for the share.  If
omitted, it is assumed that the resource is not encrypted.  For
encrypted resources, the actual key material is to be exchanged out
of band, and this object MUST include:
  <list style="symbols">
      <t>REQUIRED resourceId (string) - a unique identifier of the
underlying resource.</t>
      <t>REQUIRED scheme (string) - an identifier of the encryption scheme
used to encrypt the resource, such as "ocm-pgp".  Registered values
are listed in the "OCM Encryption Schemes" registry (see
<xref target="iana-considerations">IANA Considerations</xref>).</t>
      <t>REQUIRED {schemeObject} (object) - an object keyed with the given
scheme, containing the details of the encryption used.
For the "ocm-gpg" scheme, it MUST contain:
      <list style="symbols">
          <t>fingerprints (array of strings) - one or more fingerprints of
the public keys used to encrypt the resource.
For the "ocm-mls" scheme, it MUST contain:</t>
          <t>cipher (string) - the encryption algorithm used to encrypt the
resource as in [RFC9180] Section 7.3.</t>
        </list></t>
    </list></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 <em>deprecated</em>.
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 <em>deprecated</em>.
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 Message Signature is missing but the Sending Server
advertises the <spanx style="verb">http-sig</spanx> capability in the Discovery response
obtained from the FQDN part of the <spanx style="verb">sender</spanx> field in the request
body</t>
  <t>the Sending Server advertises the <spanx style="verb">http-sig</spanx> capability but its
Discovery response carries no <spanx style="verb">jwksUri</spanx></t>
  <t>the HTTP Message Signature is missing</t>
  <t>the HTTP Message Signature is not valid (see <xref target="http-message-signatures">HTTP Message
Signatures</xref>)</t>
  <t>no trusted JWK Set can be obtained for the FQDN part of the
<spanx style="verb">sender</spanx> field in the request body, via the <spanx style="verb">jwksUri</spanx> field of its
Discovery response</t>
  <t>that JWK Set contains no key whose <spanx style="verb">kid</spanx> equals the <spanx style="verb">keyid</spanx>
signature parameter (see <xref target="http-message-signatures">HTTP Message
Signatures</xref>)</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="notifications"><name>Notifications</name>

<t>This optional endpoint is used to inform the other party about a change
that concerns a previously known entity, such as a Resource or a
trusted Share type (e.g. a user).</t>

<t>A Server that intends to send a notification SHOULD make a HTTP POST
request:</t>

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

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

<t><list style="symbols">
  <t>REQUIRED notificationType (string) - it MUST be one of the
registered values listed in the "OCM Notification Types"
registry (see <xref target="iana-considerations">IANA Considerations</xref>).</t>
  <t>REQUIRED senderDomain (string) - the FQDN of the sender.  A Receiving
Server SHOULD use this information to verify the HTTP message
signature on the request, and it SHOULD also use it to validate the
underlying share or resource the notification is about.</t>
  <t>OPTIONAL resourceType (string) - the type of the resource this
notification is about (e.g., <spanx style="verb">file</spanx>).</t>
  <t>OPTIONAL shareType (string) - the type of recipient this notification
is about (e.g., <spanx style="verb">user</spanx>).</t>
  <t>OPTIONAL providerId (string) - the identifier assigned by the
Sending Server to the underlying share, if applicable. This
field is <em>deprecated</em> and SHOULD NOT be used.</t>
  <t>OPTIONAL notification (object) - optional additional parameters,
depending on the notification and the resource type.</t>
</list></t>

<t>A Notification payload MUST include either the <spanx style="verb">resourceType</spanx> or the
<spanx style="verb">shareType</spanx>, or both when relevant.  Multiple Notification types are
defined for different purposes, and additional types MAY be defined
by implementers and registered in the "OCM Notification Types" IANA
Registry.  For each notification type, a specific format MAY be defined
for the optional notification object.  In the sections below, the base
Notification types are detailed along with their specific payload.</t>

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

<t>A notification MAY be sent by a recipient to let the provider know that
the recipient accepted or declined a share, in response to a Share
Creation Notification.  Similarly, it MAY be sent by a provider to let
the recipient know that the provider updated or removed a given share,
such that the recipient MAY clean it up from its database.  In all such
cases, the <spanx style="verb">resourceType</spanx> MUST match the <spanx style="verb">resourceType</spanx> of the
underlying share (e.g., <spanx style="verb">file</spanx>), the <spanx style="verb">shareType</spanx> MAY be omitted but if
present it MUST match the <spanx style="verb">shareType</spanx> of the underlying share, and the
<spanx style="verb">notificationType</spanx> MUST be one of:
- "SHARE_ACCEPTED", to inform about the acceptance of a share.
- "SHARE_DECLINED", to inform that a share was not accepted.
- "SHARE_UNSHARED", to inform the Receiving Server that the share
  was removed and is not accessible any longer.
- "SHARE_CHANGE_PERMISSION", to inform the Receiving Server that
  the permissions of a share were updated.
Further, the <spanx style="verb">notification</spanx> object MUST include the following fields:
* OPTIONAL message (string) - an optional human-readable message that
  describes the event.
* REQUIRED file (object) - an object containing the details of the
  event, including:
  * REQUIRED providerId (string) - the unique identifier assigned
    by the Sending Server to the underlying share in a previous Share
    Creation Notification.
  * OPTIONAL permissions (array of strings) - The permissions granted
    to the sharee, in case they have changed in the context of a
    <spanx style="verb">SHARE_CHANGE_PERMISSION</spanx> notification.  The allowed values match
    the <spanx style="verb">permissions</spanx> values specified in the <spanx style="verb">webdav</spanx> protocol of a
    <xref target="share-creation-notification">Share Creation Notification</xref>.</t>

<t>The same notifications identically apply to resources of type <spanx style="verb">folder</spanx>.
For other resources with a different <spanx style="verb">resourceType</spanx> attribute, a
Sending Server MAY implement the same notifications, provided that
they get registered in the related IANA Registry.  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="resharing-and-request-to-share"><name>Resharing and Request to Share</name>

<t>The "REQUEST_RESHARE" notification type MAY be used by the Receiving
Server to ask the Sending Server to share a given, previously shared
Resource, with another third Receiving Party.  The Sending Server MAY
discard this request, e.g. in case the third party is not trusted, or
the share was originally granted without a <spanx style="verb">share</spanx> permission.  If
the Sending Server accepts the request, it MUST create a new share to
the third party: in this case, all necessary exchanges and access
requests MUST take place between the third party and the Sending
Server, without further including the Receiving Server in the process.</t>

<t>For a "REQUEST_RESHARE" notification, the <spanx style="verb">resourceType</spanx> MUST match the
<spanx style="verb">resourceType</spanx> of the original share (e.g., <spanx style="verb">file</spanx>, <spanx style="verb">folder</spanx>, ...), the
<spanx style="verb">shareType</spanx> MAY be omitted but if present it MUST match the <spanx style="verb">shareType</spanx>
of the original share, and the the <spanx style="verb">notification</spanx> object MUST include
the following fields:
* OPTIONAL message (string) - an optional human-readable message that
  describes the request.
* REQUIRED file (object) - an object containing the details of the
  request, including:
  * REQUIRED providerId (string) - the unique identifier assigned
    by the Sending Server to the underlying share in a previous Share
    Creation Notification.
  * REQUIRED shareWith (string) - the OCM Address of the third party
    the underlying share should be reshared with.
  * OPTIONAL permissions (array of strings) - The permissions to be
    granted to the third party.  The allowed values match the
    <spanx style="verb">permissions</spanx> values specified in the <spanx style="verb">webdav</spanx> protocol of a
    <xref target="share-creation-notification">Share Creation Notification</xref>.</t>

<t>The Receiving Server SHOULD receive a response whether the reshare
request was fulfilled or not.  In any case, a Receiving Server MUST
NOT directly reshare a Resource, even when a <spanx style="verb">share</spanx> permission was
granted, and MUST always send a <spanx style="verb">"REQUEST_RESHARE"</spanx> Notification
to the Sending Server.</t>

<t>Similarly, the <spanx style="verb">"REQUEST_SHARE"</spanx> notification type MAY be used by a
given Recipient OCM Server, to ask a remote OCM Server to share and
grant access to a Resource, previously made known to the Recipient
Server out of band.  In this case, the <spanx style="verb">resourceType</spanx> MUST match the
<spanx style="verb">resourceType</spanx> of the Resource in question (e.g., <spanx style="verb">file</spanx>, <spanx style="verb">folder</spanx>,
...), the <spanx style="verb">shareType</spanx> MUST be omitted, and the <spanx style="verb">notification</spanx> object
MUST include the following fields:</t>

<t><list style="symbols">
  <t>OPTIONAL message (string) - an optional human-readable message that
describes the request.</t>
  <t>REQUIRED file (object) - an object containing the details of the
request, including:
  <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 recipient that
wishes to receive a share of the resource.
Example: "51dc30ddc473d43a6011e9ebba6ca770@cloud.example.org"</t>
      <t>REQUIRED shareId (string) - A unique identifier for the resource.
Example: https://cloud.example.org/files/data.txt or
1234567890abcdef.</t>
      <t>REQUIRED permissions (array of strings) - The permissions to be
granted to the requesting party.  The allowed values match the
<spanx style="verb">permissions</spanx> values specified in the <spanx style="verb">webdav</spanx> protocol of a
<xref target="share-creation-notification">Share Creation Notification</xref>.</t>
    </list></t>
</list></t>

<t>The remote OCM Server MAY choose to fulfill the request, according
to its trust policies: in that case, it MUST respond with HTTP 201
to the caller, and asynchronously ask for permission to the <spanx style="verb">owner</spanx>
user.  If the owner agrees, it MUST send a
<xref target="share-creation-notification">Share Creation Notification</xref> including
the <spanx style="verb">shareWith</spanx> user as recipient, whereas if the owner disagrees,
it MUST send back a <spanx style="verb">"SHARE_DECLINED"</spanx> notification.  The remote OCM
Server MAY also decline such request because of its policies, without
even informing the <spanx style="verb">owner</spanx>: in this case, it MUST respond to the
<spanx style="verb">"REQUEST_SHARE"</spanx> notification with an appropriate HTTP response type
such as HTTP 404.</t>

</section>
<section anchor="recipient-removal"><name>Recipient Removal</name>

<t>A notification MAY be sent to inform a target OCM Server that a share
recipient (e.g. a user or group) was removed from the list of trusted
users, following a previous successful Invitation, or otherwise left
the system.  That recipient may have been previously known to the
target server because of existing shares whose shareType matched it.
The recipient of such notification MAY reciprocally remove that
recipient from the list of trusted users, along with any related
shares.</t>

<t>For these cases, a notification payload is to be formed such that the
<spanx style="verb">resourceType</spanx> MUST be omitted, the <spanx style="verb">shareType</spanx> is set to the affected
shareType being removed, such as <spanx style="verb">user</spanx> or <spanx style="verb">group</spanx>, and the
<spanx style="verb">notificationType</spanx> MUST be one of:
- "USER_REMOVED", to inform about a single user that was removed or
  marked as not trusted.
- "GROUP_REMOVED", to inform about a removed group.
Further, the <spanx style="verb">notification</spanx> object MUST include the following fields:
* OPTIONAL message (string) - an optional human-readable message that
  describes the event.
* REQUIRED user or group (object) - an object containing the details
  of the recipient to be removed. In case of <spanx style="verb">user</spanx>, it MUST include:
  * REQUIRED userId (string) - OCM Address of the user to be removed
    from the target OCM Server.
  Whereas in case of <spanx style="verb">group</spanx>, it MUST include:
  * REQUIRED groupId (string) - identifier of the group to be removed
    from the target OCM Server.</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:</t>

<sourcecode type="http">
NOTE: '\' line wrapping per RFC 8792

POST {tokenEndPoint} HTTP/1.1
Host: cloud.example.org
Content-Type: application/x-www-form-urlencoded
Content-Digest: sha-256=:81kCnlO5UY/mZ8UgpxBWnq18GY3WhzJnDjOTvSvjbhw=:
Content-Length: 80
Signature-Input: sig1=("@method" "@target-uri" "content-digest" \
  "content-length");created=1730815200;\
  keyid="receiver.example.org#key1";alg="ed25519";tag="ocm"
Signature: sig1=:bM2sV2a4oM8pWc4Q8r9Zb8bQ7a2vH1kR9xT0yJ3uE4wO5lV6bZ\
  1cP2rN3qD4tR5hC=:

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="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 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="notifications"></xref>).</t>

<t>The "Scope" field indicates whether the notification refers to a
Resource, in which case the "providerId" field is REQUIRED in the
payload, or to a Recipient, i.e. to the shareType in a
<xref target="share-creation-notification">Share Creation Notification</xref>, in which
case a corresponding identifier such as "userId" is REQUIRED in the
payload.</t>

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

<t>Initial Contents:</t>

<figure><artwork><![CDATA[
   +===========================+===========+===============+
   | Notification Type         | Scope     | Reference     |
   +===========================+===========+===============+
   | SHARE_ACCEPTED            | Resource  | This document |
   | SHARE_DECLINED            | Resource  | This document |
   | SHARE_UNSHARED            | Resource  | This document |
   | SHARE_CHANGE_PERMISSION   | Resource  | This document |
   | REQUEST_RESHARE           | Resource  | This document |
   | REQUEST_SHARE             | Resource  | This document |
   | USER_REMOVED              | Recipient | This document |
   | GROUP_REMOVED             | Recipient | This document |
   +===========================+===========+===============+
]]></artwork></figure>

</section>
<section anchor="ocm-encryption-schemes-registry"><name>OCM Encryption Schemes Registry</name>

<t>IANA is requested to create the "OCM Encryption Schemes" registry in
the "Open Cloud Mesh (OCM) Parameters" group.  This registry records
the values that MAY appear in the "encryption.scheme" field of a
<xref target="share-creation-notification">Share Creation Notification</xref>.</t>

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

<t>Initial Contents:</t>

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

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

<section anchor="threat-model"><name>Threat Model</name>

<t>The threat model follows the Internet threat model described in
[RFC3552].  It assumes that the Sending Server and Receiving Server
participating in an OCM exchange have not been compromised.  Their
administrative interfaces, host operating systems, private keys,
credentials, and underlying storage are part of the trusted endpoints.
Compromise of either endpoint or its trusted infrastructure is outside
the scope of this specification.</t>

<t>An attacker is assumed to have extensive control of the communication
channel and may observe, block, replay, insert, or modify traffic.  TLS
and, where used, HTTP Message Signatures provide the protections
described in this specification against such a network attacker.</t>

<t>An attacker may operate an OCM Server of their own, control a remote
user, send malformed or deceptive protocol messages, or steal bearer
credentials.  An attacker-controlled server can make arbitrary
assertions under its own identity, but must not thereby gain authority
for users or Resources outside its administrative domain.
Implementations are expected to authenticate peers where required,
enforce local authorization policies, validate protocol inputs, and
protect credentials.</t>

<t>Trust in one OCM Server does not imply trust in every OCM Server.  A
TLS and HTTP Message Signatures permit attribution to the server
controlling the relevant credentials, but do not establish that its
assertions are truthful or that supplied content is safe.  Resource
names, descriptions, URIs, metadata, and Resource contents received from
another server remain untrusted input and need to be handled according
to local security policy.</t>

<t>A malicious or unavailable peer can refuse to deliver notifications or
Resources and can attempt to exhaust network, processing, or storage
capacity.  The protocol cannot guarantee availability when a necessary
peer refuses service.  Implementations should nevertheless apply
appropriate timeouts, request and response size limits, rate limits,
quotas, and concurrency limits to contain such failures.</t>

</section>
<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.  As with the Discovery Process,
implementations MAY fallback to HTTP instead of HTTPS in testing
setups.  Bearer tokens MUST be treated as
confidential and never logged, persisted beyond their lifetime, or
transmitted over unsecured channels.</t>

</section>
<section anchor="underlying-security-specifications"><name>Underlying Security Specifications</name>

<t>This specification relies on HTTP Message Signatures [RFC9421], JSON
Web Keys and JWK Sets [RFC7517], and Digest Fields [RFC9530].  All
security considerations in those specifications apply to
implementations of OCM.  Implementers need to consider those
specifications together: a message signature is only as trustworthy as
the provenance and protection of its verification key, and signing a
<spanx style="verb">Content-Digest</spanx> field provides content integrity only when both the
signature and digest are correctly validated.</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>[RFC7518] Jones, M., "<eref target="https://datatracker.ietf.org/doc/html/rfc7518">JSON Web Algorithms (JWA)</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>[RFC9110] Fielding, R., Nottingham, M. and Reschke, J. "<eref target="https://datatracker.ietf.org/doc/html/rfc9110">HTTP
Semantics</eref>",
June 2022.</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>

<t>[RFC9864] Jones, M., Steele, O., "<eref target="https://datatracker.ietf.org/doc/html/rfc9864">Fully-Specified Algorithms for
JSON Object Signing and Encryption (JOSE) and CBOR Object Signing
and Encryption (COSE)</eref>",
October 2025.</t>

<t>[RFC9180] Barnes, R., Bhargavan, K., Lipp, B. and Wood, C. A.  "<eref target="https://datatracker.ietf.org/doc/html/rfc9180">Hybrid
Public Key Encryption</eref>",
February 2022.</t>

</section>
<section anchor="informative-references"><name>Informative References</name>

<t>[RFC3552] Rescorla, E. and Korver, B.  "<eref target="https://datatracker.ietf.org/doc/html/rfc3552">Guidelines for Writing RFC Text
on Security
Considerations</eref>", BCP 72,
July 2003.</t>

<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>

<t>[RFC8792] Watsen, K., Auerswald, E., Farrel, A., Wu, Q., "<eref target="https://datatracker.ietf.org/doc/html/rfc8792">Handling
Long Lines in Content of Internet-Drafts and RFCs</eref>", June 2020.</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>

<t>This appendix is informative.</t>

<section anchor="published-jwk-set"><name>Published JWK Set</name>

<t>An OCM Server that advertises the <spanx style="verb">http-sig</spanx> capability publishes
its public keys, in the format specified by [RFC7517], at the URL
advertised in the <spanx style="verb">jwksUri</spanx> field of its Discovery response (see
<xref target="http-message-signatures">HTTP Message Signatures</xref>).  Here is
an example response from <spanx style="verb">https://sender.example.org/ocm/jwks</spanx>:</t>

<figure type="json"><artwork><![CDATA[
{
  "keys": [
    {
      "kty": "OKP",
      "crv": "Ed25519",
      "alg": "Ed25519",
      "kid": "sender.example.org#key1",
      "x": "AzeStPAdQ-vbi6bJVxcQjBPF2I7fDZdfDZ_XZ3J4Azs"
    }
  ]
}
]]></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
Content-Type: application/json
Content-Digest: sha-256=:/Uz47cfD1HOdMTIqcWjd84iMLQ4gVJdC7ZFACf1ViqU=:
Content-Length: 521

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

<sourcecode type="http">
NOTE: '\' line wrapping per RFC 8792

"@method": POST
"@target-uri": https://receiver.example.org/ocm/shares
"content-digest": sha-256=:/Uz47cfD1HOdMTIqcWjd84iMLQ4gVJdC7ZFACf1ViqU=:
"content-length": 521
"@signature-params": ("@method" "@target-uri" "content-digest" \
  "content-length");created=1785060500;\
  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.  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">
NOTE: '\' line wrapping per RFC 8792

Content-Digest: sha-256=:/Uz47cfD1HOdMTIqcWjd84iMLQ4gVJdC7ZFACf1ViqU=:
Content-Length: 521
Signature-Input: sig1=("@method" "@target-uri" "content-digest" \
  "content-length");created=1785060500;\
  keyid="sender.example.org#key1";alg="ed25519";tag="ocm"
Signature: sig1=:Epax4XFqvbrrDzQUAaNl+uECasEKbArgz8AlEkXspvYX2fSkQFlC\
  kaXImZnYU898C2t0IdmbFhjR8bkN0hZgCg==:
</sourcecode>

<t>See <xref target="http-message-signatures">HTTP Message Signatures</xref> for the
normative requirements illustrated by this example.</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 Discovery response from
<spanx style="verb">https://&lt;provider-domain&gt;/.well-known/ocm</spanx> and read its
<spanx style="verb">jwksUri</spanx> field.  If the Sending Server advertises the <spanx style="verb">http-sig</spanx>
capability but no <spanx style="verb">jwksUri</spanx> is present, the receiver can discard
the notification, as described in <xref target="decision-to-discard">Decision to
Discard</xref></t>
  <t>Fetch the public keys from the URL given by <spanx style="verb">jwksUri</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 algorithm derived from the <spanx style="verb">alg</spanx>
value of that JWK (e.g., Ed25519 [RFC8032]), as described under
Keys and Algorithms in
<xref target="http-message-signatures">HTTP Message Signatures</xref></t>
</list></t>

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

<t>Following the validation of the signature, the host also confirms
the validity of the payload, as specified under Verification
Requirements in
<xref target="http-message-signatures">HTTP Message Signatures</xref>.</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>: Criteria for accepting a Share Creation Notification</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="appendix-e-navigation-index"><name>Appendix E: Navigation Index</name>

<t>This appendix is informative.  It points to normative sections and
informative aids; it introduces no new rules.</t>

<t><list style="symbols">
  <t><strong>Discovery fields</strong> - <xref target="ocm-api-discovery">OCM API Discovery</xref>,
<xref target="fields"></xref></t>
  <t><strong>Capabilities</strong> - advertised in <spanx style="verb">capabilities[]</spanx>; see <xref target="ocm-api-discovery">OCM API
Discovery</xref></t>
  <t><strong>Criteria</strong> - advertised in <spanx style="verb">criteria[]</spanx> as inbound admission gates;
see <xref target="ocm-api-discovery">OCM API Discovery</xref></t>
  <t><strong>Per-share requirements</strong> - in <spanx style="verb">protocol.*.requirements[]</spanx>; see
<xref target="share-creation-notification">Share Creation Notification</xref></t>
  <t><strong>Per-share protocol shape</strong> - in <spanx style="verb">protocol.*</spanx> fields; see <xref target="share-creation-notification">Share
Creation Notification</xref></t>
  <t><strong>Same-string note</strong> - <spanx style="verb">must-exchange-token</spanx> in <xref target="ocm-api-discovery">OCM API
Discovery</xref> criteria and in share
<spanx style="verb">protocol.*.requirements[]</spanx></t>
  <t><strong>Signing</strong> - <xref target="http-message-signatures">HTTP Message Signatures</xref>,
<xref target="signing-direction-index">Signing Direction Index</xref></t>
  <t><strong>Object models</strong> - <xref target="appendix-d-object-models">Appendix D: Object
models</xref></t>
  <t><strong>Informative diagrams</strong> - in the OCM-API repository under <spanx style="verb">diagrams/</spanx></t>
</list></t>

</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-07"><name>Version 07</name>
<t><list style="symbols">
  <t>Required the <spanx style="verb">keyid</spanx> signature parameter and that it matches the
<spanx style="verb">kid</spanx> of the verification key in the signer's JWK Set.</t>
  <t>The HTTP Message Signature algorithm is now derived from the JWK
identified by <spanx style="verb">keyid</spanx>, per Section 3.3.7 of [RFC9421], instead of
being restricted to the "HTTP Signature Algorithms" registry; the
<spanx style="verb">alg</spanx> signature parameter is optional and checked for consistency.</t>
  <t>Replaced the unregistered <spanx style="verb">/.well-known/jwks.json</spanx> endpoint with a
<spanx style="verb">jwksUri</spanx> field in the Discovery response, from which the location
of the JWK Set for HTTP Message Signatures is discovered.</t>
  <t>The <spanx style="verb">Date</spanx> header is no longer covered by signatures: freshness is
anchored on the <spanx style="verb">created</spanx> signature parameter (see Section 7.2.4
of [RFC9421]).</t>
  <t>Clarified that <spanx style="verb">created</spanx> bounds the lifetime of a captured
signature but does not by itself detect replay within that window
(see Section 7.2.2 of [RFC9421]).</t>
  <t><spanx style="verb">jwksUri</spanx> and <spanx style="verb">{tokenEndPoint}</spanx> transport: HTTPS remains mandatory,
with the same HTTP fallback allowance for testing setups that the
Discovery Process has; dropped the HTTPS-only schema pattern from
spec.yaml accordingly.</t>
  <t>Appendix B now defers the missing-<spanx style="verb">jwksUri</spanx> case to <xref target="decision-to-discard">Decision to
Discard</xref> instead of stating a stronger
requirement in an informative section.</t>
  <t>Updated the signature examples: replaced the legacy <spanx style="verb">Digest</spanx> header
with <spanx style="verb">Content-Digest</spanx> [RFC9530] and applied [RFC8792] line
wrapping.</t>
  <t>Added informative aids: same-string note for <spanx style="verb">must-exchange-token</spanx>,
Appendix D criteria label fix, <xref target="signing-direction-index">Signing Direction
Index</xref>, <xref target="appendix-e-navigation-index">Appendix E: Navigation
Index</xref>, and companion diagrams under
<spanx style="verb">diagrams/</spanx> in the OCM-API repository.</t>
  <t>Rehaul of the Notification (formerly "Share Acceptance
Notification") endpoint and payload, and adaptation of the IANA
registries.  The core notifications have now been fully spelled
out, clarifying their scope.</t>
  <t>Introduced an <spanx style="verb">encryption</spanx> optional object in the Share Creation
Notification payload, and defined a corresponding Encryption Schemes
OCM IANA Registry.</t>
</list></t>

</section>
<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, Justin Richer 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:
H4sIAAAAAAAAA+S9+5LbRpYn/H8+BYKOGKk8JKXSzVJ53J/LuthyW5dWSfZ6
tAoRJMEiLBJgA6BK5Z7u2NfY19sn2XPNPAmArJLk6dndzxEzraoCEnk5ee7n
d0ajkWvyZpUdJVeebbIiub8qt/PkSVYvr7h5OSvSNfxpXqWLZpRnzWJUztaj
Eh4czfDB0RoeHF3/ys3SJjstq/OjpG7mzuWb6ihpqm3d3Lh+/d71Gy6tsvQo
Od5sVjk8mpdFnaTFPHmRpavRy3yduXfZ+VlZzY+Sx0WTVUXWjB7gR52rG3jw
bboqC5jIeVbDL2CsNTz48OUj59JtsyyrI5ckoyQv6qPk+3HyU5k8r7K6yeG3
ScJL+D7f1tlmk7X+WFanaZH/TlM6Su4/fPGUfp2t03x1lJzKS+NVuaF3vp3B
3MazJT20rfKjZNk0m/ro2jX5wzV90oUZPRl/N07mWfJjWZyaGT3JZ8s8W0V/
iafzvCzmWZWclNtqltl5rfnVbzf0QE1/H8O73WlFT8zKdTSt5Lv0dDmFD9pZ
pct5Hv/hspPCNz97Sk+BCPIi3qZ3mf11PJ2TV08fvrTTeJcW5bf1FihoXGc9
51TOs3G9Llf4AAx1bY3jOzcajZJ0CrSVzoDoWlchufrs/pODJAeiTeqseg/r
X2SwCJpDsqnKppyVq6RZpg0+BEQzT5rSFWWTL87hnRfZLMvf58Vp8jytmnN+
sFlm58kyfZ8l0wy+dlqlQPnzJJ3NsrqG15O6hHvxIpOdSpLHDTxeJ3W+zldp
lTd5VidnebNM+A7IliSLVXkGT21n8IfaPTuGPw7hX8lZtlrR/+IrdTnL0xXs
Ol82vwb/YnI8a2DKzfnz7dThVaXtHTt3nMzKKsM1JrMU/l+5SGBzcNlnS1hG
in+pkqvZ+HQ8TI7husMjRXJyXjfZOjk+gM/XS7jFuL4lcAV4oZIl6ktpsshX
2YGsDTZxCQPaUb8rpzCmkzG/4yfLLWwp7GG9yKoKtxpeC0PnTZ2tFkA78Ku/
bnN6AIeBU1qVp7APuOE6SVjlL0uYAgwBy6pnWQHbXeIS89VqizQCW5MNdd3z
rM5PCzpy2L3NpqyaJHXTqkzxosCUTmmXaK+BupD5DeGn2Wo7x2lMYeKwyGQF
59rwKLh+p4upx116XMKJrOD47ZiwJavzZLvBAXDtmxL+iodS4UKQkmIixOUU
i7JawzdhevBIXhnqwyEM8QE5bNOVJ0d9EPdnO61hT7Oigc+v0yI9hQGn5wmf
myesoSfJX7Lpg+Ofx3zn1vkcVuLcF8j4q3K+pcV0V3yW4nSB6NMVfGZWFrgY
njkc3o3rh7dJoOAFoes0zzar8jybuxp2OsMH7sAq8MT8I/l6s8rWGd06mG+d
wb2GO7FZpQ1uiz0kh5Lhu/LDMHmafWhI9MHxwxTv8z/LM/0XTuIkS/EEYYUv
YRNPSxg03BLYWtiT9/k8I2Yy21ZASfUsXaXTVcbvL1bZhxx+cnA+VQr0BpsC
jyUwK3kDtgBvDx4mvgD7C6+XSJfwG7huSvckZR1xDVzxGX11Xm5wj4dMdRl8
gOh/iYcKJAsMEb/SlJUsgO47vJnGq1in7/BeIT+CfaTJ4SWlv82Zfqr8dNk4
uEXFKWz+S7xNyENReL3nTeetoHW0+KgyY3j+LD13tG5gR7ReZHhwbqJKwFk3
wJvqZFGVa/qunwf+wAwbP4u74+D5abZMkRkswsNI4cJpYDlwg4EZyw2Sx/zs
cPVLPBvgjvz9dTaDC5nXa575KmtqmQLQaQFbmZQoMkAtgDNG9gd0uoWb4uAg
WRla5htWiJCtAi9D5sqv0s2GlfiX8Q8NrAVW0ZzBoTq+uHDiG3wcxAkekSx6
jBfrZQbEzEcJWlaCaladDJ68Onk5GPL/Jk+f0b9fPPzLq8cvHj7Af5/8cPzT
T/4fTp44+eHZq58ehH+FN+8/e/Lk4dMH/DL8Nol+5QZPjn8dMHkPnj1/+fjZ
0+OfBkx3yELL2RZvYoISAVY7zZi1gS5FMrF2wGRnVT6FH+Cd7+4/Tw5vJa9f
PLp/4/Dw3hv6193Dr269ISHEnyF2SD86ErUpKHJpha8DCwHZtYHjQ7aEl2MJ
FzhBTomsPwOCWuQFcU0g6xXIUyRQ4jmbBt4QCbrO4AYVowJ4BQkEOANg11mB
1w7kCh1uNvfvMXmSPKb53vnqFsycROuqzohPHzn3ZfL27YO8niHFIEcAZoIn
+fYt6EjHqnyw/lDlWa0yB5bKzJwpklQlpIPj548THe58HI2Oa7p48HIKd6u4
9OCPvFokg55WJYgkYRzPmfHh3cSPkPJjbgUMu96imGHTga/6aZWRBgEKNs1k
U4JOgZNDhmPkH95gGCBMIAGKQ0JapLN8hVeVOU4KU66IvZ3T8kFBkan/5cFT
mvSjLYqYv8A88kUOLz0o1/jhp6COeiGWTAYkBcbZhxTZH6qSgwkP9Bg5QwYS
E489RenzPSwSuDaNLv8OzEoeZ/GM+1/CMvr+gDvIBzaUM1c1R558Wb5DDcyr
ejIOHdV8XqG8FmYmL5xkqIoPk2yxYN4B606R3uE8GhkcBomeNtMQgVQQ/z4h
be4+2Ga0+U9R9/W23iXWtGvvXqBuUTdMTkBwM7y9OzcPxoMvyfREAOya/gW7
COOoyrx/F/Xj0T7C2+2d/JR9hGHaO/nJ+1iD5VUzEf7w8uVzEhn4m3hMl/Ts
fjSoP+PLkLUslj+xh5aGOJ3tivZKtJGZfge2Oy3C9OiAohmBhliD2kkTebZt
RuViNEXmsebfq0HWFaIwmojRZANKcc4Kk1cZZCLylUdwnEN+EzRRUr1ak0qu
gpoFI8KDBzRQZyOu1JaQokXoWdIqUFhvSE2vvNruPzdEbaxomDsBSwPjRjny
nnHNZvtPCMtflqu5fCEVEp+W5TsYlHZuet5P7rCjZ8sc+KEqYH3cBUU6Xn4S
6jB6No9mxw+11qx34RNX3CGuz1qvMskLVuu3+YL1Nih4mZsVLZYjBIOCKKJ5
mYKsWHjGb6CcikQrksm3kxEaoUMcoEhABynhw7AaMjDBTL9za1utkqt8B1+9
+GnEhgZYKehlGdXpAia72ixTuA6i/pCmhYrKrTu37r4ZwndJzia32d6GcTaw
PDI4wHBtWuukJYkOABxtPmrK0ekWd7qmHeCd7rlgMO5pVqAM33ESdhNwEau8
eIdrLXJgVSDA+llN38Uzv6CZehqr1Y0BfJkVmEHaDHCjLZ9NiKSsXBDeYNxE
qJQj91abW79QoZsD9HzkQKtylnoZ0VocfJKtNTRMwSwZdz8K6jNYLihv4GAf
o7gCo2xeZvRr1rHq2RIMXU9gYRZgxJ3rrGEEGA8/DTorHBmwR+CBR458aEmC
jl+9LN/YIQbfDmglyetkcDSgWb7BlwbhmQGZfbiUFM5oSI6jEVzyOie9+dXL
R6O7Qhfs58rxetcZcAMiAy9U6DtCFCs0XPHjQkT2eMMgm7Ku0ZZGsqC9WKOQ
QYP1W7oxxORTfFlXB2J8DNNgbxbuCnm+PKNg848ObUXsSvmAPrDK3yH1TQow
EIpxAXZLXn5r1MRvO4rjBGlpgGvTjXr8HIZpyB0BdzndgGSkjcCLB/Ot/7pF
JWEKZ/QuQ4uEXnl/C4lApwlmcYm3Em7zLF/DQKjAD5Gi0eN2CmoJGBxzcrIi
zVj7CobBe3/z3t07b/z509Z/A58Z6cyu0Tf1g9dw1BEO5+RmRISLbqJZCaZ1
gWbeLEUr3MtlviWom9Oj8Jst+W5RL5qrgcHC1dsbaEygC+rAXkS5OWTTwvhz
a0ixyzU5BYoreDVkJcokiVTg2+/zlB77BVS/0Z8LtAvJuLxzePsNHDfYbpNr
Y9QLR+/wj9fgWkzCpUTlSfZD7Wq9Xrg4eN1wHms9Ef+RFSFBZe/T1Za5wqYq
NxnrJigUQNCsS1I51BcHx79orH9BrFXyEogTtaMg4s9WsxRWrRqTv3HBaxgp
1aRki8LKv4ejQlsqQcUpHYro0XsZ67DwIrlWwkx22qFLo32r9ZgstgWbfPR+
y68pg2wwxADyUOzPSjSLsyX5cWNnO4tr6/CEH+C90yX9kjTyr9Xvjo8ORC0O
ztRryYu/Ph/AQHDQZOKPXj057tFaukKovcFtXQW3gcNbrAkCGew1tYwKOqTX
UrXsaBOAG9IPFJsgG5/c5DqHWOqREnJODCAHlWJ9gZ3nv1cjRwGiI3ttlcMe
DNkaCn756IOwpep4XnLMpnMQMppEANiFzNrJvcO7bw6UCYvmSGPUhtz50vhh
hUj8V8Qj6xWOmLZ1CPMu6ap5NiPP/jxt0iT2RgRt0TvKydbAQYX49scAjiQM
guMuQF1ljQEniaY0GsH4s9zyIXlP6fMJECaK2KyZ8bR1KdZYO+ZtpxcW6SyL
Zu6v/onfS4lalT17QwbR+8wb0ThSoTtAFhxwXuQWSDbxjLrXtXNPNbLFYoKH
08Hq9pWUs3x2VpDGUbR9ba3riJe170LG69t9HdGIqGOucXVAR8aPDnA1g4dF
U2VwNmBmP8K/nZwXMw4SLNlQuPrw0cnJgX+nKleZXFwhytoEZUCzuwokmn0A
tYYMGHXgg1hNBnBBBvJuk76Tu43iv47PwzM1Mg3QU9qiB7o+p0wwdYcghBzQ
mIBvRrHHE7OKROK1rVPYPcF0ijE8PXJeXpOt0XUaMQi/3zQ8T8MfQWsGO76O
bALEKXxuLy9lHXCDErjKcecMcxViwdeVhtEzCQb7FkmgUZUejkhdlyl6HWtR
ycUwQJWNV0bBEl6qX+HXeOLox0xXdcn+ZX4AGGhZkf2ElwsZEB5lgqQGOnwh
34YbhLMxU/Ur9XSNNpz3ssh2yE33w+JqkNOJE6/NAfIi8iWl6CTFJS22q6TF
fpidoSmrgV2YT62ifM9hRLoBGpNyHyuWxJ5IyW7gT9ZWYTEip5Zpc3i+K5L4
77RWjEPJnviwIV+iuZ0xuobV1sXAzggemZPSyUbNcJeA8by1rHp3Fo2WbLVp
aWL8ypbSKDA7Bj2VJGuM1NQbTsLGsBA77edZtc5rvHts/2qIa+StVhLaKUU0
VGXy+l97PiWbYetyLpoqfVK314eSzfdfUCieQrC1KsCtCWAuTZX7AHf4Akzg
Mt+Y7xT5Nf+Z/SfWDznNRNNJaZGR3pDk/M1N1zmx0xV7IoHaV7XXcInbmtCn
5+9p0lV8YuH5EiMj2TzSmO38fRIKiOUatWU8MnznDKyb5TnLPb170bJVFJTG
gWrCPkOT8oKBmmw9BfJb5qxcV3ms/4BNKgHCaSbMit09aSFJJ2RysSEKxhyq
b7Iycb4OeSVhlO1mTjYwxVKbfC3SCwmhSIrszE5WLDI/vIzCClcWedmYmOOP
e0/JZgsG1QzDpqBY//jLn2G3GhImX90+/Aq0TjJgmZ+RS10c0clJflqkJD3Z
FQEsnAICwMR1Dsp3wT5eZ01KOqQGl1iRQrJiV/yDPMUslVcvfsLVVpplgo6a
dJNOMbwFqjwTyC/Hvz6CG3mqBP8LBhZHx/B/v5bb0SNkkxucIiUzBeO65lAY
rYjtIVGWzttuqcgzqVQ/ds598UXySCyzupvAwU7FGj8J0gksU7XivLeGNOAi
w7uQwozQ+E8L57M0UtUqffrEaiUHuMYhCoz0gSoMEhO9WuxeQBHUlI5FrviT
knjIWtwMCwre2nnhkr6ITE/n5LJ5W5T9NbhTmteFvg3UbpRdwc1L3qI6Ur+l
vXNtDZMdfUnXEqSkhPhz6tmAUfqixKxZ+iuTiuNLLMfkbaTevDUL7MRE/Uo7
f+lZMumjWR1FiUWbczYk3IkD0wySF7g5uykGN9BTDW2kSOaevXGy80e09Z2d
Jq1QL3d3w+nvsivxq5j31nJ48DZEM2CXBdkFL2wGjm6QAw2d+TzK1TjZas3X
gP5Sk2Xis1hEbWeJVr/F3Dn0YiUhM66OxsL0Ef99JKL21JEd6S0KXyJXEXky
iaOQwaeu+ET8+kDDNo7mIjeTnQ8KEi9jwnknyI/QNUmKVinqrQsZUYZ/USac
D963AwXC4ulxYmg4DtC8SaNDL3xjRUs0l6FkENQc6eRtY1+yq9ErailXiKJN
MUgWHQ/ZLsLw/huxGkKQN7Y6SJWNT6weBodNODC+YuqZcUofnP7S64YJtBcR
mBCPeBYt6bDsSnYQC4z9Vv2d35XlO7zg7u19pon6rb9phqBYewrkBBsLnPt4
s8H1fkgekC+7nP6GWVOo6FG+lRg1lAkEpxpn3ZxucWYohENCHy8raMii4dts
K437wl/QbMEcKcqW+p4ofkU0xklTq3yRzc5nq0xEX5tPsTIL36ka2ReYL6WZ
1rhEkuoOJh75Z4kkh70+Wz6/ngQbnA3LFE6d9QFy0BXK1Xuxp2MrfZ2+4+w6
tTjUENvhzen+DgRaVZGZRCm2cDtSygVtmc5Df9qt130wt53aYKk+OGDjy4QJ
x+TcRmN22O+RRgKVVOs+OwmmdQ2Io2+xOOOzHHM8gNq6d0U0cLatmp4UWhT1
PX4JYU0dAymeBP8SJ08xW1ZvUbsDos+sl+ZIqFcT/JxZN24u7GzfVkr+Le/B
VM4OI3vFKcm45KGlPbm0zn2XLcoq66eDQr+3x1BXA7F9TKSYkfoSsjB6jovj
tE65ylWTbtF3+PA4KvKB+PwDTocLYcgDeGxdIiHT1lBeKjK5E0zlAwEBXAE1
xw0y6oyGcy33RcuNHR9llGBy1ScJulX2Plt5MXSwK5uotRGs0vJMMV5aD13M
QC41SrLEtMeCJIEEKyMilHWxHsaqXoIuy3NmfZzbW4N8T1khbySHN+//GvEl
ugx5FZ2j1y1aWyZXjJIpyyhzJy1qf6oufks5PGXnczYB2JRM9S3HtuyKMj9v
7J7zF+jv5xtibhQdafxgQOw/vHzyUwibAleYMS91mHLACgaYZGJxs1nHjMBP
iheGQ/AOP2d78id8nwXMcWFmyyZPWZyvy229Ok/e59kZs07vFhCjoqWdsouQ
dMriPFR1aHAFlpjpAjNVTkKkOKzW8WpJyrZJRBK4ed+0gqV1nnpeHUZZbldz
tEhod1C50vgc6ICthGZShimBwbFByMocvAxaNOZ+Yp2ByRqNdtYoiM6dcHhg
dT70bgcmir49TPr30H30HibdPfRClw5YQtAhfKvlK1KkYnPi8d55Bc3RrlOi
2myLcQ9bn5EoUfIV9YvlrScRQzqS6rtT7wJDYy3BHAf8JOYrGi6HNjYWeFBu
AGlVziaLqve1v2yErllL/1Bycr36h+cTwD4w9B4FZ/CYo/MljTxlJwoYrE/w
3NYZ7OWcbfregDgf8baoKY9YErSDDYPUCwfgk+nblIwhgcz72TZBZNl8HEoN
GBMHNROW0qOs7mWdKD0CfYuanDdg0pA8zqOkiaEoJeEagEILNFNxjpbPoDZX
yqEZrUmOojDi3QmenZquQIY2PBb4aDwDk8CLMCU2MvzIpNyqfSU7WRO/xMHA
bN+s0nMi5IqFeFvPC9sKjHWfXkFmEWzBtqDtbXEeDHWwfTUX+x3lOebTG7ux
m0Cm9i1lfFEGWTcnDz3wmkvdyWo1IbU4GbX3y1v0knSEHdhva/h40J9Iy2ps
EpsMGqWfmuHjBMLOakNKNCtL/UnE8Yy9P7tI3+entEUX5h4nHIxY+9jezlR4
lSaodfUl6ueL3g03n/LGHh6ddxpIgr6Kp84GJmfEDr0T1nNNuF8LCcL0JuTr
LlBovu+ps8BnjectBxqdCYHkrQxOPK4NpvxIYteuHWPRIUKCtrfYShXcpjd5
fbzjJM231fFrctvB8IkyWiXFJ36P03ro1oC07dioHCCtJVOUA6UXT4ajsf2r
l0ybTgVBZ2qOr/3uER5w2i7WdmYYdGQHf4XRZ5jyOVyrD62UXqWZ+F65LjWz
EckuZM8ZW17m4Y4hdHres8uRhOfP4EcRr1QWJJdvco0DAyMNQ004Ky3OpO3s
jphVCR4XDMbHOElDPf6130Adm2jwYYLmIEx99BK0nomWC/BElxnWtcIg6AzS
X07L+XmUGp/8ePLsaajrigLT3sODgUsl/FBoJdozWGyrec25FlqYdpRM8MA2
aJ+rc22CJTshmLOjJEQ54Lg9XoM3ZiLB8OgWJfZXXXqjMdnVDnNCRYllcvcF
1QxIM6PvUTkrJy7TOBiXbc0L9c7HD1oT00VFZq1kNuYXLpUSWXHEp5ED7Zr1
26err8m7b3Neacwd3HFMBSo+bJOjotAENZ8OJq09+7MMsDM/TB7F6f0Qx9Ap
RXVXyQ2q2ZzttT3FjBXSFDhtlDSPvnsBuxel/et9ePnTCXGHYlcwj8oT0/ew
NVys28uyXPtGS3U4chGYMqcftTJuk9f2iy588c3VLxC5YCR5mZSyzH85QKU/
4ppY+G81QjL0WQ/kutSUskQ/sAsI7y4mBYIN1o6HhdJOysMF0bgtVpS6D18n
w7YOuyBFwnvYuwyXcpUiMA3U3mwZH+uPLUnWlT2iCYtFsZebjtH4K2adoEHI
ixddPMly8rCEDDcx8zAtASPctIl6GYeRz8GPZUxUTv+AV0uKy8EZPURbL2ev
S3uTlmQk+qfJXueE7GYnKwuOWpiJ5xJ0wFS1bnPS85j/RBN2VMLdAMPKcbuO
V3U5pIiwxkH92N54Z7uVPIlgrKSzZfBYo436vsznblZW6men2nziUhyddo/7
yoMuq9KlIcoTtLdF/iGbk82KH/OZA3kR0pqacphInAcYCjwGq3SLKstGTfYB
/TabraIkoP1opiP2FnmbwFQKBezkiSUgAich5rxvZXk4i9TiheDPNQFwSExK
zrQWl18lpsWm3FDaPw2ta4zfDOEhVHbbTK4Ojg0q1t8yXEdPBazak3ntwAiF
vwkOBclk5uaSkWMr7pl1+djNfTxiPcJSi3xDaM+fqHIEmhQOjl40lS+ooGiC
OB0qH343DA20t8hPt5XgJli/bNhTuZbhHIoMM2He7d5KFvvOj96q8Ldeoijt
JvqOFpk4+Rwd0LZWqcQaEph8TA2+JAUPmUo3kEv67Rrv1mwl6c6rti/7BFJ4
zmQGxCWgpGG20vj26uOfrEPK+C0lUn77z9Mig3bVpx1crFvtVK2Kz1eteBqf
oVjt0quWF+pVWuv4cVqV0UojvcodJzeuXw/Hi2mk2+BB3mfugX7sQhbpGEa6
dZmR2A9C/s/36SqfUzhNpB5wthw1Axzq5sVD9WkyUmqn7q4QziZhzC/yB+5d
/AE0AdIVnsa5zykc+/jbhmuBWkpRz05xvTK7wnbpRDyT4X7p26emuQhtoU9N
60t7xLSlc7rwQZNVp7sajLBff6gyDMRmokz+fseE2t0+3hPMnpfMD88rKVkP
aae4sk/DG3aeIaXK9bGVlnqXx7mixOSPVW3hiIK5TcDdH5VGyNUcshzCHzHQ
aDy4eklpI/juyy2naKKTkDAqWUrJGJZQtILgx+X4W1ZwJnO2ymZ6+mvER+jg
mo0tE7qUN3mfw1cSYdifd4GD2UUOZslQYTiyj3Apy84YVzLex/b2EmH43WI9
mMO0qSn8JVKUCqDGhSINr5hrGg357slTyMmznBCj6utQVUtRpBUxifMwxXjR
WmPOCuUiKkl99Ron6LqUdMvf9VmSHB4O4bzf0Fr0jnQWVRof8XUgNrOAqD3j
jED7CWVtjp31cg+5arazFh/orZj5KVsUae8UnspcB9aVRTnE+LgxY/WkFIwN
HS0YhZNbgIGQYJeQl7I49bEJ2AgSsLgICk/SrywxOU9MUiKDFLNO55kfwPuo
5HZSxS1F7ATzjiq7OfSyhzxTGrreEh0+LckSgNEldYqSVurz9TrDDHm0Rmi6
iDbkj0yLFpyJl8qcurKgFT7wnJ1SVDit0gnFdSO/osK04zpahhNA4tpXPnuP
Bp9eNA1Q0d0OeTCW4pQMEa3OEERCGaHnjjLDNaIalXisY0Wa9TL30gtxihEz
2gTFyrC8r2aAOZPWWmXqO5hjjZ74Dx3n8E6UoqUmGM+6YorDJPjTgkrZeLSa
lO4vv5TpqL5Kfzv68kupam6iyI4O/7/+x//UxJc2DgQ5afQFKl/fAwZxWSgI
LmzdDQbRgYJIkodc307142L4q68VHRfp7dvpvTt3stHh7dnh6NZsem+U3rw3
H93Kbs1u37p57940XUx8PkFidpZe79bQsySflesp7YemYKCGfamP9ZTlD31h
DV1/v3Uj3VIqFaFalMmvL18d/vry3Y2n61fNk5c///bk5Pr1X288vv3TLw9/
f/bLX5qn37+6/uvvr64/+f3d7V/Xj9Z/+f5pPb3587uf1j/f+vWXw7Pp96+2
WCF688diMsY9Iz8kUHwttk5uycQwOzS02dPopzfPcHoYPE6Sq0zcqrXJtsB6
6EbBrUV/kJ5eSLU8ECQRkK40jGhvhLmgRDZErkChdakZY7vYW7P4XACS4HLA
xpM0XuYx3wBKh7GEL/RCS8YP2FiRCrk0pP4Ow9OZ5P5jOb+WXJFYpjif1w8b
RcpKvUKKtQHASkl9tbQ78cixbfq4dpaeL/4/GuobrO64DEUbD4koOT7uIxFD
jfwLkxfRF52+471SjxT/1Kr5mWEeEYoFCWOswh7jk6iDtZxXgXWb7dbMfrq+
3ZKUiRNnRYgA+uJ+OEZYatetrFK5kVnJaviONYjU52k7choJtiJWPJzSjGBi
rm9OQJbVadbUPpFfkCOP5+9TmMwp1hpwwUmAevTZwjNNfkQAhrZ5rHCFCgk7
dIy24it1F+XWAkgG0Er/adiWR3klvjws4ubd76RLJlPQld5dUOtvM8Up35Eg
gZclCR282D2K045EQb7vjpaHdYDZrOnPU6Fvmvp9k0jDqSFk/rm0aRCcpBLv
MdiNmEmUtbM0fd5Yd6AhVsUzdCPH1he0b2pmYdm5d/F3AZYVNcDtTrRAl16R
rSIzHrUKJilWMNfoE8YgCKdg9n4MlawlupaJpbITHja5k1bUKp9mJIO8GIXa
d9a3p7BxI5juaIElewfikLTraMWnybVob0aG4pyYLq+6IFc3iTLXtwLkmapz
T7MCZL5o+7mYBubjLtpEJGdTRUGYBHB2yFbaH0GVbrYsS/IuOptSpAqt6M4p
Z1uvCYuFgA3eS2Y0FgQQIpBjFwAOrnC9GPIBuVdQbpSkyXfIbMZInOFKt05U
vcZotPQkOfoSS4QTRd1uKsEQNd74sEHpUIO1hSchV02c7TDJbUXuqtbjrSTm
C19Y22RhwncdRsamY2Mz9/F6VQciiELyj9dmiWeUox1W53B1FF3xMYp44amo
6PQ27qElHBFX7jR/30mBO9FibqwFp9jHFss/Ko1f5lHGpvftL1EvaoQ9bKgW
hvMw02qag/FbhTzOESL++AJPClrmFdAKqvLA6gm9urf6gUkhbzjwQ85nivwo
htKuzPRuPYEQkyocZZvxKx9G5BCxtAkTgCv4JA0G+bMvRUeA5AwUh3OHttJp
eiHF1UoW7Hb3KFCMgYwepm2FR6zYtR5CGS8WvkuOgypbl3qGZLCBTX8Fm0LQ
e+dXMIEStBmBQya3ax0uZU8ZHVIhf82H9sCS6+wo+bxjUjD5ZL8oCPxSI10S
EMM8clRQQHcCiYKArlmRMya3xpJYWoVIJ/cYqDkRbd3Jqa4JcXvLFv9iVZZz
n9VrdCe6Ei2PQRtfgowLFI3oWUwr2gOudTzd4u1DLuzgaEEPXiMTFDqovYVL
7sg2Dm4sTa+KM/zA7fYiowcDfSlwAXO+2SxBpOYnJSi0aFABVjtPaOxh4n/W
r+0t9/Hu17odpu+ZHIp8Sj32UFot5ER20aRkvbzPOXfe4wEGNEHJCex6wD1T
+KKb0iZpxxab/ng33FZKMb7ZtjbohjopzYvjYK2FBQilPETascq3t2CLk4zj
sdCg0KhrHBMzjgxyPgSwgTLkg8Pvn3skdvp9SSkBc85e50z0L2MGE8XMaOB2
Uc+OP5ubDb9XYPCjpAsQ0fNnhN3o+bWBteCIaIHaD2Wa5rUPtrVlemkq8oFq
NEGSI6NtlTnwLhHEex7yFitGEOkxzLTgq49OZfIqFXPrMfbIeVqLnmL5JLyc
ihZHUACcV2khCnq/T+wFGSKuPIqsJDa16WpOYF9g+NOIhFJPBrLCHoj4wlg9
szqWNGgi/3b2rn5V5ROOtvKm91RXsAIP6i5SYQIEcU4edHKdeX/6bJmh3VMS
sD0RBmeOYLJHgfc2PAoMvL3aWsVNf50MWsfi2SBJSsOwU5+1X89hYM8CFIFF
lvBpLCSNEFDN4xiF9VyzARVZ0lBQvhQ/1kn5rmJQAdNB6iV/+Y46zEL6A5g7
7SRQSOyhovjKImtIg87jgvydkH6sDNUactR0bHgXLGDgwwKb/vPzp6Ypga7y
8XNnlcixJNB1M4Nx9uVstiUEfmCJhMXQwh3qlRW9e8HwUXLIV7qQ9lfI8+w6
VYH6PgaNBPuu5MLeKz14ClfG7hFV7Ej2Nwfm5hklCgfsDM4xGEZgHBzSED3K
+XN4D/Sb47OYJ/3ap848PAJmpp8AAQWfeHP1i1T+PMpGYQIjmsCBVD3xkYFI
ktSAxgCSynny/nW3iNRI8edzLotW61F07TdG4GcyJ9pplctnfbm4jvYixgjp
T89DdnyI7b64jVDOwYo0qvkhbVPcRsw8gJOTuTH5t8Vf58Wf4Htkpjbszab0
m1TqhVveStgx+uaNI/KH9eyHBsAZdKyHhMkedcRCv3/4MujkZXAS8rS6CKH8
7ZtH7NokMxfRzgV9lnMV4gwZMaj4T5gG4+I0GYGCZZOJnYc5Nig4LamCBD93
Wz57iz5blKBuLbCJE3vmIickcme4x+h6wNdpKpIyh2Ez/PmE9BkxHuus2UrL
kipDvsPlszdGN8k+NDVqqPe7NowxYXCSEIk9VDLh23xGlPwTr1rQdwktx2t9
ehO1FvAR3UcWQz1jqDojllLPvRdS8PrmTi0q6fBw1qt87g0Hz0FdnpbAZ9Li
IBmhZ98H0VT7FFwVfTxtyFeeB6zUaNR0k/8smsNVdgkfSJ64Eq0qFvEYiVdG
jJM7mQwOx7fH1weT1sznzykHr/UFxJgWBuPFluYC98w7/tBuXzrcEppAUOZ8
oNtM4Bg4EfCbOSho0ypliRDSmCjY0//hJ+cE2HDSlOgjay1VuyVhohooQmlV
pef8NZ91CeqA7yXW0GPyuXbsHajFh1dbMisCnwkunsT+fWgrIKWq0rfQwiWl
lLCbrb0vGqcIY5DWLwWk08yAaLQKxgIZ28w42sNonwPEVLTu0AAFA4Yo8law
yLQaUraYzxtB9NEeLoNzpNvngwBkUhgQSxom+iKcHn5qolcf3Y/kPAwzJL8E
l54l4gQj731t2gkZZ4dc6AGSr7eA6OwH8nlBDaNiptePj58eIzwCRVZ4JSCb
87RIR7PotwcERS1nFK2BYg0dKGDOzTmSQIgWDDx99jLsJUyVvWBogaPrJh5W
jniDhYzETXlILqwga86SNGXT6hHTN/A+24MWaS5ZCkTnYyGtABIP+v4AnSCD
CYXckzUQ13q7BrthBTausnk4oMmAUIThOSprP28fz64zYV2QD8QfBmN9fuKB
eD7wmmf+ZqIAq9L08CrvpPK4sCfhkWD80pVmU9lCFdfKhGjjesifPelE/kzS
rddpn30DQb0Uk7NsOk/fT4aUni54EBTlVii+hA0hizcVpp2HI2kFNpPkH//4
h0vMf3+LfkqSAX96cJQMrlWEDXQNfkRWfW0w7H92JLlD8M7fksG2yvHldFqX
q22TDZK/970Gai4+vutv8ZAS24MfXg+mq7R4h+3G8gXGbgdvesZv0tU7WgCM
VF+rwfDI5vDv/NogevLv0Yb87YjO8JsBJjQP/u78ZZn4jZ3o5TPeuizkf12p
md1TGXoqDWP15SNudoeo7ufEeudGafV95ihAFI6fbx5vCRDDpK6XkwMMLCI2
PJUVW5bKmXoRBgG+r8UjZ9Te0syi3i64loLEz0T3fMKz8N82J4xziA9IZuV/
tLOTZOL+GfYYpPj4Iy+g8LLy19vaSFNuRoyv0oYE57LItFFBjf/Z2LQJYoic
VWh9g8zQqoySYcRQYFucqjyaJa8EyAu2UapgxSknWk4tzEhXottkec+x7hfL
iB7+ITPQnQxxWFl+rSHYx17y47wmW/TO6GnLIGeEeMasWLMQxB6chDtL3Hsy
4KIeuIUTvWKUfbtaqWKBeqFE8iMFUINunM+e2VUQrHlnmQLnZPIE2DdBUzd7
CJTXv3dDCb2gFXcu13TIwKf4X9+2+o9pJjVsJxjnup3RR//4gzNf6hyc8LuJ
vM+C3DYVO2NHht1xDKlINomk80g2fxJ9TT3KKBIJQYSS9FBEHcnTo2RCPFbr
JPwXyJmzkYAOnjyZsf4yetY6rcqzWv3jYLsH9TElyFZQROcYJUSHzlSakyy2
qxWl9fhRIu8LK4HbimrU+P1xmC5Lgt75YjnfPJow1uXh4/5DYlNrjeKrx8Od
YSvBacT3lbnSgs/5LCqPi8oTqxESahfrMj1bWEWv1skE45VHSCt69OxT8Uuy
ZFvT+FQJMNv4UCw5hq9J+FwGwQagjPQb91A189xP359zuQLRn5z80LpbWDFg
IHG9FAyqmIefehHpwL6mSW9IuIqYfzkMHZCV1WEeAlYpok9AcCLblIsUwnaD
IvwmWsxG00LQMAMuFOZdGbMO/7MuQRpmtq0bhOD1CpqpyQoz51xNvbRGHHs5
7Rli4msGzLYZy0fG2KFra6THaNokveStj9O1rfUeLbzH/og7BNmng5dCfTR5
3aoaP667UgMFmIWo2ZEz5bQ1GzYjWsFCGDG4gz7McDyUrEJYs1wQ5edJgsja
FVpWPaJ8QFRKPZo6XxIwOiQVjzeDIaE13k1h+YqNPfGuGIcT2PtiqE8GUlEx
Wi/SAfG5CGREpW+rjJWLelLX7toDauqTR8ea0Mylt4xRxXvIDva8kpbJY51D
vNhLTSOqTuBCEcpSpap18qwWoU3DyJ+OpGoaze0Xjd600FQE77TTnKChZk+1
ZB8/FLfWREei9FZ9uRe0EDdwWRbk/Z6WW+SyCnOX+kJyoiua6QeFWOS9oool
0JU+bpcct+C6d+vG4ZvdaAQYOAsGQCsa6Liw0BdJSb2VBlWMsEEWzeW9fOM8
wDmqejvCfu2gny5X8lZ7VutbqHC6jjd0gyGAxmwcnMcA0746M0akoyQZj/et
65bKRa7rkH5+ISHFBO3tCJvTKp0rAjrOmW4kN10HNoamteY5aBXAgSbnIiXr
NhSW51zu6IFq5itif0W746vSlICEUuBLaJBR+mnP4yMYYXby5b6sSb6cbesS
ybfdhb5s19lmcpflSC7xoOT7S7TYSPF29yTU/HotGXmnN2Q3WdXjvjHl/8Yh
KvnohBCMuTdSLIdbOmHRVHujSfD1jYCrsA0e8K1dws0/oJ4jzsL3/Rz6Fyzi
DR3O3di2h5th7IqQ6YTQJVSL//yx4+5Q9aXFmk50u27LtDXoKiP4wMjzsK4M
Uwkmt07jgyqtukP0UghGETS1ySUhuQleCgys9plSVfYbYRSM7VcuI5TOfOQ/
qpbey/4j1L4gshYc4leZgFqLmnAnRjzMS0nEZjk/6ZnqJJRGRIIYq/bQleyJ
uJuHoztC10n2hNKvY9EoMoJNRqwT0BMXtQkrGj1ZUEZHe4ZG8UEdgmnv9X3c
DcRVAZ0Qd2a0IMCvRDOdxsTQfeibo3pSgtK/E1xcudlkqVaM+Ks//nJst+f1
m4l0K7EyWchzmrMSIFhcgdtUyUTvJQ6gxdP4+/bgeW0a4aI83nNrYf30/ZFC
co8sDz9QOtUUESJOggG0haVA2JT0j0I4lWYsrH09fu4SgxiAQ/mkCxpLMRE/
eTg6DBYcNGAoOCIKof4ZlHKqBzaPsCUT3cWAtS7bLaA9+5k8I63wKE3EZXu6
oBgzGpUScr5RDslZNmWMGLL4cIks9BWlOy7xI1YAHAeYoi/9ASVxoNyD40kk
4SgM+aBcg9TAP1ShX+B+L7/cJaMThWukvDwk6gG94XqADVHbeZNlTVHNpU+7
ePXfWmUp0g7h8YLdzczB6cvXKFlkvFluxP89yzGjZ53Vy2u8JQMi9KD+qbFc
tLQBL3oYZFTdKyOFx53s+5RL5ACkWur3/Pa7svzz9mb+vlxW99J/iTf5m74O
uZYqRPVskwJRgaaredAQr80GnUF9Z3HuXKykEFTn3pQ54TX4ZbokKIo5UYKU
MpuXoMlXmH+o2rK0VjBN3QL2Elosw0h0576zNZcnW1TPr42oV0wkCwoocfod
xOqMz4Q1e2uzGIptJZbG9Cp6i6+w6/Tp7cKM9SWdkEnsVbUdaSexnrI/qeAa
0sqgRT+RJdhDRc0ya9mdiZQPkKOr7ZEwNullLNKm1T5NHkfEx1run1H502TC
ebknGQiXZsLSn9QN0HFHKyzUB+YJT1Q8Z6KtvUypz4JvnbNL9p70pXdfhqfU
6h1mLMLEFFvEWtP2QFYbJHYrCHoDdovRF/PTYCAP0CnpIggRlkEexVn0kdrD
zkoSo/I99koE3J6OQ2RD6d9ciiswflJWjkpTUFHHzuf0fWf9+OTPwGp23SDn
nhvms9tQp/XPTfECpl6QZ6g+cmm381vLHzDRq9w9YUnzJW+3ZYRR0q9nnsYP
4IyjUra65QyQChP32nMBUJCogfwmH/m8yQOfl8VpW8eMJMVzdO7ERAt3eUCQ
6WWnoEpwtUpo2uz6Fy7Tvfy8XkaOOGymiZV2WBe/WZXnglU3B2MxYCMWMyYc
yoGgQKursLBP/gpqBhqUGKChXLHj6PgMBN6uNXtZ02CN3BkX+fsCECzu5tY8
nCpwKdpoeTa/TE4YV8PkbhdgZcNLBAOJdJ0X28wWgAUUe9mIodhxYRixhwSD
sCVz+o5rKK31UECcgYFe0zWCaxEm+mm7x/dXclLCvdNgGQHie6Ci0LiJYh/G
U5aRI8RMgjLJvaa5LYRvRT1K+7ejK4T7NuTr1tvxgaLG17G3J2rswaJo7Wwn
diZXd3fTH1Wox961q0TRTWZt94YBN77LZqkmrb/eiZWKMQULa4x/G8nMRpIv
f+CNi9fyFje8ci1DLPKeHbS6zeyGQ3WXhEMVlr/IZOkCjUrKy0WIscznToRT
RNUtIARb1CJpV+8zkyEXxwX8Z0aPEcUSK3OBbeFwxFkG33IzhEFi/xvxIfKf
6CkOMY8wWcc8RWFYnQvGw67WMzhSzLTjDs1wP1vJNvY/1D+HbF8hAvhgJmCA
8xy9sgP9Csnw2zevv0n4D6p9YaKufW2VFafN0r8mCGCwZb9n2qnG3+JgzXFS
pLpepHGvOPhA1uVzUEwewSktC2ncAHQHS2NbOTxP6Rw/W6Fsj+7gaxceJV8E
aHHlWYKoQlQOvcFpzc0MgSLPa2EUjCGGle7+unF6ICZyAuXjXa0ywvOS6DQ7
sjhwTjMTLBb31fjG+AZuoFeMpHZcF9vO9fgrdvGSdk2Td+EBOYMQJEViw8ix
iE8iVIwdqZZAEcPXfybtAfb2eHWK9LFcY6wQdQqqZk/9bzFWSIc2eQC7NhEw
SHa4rLDPCPwW7iLuhdpPEnTwe3jkSPCswRwF20iaKmACPIbezyoCa2ii7Unu
jO+MD/32HB5ex2bgUoFJEQmCIzXexkWVnlKSq/KdcMz+KeepzZYQvddiLKHT
K3Xo1Ub4RLRhOjE8t1utc5P9iW/NJPE3nDxctfcZegh2NRF1fkMnYA4cR0zS
U1RIqbVeoOacKolBIFBiFAhPQyfI8VK3TDG/QA8wlBJReHjwA/41HHrQ2B7w
neZEroHzEWYKK48ePP7+4cnL0fFP37/5uj+eqzEitIBGN27fQTvi2C9Y+KWm
hAjKgdgQzD2xc128IebAJk16+s2AEs9jSrkxvtm5Rq+KVc5otS5cZGDq2coU
V6MJz/V68Fm8MNqMuUvKZhQkL3HYMe02mT0Trt/ByU4Cb1NwYcU0C6NRw3Zx
QDQeUQ1vyyny7JHQA9VKHMfCxgajU6r3JoloR9degM5snjCZ1rbokjBrlejJ
eClo8UR/DL2CBxYAL8dtjh4Ij1gE3nvFvNK1K4fCIukqT1dfO0oVvjxLYtHc
87xzlM+Ng4fCyF2MMNpGOjZkq1SGNoGPTaxw8qaV7B+OwQ+Z66dNmNHUSz3Y
W+/edDM8+HZSBcwv2dRgceJ8HoKdck5BLrNYkwUi00Owr9BU2BF0MKoG56Og
CIc50JW5e+cWXOjJw/mN27cP78Hdwt/evX7zxpuh8w8c4Fm+eHj/2ZMnD58+
ePjgokOvyM/hGY896wTkxZKQ2lNEpp6tUiMxhAMfyVnVFoZfNQRPUlRy2sPm
WmenAhJPLE7rZ0nKwrZHI5HOrIKw2mHWcndrF7Y2LzxXujm+Of4q4ktauHmW
nne1VoIAknROkGZINgbRIVC+E8zPiGaIewd66SMQdzUI1pbWgZ5LbYMrbS21
L5l6ZR3W9LM3A/MAw3SG1oeNwfZmBGpK0WzXyInQBKsyZ0gdn/7x2cnDIxqq
9CtJm1BuLwkwXtzVhP8uSKHEoMKZe9SwcL8jkqHgdXqK75cEPkKZj5IggA8q
MWGOwSxZgGjMbXNUoBnXJicPH8VGHQ6OeyRX4sdfTsz8JmiIS+DKs4Mnx/ej
LZQkSzf54QSl5tBXlmhG25HP/bCfL0qFfqIps++CqlOwJlITN2z02e8K7CXF
iDZgaPrgJDq1nTSZq8l7qXoNbUDPBUGiMW7aZYsNpCvMdnVdEQC7OoxhhNMp
iFubc8wpQ+FLXEGcq7ZTq3UenPCeFRJjiQ+P3hl7pLpYLrMbYdief0O5/rX7
2Jsm6tLJ4+9JV3LCs4pS02oIUth/R+DXW+KEfSlyr4bJJFPuzOle+DSn/tMr
nnkPY37prAsh5l3kbjrL68xFulTMsci14meKGPtbj3+A2cdN3mzJlmFAFmpy
8otm4OIcw8tLuu8I2YKGAFX+ysX3eubQMO8+YlNDSEErSQXYaec593MsNmQb
jMXAbvZ13nCtDtPGGrNLsHOBsc8TYbqEOdfrEFBA1WBzwPGpaAlaBJ/PjulI
7owfgQjBYcZUiQ0YCdUlqdeUxRBJj5EGvut3wJybcgUmGUYfNWdsy71wYUac
wu8viBLKFbxOaldrkjaom74nwAMxaMT0Y43HN5r2EJKBqYU4tMsorCR4quiE
FtcBdzNR7wH6ylCbXGXyhxQN8ppaUTjz8jqv+e9KDQ1vl+Q5e8WZSqe5VW4/
HaSGxvKFkR9GP9SIgAPKRRVGTohsbzLHxTPbPmcPA40cKFY59FnvPmCjx8e8
qRLA6pUfbaxz/xTKPqdx3A7G7WsNUAr62USZ1qgfhSvc0urg7sDyuvurOrCP
ZRqFSSopgzHizJ4htzPB3qB6a2YNt/hRJK5Jy5+mwQxaT14DV0krD7NvDD0y
d+pxe9riZCYjivURHZ7lRlzYGQxUPD/0aJhFDSXc3qDcVd+X0qtN/FF7jjvF
6khAbGHLmMsb0zevgzNY7EZORZy7NjB/FKFRaNlMDEUPb6bNIBxGVEDokzJB
LZV4oqGmwmeJmEKxHhf2wThCqlEPs10EJ/VTZqeUrIEm8+F8RHJkab1v9QHh
sLRMANSNPJIK49t7+zomuchOZSSo0KhiZ7ZtpCyJQ5lazFRr52EGN+n5qkzn
Hsm1brjGRULqzE2AFYyBgnyHS0b94oT4YIX4sc4ysv5zCZFRV0ZM5Vaih6t4
mhcqqyqPz2H81A+0rWxCwCRidFCx0EwU6sQAnMBh7UxYJsuHsGc9DWyy6Pz3
Bj/6iMPEN7jvqLoDvNyVxERO02uqdAHHonqF6WiGsBWrVJSGPs0fCzrJriLv
+tu3ezKa3r5Nrk6oheM1zkubHEhJUqjG1Ixv+FL9Nf2tkxIgn6455+7zctDQ
Wf/6AXa7zBliEWOgwNDgtbn8dtSUFAWF3x6wYvF6Z/LL3l4cuDuMzKaRGr8f
f4tyL/7u96W9dgnMyc60iq/ifUle07cop0KjSfQVjSDBYl7rdDiwa57gXxwo
gMDrHbR74Xo7sS1DA+2WnbrodgPeaM1xJnx7ySb1KwTPNP2yc3QfsxAmMQPa
s4OwozibLqkvseWy54i7H9XqdIN5n3lGvJejwA4/cmmt6SugNXzm0hf4P2+B
7ot9OZYOGx1Is+pUAZZ7jsS2ZutpRRt1ohXWFuWatbfgikfG+T+07SzFJmLf
AQX2o66g+u9O6pHv14QCu6m2vkNOVMTRu9Okd1CA1O3fuB3g6i24QQXFNaJ0
V7I568yaBx26LLQmGGG/704IlywP16qv2r3mvbnwzidvfWQmvLeDEUAF0woT
zStEZNzZuaBbjtgRJW99zj5Ot73g0Gj5OLR8QkL93t0zHcrYhfYRO4laq2lA
X/OtdukuJEjx37G5WpxHNKpJEQi+6DigJgn99izGrr1fdt2txJ599OcC/fWv
DxFRCTR+P7m8L1dbuP6YHzvuBZ402Rue/XH5O3u+DJYKQga30Y48Es4wAlbx
+nf/Rrh4IzpNEnyCGcgFbaxJDXwEnZS9psACJhabSjIXPLCPeOcUY6RzPfQu
daqn2jj2nuNEn6snXObjgr2i6LtACZX3XnDVlHVfRJMe8nMuzFsHDgmS9FZ7
Xa3Sr3riYkir0GCU/o7TD4XSpj6a4nfoEnf2rINjgh3VuqguEtFzNqVsAPsT
gIgQSHJHIpuA+NUXXAQssXBKvKHVHQNxcbsqAYuJiLqNS+vqnRcWg83c0UKD
t3W9XfvWd76uTlE+23JO72ptqnY8Yk13bexNviSflAZLLdboppJfJsAWIgyi
mq3ODTXp1a490XGcbD3Vboxei8AR5WPi0CKQC0oDF97YxW3Fbdb0a7LupYqM
Csy81PKcrr15SpR2r8nd06UVPl2cIVrbHuDThzIpWIDJ7IJkWKWstpALn59z
vpGblhNpuJuQ9gga/XcGke4pEmWHKeuctu9cbToV28AvF0Bk5F6OnNAYp4vb
QsKVHD1+/iYGeQxAfnwzEAbep/RLHZw2wBYvB9WswGIJnoydEIo1eJaivoEA
msz4xaIRmYCXTlPI1f3m+9tRjxcEDZIt1+4VDP6tpc0iaJAQOFmZ03SpO2iU
WT+4fTif3bw+n89ufXVzfutmeuf64WF2L5tO0zuz9KuvrncbVg3sZkSQfjDw
U9Pt1S/oKjIPOndy5B/EM1A2Pm4+NANTQCGqMicP2K1WOAf794/7pLbYJlcv
Asyg/nsS9Z6m96/Chv96/OQnLjtdp82BB6XEtwjsEQ2oJRW+RBujZ/14Hs89
BV1cXORNGTudGe0trEH9dUo1yOpxHRFhMAA9FSSHF1GFyCrV1Li3JQox3zBa
y0i5mIkr7sPrQJKn27QCIpUuOKeYi+4jlhzJjHb0q9n1u7du3Lgzmt9LD0dA
QXdG0wX8OMtm12f3bt6YZdcP7e4AMUeQm3tuEDYagsfr1i2JD/TOzdt3p18d
3r1+a75I76bT63fuzRbXb2fzw+n1bH4jvYCKpazwUvMRPFh7gaWstn9qt298
NZ3fnt6e37l7L7sxu3kjze59dWt258aNe4vFV3dv90/NXwLaqQfcf/Rp67LJ
r6MWy7yzresQTehBvs5hiOgrvAEf8ZldW7H7sz+WyyJ5UGaDDi9FZcx+TxRB
NlNCsiiDKuKdFsTHYR8GQMYQzlhZZECqJ55pT6KDJanAmlm7mwASHpY81CHC
xxy93zIRWClm9vAMN/AQ73nXXYVNbBsDISqaEOEA2eQQ6gDkdgLr9IJYKrTO
x2iOX9uEmCELwSc/nbwxn2Z2OVhk+trA2C1i5rSWL4V/9QabUvtwq+ney+xs
lzVFAR9KnrFqe49RFPzcxp7WFgw7jJy2tUQr1RbWFPzAgFmcttRjXPjwezNb
8kza1g0r/Homn+5aJ++ivzn2I/byxLBVV1ltZyFocHQDhu54PD7wOqV9nwhf
X9xRrGB1eswEgsXzGxPJluPII+OQxi2dagyAr1d5kamQk3iXSzr9qQwm04tw
Dwz4bnxKfZC7FuH1E8wqwyrBkMilp8BV0kJBuxAqNn+i/GulQArtsSzGJrXU
5gg3C2jn1cv7/Cx3qHlV5B+SbFPOlnwmkjOiKBveUFp6xsJX0FtZNIWMcfZY
qNXBwNvyQTUSqF3p/WRPmOyXd2ZSQSGHNWfl5pxVBYRER/Q+j4qOHYkxFuDB
uYkRgJmL8S+C+WUUdcwylhJkCmxTqS3vlfbFsZsc0kYVH85qfuR+FTOdTFTz
fNSMwrIA2lHc9f17GnZCMqplbAp9P6JKMf8b/6wYHHCjsNghShvNa7FrA6ZB
uW349LFhmSbtIYQur8i6LxnhpHPrjVaJMAqqBYb2Nxp4xUIWSv9ZUcpLZVQU
MyzX3ERDFt3B7C7zGzx8zUqi/DXaw4DEiBH00eZ0Mxj3XGIaZ8dFNhnEJ/TR
XhC5j4VrNov/G6/lGW3+3y0eYYA3hxNV1FqcGCnM9F2tVmqV/EsxWc/G4W4x
GuEjIU7amdPN6cAPlvuyLBpUsWkXMHpWbeCImi7YXY0Ttvhu0dPlQoqoiNea
Mtx9h9czzTVC+F0wzVm+WUbKdHsLQmpOz9edAgmqMUJ+AS6muXv9Tcj4G98c
t+wtATQO/KLDJiTjeSaQgHXXqakKSR82N8XkCcjEg2UHWF86deR0aJBTSImx
csf+DfFPlcF7RDDAZ+xD0VCV4msh8PLO8duwm1w3kOYkIlmv7CBAevSxdD4P
V4yT7FqS1e/lfhEbUB1dgLMPOcjcU0QPcoT6CMfy+J/6EcLL8H7Eep9n9LM0
XEYJ4jYwXqMPyF21urOJk2tH9SVmYDP2bUmKLNLPueXWR14uYZ+Zk4yvkHir
ObNLRJ41n/S7Qwmjb7ZN9HvPQCjvm4dhCG8PGTYOH77xn/thnzBpBhOtwV4b
mczN3ZOZkAkgfnf5sks++tu7vnwo4VP6tEdW43HgvN7OUbNBW3H+tg+9Ag8c
W65vsXcHbx6XRkkmC80gO0PJ7ZvMeNQ2D+JEUV3rcwlwLPAmtw2X1pZzWShd
QfjTb2XlO6powRUQHM6Vs4iY+ijrKMrq8xtIXWrUTRPI1rAQE5KPTkebH5ID
PmvMadFWLfQn31JnGAkbc5k1eCwb+mGTaUXINPO7BDMqJcuxFCro29ROFbxw
N0wAH3abF1Bvm+iDzqC8MtkR6vImQMNMs7hFUEkeOrRkAjafJLkRsG4UUSGh
8v5wfN11MYnJygio7L5GQLAjAmR8aJfeptBf0go1iiNt7eo/gbZ1vdQ2oukZ
8yoYBOZy+K8uiRC6tLyRGsb4raIYn95HSlXkZdg3bQMU/+bYdm7UG4tb44fm
LEmvE4yCWs+E2N8tpPaI1dRzZKE9IFEbmGZIKqfkkfRsTeSn11Y6BhMQW0rd
r+gSwIm+vsLvXCGAwQ4S+QhNd/y75PGvtPJVG5b0mgje8qExFpSBShMzGQMe
NwPxzQSsXCGpJyjVmw8f801WlyOLKzKyeCuK0hqk4d56g4iGoRzLnPO3qRUE
gcScFzNUzkbSj5ygzlATY3DwMOpcMb8J7UaLUbAoBmiWImYEVsG4wAG0TdYm
XgTycjC0N82N7dbthsKnBGjj1Wq7ytifANPjmZDJKlARdBF7ezRKNWSYC85T
2xvz/uL9rOYj7jWt3bMoqJfNthKGim3bXhxjr6FuDZQYfeFYAcANf271hvDg
X49D7S53SGBUhIBzjxogueBevXr8gLaG64VJ32GBSU0jOA46D2014V50GskF
QCofZhBNPZqq2Hg0CCa/hoCutHUYihnLSVMYD0SZw30xMHdGyEuxpoz7KDTH
aJaMok2zxo1QwCuipRIMdAaBoNA70xCWx3A8MicknZJYasDd96uSTjtI+4It
L80Qmd7yym83Z58R50kJqKJtQZt4bvuUJRfIIL3v2EhfUcf0F8FtASFQn4X3
SKwg9t5JqT0saFWe1gwwnYSEHUa35AYE52HCnhVvQvvaXlZMoyHt2QdbHJgW
ne1kpSmCYHADA/xhxPn7vO5AF3MgOhKv5F9CT5PnjISw4MfgvJqh1HoOpQyS
4K6ogbm/6S8i+3UkXlszlxE7zXa/ZfYpyhDbu1HRk55t8x7xuSy2qwWmWIg8
6iGBHXvZm+EUZR8YgcGDe2Q3769oI7yxISklGYyBp+mXdI36GkFfqdup1QFN
fSw7kcfRjLw3W8Fk/fHFvyAno5Os5hPxpPeA+MtM2UcnIeOiXDsZx0Mqj6Pt
R3G4XqStfUcrc7tmEQQrfvLoeGRaXqirZ9emhFPzQd7uxgQk/gggNyZThKiJ
/NGKlvC7t5hCzlnJBWgstcjk9ZjmQDikdBOsWC7mMgzgtRQlWmw+tk8TpISS
jiZ4GWEo2u6IFCXSS97n2ZmuohUkb/N9jjupsztte1eiJpKWLmmESDUgmaty
4mJ5JrqHCFvjcu0PqDT2C9LSnUVgS6TxsnoFGflvuDQyJQNynhm+QlJNnpJd
oA7LFwg4r4Z1ZZw0CerX3H8oz3q1OxpPa/Z01XFLINxt34FIMb9DKTlTJTaC
2cEdpXnQDv25vEQLoXYDoWSGSYG+CYEWkO3sK6TO1W53oUt2FTI9hXYu48LO
Qp/cVyg01unpKtRN/9Kj4VSzVOjCWio663nOzQt781Tbfd1Mq2vbh8sQ4B+q
s1iwAqYuVdc6BIb8x6sPAXXA3ixYEz7FOs66nAflo6MHSeWqaD0yHApjM94O
FYjIKsM+PBjLYfVl15sfp/SIjKKiOSYF4poZLfRM0/w0E5YQW9NknaH8zOu1
mL0jaUbXOrZ/ugrVGYq5rLqLQi+BpF8RkMpZzVeI2x0pL8sVk1xjsOImGsod
aEG7krXofXNhSIHBTRiQg0OMIQ8jF8Tx1HdTI0Pbf56TJeXLPEzNb2AXQ4k5
k+Mn/qLFrFIGYqfM+hW9aH7NvDkGvNuzix9tIcXNT42PR2mbjKBTaudhb6FM
n70um80wYtpCN9LX3SvFueKPpSHsdKGuG/zLvicBfaxAjoN+PD6ColvRpPxC
NHFqlOjDiRV1aSdGTCaf6N/v2CuZcqu2KAjAy38runKIgnpl45geeHP1Cx9/
4VcOFKwvAkyJewJTrJrtbZm15B5H1S8XWpjw93YmGZ71crtOi5FvsG19+i1l
bWhN5pxCp5Xo6KCfL9IZgU9kBWdxVd6bDEdLWmJ3Po9Bvv9gwbiV/rhZhO2M
R9YoAf9JJs2Tx08e0j8PmDNp0nDdYgN8AZfUZXtT5WsGVccpFwJFlKJr3jOF
uJdb7XPHazBtqYAGJw7ysMJaQlIBV0k+60lukKRWGmYuKXtr0MrJRxWd3JTz
pytgZYr1nDVwM6aUMivmIzq56DeCDshNI32iSSGpoYEKJrRbnPTEWJN0p9jH
p7slrijcFq2VMh5csiXv3rz7Jj65MHCP+OAjLEI6Vji02pxafaAkRrw0NC1j
FAJjp3GbCCJqc/6YxZUrfg+ORKHHJ/QATk14EMcng3dRWJDYI0SbRAFLpEI8
wVePCbSg3DZKAlonragr2P3mtMAoi4Rjc3MMZGhQayGPHsgc2VA7VUXktaFY
DjnUdkd8r02BOROLqggkJm0kifaWVB0YjmuXIYhR7P+34wHeXuqNCXTjAUP2
sqPWBpuzqC8bBihNCpX5GgcdlCZZuqB5QOPPNnvd3GJw/me7uV9SmsEqNCBt
tbzEpqL4P7ON3yLDiPmkkPWjpPgWbe7x4q/zgpqWXtNtuIbW68R24fSvTJQn
xjZd2yCyaDK2G4byOUrwNIctG6r1s7w0pKKo4Wk7IolwYGwRr0B80Sl1MzmO
+t1XggK0oRYdxvu/t+fN9Nw3G+ZCVTo4/iaNAd/z9YCKAhAKmASE+feWwmWc
pVgko3gHUhm5Zzr6pO1HqgXY/BdCvcgL/7P3Q+4dld2Wn1r6LV+S2m93nNy4
fhh+Ddy12dZcO3PZqWBqpAuALRzx4KKstM5UQZUPUHm5zaSSAnN3QYG5KS/3
YN2iySx8U/NwM4+QnQnZmkx/7WL8wpD03GT8x1qUHYRbSyDEU98YIcvsqjYl
f2l7bBtkoWZbFdZzaypM6WcwNUrf/1gKE+FASbqM4bhuXb++47io+5WBZBKc
Gk5NwuSFXDB2cJC9Z843Q4rskGytlxdjNimjvpNOTUyUB7158aDaU0fvGnEK
jnY4bV98nNzeOT+pBAtMw5ZdSvje6R6aUjkaephYNVKEbSxj6JcO/2oGRNc2
Tmr3+qIkfV5mk63hXVT9tkULrr4HM4bZSZcPogjjJ+gDcWnowoDiuXAvQB+f
4wExf8HX+sEvEur0yQZof+m9Sy7X/URkWLcaGwYop3jNLdLso788eNqqWCHi
8PlLAa+AAzQCXd8nyi4zO1xbTl0QuxO0iF6+5cpld+3C55CG+P5xHv6nYP8g
1n9R+gvnce9Ycw+7K4Tc3lz4zN7tpc0des/ajrYzfVtHq2eEuQiJL7kUEp+L
2oR40LvP26ceCiFbgHsEZvOdjxBP0v5/nee4Rkoe04PoFG7wUwSVhnC9znfe
Rf4dEuJB+7pmVBD/ZqxdRW1MvNnZ88Ertdc1p2X5Tnehw0kIk47UdArINwLG
iMWgknGFFHSVGQoqs1Y4gVTTpNiu38pXwH3J6I6IBLQCDTQDFaxeokPW8Efh
siJbgtawOufoBw9tOg/pjHbMR3Sy+AxilJ7HJpi2Q5ORoxVO23O4znQaO5fu
Pb6Wtf35TQqb8x77LWAMaq4BKMczQHcHSmqET/tAqwi2L/XqDCOvE86jIrhD
3g6EnNWOsJQaDQZFJBSkImUNAkdxDRnFA7EhMImOXIp908bfcR6g5mxsmgAy
SCsQJyt+Yz43khTEeYllKAS5EYDuke8wTfgylXTluhAppCwuKVpHSAjui1aH
ecbH81mTPmMnD0n9/A1eBKkIbOSlU8Q1TBPBJmAQxxI2r6ImYlpLDpPlqnNU
c7BNUgh+eZqlxB29/SdBg6AbL50xDwiTNWqgRM4wLhql7YiPawc4lBPufBSh
Q8UgWv//BonqxyuwOxRVC4LSbnKhKJ1XxWPVKbPryf+P2AWX2bngA/u0MrtW
STZ36mzXkpA81wxpeo7cNz3loEJK3vdmi8OAhAQ81Sssay9eDeJ0pBpoErGv
gETuFOrqSLERjAoXVV4xUyDWoVp1R3et+WpGlXC9dZ6yD+oZi5V1ziruHVkl
MRdkxnWN3VLs1les34uFQxAoSfcTePVbn+jBRJBvmFozFBSnAXTddfDwNHmg
tbccLBPoWLAqyNqEt3vz/02zCQtYH8022kFTFeZZLooxzVkPUNkOPbiaY1H2
oNeEPFhjXhGPjC6UZp1HYGbG1GuVMwuiUwRvhFhAGMKTIMkqe5+SH/+JRjaj
D7LHHPOCNUufEotDzHJbUWqStJcIi+cXJb1J3nWImWzT1fGdHUXsPXyEvOvu
RXCnP9JCraI95SEmsWldl+TSt+aidoA/uVg7oJNVF03o4qmlHBQAw+zi/t0S
hzc1KCm1LyK72fy05CwF8LaNfIlb8wqTGpF1YZtS+x1ZCsV8UXWKfcKrrIUR
ghKb/dKx/ziAKFfUvISrMExVsvW3iUvR9SqGhJK8BtO9QiSxkPMbZugnwxNs
zcTPMJ44Z3XOE/GXv6fpsT+bJ+lsSU3bpT1bZSll9m43bFOjZEavNR5cyDdm
eC5OOu65Q3TVAr57+4axcOzw9JinysAGrkD2RyIRbHkvnE8jaDqfNe8q2kaH
1ymY4qQt3SctgX7kRsng5IfjFw/fHt+///D5y4cPFDiDlENm2viR0BORg58c
VwyvP3h4/6fHT1uvcy8R45Qjq1GIzbz86in9b/vlPtisKO0D9aO0DiTByOH6
EclyQ3MI7x6mLPkv3v/h+On3D98+f/jiyeOTE2Dpl/u0WnkmgyjsBvsPhVTH
7tG2Qnas5VTmJCZ9tdwtV636aL+0gU52mMSF2J5tcegcc4jIaNWnZdpRQDqh
RPFIo2JEo77q5r3FyzAyjWVyH9GvvB/qSMR6tyxdpTuH8XpDMTvkO6dCqHEi
HApH6edSNMVLZ7vvyhqzmdCchjT0WbFk9hJIjboxuj3ipKphB0VO2lBrOAty
uQS9O447TcwcJ/pI1MeJntJKLOtI56l8Bv6I9s7ChI3I6pLzFUN3wwGqAI1A
dIQ6pBZ3MEohW6ThKeniG/SNFvtNG2lODcyvjSFLMXLfPrbpneXQ4uqwfDwn
YKuuVkI5sfAj2S5GCbFdfjo4tuSrYMBTAvQAQi3f2biZMZuvZrBIcWOgQClJ
V6y4nEGvIZ3Uge9DwC6Q4GBqY6NIII4z8IhRvgipR3xb6PwGeG8fnrx8++Ih
keWgq1JFqeo73D60ovrdjgssLhAtOTMuBc75cCF/O+ojTbHothdm3IsRhCiE
IQyQ18FCI9+DuaUy6qbHY0ndZYLPBkUNtyogWtYEAz2C1GdVhmvIqCJ9bngS
glHzTAOZoBixmEYskZfSteZ6xPTog4aowWho+jy0FGZ1nJMjfD97+gpGmyXS
PM2as0zCa3Y71BjRNHj16emSFyziTN57vyfVB+4I79jRDU8voLVL6GCuVwfz
Z9SngQ09n2Fwo2HbLupXyJJLKWSudwIB8+ByioD7ZyoCvtnGH6IKBEr+v04Z
2APgKTPsgfwzd8UL4c5kQil2lUlOG2F4fqYOohXsSTvTyUxqj9IgJ5b8n6A0
dBiG+F4kQ47MWrE/z5aZ93HIdipbI/4sGeBsKsK3xLoDsStcsj9zxqGbZ049
ZlbnOrCRyUPSctlV0sfnKaNDzsFUn3GvQHVjTzoMbxIHXnqL6mCPjEVNZ+HH
0VEulNGpUxRPtYsDzN5QhXWquWjhb0ZaF3NeYK/OEglxLDWS4IBPCJLPqnqA
wkMQrnqzXz6F7YdSqiIhgiDP3A7m7zzzj63xuBufabvdx7bdJey3/zf4dhuR
dS8e6xmWYExD2UBWC3cKGKAWROoi3tvzqZ4kyzNsilyzaaFcQ7zqi84nPxfi
uDvpWKAd94izRStvpjUPCtgcXbvW+do1qu67hu4qxEDWFOzDGzdv3b7z1d17
19PpbJ4tWjv5x4kTOUGknf+bZEqXlZEncFmW7MX0pUJR9EaBZ5AVo5OQDIFk
U64QrbA+8m19mVOpMigY/mysUKjoxvVD5eZo+PquywidsazKghklMl0kCyNH
NHJJF27ithGmO99CKgWqw9dZurjP2LJw7V1giAyHS5eaXGxy4yK4jzApsLVk
Xi6aF6WVouhreQl7nRvhzJw1mzGIJl5pjjL7oKrg7nPKjT8mb5+4jKF70Ken
vE92tm09tY9SSocuELVinUY1GHHWKCXHaWic/nTr+i0K2H9hhDHiesAt2eve
N05Zram0ctp4Wl1gjzbS7tHmDyKnqU8ywxguMUs2fon2CH5DRZpRqU23wYAo
TyEl34I3WWUL9u7X5zDems44bQzvRrgr8pBN0fbsJBbIEchapSbDHDk1WvRq
tnaaDYFKYknIbUBKvoyEBnLCbTtahHtNj1Ql+6p4gxLp5qvv7tquRLbLhHlQ
6xRnkc/UdAKYSHl0HC6Lp2H6L3ImPDXInkeQYR0NqKO2tPUaBuBR7pKSf0ln
RZvFNRNCEyGZg+O0eK4TIp3Jx8YWXp08fAHq7pNnP/dGFmLwbA8bq7RJsm6d
Vu+4Dsm4ZsiV//2LZ6+e7x1dB6LJ/9/mko9bRHyEYueSHkWpNNByY491iOAN
dMaBBRps2dZkYiVnJwS+/VJcgdLhW4Jex/LETEmJbf+c6Kl4Ul1YWmmw8VGT
wnyqVrEk9a7rheXpdXlpTZcvE0ZDcOg6sX/KCyovzrfTW+dVJSm8temFIkXJ
zTaXfFo0iYmA0RQ57FSece+bBtHHvI9DVkBpNH6TNCOWt04TXZsw2Nw6u0Jb
Oa8SvvbpsKCMIFhsuslHvqb/IGSopYIVIDmaRxQkJqXy33gOI8IKTpvlnyaJ
lAxG7LB+ff3N2Bc0j1XJ5MbjErFR0xiZMze2lmyAsbvB+lbof6NlQgEQr+ns
YV6gdhtqhcPbf9N/YTXF331PKEygDt2ffHFqhJVIt1hS70R/nDUxOCKqPXUG
TKbJZ/U4wPFqbgGXNqXsOKlaXX0UFNGgngQQNl4ctW/QTdtKd6aYKwI33nCq
g8ortgzG7qaid7Q+Ora15EFqyB5m8yN4E0j18YIRrLSbU18Ved9ZcGYgTVrx
i/pqrW0uYOxx+V//43/ymtsV3sPEdG2SiFtraRGIEg/CpdrcAaFellUzWtF9
sQBew5ACytloaWOrvWWMfmCw5Co2Y8XfvPZ153DHfOu8A9kKTlwJcP77gaMo
VibhEHF+8zhKIwGPwx8c3l0kh+Rwb99GHqfTvLGL4hSfLUXQsEbEIEHzvvgj
SWuGFxxKBYNU99tGjBHxys4QBYub1gQq4MV8hWR8YwcxKujTLhlA3LWot5XO
ttuvjxOJl2nNSnBcN0T78uTRMSnWMClYug5ksKUinEPM4uIEQ8wwysiobOe+
uVvj/ntJuANxBRam40R3E8fKsYKLbpggMBLozO67KFm6L549f/T46QN/EdNT
LH6gJXF+5G6kw6GxKxiYX2CqUjx/SsynYYL0n/xbPv/TpA/qcOcMcYTOJJvy
iItk0DmjEgjrTP/UEUfX6JM0D3Mk7dLIPgTHeEqYDe/opiWTYyn7klZnzBMm
kmMs3Q1C1l+XvTh/SXzdCzaZwEuKTLZFGlru5SIR1sfaWJyO3e2xxdzN++Wm
yppo98XHL5TlfAqDvh4AdoUgj+Lh5e9djpt7uGVB3+j77F7C5AJac+rmE386
+nY/FUxsKgAvK/e4QOsMjhPmhYlnyO+T79I6n1FZ8LA3C5UhoV2SeFPGokJj
1qaozLhIrbJnFp8qfIcvS4yuyFycA2pR9+w8VcDIXrKzvNBzau+nLbnzSBdS
Sjl2d8YdzWSnVsK9Bnu0Et4Eq5i0lZLWNTKwYgrExCfrTZXpOaEaUK5/uwcj
MUNOpvcOF0bdYAPCq8YEliHSlYyX9kgBvEzjwPwLuuNajmfSS3gRVy6NgcXy
nPLXzUywthyBq/q2BrvrNN4HizuOw0gpS4qnvq09QIGBTPGqg26EbgwX0QvW
Wo/gJgJ7K1Bs6E1425SbSUeXxUEYw0QOT3wi6NjrwmYYxbvDsHDfIzVTBNde
EY6j7JPiFwtwOtKLZPiF4ltodLcE79sJjGByNkcfA+92Fc0D6l0E/yKtUPPG
XBbTXRQEdhZgrPaAKOWNAU/6DOykeYbyrAqMJ0ZDCqqxveeEXmqBloSl915y
X2LDQ3F9qzLaFrgSjRLjK0UeP0EW7nuLmy/N38qZvoV/U8D5LU6Cj/Ti5wSW
ykNPFh59UkBa4TxZMSuaqqRA+K5+WXHelLSTpUI9BiXMWqfv4ZOQZEI1filV
7Ry/4MljaX1wVvbdKizGhecaLLs1UOispOC+YwyeD+RrQS/uUnkLpir0Yffo
WBaPubVUKbKcl7Zu3a+jyngGBl9HSmf4XAOiErr4Nbtxtsyz93rpU1Lny1G9
naJbVsyNH14++YnpQ6p9mYOaDEZhroIgS7Ak+GLEEcWvrxCPRGVDz2GHgcVi
OCyG07apb+2eogaE1AurblN6LjiNKv085ihagDyobw4XqqEIXNRxWVw/cPZP
nA3At+gM+GJvP2ptBq6H5vPaYCAYo/ZI2ZdV3PH/X2tKDxiDgdYJuwE9O5KS
ShWvrBbVwV4kjxvKy7yutxyW6Nj6kodH5MkYSCgYd1xQyTbxlcNpqAmSNEkt
cX12/4nc5oC5iEe5Yu+H52/PUM9Mboyvuy9Ta1e8RV/Blxz45fQRMp9rxa2D
MVCgVRnFLMHyszhkkuEnLQwQVMYkE+q5ccJpvL567J6WrIfZ16nEgzleQjrN
+3JFLmsPJU3Bs5d0xRXbBZ2zyjuKiAvss8212rZTRNoPb41+oY7goqYqrJV5
Hc6hG9XXrijKmg2lKRXdGt8a30ClMeBksyDQiUR1XmSIJ5MPo7OzsxEezGhb
rbApzTybT4ipUOt0LCEvXIAAlm9KTsGRc//GZEQdwPG4vxngPRn8CbOgHh4l
V/77lYSCrWcVXFkK/MMyYILJ3a/u3XCOBGp7H3APrx2OD90PcMWwJ0krjcHZ
itkjC+R3rXc9/vkH+SmW9SLNj27cvvPN0d3Dd/eL1bPbr369tv73u69ONx++
+6X46+Hd73+9+cvy9x+LB789e/n+5P1v0+XZN0d+mJ+y4rRZHiV3rzsPjjB6
XGy2OHR+evjN1cG3bJ0NksG3zJRhOjn8JBB3oznNZJD8d2DH/pcrGndw8DUn
7c6/Ofzq5vW7h7dvXL/+NT5I2A3fDDxqrtmSL+Bvh4Ov09XpN4NsfuP27cN7
g6+bFH4CzjQI05QJHk2f3Kh/vpHeKp/c3fwyu/WXu9W9f5/enf7lq/TG+x8O
37249+Hl9fMfb24f3jp7dnv1853pv+MEDmfPb1RPb/71wa3mxe3lfdgSzuN6
Syff5QP/wuAGb2HWfZP+F3zmGxx4ff6WBS+95v7tWqCqP2kOBhOxEq94Y8Wo
KnbAgDhfs6z+Yz+jSTBf6/57bYHfJeKJ8obxEhBSg03fOVcOCz43fwTmPTG4
GgJzQhHsaJd8xwaNViLDD3pWGyqDOcKe2A5DJxK/5pQaLXynL/tCSmeAirQE
U3rfEePwCUaT7plODG8fOkGuCRhLrOBIAaIyVgXteqxhHj5LRkbN514/IC4i
Ho6NDz63BPbONJnrybM/c2iDpdOIPIo5Ttb053OtOKfsOLEgoOd//OMf7m94
Ka1iPjhKBncXN+c3sdP4AnuO35re+mp0L7uZje6lizuz6/Nb6fzudIA1uQN6
ha4EvvcdiWv+i2i0b3Mc8eb16+7v/L0jYZ2ICzD4OxN8yzLIa44GU1d3UQGA
dIiEwcalfShKln54wnVTbWfk2Hmfc+1ayJ/s091ZzfXIUIw12q1bixyrLVRN
Y3iZJBZHaH6kW4XOiZxJyX0LFSd2EnZHTRNtuc03h6cIty6jspfQ4Ja8ZBi4
Iz3b7BifLeqpZGlyBkm6zpKWbG4LoAAYtiFGDP9esNqeuda5LAlehqysoWQM
ot4uBRethyXfq3BkjRrAWT+xdVoUWmPzsKrgGurtqfuuj3jF+u6J5iAh5Jln
kLeA5kL+M4dKbO9KiypRBB0vyWgqxJs9k9DLAmSNf0Val+m8lRkOkh30/RyT
1KgkIgzMcb9JawjMs9VfMeueDJ3/DXEifGRbBEwzfY67eWwLDyP2NsiqCe9w
wAJ7SX216OKxvshJF2T6YqSUg+21OCbKIkoeD3jZYHbNGq4643977LO+q0fo
Qd5nhxiX73OqzWpwf8AicPYrreNlq5e8Usw3MT4nYduiLEb8fWe/3/Gc7P+6
rtG1ImORQxW1ZJErXIV9ms60986Y0wQUAqgtzPYFY+HPreB3b7y3Y1jq6B/R
9WWoR9VdpiZGcNmI5wGxkSuYST7a//FrNU7p7kpsw+1SbO19q/HFI/2d7tHp
EVKS0sbGaIfegb9zNtJWMoBZ+agdflKnxfH6/r3AvLJ9G/Ex/Xr2BXstRotH
aYkCv/Fx8832Ol8U6GWqpoFY5o1Eb9MeUwveyzAYpk5RcPQTd8EAkCWXPXmO
+csNjOZJo+hcze2V/OaOXQdPrVYwtYriv+yTwqwa+OgItcly28C5Z5oHdML3
x6cReXZ0hGEktlyPfTe1Lh6uWWR/lP/iM+cMeP+17/zXerV6A1yIsCX9dCZ9
K3ubNhwvGk5UJmMdR//uCud59B+pNnoawj5EWYF720PtZ34wje806yqkkfAk
Yvc8UOYxhoDiLVO2Q3D3TDvkoW03BujPFGF298yDgukU6Hjw8uDducT5O80D
+YPP37PN0A1mR9ZPXVJfCJTuabjivi51FwlQo9zvOOsr+DED49RkA8EtMekm
nUyT3uNhRi4loz3cZXdKiuFWMSEwW/7JMAiuvPLpPSPaZ2xEkmVVdHifwI/G
3fPgF3uvG53Ddwkl0fMcykWyLMGYzAVsGH14xbTcFpIeWIfUS8Gcy9ARCLdC
hNhxHxF0pQUNc8yw9AE3L+KjRKDfhUe2dXahTGATWn3YLAuO6/M1mN2wlqQq
sRWkKF3RVutF6GNIu1kM7V/e9KuF7EvmzQszlp4WGFzbwSyVzI89mdNzIlFb
5bNnGLMPJz6UTeuewb5FHHM7YJCOOy/ed6SEaALBLnEuCUG9jA82w14aGiZW
XJEgkKZY5dMC+14qxJQgaclbN1gFRHVB7GTnQUfayhmJetuYlzks0ANc58jM
Sh6CYo3UseHUDIRkx3AVzr2ccXcvgb0Y4OP/Df4beBe9w18V2/XUQp1p3M2D
BTJallQncI5eNma3+C/YqvXPVD+BYTr1Cfnk27byIDa75lP1YHDFI9YDFyD8
gu8AjxPJja827sPdO4e33xyAsoHTqLeLRf7hyB3BFqydu8/H7WOUFf7l8cOX
j5w7kfQQaSAsK75aH+Ajul/J1Wg/DuA1ApfGZ7CWKi0wW9G9EKAOA+uHTzy9
dkxb9eMJ+obRUOQWEwrl0dGvClzsvi1qjXTZLbp3+/ZN2iKqwMD8YNkhyarH
yJ30hXmFLlL8K5DlGiFaT3JEYvqZ+8HjH7A/t3tVADXb39JaZbvv92z3i4zg
VBir8wHVI2x0n459lUEbnBLDG6nvaYC7FbsiUMdEWPiBPDRIrp5Qhv7Q65sH
R/QejrTI6Aplcw/LK3akwLUNMET0rYZTBpIz5MMrOasfivrIiYA4sBeMtS81
gClJ/QhM6buyRFywoS/XgDn9Ira7sAnJ8ck9YjBzry5+q0JaoXeC2ogcIbeq
BR5/wHqF2QbzSW6NGD7B4Mc1dtfBklbpEYopvobOHgKPSH6muspBwNSkHOOo
LlO+D4ZDttrx+bhEhZ70aT+8XDlpPFOcht7CYfL6zdUvfqtnPKcRYd6NdDIH
49Ylex4S3/+ImxaG++jr9lwzXPXK5VmzwNjGUbh76Lrzz1HICp7j7Xsdnnpj
HrrPuE743H2Cp/+vvbwgcDd4H8xd5dY+pDvSHsrdfZedsx8vraZ5g/j7zmbS
1ur5HUhjpgH886ys3g0OvCtHKnwZZiNsj7AFAa31IQt8YxfzHV9AZKF8Yjel
mcvxh5Aajuc6l+2PpDUJnTnXIaJ/AqnITonfHte0BJYUs/kOU6JTgrPadU4Z
7NmIyQITYOKz2nVYJ+FBuD6oYRGUgIdDMgMRJQ/2bebAXdXdpL08ILcnJRwS
iiGpXP6shrAeDsnfHH+FCf/J8WrltK2X0IRHaufYr2CAcg1rmkRHhVcPjmro
ijKJTotVbDwVxZLuHBvlwNCXnH5J/PbAjf/1m+i/1o/7/vtXfP0/zIbTj54y
rhmySHr++48/5Os5A/zLkL5+0JAW5e4h6cmjZAvx1/9jFP3X+nHff/y6GIZ7
vz49T3zPPQ8h8cd8XZJamPWEr8MVw4i0gs9IGJnyYszOf87XkXSQRT7DDm73
MTMDo+5LzF3ViLLyyeR7LJeU2xdg02zXGQmT+ZsoBZZ5g8mGg/ANR9+4Ckd5
YL4E0qMVzJWB8J7FQsI0aKHeawy8y53scOOwowxm0Te+/sAMx4g6nDlMzILw
gf2ktfqfJw//GMSWxwvRUwdk1N09vHFHsxHgmlCmAnz54Qfk7eql93DhKVce
68bReTtjr2huKVEdQudQLyRUI32Epo4mw2IWofEb503z+ZYzaCgJ1NfC08eE
yeIl8lGPto2z74BJ/nXfHrS2L3ODNkV1TlsqryVb0r8PtI7JfTRIhHStqgQD
F5WhRG9gSzwHoQT184AvCDFW1oLJIGZgohdRE3qmAEtjWBUbjzunaPVr6SOQ
XLLklTRrPRpew3OiW9A4e4ky8TRJb4qwSO5fJCx28OvOU04kgzl8+LlPPhj5
sVNIfNxXCcTIjH+sCAHmD//B1OT9IcJfJXHVvMq/uTZDscrSvffVT52w8FW+
aVp889GXzL/YuV/MTd2l7tfDQK56udJQTOyL+qihLvEScnBHfXIGmzATMeg/
n7iT0udA+fH98J97fwkX36+NE6oHL8CsHxBLR6/wQHKlBxyOQaMlBJK0/Znt
cGj8o+TvhcmHTk6CMO1tHpsMwmH7pLNKyu+C2WgZz0DcYRR021KnXcyCp2k6
maZ/9mDYXZb+bdizFGp30xtd7yyGHMVYGWmafwfUOMemIsPGxSw6VVco/4hS
FAc0XRmISPhYn3MCay1UwqcpWa3GhvOk/89jhuZC7+BF3njzzK5kHnQptnfx
+NKIPXAsCmPsZnAxbcAvwr92PY/FMB8zvik3u3h87M1qLYSLxofn/eD0i73j
f9R+RqyYKe+TNB7z6mepO73smNGZ6NLsYsEekadfvwi365NYsBl/4IIK9Xlw
a/HRqSelDtFpcuAOiG0MaH8Ghn3UX7MC7yKVtxY4Jh7LthMxb3olPvAOVNAH
4lCG5+2HuI+tJEsME/8aOX1gZ3FXR09+OnnzT+JAO3hCIMBLcJkdY1jbsf8m
stmz+4kLvtJz25TPf9qF07c/684pkFDHfHF8oYbdK87emB1qGFqkfHlpJtYl
Gpft+ns4jOkxMnPOcq4PwpCGdqeimXjEr6bOVosja3hMc8pwoKapIMoXW/QI
reG3qRYbR5J5GJE7I4qQx29dVpkR8wIm7o9cerxxUhhG0wWpUVrAdyb+WSaX
xtjtStA+PCsDSL/wAIwZE6qgoiWFMGZ0GKiPUBgXkywYBQwoA2U3kprgFGr/
NHpY8qwVsFuPABeFsHXJtvBolV+3zjSvfR9xzP+HzXGyOVgwlRcFlRecFcBG
HpLOqGnRTJeRVYUkGchRqTFQIuzRarsuakUTxjDNeUtkxChCfWb70PXQPbpP
d1gftqES0eGQyKXr+KBZWbcH+1+EZ81jL4b7CAJr3QxRzy3FGKhaRE6juybc
mOhec5xYyGmcAstAUE0PjdGMtu5RcVlr1xIWLyPM1yVeQkXcICPIZ0UuqmbI
IHX6rfug2cO2pQhvWM63M1kgZ+IgYQdWIxDTmMDEXSuZ6cQuZ94c+pJfVPcb
gSTG7ofyLCOQ51zLKqkOFNT8c6zFIKta2kIMjcVId48k+DRzgf3QvGZw9mne
sgo4/2KWrkDrAOKUpjBW5DrqPbmlgKlUIeBdhvmvHhz/jAT545Pj57yB9AdQ
FzFd7WO0A3tGlkTKguoRKCGrkao/uU4jc8R+9ZRixV5Oa/mAbRU47NcJd+ZA
dFJ1yq3Lub8MOtiVGjFSI78kKypBT+nSVjsghVwnPW/pKY8X1BgVmbzHw+CN
OqcYjodcjo+l9ttLfkgsFVR2OWWkOunainlJc2y+6qtEsPoHL5uvM/0v8l19
liMrUrGC28YaMh/r1fosF1ekrrGNNxRbbEintMvf1RonUuo+ZpyW3+yT59Ma
59Pm84fsc6SgdjsIfqyS2teD0CiqzvvqPsMX7kwgfZd12IZctX5witfGrYIV
N5jejXvhDoJ1iJ1Y3euofTDocNHTB4qqPTiZleGzvtQrqqyJpkDaADcLMF19
uqBcg9AZZBCacnqkTzEGRCFgmCruP+BhqfNxNo6acdEFRwb3OepqmCt1BiSZ
b/UtgzimmLkDhkod7FnAP9HJteOa7GBNHUI37IWO/vL88SO/HDchjN1KnoHv
4jwxuPgnvawtCD/p5U7vtsu93GoH8nFfjoDJk4+ctoVlTjovK2bwjpcj2OWP
e/nTiSTi6A+LWXXOkaiT2RJMxo/m6N0R/ms4eubnMa5pHn9UaPOfwWIu5c+i
VX2cZ+sy4xJ4y+nmUt6u8Ozl/V6X8oBh0tC2yjn7L0oFx0L6JaGsPSnn2Yql
Z8O/WeNvFJaZyOAxVYATpoB5IvR5B4LE07l5+/aNNwwXkNaIHlYHs7tbodUJ
ASGCQJPD/eQsL8ZKwcvgE/Apk4mxAjMyShCwDL1cnPuQVy6dr8EkZZJ6L9h3
i3SG5iti6yTsdCGziFD/qbFiTpikmGc4dKH+XVpF235ZTVkhFATb/pX3BijE
vqos9djd93OjWD1DYEYOb+3ewQngVRqK6+HUy22Dx8XF5STXSsHQiwxNjC8W
WK2Qzt5xqjHvO7EU2iwyJ2vcCslm1zljrue28L6PJdaIrzykYzmlpORhMl2V
s3dDrhI4p6J3MK6H7LNjU7JKFzAdPICfThy8Lw04KEg33AGhUWt6NHu3wMSR
5Blnaapnwb4Eg5UZMIEbTPX0W9DaEFqKuNmElrRWknYhr9D0Hfq90Q5T1Fti
yOGidboSjCFuPp1tGBjKOyJ4cTVtCkICrLTczZASOh/CvEYG/awOldeM+emT
XOEo0YeLFjfRIJEMWuqs02FxJlZyYUWLOnWqDAzwU0IZ4tL15twJihMGPCov
eD2F0aCtS8PgI2C+t9ydSPbZB4FSRvXWAAlyoZQcvbq6hi7D0gZgogyaGMOU
hHYoVHhPg+im5gh8wxfQCXkkdjuBX1HnG3QaFREsvHd1oLP2XBrkwGPshDMg
+nAiDkiWSH4nlRKmgIc+y0MDHD42pwcZcsW4TX0SsRE8JsFx86l8mjBV23Mm
100Fu4SuLF/rtUUsInLwsY8NL0W6QGAYH0DAtAn40DykwMBPWA4zNPBOzHNF
8/I5oh4fH5ODnSIEClnCdUBq2haBVW227NorMqaCKbLlYk4t5G17Ij7yWgWQ
YGRiQgTcKDh4bNOCpFmErDKkISk2W2y5DZKgK7Za9paVC5SMk8GXQtEWUOky
pWvB7GGoiNlcXFApI3dYgTHLfc8oT36CSHu6TanXVKaZb1Ityl32fDNTR/Pm
Ode0czkhJ7fvjyB4F0iKsMmUI0gNh53tz4M4JCURv8ehpnIqAdio89+xtwuW
esMT+IL84P66LZtUhBai8nMp17n8nevqKbGRmSfGIrbc8wWVATxf0gIqlm81
zhLvrISsMGmwYuGrYGIU7u2KpCcoZ+H2lVUDmwd38CxT6leun5KzEAWjXge6
QHRXBZ5NMNxabmd0JyaLTK6nRkdCz4nVOYVicCBuEuMk3hajqVqAAs9LkKA1
395m3JpegHyVm7BJdjquPR3atLdAS289LAt1Mqxzr4iUFUWJ7TY4mr3EOFDW
YTb4MMo2Rmo3I7Z4CjF7hz2KiBRIDTBrQCooRNxykjnfeJERXunSqiRtSsNB
Oo5yYSpwCez0hGldt2D3xFKnDCQ4lVVRSJMZRnGCfGjOdSB9qSldaJC9BoKk
46cMoC361gXBDx3t5ExXxu/lK2EPc7+mgFGsN5XtNoJizE/BPmvYM3L/2ZMn
D58+ABNSYJyl3DEI/IG8M0g8JBji9bgo09bupuZmyU/n5VYEqgDMTyUsyhm7
booXp0BkDOIV+Ljk8oPixjnY5KHS2HJSB9GVqgrGrcK5qptUehFUoeqf1Pcd
IhCsOFzkSBY9Cl+QshZb+a1IpzWbE1L+GiJnqoKRofW006gsHgMxm+kkfeNz
PG8sr8Wi4DrRAlhTwe+zjFuBWqPKICkY1BJG56Y935ArMELFFBxMQXoSeB8D
uHm8WiWTFs7TJKB9KuITgVUJNhFFNhgJF3WbCHGOjiBsPdV2B3DMkOT3nIXZ
0LXj0Wi/K0wCkhMNKLPH/efvomLNDRMRgW67+d+1Xcty21iS3eMrEOpFSdUk
9bQtq2Y6WtbDlizZLskuV5dCI4EkRMICATVASpa6ajM/MjGLWcwPzGJidhX9
X5MnM+8DIKiHe0YR3WWSuLjvvJl5M8+R9PbIYhX7DRekqqiEonORGGAwOf7R
kzQfDKDmXyF5pBRUK763E+Xa4GoJUXl9GCYZawfQbMT80LPok7O4rP1a8QmU
Buu0YhqQ9MeNbT4Lt6/0dykAqoLPcTd8y9ll1OL9z2+purE89eLZ8otT2YuC
7xjuyvW8JOSsLp1qBo7Vb3oVA1usF+Z7q14M8nlfkWdGpblQmNTKUjVKlnm7
vLR+2zjOB+ze3uBQDOm23ahsTmaCjMpCkTSi8RAfAz2t6HzljCPZBcYWM6yF
LMzMGJONLKOC17PYDc6rQJjn6h/SXVs6rZX+M+Ch4tawEsUB9ByaalvLQDUy
5HwzCG82550YI4H3Ie3CK14gwGpL7JowSIjz5YIGZtDYKbSgZZ021/oJvfk6
Z8DysEgGQwYUJ1ubegixIA0pDegxBwKwLilnZmHBPNgQtqTwJEvBq0f2YjIZ
OSb6Ir+NUphsVprhdGgZ0V7GQE8c+5SnAWd/KGMzEGdNU/paI5BzqUGlUa6M
dkflU9rw2N8yGi3MoeR2cXg1Taz0JGeXBOkgyqbj8tA7wjCmPjDxF72TH6/j
yg8ncGe2t/de7xx/bG8evD5l6AE6G0/eRHTwb6YDnOjDkRzXvDMrO+p0PjAg
yDc3N50kyiJmlRV0AT6fFvkEkkXRHtJb21E6aPyy83U4HqULcx3TruO917VG
VWSs17xHt2PqJJzxtbTlD/Yz2qd1SQNJkqwsL788DV8VUT+Dv+G4Qy0kgSTI
0hZ/meaUnmXVdE9vtIIjjwXpgERxSh0w7Ye1B4Q5+ENMBuJiP+8tokGLxUUP
1S7MtYLDqCBDYPnlyxfantWX68+pPfD1FWX7ICbB/bHTkpli2+moI2hWUcme
tVZ40AnmTj5lCSOGW+Nyz906zZMVurARvo7plUkvPL6lRfo1eEJj0SZqbLgf
ZWSO3QKT85m0du352vppuE8C8aIssbp5/CAFXpFStPy8xf9dXVHUEPr387Vw
m+oLdoDhSx16yqChNrTjPam+XTL9qR3PddjWXi5TQ7YnZMgjtx6jEh52zGrb
ERdcrojaOHS23WYOlEFHVVjNwqSPDzTNNovqXsRk7k9IU6RGmbkU0NU3pCtR
g7Y74TxzpMj4OBDGCn9PuIubA8gGbzfcWzsq8QYFvMIrpv71VRqUXRLCJL/e
0Sp6m2IYaJr26cMb0gUAfv0Rw3RI0i1iz3sVX6NUl4V/R2CgzMuH1pBtIrWj
un6WV7WJdMo/wwLKoMwfUquwE1MccWjicXSZjCZFJK2fO2FMS8yeQwKe3/98
vPCENYQK0ZbDiNvxzLXjRaUdXmUQB1TN24WHpqRWz4vmetZn1eMJaqpu86nV
rTdUt760ulLbn7Q1kkl5HUUY1j1uwU6f9fn21oRsIpwNyThKgwYRHc7v9LeP
n9YyNKE2+WZ/8FUS6RHjMZqG0TiIky4165XIuHcIWzMr9PUkgScqE6sz+FwY
o7MJaMemaqvgflKDqVXcYNnNXmtfrJ16LZw72Rx1k8GE9amL8NMVKQ4cAHBd
hgf5jX6QBoSQ9wEW0mecK4/cN6jRm1TbEODmwHjDAAyjUUsknY/CM/s0KAMc
B+VTtgzq85rxUlrxcnl56bRyLrXqbVJvZ294GWM/qzQOjg0b5RPagNo8Ebti
RBzbEnSw9C5HwGnZpEYcwTAvuEI25K/yIrtteaeBmiWBb2KbhoxzEIJOzQSq
wRDsxt1CV/HKmmkCbBHcnKaJjAKd6Tc5KLy2eXfN0rUe7jO9eHalz1ZPw+Mx
Ka1ZfCn1HuQXF6Sl5k6wKIICsD7Y2jqKKxQhtGoNxgLO5Ke17dnqglkSK2tz
2qr152sV6UYNjJFK8Z4btAuI9faxCZuuaaYBC8L3kvZ3bIwbmkHvIn5+//3x
juTkbr16f1R7Oqg/vYWnn7LKqP1YZe4sXTGSlM74JSy0gvuG4X41jIpBdI1l
95alKmLWVHJ95vnf6tCCDLHsbrtF0g8+cBY3nyeulU/aBOu8CfwFsSIG+54x
HOq2gbkT5o2YFynJrh1p49u84KjfV9zEqngNjXiF7PoYfx0HiIJQQzuoytqn
KJLUEqzoV1sfwhcr2M0pa5OsDSBode8DBBsuMPQ8yEndgKekFb7uGCVyMOxG
WaI7uhaAwZA6A03tN4Gbj2hhv4guxu2Mq2bWl8S9p23cyazkfcZlZ8Jq0ADg
DC17Nd/exktMVxB/+8S+7FqYK4ZYKEHQUQ8wET+ViDD86yC6BduNTs239HSU
lm0LsNXm8Ify0T3FcfTiJS2vz9GYtUlshc0JnTM3UdrHWiP5FZGZn4pw/jxp
hT92xDbN+ri0Cw7AjXXAK48qU1cGZFO1NtVEn3qYU+O8w3xlSbD5NplnKPka
bm6EhyALa19E8KezMq4XqlhBAZMk3gdD7WOYnutdq9LFJePAhT/qXaPA1Yw1
T5jzHSz26eHuZoVaFxH8uAwIasx6dYhGeJSauS4q+OCGnAkuSua9qPqg6/cz
qFn8xC2NxBw3UQewo5IBPSW633IzTJMM8E0qztxUA+2FppW6bXHYLIEXY5R5
xKgekZT6x8hus47Z2VdLLZPb00THB+BT6wyKlHYg1JVQu9WBL9Xc+suEDdg1
W1i/LF9jCMKPXE8x7CJfs8EFZi8yGxgCDZsTrY2AapcECHNxj0drS6OlQyes
9U1rIg+8mx+91rPDNVUx30Z6U4ILx5yxwAO5LpuMHmq3rIGmxmr6p23PSLe3
aVSKWIP4OsHPjEJe9csGgtHPvTb3zOZWxssdsTycV4XyVOD6QJYR1ToOTI1x
E82UvXxWkq7me1Fch8gtngQEWerLijNYXMCGZKtMRkkaKTMe0uJ6CZYKZLkT
1qV8OaIvO0m+EHqHj03zOdnj68fT+T/IPaQQd/viR0HcY/oZ+q14aa2ke7UB
/7oXbOHsux2FB1effmSKMBOF1StE0WAdhi9l1VvP4T5e9IdcuTnUAd6f7J+j
vV+BfL7SV5XM9yYQNxICZmIf9d7KJtpxcot3NyDr8dPRQTBNknr+5eay/AQ+
RBstiWrcHY69z5fo9qffvoHh5I1s9IABdmQh2vcy1JvllxNGOZ8naZFO30W0
8twnqMEAzG2EJwys+LdAIhHnLse3YOJ4//bDXMt81yuu8d2O8kLZ76N00Pj9
ZdLH99MNEZYp+9xXPLV5Fx+PP2z2f2xfd5Pn3f2fvvZ+/PLqw+7K3ouL7V/6
9L+zn39Z3V/bvCvnuOBv9P+ns5hvaOFYjT5URjaQ0qMlC0HwmiEk9LhpjmU1
d3r3cZMx6xiPqoJz1hjHmsiq7iEdQ+Nnc4wtfrpbe9G72F5+875/+HHvr73P
X/rra8nhwY9rg5/2+1svftnd3LpY/in566cGjrFnK8uBzDc39TOJZoz6KCqS
+M9N7RSmIQYgwhzSjujcRqNUvvYyI+jHF72l9bWVleft/stoub0MXqMuGI5o
yJZ6L1dXevGSzPZcfpPFzPAS8xVlkv15enHIk/L9ox7ll9I2Q7jiO23vZtpF
NuiOlvXf+agnLSTBhkIF8NcVvCf6BdlOdkAkZXNDt5AduRG0PV3rBvBlw+0z
0LlNjS//4kOu45HhRTIZ3uTF3U02KV6u91dvviQ3w8IVcPdIvJ/nkErIwJgg
DZg7tZvmN9o0Dcxo7j6uy36kUlNJJxz7V6FFto6Qf5y4zzLcbQjbYYXnbiM0
wqxphXobL6gT4n3zvqmT6MnOmfuzu9NhzjOM8P8dO9/6s6XnS8+q7HyzpOZM
br7alEL8ibLA0ynaiq+/qLgO563fdgFzKwm7cfWKtuVIHqJ+PxzSyhItxrLK
8xFItgcnvdJhx6C9wfw5aALPBZRygYOVTazrDxIV419ZkzC65NADfj4baFQh
zno6h5noxHbXo8Uz5gJy3b0IbfvqgAcg6tIp/I+v1/9H8fz/zQH5f7LKphgg
d66ir2s/7/71ulsU23c/ftqM3qV/nOxsReXO2+5mMbhb30x3Ln8ur67/8vPK
xfHlj7vpFjcg+nlv9Ev2l0/rL9e3VsZLe/1Rd3f45Wi9e/luafjLYGvwzzRO
9UVN5sw3KE5Wp82sz6oaDGVZalyEoxkS1iV+4ugu0SacGjt/pFJpQSSoe3sl
gKJSFYcQWvXyG6OwxHqwUJSBa3+d/Je2j0amgZg5I2uZkxokBMlpOMsdXFky
Q5kJEOHQE+WkVMxx0nFlvZzbZEseVTpXTNxqN+/fgtFlNx736jFMFT0VhRwV
sqmwLRX+abFzg8sFBDRmEPPnGhArkCRctqptz3RWzDQM8BLPNkCQJxnP7rWQ
JuK7rhHLcwY6dQpYyGE4lV7aEmRpL6XhxLLDCUfEthSmCe7rD+BD0lcugFvF
jZ5npLhZIPtDQdBosdoWgxnkIO+ZlLJJloDi0QlYkIfemqD1RkGqIPf8e00Y
navMb6HrRTyIRBeATJ4S+vSKefZHiPBfCJ651XXOcudcTZUZlfBkXySKJUEl
8EraWb2hbf4lXlJBMXGXqmadBc87sLyNElM7b/hQsENq1q8F0OblkY/oRbxt
00RD4RsaHZWVHe20o+BFRyVHrW6P4NLedFK/bUi+9JF+41Uq3cyVvQdWsKKf
mxPcHeC1xcc5JHiFjXjzbkBksr9B/IhElNAs0w8FSwqCXYuPq5mG/JTc/VQG
QXYVJ2hFacnhbhdJMbIZiklf7znHDgynVR1rSZH5yZO1fozMPxDjulmGzr62
Hj0LilRCmQChEucjyq0wI3OU4r1kTwLIXNgyYc+fhJgLDzgAFt00m3Bv41yg
6RkkZrgM53bVs7K1MR2PjSQLjneDfkoDNx2wjWZzLC1Tr2kgtI3bNg75gO0V
6IfOxSJL5yLqQVQa+bLngtMtW7CXKRSIy7rF0NlRlme3I2R/SDjq652PAHbR
Y2j/87FLebQxGhoqHphFg1G+9AiCR1E/9tCJ84sLVtsMAo1PUh5EfUFHytXJ
Y5aouHvo/PveZsVvhOcuXP08bFMzh1U6Co6nM+icKcf1cxxnENrhkr5b+uXp
yarUp+HqUhnfSQrKHr3WkBVwVozsalstaA0uKrNk/a0eSDXTQyjQ1AYzb3g1
T4qUa6Vl2S3zFDGPOFsUQODWE4XVLKo9wVna4F/aloROsoU3TOqjPd7BlKRG
6jwPnIQi0+FW8LXGgjyKJ2tvZPEwr++LlFCl4BiMD4YHYEHL4JrBlIuYurQv
vCch46nqQ8bf757kg+AqoqFTsXrOGsfCrBJwB8BL2QppawJfDTRQRTTA8q0P
cN/5GmauJa7HrCc3zIE6SX1XnS5q52TwYAU3wjkohZ671607437QlWa9fc7f
x56IlN0MOmmMjCoTXve4aIF+1ZHiuWSX5/Sp31rfUg+duxtra2urj6ts5ZGV
UV3LL1c6y8/XO8ud5Y31pfWlx1Wwaivg/8KR8pt1+rC8w4RYL+gxmYNz8oA9
VfBDp9OZm+Wu9KU7rRuNMuCU65L93faKIi/Mrsd6Z44wCL1by9htcIwlX5uZ
pFWPhc/4zCD8v8rzyzMI4TONyMAH+l3EuvxiSNjkE/tKz1qBMKOffaJJO6tb
IqQMRgO4RyRf2sY90/GeRlCEAslDzoQILbJZAwV4seC5GiZXJR/zUThAhIBQ
zrnea76A3w0eoDMFjpMGC/vbxYVm0HJjyzMWdFqwSwVDBN+YlCRIcMvXYS59
kDRoUhcMWXgkaq6gui0iszBGTK3BqTLgo6R4TpgCldU8mpDurbvW5Ak0fVAZ
ze6LUi4UFA1ximgZ189VxbWMUxe7jy/OHGEtXzyeoc20AjjY3NzvVP3eCqTj
j2moF4+wxpg+i1FmUq8uZVUx/D2Qinw/quo4OmisOjkxeJOXhmFEiXu8iytE
5JBwlCgDR8BVWRkmU1Az16JekZewQC44AGXMk2iv2MzKponXmyqhtVA1oNLd
8bDgZEOn2QScdof8b48iQ3pi8xwYbY/sMAYXwb2rS7ymGSRxST27E53EUZ/S
ane9M6MoDjYG4+AbRPuSAYKooXPpzizPOnIg/HGKVOOPwa9htVdAsfg1rP/h
u3bIuulG+EmQKn71X9K2zaKD4hSwFLZkQ63uR/OPqRorPxpCNu/H0PSydI8t
dTrfz3jHdTj9d93ctKkv/ygDYsLQTIP5Sx3h+7ra8D6LAuPov6BQnp3xCJ+d
bXjAIrr0eNBvhjkmoQwrTGuQS1zaTAFesGn0QdNsoxeqfNI9V3kHN+nI3zxo
FUnKygoRR2tZAWVlYdlpeNjO3F1c5PZxs8uaSrgFrUAGHCpgp9uMuMh0fVGw
abtpjy5sNbdpGF3FlwuV3F3dyoEnhYT82M66euHs2FUORT4m+ioxAvWeNsgH
k1+OcYCNUxMTrhM0BgHLy0lRxi5jBxEQPH6C8VnlhFQDUzwTBruUESospFdy
wdE9kSHrQRusjJiSW/fKjPp2mPFcW2rajsYGIQffAS0grckWNpFq31mfovcd
o5Jtu+ea6tUf/8VJBg/NtXsb3Fu4SSA2PTdzD9seYxt+JA2AFtqISew4mU03
qZsGLsRDggJmWGWMzPac9yY6She4CEYMJWrUh6qUip2A52TEuDHwHbicGwvx
IjWKM4GOGs+gQHkzC+YNhqLSK0tqhldohhixXdOTtTInFWlS2VsmdpQPWFY6
dDOpuuFteLSom8giFiBViYmphPUETn1IMpNMOfZcFaWgUbiBsbhCFU0C0aYV
LcIG6jywcUz7H9o4SsaJFWQWv4oW+Uq/E/e6OZXlOyEkftQm8U5ZI2L9PdJ4
RnI/qpukuY57NonXu6l9oiAG8gw7uuZJdJkisvq9oZhV3iCK8fMyTPcfraWB
JtbVhnI8lCj2iZ3jrZDU4D6c74OJp4j7Q2fmVyJHrLXIfw/vkswUR16n/9Yo
m9K2EaHZE228VpKMgryXcFFNeY84Oxa7jLsbGYQBvsuTqCnd57LJLJv29Dar
QCR9V7orkURgViTacDBR4wHuZb3QqZ2KUwQQ5oDkLRl4VZoM4MfggzFFjGrH
QAX2zOAR5+/yNUHCCBgA0DEYWJHrc80eDvjc1+tq25Pps9dDQhacI1je7IdS
vCjf4Cw7dTJPNYQ5pM3czuFmkPPo86ytcDUIcxMbWiilAo05leDBsYBu2644
plGDKjE96pL2ESg13Q/Ws9TNv9ZIIgF2JQPh8eA6Vjue/XHlWtPdl7VoQ9Ly
LBLFGKpiUjNnXmKy4iX2Vt/asZh99m9a2NTEmlHS8fehokb4Ms89Ne9W9ELj
U4+tkQT3VWLYM2fWSDoQh672K9Kh6SnBi7j/KZF3mywft5MozQdNT13Vh6Hx
XRWYiplPdTqdsP73LePVWNTWoyHsD5RwNTX9a1bljRZnw3fVuhrNyFmlGhrR
ZA569rCc30c+P58a07+GW56UxZd+a7+9rrriLXW1Qy9LIKzXxVqHJfgxbeFS
qim1RQGZKmW5O/72m1eXuV+fngUpVVtsv/qLvgybSjX3m3tbAQirlpp+k3x0
7W7LwfDIUtPtfqjUQ/PVXOr+v0eVavBRPKLUo159/fi+PlS52J16iPC6e7Ap
31RLWxwQfFH3qA6jCNlVt9Ml7i1iM0KqO+DBIhX24ccVqe3MB4o0ifd7ijxq
kF1Z5fizcr3JxlAjo0Zr0LyzRSDVSNzMlxWmNv6yTifnfek448yXFWI778va
k/Wt3tzO2daQVRlgaRjtQW0LpHLIiJG6oMqbmEDeiYBy7y1bjEG+s+XUZJKd
w24G/be44llz0FC12eHt4qgQvQXvIDMkjTlGzFKuJxcWxszED/SgBmpR0Sq4
LG4kPh3tcf1GI7XAuFN+h90ioR+RelNEYgBY90aFzbbi+XSjVqV4EZPInkUS
+c+cdqyQywg0mD0KTilwOzxaXurXmTm1zwK+aImsqSK5XAbn30/wQp7fDFdB
0/ZrPh+wT6pVzdRjphLM7vfOP6Ju++ZH/vk+fTbgy3sf5wdllJ0aOEPfmv5r
liv8U4XcYVbnpFfHFbL16efa7T/9Om2DztJBGv5mijRSf5PCNvH+QZ6ly91T
gsGneArsOna3PI98yXVFrbu3xMxuusSQe0p7ZADzYkwvSJf9SFlSCZ5Yty88
wqpHzVVdVXinvkReTOXLcTSuuLLv3Tme+43ZZ/3ZsIM805foGBJm1HTPoeOW
V+Xw8Fbd2DjV7vM3G6wwdicJNKPFG65cafn317lJeDW+CzxkpD6vJZbkMhJ2
eXFVDLimHGfzho6HDnrDybNQOTz2+s535/u+LVUy7+6oGsOs54pbWJVjReen
EqI97yf3tpoM1iY1bGHqAGNX5q3guNtDax6BgS3lJWpZFqxWGI97nYWad7Nh
lCW6T7yhGmQpxx2XNOu6WrWhv5gXiHPOuK9UaFb+zJmtnDRSZqyXIluMOTzW
naIlZCbmjZcXYJGZoLb0Y/Dt9TmI1BzV4TG76mUlb2oZvFsn1L7FLjGZtgT5
wiizLS91RSBVrgW+nbeAKk0fpBW8Am6ixJ776pju3k51ddb1h1SDHCm9IIRT
V7yx84yCvdCpPmcht70HVfb5T07JDS8RXZEyS+PV5Zc0X5zIKpErEfaGI56l
FJK5vmmLpPlLFI65+parzwzBsluV0AQOL+KrLkhIi8Td4M6bIaOrotI7C/Tv
U1nxZk17kZ7yzvq15Kx3Npyz9zyZ90ZmZzzw5CTp17/+h3p0/3tmuM0anrs3
NKPyHEcm1L5zXB2xCR+v/TVHZjQ007XyfmWUm1y7wrXxGrp+p/vxbfW4sBd1
R6hzqjAyQb5+sB6jdtgSs8bY+7u/ba5M43uSspw0elYfGPqaA3Wv4oR7oJvV
gYPk8Xw4D5WdrcaYm3NIg+/K6sX5ky7K3V5lk3OSpv7JJnfpyQx9ohbG5u7S
ZhwGLLp4w8y6+J4vVcrzozJf1SgaGwljn6rtturjRnSX1lxkpg8T+Rdam5Rb
rBocnxr2DG0+ORBhyHQJavV3Yw4jF13Q4PRXr75M9D+KS4Ii1ADvcEnMeeb4
4uvGq3+TOBX1uPlhD5VkeoeaemdiwFkNLphGCH2/hj5bilEPNdzcxM/exIJK
DLxlpJnKBSHijG440cBdtj0UBPAIxR2bBHqBNQCbo/AqdoxExmgQgM9799hI
GWeO2OG/TqKpn+9x2dUt5ie6wkyPeZsd7WFdcaA91BobDznDwngwaK5W0I1a
86auWSkSD1BTlY8eqaVX4rV3NsJ30XUykLndI9396wO4JhJEys4xdM7dr5aG
owFXr16JMEr65Q+MlQPuGeRnM9QPswFPUl6hrAfbW2BJ+Dg7o6VzMnVHfDr/
B0TdR1dJ2zIjLMDQOTGYgX+Q8mIebFVckxwG5mOfnPcql1nnP/C1sqk1CB+o
V6qw3syG19s7Ak61S7JuPmHiBwU7CAeQkD9QRX69j6n1Q1y0S7UXfPuQL6TC
cxs4+H2n6piQLmK8vp0Lr9YAaxYzE3hDEzTPtdTRFZsv/Paqj+mgbKtTmn6V
Ks8b7NpzTml87GzasAA1GuTkoGL3jKa0R1K8ZMU+PWmPV69BfNk2QWOyGzEc
8kvbhpO1E/wiQ1HJtpAGTCdj0PvlAXqb2dftvt4htuUneZ2PjGjSIcyEqkrR
xgKlgzcvE04Lk0TGc/P04jnD3fMkWN4D7ZEG4SsUnDwiNhnSXtEPFZd0ql+D
cClQIHhT/d7Ox93Qh7EzxzcY1YVJyRDg4g3xTWACXSOJtKEZTVOJ+RMjmyMh
B7ligwAqIY3KMYRmKqTiciiPTXsR0sBYYgztXx+W18n4zaTrjY7NwOdeLL1A
8pzhh5RcYEkpdum1LqFZEkwEZowTiCUfA+uRM4j1UKjzHZg2cYIiNBCFnoJ2
hg41r08vmZeR2G6mc3rpPVS3PZVYHdL2M6GGhRFe7ax2XqB5Hn+FY/Wgd4he
BnjHIjHkbKhhbibavSMT/cGMATKMG8cN/BHGh8gYaMO4d6l0LMxLQS3JQO2F
uSDFu6dzMck8kvjzShY/0tQ7yHc6d5yIgkMYTGXzm/Gfxg5oyVi6RBqjYgSh
mUydK8c90MAKkvhhbGZWzxHna3PQBUwP0fHI+Xf0V07obFBb4nKYYW8kML+i
rDeUfCFFBFPnUPMYAwXMzveLzkpnTfpgZ5xNhi3Om0qUPMJ7JZ+CpWaDCuUK
OzQRpIWaAE7gZbszHZ3S5AmYSpxewPcaS5w9jCdr90SYmqyf39A7ppq5Mt1I
N31YLNP0OEwDg+u7DU0AFo45IL6QWoVNDvlt01dLeGR46iyzDd/hs5POTyAV
LhuLP+OfToYxB9nXP4R9UkyvdI1yC9qs+nPCagSdFLlzBpfCYjE50KOUl7qD
ttPdLTzi9E5WReh8cQMhLOJ5HfzhfuwHn7gH/lS5xaUty6swCCvwmcKV6muJ
NsTu+/CTCtcq7oAmWJYbMuNm1ypp07lhc5EdYGZkiuzFYVBzVKYyFTpkVuRh
o7AC6PDIcYpCXaPd4Jn2tRCe3UYtBAvEncpOzeBcPJIaX1sN538QPqgBtLzD
vqLJe2XteR+3M/u7LW9wVaMs4ShyTYA02AveqT5bAxBBOowmlqu1AkU3z2yk
Ba3YOdE4N63TOggrj84tOOnK3D4WOIFVZhINFTQGINnzsuKDIYkNMGUvL+Ja
eJXy8N4ID+8FkLWxU0BoCrk1GbdMjqfeSySFoFaib3vGbIEDGrC1Boz63J0z
GqerY1TVrGu9rHaLo00ZUJWZg3BQsP9gmk87kKBtxu835Nw19eJ5tbX+o4lC
VVcDEFou+KBltV39hVmTRL+XBut3V/nVJDX7c6THYJpaKtEgNBzdpm+GGdfg
JGBQD1n74oPGhyyQCmtxuPR6oB4bERuEtbGqtNLnFDV6hYOYVijm78FaVdgm
2KgnzsvCl/FXBVAFKXLOmp7CXkSYT2sc8x3HlA3cgb8H5H6CqcNoD6xhsAOH
ytsKI0N0V9Q54ORgMGnAMB5dADM6cCwBJXjtx7gYlXo5IlptfyLAjOqT08zg
vt02pCZjQ4qOvGFSS4dymTUpVZFRFNYw9MkSjvbMjjOIQVzYqPg2l6Z0xS20
fqUkqF7tDBhjz+pBtkicTUZuSZWTrmWF57GnurmjfS/420R1i8DWUXKSQq+U
YxpvSbKB1QCCUe50wReYTMtm+ItxJtR22rOaXCB9UdFOxCb29ETOYldiVMn+
Y2ZB3c6lgSDWVRzZHSpiVfCVzVaRi+Vzj7KTxiAFWF5ibSfGcjHg8yGOYnh/
QAV6y2YS34wy+Kcl/jO4I5YqsCb28MrzfzKV/smEnLl2lFNKL9VsRqDFvWMo
a8n0VNQqHhiJXTOkkzwEBusJogh7wBrf042qgp7XueuYh47Js1VM0xvhmG4k
Yo3UDtGgPA9UWBFkTAYnvURg32WC4LTvC7FqFSsNJ6s56Om9iQicugXy/gEk
V096nPugmgAbiSxxtaeZcxgdiWPbNyO9ZTBliKBDo/bd5KvgPltgRdCdGP7Q
cw8749zkq7NSBiWzLkSBl9z2BagiYaGGHAgtsQTAGfkgw+dEQJTiQuSWdjRZ
/7KlGcykbYIhzqvagexpAejvRdcwkhzgmPPDGXXTXIg4Jdu8DSNZ8iCwsTcl
iFl5GCWDIvJMVWpiPhpBVmBBRCnjV+AMKGuSYm3aDpL0HVW1qGmeasgX7rWU
m4CjxNwpw8dnAvxwFXACkvN1qupVO8PegxA+BbNMl+CRp7XVJTP0UhZslzQj
sj4RPVx/2YrVhBmoQR08Z15qjP/0cnWvXkyynsp8LyfKT24yx0WdnNlUqiGU
AgBx/EZANkobYlHCBQSgyZqQOJcf4SM/N5cit9a1Vz00zQ3S+Gvgg+Li6Yvo
WrBLSE1DpGlc2FrR+MpeKKpxHhV9RFQYDnw2JkJLp9ghg5nTwig0iuttboLO
F9W1adavGyS4r2DYznQdmFFEvnUFTdADE1TiiBBAViEThnk8BRYUHfduBqjN
aDXAwjKtnIKN8g07pnkmvWoQA2KiX8vbq8qZhrXgKQeGqo65BqeZrdgJwcPc
txJOYSFVxvVAFuKDBFnI1JXnzJeH25IeBAPZCgOR7UHwflLQvMZXmCba0plu
HyDpx8h2ZM9+br2ZcY6KObFzHBm1LcAehJpxwy4LplrvQqrE4TRMPhYhM5Xx
VaLcrk6AlH9D71HXJzcECdokjq6GZFqCmINMkwKw4SEoa/JwswvakSMw/5G8
E/joVvAmT+Eo2sxwR4kDe5ssxT59Hud///dW+KYg9eg2CjdJKkSkeTGJz4SW
0atoEhetgEa4AFhMfxLux5MWleszCftOj+lX5WWvSayxGoJfydy8DN9Et2Rl
x2N6X/g5GiatYBvM70VCyl4WvokhJraGBcmi/GoI7Pi7fGDetg9yxmHeAgMg
dfotNYC0NTKULtEclKHlGr5Fw3EHdoQRoY8JiewURExlmYzy8CAaRVkWtWiL
jGiMD2JS9LJWsE/SmiRsDIGJ4dqPLiddsljKXtK7TFAndAHqwXs67tIIL/gp
pY16lINWy6ufLDfq0F0LDEdfEnAC5WCfyge40zu+ykF16j19VURfeq3gA5/j
x3cxrVqQZFHLPpLlAdHVCl/RDPWTyzHp5AM0XqiASbnB7Ic/T2jFfo51NTE0
YZpcxm517JX8n80iB6Hda6oWIOpRuB2n1EHSeaj3v/9XkXGcex9jTCZTfMtj
SB9oAtH7ZBzRTLyZ0BJ/nWd3v/97Gt/RYHaLqE9dCg7pqBkmtABo/Cfgtoq+
8l3ogci7gxyUC+HBZJDFg9//A2vi4zDpMtrZYTzJEqypY+pXkUOG0WCQPd6P
W7wemVIxwUGyjwzUTAnMhCDoCzedRj2Jf/+3lB0ygRjziieBGBnmsTT6YYOU
Cd4LMUMc3pKVxG6+W7mf133M+gA7EpLsOk+v3TVAH8Sm+RUn91t+ZDsd1ZmA
viFq6MgIzaSoNrAVCGwbju19OnXaH0lo0rBu9v46oV1wjYUbjSYxNvJFBOFE
n5PsrhXQfoCKSTuW5ht7lJYzSdU0utY9G+7GKXyBv//XEOxzUS+Jv4Svirv4
7/+dJdEltmJOs7sVwX9HC4Wqy0Kzz9/GGS1CsE5G9NK//2t0E27dTbqohHYD
7dCM1Hp6xyFWDLVu+7vjJEVrDyaXUXkXbk/Gl/TpQ4wZ3o3JlE+wGqFL0/Ds
kmTBCnibRtRXu9qOsFepIdlgklLVO9dR+DouBjE+vAFpyC2txbzPvI3UArLl
SMCQfKOuYL7exLe8aCBZoIHk1+XlrflcZAkaTN2lpRVR/0ZXGKFiMEFnebkF
Rqi9TXPsaLfGszxN/W1shc4hvQ0ypiyzZEBiIY1oKumNBxHCf9AaWtDDnFbX
QVzk1JgPEe5DLqkgtgDLlITn7DC6JG0lu8zRDGrgYZTlE+zIMf2bBEIJUfnL
MGauK9qs7V+GEc3aVnFL5w1tbGwRUuyokZOoFfwlh9w4pDWZuLE6/P1/6InC
E272m6OoHFGzDyeZmdO//yuJvruYBPBNCYG4H9HwUfNv6EVvk7F+u5MVHMfw
4ff/LEg+bJKCPKG9vpeXyYUIuQt6ahN80rLZ6bsiwnKjlRBTtfAbt/hUSnMW
rvTcONIjIDjKcYrxpKVkQkUTOjW4Alo41Fx4zUg9ybpYJDIbPYjghMyLiBsY
fEzovcfjOOEHtjrbnfBjckOzxq36Io36xHcoEC8f8xFt5rv4KofGJ4Rfec21
xXipLBv4jGZqogt4Uw0OmxUr3VuHVkqao0AiscU0Ea8WbeiMtmW5EQRt9mue
bB2vHu4cv1nbeX+8dXrSK1dBgXNqSodzexrmalL1o0GSxot6+4SYWSi9eDXK
iZuejgGIZA6csg5xYz9DLKGuOcDMIfgIaMb0OghqgMYYeh7mWjs98Xh5Tlsu
Ztj0x9wjBjsT6OERE2/m2XclNmByl2fMOAb1mSHp9A4+y6/VawpetYjOb3VO
v2aW9E2QpvPAZ3knPFl/vrr6bJXGBjcfZdsMUYdG8OTdQRaPT0+yFP+pxGyd
vHu9t0SaI4n4XXq5PtOGH/lUGNGDiwSU8zSfzhAx16K2O1tkEEpUx3dlcPIO
FvBrwc2Q23xxVdDbB8lpvTtK+h6Z7gTv0J3lpeWllysvXy7ZHpE9zL3h9YC5
YS5KrhrkgicxKSn9nrcmVPuWyeQ46LYgY0DJ5rsbWoEJA2DzIrDREC21X8Qv
bNgli1gJvnkiUf+uQ/G8Z9LD6qRrp3kOg9ocUqeX19eXX7y0ndZO8Swe82Um
PF4fSf7Q/MORQmtvHNXmlH+W6aQf22iQmczIHvnhiQ6UPCSjG9it5Sg89Js1
NKUTTxaDymqf/Zw+haiPYaBrzz0N4nb+jv5/MfCX3Yxn8FvAC8g9QJ+kRbVF
7zWKf6CHaAoiPKudXkz6i7JjAn99Pa6gXZuBWXTVNuPLNpZUuyeLs9LIqSIP
VCUrIuB5rtZTmgXRGdOMLwZ2Iu99jP+PFmTWZgNQ58culHvL6tYtF/EoCed2
m5Gpg/8F8akmq3cRAgA=

-->

</rfc>