IETF-OCM-IP.xml

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


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

]>


<rfc ipr="trust200902" docName="draft-nordin-ocm-integration-protocol-00" category="std" consensus="true" submissionType="IETF">
  <front>
    <title>Open Cloud Mesh Integration Protocol</title>

    <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>
    <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." surname="Baghbani" fullname="Mahdi Baghbani">
      <organization>Ponder Source</organization>
      <address>
        <email>mahdi@pondersource.org</email>
        <uri>https://pondersource.com</uri>
      </address>
    </author>

    <date year="2026" month="June" day="13"/>

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

    <abstract>


<?line 33?>

<t>The Open Cloud Mesh Integration Protocol (OCM-IP) defines how an Open
Cloud Mesh (OCM) Server can integrate supporting servers, such as
SSH/SFTP servers, web application platforms, or stand-alone WebDAV
servers, to perform protocol-specific work on its behalf.</t>

<t>OCM-IP makes it possible for existing OCM Servers to offload protocol
specific interactions to stand-alone servers, or even implement OCM as a
lightweight server that handles only the OCM parts of a deployment:
discovery, share creation, token issuance and signing.  Anything
protocol-specific, such as serving files over WebDAV, providing SSH
access, or running an interactive web application, can be handed off to
one or more Protocol Servers running elsewhere, possibly operated with
different software and on different infrastructure.</t>

<t>OCM-IP defines three integration modes: a provisioned mode, in which the
OCM Server pushes Share information to the Protocol Server over a signed
back channel; a self-contained mode, in which the Share information is
embedded in the signed access token itself, so that the Protocol Server
needs no per-share state and no inbound API at all; and an introspected
mode, in which the Protocol Server validates presented credentials
through a token introspection endpoint, restoring compatibility with
Receiving Servers that do not support token exchange.</t>

<t>OCM-IP is a protocol between the Sending OCM Server and its Protocol
Servers only.  The Receiving Server is not involved in, and does not
need to be aware of, this protocol: everything it observes is
indistinguishable from the Sending Server serving the access protocols
itself.  For this reason, an OCM Sending Server MAY adopt a
different strategy to interoperate with Protocol Servers, including
e.g. establishing trust via shared keys, without compromising
compliance with the OCM protocol.</t>



    </abstract>



  </front>

  <middle>


<?line 67?>

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

<t>Open Cloud Mesh [OCM] is a server federation protocol used to notify a
Receiving Party that they have been granted access to some Resource.
OCM deliberately handles interactions only up to the point where the
Receiving Party is informed of their access; actual Resource access is
subsequently managed by other protocols, such as WebDAV [RFC4918], SSH,
or application-specific web protocols.</t>

<t>In existing deployments, the Sending Server typically implements both
the OCM endpoints and all of the access protocols it offers.  This
couples the federation logic to the storage and application logic, and
makes it hard to:</t>

<t><list style="symbols">
  <t>implement OCM as a small, auditable component in front of existing
infrastructure,</t>
  <t>reuse a protocol implementation (for example a WebDAV server, an SFTP
server, or a computational notebook platform) across multiple OCM
deployments and vendors,</t>
  <t>operate the access protocol on separate infrastructure from the OCM
Server, for example running a web application platform in a different
security domain than the file sync and share system.</t>
</list></t>

<t>This document defines the Open Cloud Mesh Integration Protocol (OCM-IP),
which decouples the two concerns.  An OCM Server delegates the serving
of one or more access protocols to one or more Protocol Servers.  The
OCM Server remains the single party that the rest of the federation
interacts with: it performs OCM API Discovery, receives and sends Share
Creation Notifications.  The Protocol Server serves the actual Resource
access protocol, authorizing requests by independently verifying the
access tokens issued by the OCM Server.</t>

<t>Two properties of [OCM] make this delegation possible without sharing
secrets between the OCM Server and the Protocol Server:</t>

<t><list style="numbers" type="1">
  <t>The OCM Server publishes its public keys at the Well-Known [RFC8615]
path <spanx style="verb">/.well-known/jwks.json</spanx> in JWK format [RFC7517], and signs its
server-to-server requests using HTTP Message Signatures [RFC9421].</t>
  <t>The Code Flow lets the Receiving Server exchange the <spanx style="verb">sharedSecret</spanx>
for an access token whose format [OCM] leaves entirely at the issuer's
discretion.</t>
</list></t>

<t>OCM-IP uses that freedom: it requires the OCM Server to issue these
access tokens as JWTs conforming to the JWT Profile for OAuth 2.0 Access
Tokens [RFC9068], signed with the OCM Server's published key.  Any
party, including a third-party service, can then verify such a token
without contacting the OCM Server on a per-request basis.</t>

<t>OCM-IP defines three integration modes that share a common authorization
core:</t>

<t><list style="symbols">
  <t>Provisioned integration: a small back-channel API through which the
OCM Server provisions and revokes Share records on the Protocol Server,
ahead of any Resource access.</t>
  <t>Self-contained integration: the OCM Server embeds the Share
information in the access token itself, as an additional JWT claim.  The
Protocol Server keeps no per-share state and exposes no inbound API;
everything it needs arrives inside the signed token.</t>
  <t>Introspected integration: the Protocol Server validates each presented
credential through a token introspection endpoint [RFC7662] at the OCM
Server.  This is the compatibility mode: it is the only one that can
serve Receiving Servers that directly presents the legacy <spanx style="verb">sharedSecret</spanx>
instead of performing the token exchange.</t>
</list></t>

<t>In all modes, normative rules define how the Protocol Server authorizes
front-channel Resource access using the OCM credentials.</t>

<t>This document is intended to be useful to anyone who wants to write a
reusable server component for use with OCM, such that one implementation
of, say, a notebook platform integration can be used unchanged behind
OCM Servers from different vendors.</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>This document reuses the following terms as defined in [OCM]:
<em>Resource</em>, <em>Share</em>, <em>Share Creation Notification</em>, <em>Sending Server</em>,
<em>Receiving Server</em>, <em>Sending Party</em>, <em>Receiving Party</em>, <em>OCM Address</em>,
<em>OCM Server</em>, and <em>Code Flow</em>.</t>

<t>In addition, we define:</t>

<t><list style="symbols">
  <t><strong>Protocol Server</strong> - A server that serves one or more access
protocols (e.g., WebDAV, SSH, a web application) for Resources shared
through an OCM Server, on that OCM Server's behalf.</t>
  <t><strong>Integration API</strong> - The back-channel HTTP API exposed by a Protocol
Server, through which a paired OCM Server provisions and revokes Share
records.</t>
  <t><strong>Pairing</strong> - The out-of-band configuration step by which an OCM
Server and a Protocol Server are introduced to each other, establishing
mutual trust (see Pairing section).</t>
  <t><strong>Share Provisioning Request</strong> - A signed back-channel request from
the OCM Server to the Protocol Server, transferring the information the
Protocol Server needs in order to serve a Share.</t>
  <t><strong>Share Revocation Request</strong> - A signed back-channel request from the
OCM Server to the Protocol Server, instructing it to stop serving a
Share and release any associated resources.</t>
  <t><strong>Share Record</strong> - The Protocol Server's stored representation of a
provisioned Share, keyed by the pair (sender domain, providerId).</t>
  <t><strong>Provisioned Integration</strong> - The integration mode in which the OCM
Server transfers Share information to the Protocol Server over the back
channel, before any Resource access takes place.</t>
  <t><strong>Self-Contained Integration</strong> - The integration mode in which the
Share information travels inside the access token, in the <spanx style="verb">ocm_ip</spanx>
claim, and no back channel is used.</t>
  <t><strong>Introspected Integration</strong> - The integration mode in which the
Protocol Server validates a presented credential by querying a token
introspection endpoint [RFC7662] hosted by the OCM Server (or its
delegated Token Server).  Defined for backwards compatibility with
Receiving Servers that do not support the Code Flow.</t>
  <t><strong>ocm_ip Claim</strong> - A JWT claim, defined by this document, whose value
is an object carrying the Share information a Protocol Server needs in
order to serve a Share in Self-Contained Integration.</t>
  <t><strong>Front Channel</strong> - The path through which Resource access requests
reach the Protocol Server, originating from the Receiving Server or from
the Receiving Party's user agent, carrying a credential issued by the
OCM Server: an access token or, in Introspected Integration, possibly
the legacy <spanx style="verb">sharedSecret</spanx>.</t>
  <t><strong>Back Channel</strong> - The direct, signed, server-to-server path between
the OCM Server and the Protocol Server, carrying the Integration API
requests.</t>
</list></t>

</section>
<section anchor="architecture"><name>Architecture</name>

<section anchor="integration-modes"><name>Integration Modes</name>

<t>An OCM Server that delegates protocol work takes on the Sending Server
role of [OCM] towards the federation.  Towards its Protocol Servers it
uses one of three integration modes, chosen per pairing and per Share:</t>

<t><list style="symbols">
  <t>In <strong>Provisioned Integration</strong>, the OCM Server acts as a client of the
Protocol Server's Integration API: it pushes a Share Record over the
signed back channel before the Share is created, and revokes it when the
Share ends.  This mode supports the full Share lifecycle, including
prompt revocation and the release of per-share resources, and is the
only mode that supports SSH.</t>
  <t>In <strong>Self-Contained Integration</strong>, there is no back channel at all:
the OCM Server embeds the Share information in the access token, in the
<spanx style="verb">ocm_ip</spanx> claim.  The Protocol Server is stateless with respect to
Shares, which makes this mode attractive for simple gateways (for
example a token-verifying WebDAV front end to an existing storage
system), at the cost of revocation latency bounded only by token
lifetime (see Lifecycle).</t>
  <t>In <strong>Introspected Integration</strong>, the Protocol Server validates each
presented credential by querying a token introspection endpoint
[RFC7662] at the OCM Server (or its delegated Token Server).  This is a
compatibility mode: it is the only mode that can serve Receiving Servers
that do not support the <spanx style="verb">exchange-token</spanx> capability and therefore
present the legacy <spanx style="verb">sharedSecret</spanx> directly on the front channel.  It
reintroduces a per-request dependency on the OCM Server, which the other
two modes avoid.</t>
</list></t>

<t>A Protocol Server MAY support any combination of the modes.  Protocols
that allocate per-share resources or sessions (for example a notebook
platform that starts a computational session per Share) SHOULD use
Provisioned Integration, since Self-Contained Integration provides no
signal to release such resources.  Introspected Integration SHOULD be
used only where it is needed, namely for Shares towards Receiving
Servers that cannot perform the token exchange; where the Code Flow is
available, the other two modes avoid the per-request coupling.</t>

</section>
<section anchor="provisioned-integration-flow"><name>Provisioned Integration Flow</name>

<figure><artwork><![CDATA[
 Sending    OCM Server      Protocol     Receiving    Receiving
  Party   (Sending Server)    Server        Server       Party
    |            |              |             |            |
    | 1. Sending |              |             |            |
    |    Gesture |              |             |            |
    |----------->|              |             |            |
    |            | 2. Share     |             |            |
    |            | Provisioning |             |            |
    |            | Request      |             |            |
    |            |------------->|             |            |
    |            | 3. 201       |             |            |
    |            |<-------------|             |            |
    |            | 4. Share Creation          |            |
    |            |    Notification            |            |
    |            |--------------------------->|            |
    |            |              |             | 5. notify  |
    |            |              |             |----------->|
    |            | 6. Token Request           |            |
    |            |    (Code Flow)             |            |
    |            |<---------------------------|            |
    |            | 7. access_token (JWT)      |            |
    |            |--------------------------->|            |
    |            |              | 8. Resource access       |
    |            |              |    with access_token     |
    |            |              |<------------+------------|
    |            |              | 9. verify token against  |
    |            |              |    OCM Server's JWKS,    |
    |            |              |    look up Share Record, |
    |            |              |    serve the protocol    |
]]></artwork></figure>

<t>The numbered steps are:</t>

<t><list style="numbers" type="1">
  <t>The Sending Party makes a Sending Gesture to the OCM Server, as
described in [OCM].</t>
  <t>The OCM Server sends a Share Provisioning Request over the back
channel to the Protocol Server responsible for (one or more of) the
protocols offered in the Share.</t>
  <t>The Protocol Server verifies the request signature, stores the Share
Record and acknowledges.</t>
  <t>The OCM Server sends the Share Creation Notification to the Receiving
Server, exactly as specified in [OCM].  The protocol endpoints
advertised in the notification point (directly or via a reverse proxy)
at the Protocol Server.</t>
  <t>The Receiving Server notifies the Receiving Party as usual.</t>
  <t>The Receiving Server exchanges the <spanx style="verb">sharedSecret</spanx> for an access token
at the OCM Server's <spanx style="verb">tokenEndPoint</spanx>, using the Code Flow of [OCM].</t>
  <t>The OCM Server issues a signed JWT access token whose <spanx style="verb">client_id</spanx>
claim equals the <spanx style="verb">providerId</spanx> of the Share provisioned in step 2.</t>
  <t>The Receiving Server (or the Receiving Party's user agent, depending
on the access protocol) presents the access token to the Protocol
Server.</t>
  <t>The Protocol Server verifies the token against the OCM Server's
published keys, looks up the Share Record by (issuer domain,
<spanx style="verb">client_id</spanx>), cross-checks the identities bound into the token, and
serves the protocol-specific Resource access.</t>
</list></t>

</section>
<section anchor="self-contained-integration-flow"><name>Self-Contained Integration Flow</name>

<figure><artwork><![CDATA[
 Sending    OCM Server      Protocol     Receiving    Receiving
  Party   (Sending Server)    Server        Server       Party
    |            |              |             |            |
    | 1. Sending |              |             |            |
    |    Gesture |              |             |            |
    |----------->|              |             |            |
    |            | 2. Share Creation          |            |
    |            |    Notification            |            |
    |            |--------------------------->|            |
    |            |              |             | 3. notify  |
    |            |              |             |----------->|
    |            | 4. Token Request           |            |
    |            |    (Code Flow)             |            |
    |            |<---------------------------|            |
    |            | 5. access_token (JWT       |            |
    |            |    with ocm_ip claim)      |            |
    |            |--------------------------->|            |
    |            |              | 6. Resource access       |
    |            |              |    with access_token     |
    |            |              |<------------+------------|
    |            |              | 7. verify token against  |
    |            |              |    OCM Server's JWKS,    |
    |            |              |    check issuer pairing, |
    |            |              |    serve per the ocm_ip  |
    |            |              |    claim                 |
]]></artwork></figure>

<t>The flow is the OCM flow unchanged, except that the token issued in step
5 carries the <spanx style="verb">ocm_ip</spanx> claim, and that the protocol endpoints advertised
in step 2 point at the Protocol Server.  The Protocol Server is not
contacted before Resource access, holds no Share Records, and learns of
each Share only when the first request for it arrives.</t>

</section>
<section anchor="introspected-integration-flow"><name>Introspected Integration Flow</name>

<figure><artwork><![CDATA[
 Sending    OCM Server      Protocol     Receiving    Receiving
  Party   (Sending Server)    Server        Server       Party
    |            |              |             |            |
    | 1. Sending |              |             |            |
    |    Gesture |              |             |            |
    |----------->|              |             |            |
    |            | 2. Share Creation          |            |
    |            |    Notification            |            |
    |            |    (legacy sharedSecret)   |            |
    |            |--------------------------->|            |
    |            |              |             | 3. notify  |
    |            |              |             |----------->|
    |            |              | 4. Resource access       |
    |            |              |    with sharedSecret     |
    |            |              |<------------+------------|
    |            | 5. Token Introspection     |            |
    |            |    Request (signed)        |            |
    |            |<-------------|             |            |
    |            | 6. active + Share          |            |
    |            |    information             |            |
    |            |------------->|             |            |
    |            |              | 7. serve per the         |
    |            |              |    introspection         |
    |            |              |    response              |
]]></artwork></figure>

<t>The Share Creation Notification in step 2 is a legacy [OCM] share: it
carries the <spanx style="verb">sharedSecret</spanx> and does not include <spanx style="verb">must-exchange-token</spanx>,
because the Receiving Server cannot honor it.  The Protocol Server
validates the presented credential by introspecting it at the OCM Server
(steps 5 and 6) and authorizes the request from the introspection
response.</t>

<t>Introspected Integration composes with Provisioned Integration for the
same Share: in that case the introspection response identifies the
provisioned Share Record via <spanx style="verb">client_id</spanx>, and introspection replaces
only the credential validation, not the lifecycle handling.</t>

</section>
<section anchor="relationship-to-open-cloud-mesh"><name>Relationship to Open Cloud Mesh</name>

<t>OCM-IP is layered strictly behind the Sending Server role of [OCM]:</t>

<t><list style="symbols">
  <t>The OCM Server remains the Discoverable Server.  Protocol Servers MUST
NOT be required to expose <spanx style="verb">/.well-known/ocm</spanx>.</t>
  <t>The OCM Server remains the recipient of Invite Acceptance Requests,
Share Acceptance Notifications and all other OCM endpoints.</t>
  <t>The OCM Server remains the OAuth Authorization Server towards the
federation: access tokens are issued under its identity and verified
against the keys it publishes.  The hosting of the <spanx style="verb">tokenEndPoint</spanx>
itself MAY however be delegated as well; see the note below.</t>
  <t>The Protocol Server takes on (part of) the OAuth Resource Server
function: it is the party that ultimately accepts access tokens in
exchange for Resource access.</t>
</list></t>

<t>Shares whose protocols are served by a Protocol Server MUST use the Code
Flow of [OCM] unless the Share uses Introspected Integration: the OCM
Server MUST include <spanx style="verb">must-exchange-token</spanx> in the requirements of every
protocol entry that a Protocol Server serves in Provisioned or
Self-Contained Integration.  Legacy shared-secret access cannot be
verified by a Protocol Server on its own, because the long-lived secret
is deliberately never replicated to it; Introspected Integration exists
precisely to close this gap for Receiving Servers that cannot perform
the token exchange, at the cost of a per-request callback (see Token
Introspection and Security Considerations).</t>

<section anchor="note-delegating-the-token-endpoint"><name>Note: Delegating the Token Endpoint</name>

<t>This note is non-normative.</t>

<t>The <spanx style="verb">tokenEndPoint</spanx> is advertised as an absolute URL in the OCM Server's
discovery document, and nothing in [OCM] requires it to be served from
the OCM Server's own host.  Token issuance can therefore, in principle,
be delegated to a separate Token Server, in the same spirit as the rest
of this document:</t>

<t><list style="symbols">
  <t>The Token Server holds its own signing keypair, and the OCM Server
publishes the public key in its own <spanx style="verb">/.well-known/jwks.json</spanx> under a
<spanx style="verb">kid</spanx> in its own domain.  The <spanx style="verb">iss</spanx> and <spanx style="verb">kid</spanx> rules of this document
(see Token Issuance by the OCM Server) are then satisfied without any
private key leaving the Token Server, and token
verification by Receiving Servers and Protocol Servers is unchanged.</t>
  <t>The Token Server learns about Shares through a special case of the
back channel: a share preparation request, by which the OCM Server sends
the information needed for issuance (the parties, the <spanx style="verb">providerId</spanx> or
the <spanx style="verb">ocm_ip</spanx> contents, the expiration) and receives in response a
<spanx style="verb">sharedSecret</spanx> minted by the Token Server.  The OCM Server forwards that
secret to the Receiving Server in the Share Creation Notification,
without needing to retain it.  The code presented in the Code Flow is
thereby validated by the very server that minted it, and the secret is
never stored outside the Token Server.</t>
</list></t>

<t>In such a deployment the OCM Server is reduced to pure federation logic:
discovery, Share bookkeeping, notifications and invites, with both token
issuance and Resource access served elsewhere.  The share preparation
request is identical to a request sent over the normal back channel, the
only difference being that the response from the Token Server includes
the <spanx style="verb">sharedSecret</spanx>.</t>

</section>
</section>
<section anchor="the-transparency-requirement"><name>The Transparency Requirement</name>

<t>OCM-IP is purely a protocol between the Sending Server and the Protocol
Server.  The Receiving Server MUST NOT be required to implement, or even
be aware of, OCM-IP.</t>

<t>Concretely, everything observable by the Receiving Server and the
Receiving Party MUST be indistinguishable from a deployment in which the
Sending Server serves the access protocols itself:</t>

<t><list style="symbols">
  <t>The protocol endpoints advertised in OCM API Discovery and in Share
Creation Notifications are ordinary URIs (or <spanx style="verb">host:port</spanx> addresses for
SSH); whether they are served by the OCM Server, by a reverse proxy in
front of a Protocol Server, or by a Protocol Server on a different
hostname is invisible at the OCM layer.</t>
  <t>Access tokens are obtained from the OCM Server's <spanx style="verb">tokenEndPoint</spanx> and
presented to the advertised protocol endpoint, exactly as specified in
[OCM].</t>
  <t>Errors returned by the Protocol Server on the front channel use the
semantics of the access protocol concerned.</t>
</list></t>

<t>A consequence of this requirement is that no OCM capability or criterium
is defined for OCM-IP: there is nothing for a remote peer to discover.</t>

</section>
<section anchor="topologies"><name>Topologies</name>

<t>The mapping between OCM Servers and Protocol Servers is many-to-many:</t>

<t><list style="symbols">
  <t>An OCM Server MAY pair with multiple Protocol Servers, for example one
serving WebDAV and another serving a web application platform, and MAY
provision the same Share to more than one of them when the Share offers
multiple protocols.</t>
  <t>A Protocol Server MAY be paired with multiple OCM Servers.  Share
Records are keyed by the pair (sender domain, providerId), so records
provisioned by different OCM Servers cannot collide and access tokens
issued by one OCM Server cannot address records provisioned by another.
In Self-Contained Integration the same isolation holds trivially: a
token is honored only if its issuer is paired, and grants only what its
own claims describe.</t>
</list></t>

</section>
</section>
<section anchor="pairing"><name>Pairing</name>

<t>Before a Protocol Server serves any Share, the OCM Server and the
Protocol Server MUST be paired.  Pairing is performed out of band,
typically by the operators of the two systems, and consists of at least:</t>

<t><list style="symbols">
  <t>On the OCM Server: which protocols and resource types the Protocol
Server is responsible for, which integration mode(s) to use, and, for
Provisioned Integration, the base URL of the Integration API of the
Protocol Server (referred to as <spanx style="verb">{integrationAPI}</spanx> below).  For
Introspected Integration, additionally the domain of the Protocol
Server, used to verify its introspection requests.</t>
  <t>On the Protocol Server: the domain(s) of the paired OCM Server(s) and
the integration mode(s) permitted for each.  The Protocol Server MUST
maintain an allowlist of paired OCM Server domains, MUST reject
Integration API requests whose sender is not on that allowlist, and MUST
NOT honor the <spanx style="verb">ocm_ip</spanx> claim of tokens whose issuer is not paired for
Self-Contained Integration.  For Introspected Integration, additionally
the URL of the introspection endpoint (referred to as
<spanx style="verb">{introspectionEndPoint}</spanx> below).</t>
</list></t>

<t>No shared secret is exchanged during pairing.  All trust on the back
channel derives from HTTP Message Signatures [RFC9421] made with the OCM
Server's signatory key, verified against the keys the OCM Server
publishes at <spanx style="verb">https://&lt;domain&gt;/.well-known/jwks.json</spanx> [RFC7517], as
specified in [OCM].  All trust on the front channel derives from the JWT
signatures on the access tokens, verified against the same published
keys.  Trust in introspection requests derives, symmetrically, from HTTP
Message Signatures made with the Protocol Server's key, published at the
Protocol Server's own <spanx style="verb">/.well-known/jwks.json</spanx>.</t>

<t>The Protocol Server consequently does not need a signing keypair of its
own to implement this protocol, unless it uses Introspected Integration,
which requires it to sign its introspection requests (see Token
Introspection).</t>

</section>
<section anchor="integration-api"><name>Integration API</name>

<t>The Integration API is the back channel of Provisioned Integration.  A
Protocol Server that supports only Self-Contained Integration does not
expose it, and an OCM Server never calls it for self-contained Shares.</t>

<section anchor="general-requirements"><name>General Requirements</name>

<t>All Integration API requests:</t>

<t><list style="symbols">
  <t>MUST be made over TLS (implementations MAY fall back to plain HTTP in
testing setups only),</t>
  <t>MUST use the HTTP POST method with <spanx style="verb">application/json</spanx> as the
<spanx style="verb">Content-Type</spanx> request header,</t>
  <t>MUST be signed with an HTTP Message Signature [RFC9421] carrying the
label <spanx style="verb">ocm</spanx>, following the same rules as server-to-server requests in
[OCM]: the signature MUST cover at least <spanx style="verb">@method</spanx>, <spanx style="verb">@target-uri</spanx>,
<spanx style="verb">content-digest</spanx>, <spanx style="verb">content-length</spanx> and <spanx style="verb">date</spanx>, MUST include the
<spanx style="verb">created</spanx> parameter, and MUST be made with an asymmetric algorithm using
a key advertised in the OCM Server's <spanx style="verb">/.well-known/jwks.json</spanx>.</t>
</list></t>

<t>On receipt of an Integration API request, the Protocol Server:</t>

<t><list style="numbers" type="1">
  <t>MUST parse the <spanx style="verb">sender</spanx> field from the request body and derive the
sender domain from the part after the last <spanx style="verb">@</spanx> sign.</t>
  <t>MUST verify that the sender domain is on its allowlist of paired OCM
Servers, and reject the request with HTTP status 401 otherwise.</t>
  <t>MUST verify the <spanx style="verb">ocm</spanx>-labeled signature against the JWKS of the
sender domain, following the verification rules of [OCM] (single <spanx style="verb">ocm</spanx>
label, required covered components, content-digest match [RFC9530],
<spanx style="verb">created</spanx>
within a freshness window, <spanx style="verb">keyid</spanx> domain equal to the sender domain),
and reject the request with HTTP status 401 on any failure.</t>
</list></t>

<t>Note that, unlike the Share Creation Notification of [OCM], where the
verification key is discovered from the <spanx style="verb">sender</spanx> field of an arbitrary
remote server, the allowlist check in step 2 happens before any key
fetching: a Protocol Server never fetches keys from, or processes
payloads of, servers it is not paired with.</t>

<t>If the Protocol Server is deployed behind a TLS-terminating reverse
proxy, it MUST reconstruct the <spanx style="verb">@target-uri</spanx> that the OCM Server signed
(i.e., the public URL) when verifying signatures, for example from
forwarding headers set by the proxy.</t>

</section>
<section anchor="share-provisioning-request"><name>Share Provisioning Request</name>

<t>To provision a Share, the OCM Server MUST send a Share Provisioning
Request:</t>

<t><list style="symbols">
  <t>to <spanx style="verb">{integrationAPI}/shares</spanx>,</t>
  <t>before sending the corresponding Share Creation Notification to the
Receiving Server (see Lifecycle below),</t>
  <t>with a request body containing a JSON document as described below.</t>
</list></t>

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

<t>The request body is the Share Creation Notification object of [OCM] that
the OCM Server intends to send to the Receiving Server, with one
transformation applied: every <spanx style="verb">sharedSecret</spanx> field, in every protocol
entry, MUST be removed.  The Protocol Server never receives, stores, or
needs any OCM secret.</t>

<t>The fields used by the Protocol Server are thus:</t>

<t><list style="symbols">
  <t>REQUIRED <spanx style="verb">sender</spanx> (string) - OCM Address of the user that creates the
Share.  The domain part identifies the paired OCM Server and selects the
verification keys, as described above.</t>
  <t>REQUIRED <spanx style="verb">owner</spanx> (string) - OCM Address of the user that owns the
Resource.  Used for identity binding on the front channel.</t>
  <t>REQUIRED <spanx style="verb">shareWith</spanx> (string) - OCM Address of the Receiving Party.
Used for identity binding on the front channel.</t>
  <t>REQUIRED <spanx style="verb">providerId</spanx> (string) - as in [OCM]; opaque identifier of the
Share at the OCM Server, unique per Share.  It keys the Share Record and
links the back channel to the front channel (see below).</t>
  <t>REQUIRED <spanx style="verb">shareType</spanx> (string) - as in [OCM].</t>
  <t>REQUIRED <spanx style="verb">resourceType</spanx> (string) - as in [OCM].</t>
  <t>REQUIRED <spanx style="verb">protocol</spanx> (object) - as in [OCM], transformed as described
above.  The protocol entries carry the protocol-specific information the
Protocol Server needs to serve the Share (for example the <spanx style="verb">webdav</spanx>
entry's <spanx style="verb">uri</spanx> and <spanx style="verb">permissions</spanx>, or the <spanx style="verb">webapp</spanx> entry's <spanx style="verb">viewMode</spanx>).</t>
  <t>OPTIONAL <spanx style="verb">name</spanx>, <spanx style="verb">description</spanx>, <spanx style="verb">ownerDisplayName</spanx>,
<spanx style="verb">senderDisplayName</spanx>, <spanx style="verb">expiration</spanx> - as in [OCM]; informational, except
<spanx style="verb">expiration</spanx>, which the Protocol Server SHOULD honor (see Lifecycle).</t>
</list></t>

<t>Additional fields from the Share Creation Notification MAY be present
and MUST be ignored if not understood.</t>

</section>
<section anchor="the-providerid"><name>The providerId</name>

<t>The <spanx style="verb">providerId</spanx> is the link between the back channel and the front
channel, and the following rules apply:</t>

<t><list style="symbols">
  <t>[OCM] guarantees that the <spanx style="verb">providerId</spanx> is unique per Share, so the
pair (sender domain, providerId) identifies exactly one Share Record.</t>
  <t>The OCM Server MUST set the <spanx style="verb">client_id</spanx> claim of every access token it
issues for this Share (via its <spanx style="verb">tokenEndPoint</spanx>) to exactly the
<spanx style="verb">providerId</spanx>.  This constrains a value that the token profile of this
document (see Token Issuance by the OCM Server) otherwise leaves at the
OCM Server's discretion.</t>
  <t>The <spanx style="verb">providerId</spanx> is an identifier, not a credential: the Receiving
Server learns it from the Share Creation Notification anyway.
Possession of a <spanx style="verb">providerId</spanx> MUST NOT grant any access by itself; all
front channel authorization derives from the verified access token.
Consequently, the <spanx style="verb">providerId</spanx> does not need to be unguessable, and it
MAY appear in URLs and logs.</t>
</list></t>

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

<t>On success the Protocol Server MUST respond with HTTP status 201 and a
JSON object with the following fields:</t>

<t><list style="symbols">
  <t>OPTIONAL <spanx style="verb">status</spanx> (string) - e.g. <spanx style="verb">"stored"</spanx>.</t>
  <t>OPTIONAL <spanx style="verb">protocol</spanx> (object) - protocol details allocated by the
Protocol Server for this Share, in the same format as the <spanx style="verb">protocol</spanx>
object of [OCM].</t>
</list></t>

<t>When the response contains a <spanx style="verb">protocol</spanx> object, the OCM Server SHOULD
use its field values (for example, a per-share <spanx style="verb">uri</spanx> allocated by the
Protocol Server) when constructing the corresponding protocol entries of
the outbound Share Creation Notification, in place of statically
configured values from the pairing.  This allows a Protocol Server to
allocate endpoints dynamically, per Share.</t>

<t>Two restrictions apply to the response <spanx style="verb">protocol</spanx> object:</t>

<t><list style="symbols">
  <t>It MUST NOT contain <spanx style="verb">sharedSecret</spanx> fields, and an OCM Server MUST
ignore any <spanx style="verb">sharedSecret</spanx> found in a Share Provisioning Response.
(Delegated token issuance is the exception: the share preparation
request is this same request sent to a Token Server, whose response
legitimately carries the <spanx style="verb">sharedSecret</spanx> it minted; see the note on
delegating the token endpoint.)</t>
  <t>The OCM Server MUST NOT take permissions from the response: the
Share's permissions are decided by the Sending Party and the OCM Server,
never by the Protocol Server.</t>
</list></t>

<t>Fields in the response <spanx style="verb">protocol</spanx> object that the OCM Server does not
understand MUST be ignored.</t>

<t>A Share Provisioning Request for a (sender domain, providerId) pair that
already has a Share Record MUST replace the existing record and respond
with HTTP status 201.  This makes provisioning idempotent and gives the
OCM Server a way to update a Share (for example after a permissions
change) by re-provisioning it.</t>

<t>Error responses:</t>

<t><list style="symbols">
  <t>400 - the request body is not valid JSON, or a required field is
missing or malformed.</t>
  <t>401 - the signature is missing, malformed, stale or invalid, or the
sender domain is not on the allowlist of paired OCM Servers.</t>
  <t>503 - the Protocol Server is temporarily unable to provision the
Share.</t>
</list></t>

</section>
</section>
<section anchor="share-revocation-request"><name>Share Revocation Request</name>

<t>When a Share is deleted, expires, is declined by the Receiving Party, or
access is otherwise withdrawn, the OCM Server SHOULD send a Share
Revocation Request:</t>

<t><list style="symbols">
  <t>to <spanx style="verb">{integrationAPI}/revoke</spanx>,</t>
  <t>with a request body containing a JSON document with the following
fields:</t>
  <t>REQUIRED <spanx style="verb">sender</spanx> (string) - an OCM Address whose domain part
identifies the paired OCM Server, subject to the same allowlist and
signature checks as all Integration API requests.</t>
  <t>REQUIRED <spanx style="verb">providerId</spanx> (string) - the <spanx style="verb">providerId</spanx> of the Share to
revoke.</t>
</list></t>

<t>On receipt of a valid Share Revocation Request, the Protocol Server MUST
stop serving the identified Share, MUST delete the Share Record, and
SHOULD release any resources associated with it (for example, stopping a
computational session that was started for the Share, or invalidating
local sessions derived from its access tokens).</t>

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

<t>Revocation MUST be idempotent: if no Share Record exists for the given
(sender domain, providerId), the Protocol Server MUST respond with HTTP
status 200, so that the OCM Server can treat revocation as
fire-and-forget.  This document defines one OPTIONAL response field:</t>

<t><list style="symbols">
  <t>OPTIONAL <spanx style="verb">status</spanx> (string) - e.g. <spanx style="verb">"revoked"</spanx> when a record was found
and revoked, <spanx style="verb">"gone"</spanx> when there was nothing to revoke.</t>
</list></t>

<t>Error responses are as for Share Provisioning.</t>

</section>
</section>
<section anchor="liveness"><name>Liveness</name>

<t>A Protocol Server SHOULD respond to a GET request to <spanx style="verb">{integrationAPI}</spanx>
(or <spanx style="verb">{integrationAPI}/</spanx>) with HTTP status 200 and a JSON object, so that
operators and OCM Servers can verify reachability of the Integration
API.  The contents of the object are not specified.</t>

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

<t>Token introspection is the credential validation path of Introspected
Integration.  The introspection endpoint is hosted by the OCM Server or,
when token issuance is delegated, by its Token Server; its URL,
<spanx style="verb">{introspectionEndPoint}</spanx>, is exchanged during pairing.  It is not
advertised in the OCM discovery document: like the Integration API, it
is invisible to the federation.</t>

<t>Note that a legacy credential is opaque and carries no issuer
information, so the Protocol Server has no way to determine which paired
OCM Server to introspect against; Introspected Integration therefore
cannot work in multi-tenant deployments, where one Protocol Server
serves more than one OCM Server through the same protocol endpoint.</t>

<section anchor="request"><name>Request</name>

<t>To validate a presented credential, the Protocol Server sends an HTTP
POST request to <spanx style="verb">{introspectionEndPoint}</spanx> as specified by [RFC7662]: the
request body is <spanx style="verb">application/x-www-form-urlencoded</spanx> with a <spanx style="verb">token</spanx>
parameter carrying the credential exactly as presented on the front
channel.  The credential MAY be a legacy <spanx style="verb">sharedSecret</spanx> or a JWT access
token; the endpoint MUST accept any credential that is valid for a Share
at this OCM Server.</t>

<t>The request MUST be made over TLS and MUST be signed with an HTTP
Message Signature [RFC9421] carrying the label <spanx style="verb">ocm</spanx>, with the same
covered components and <spanx style="verb">created</spanx> rules as Integration API requests.  The
<spanx style="verb">keyid</spanx> MUST identify a key in the Protocol Server's own JWKS, published
at <spanx style="verb">https://&lt;protocol-server-domain&gt;/.well-known/jwks.json</spanx> [RFC7517].
The introspection endpoint MUST verify that the <spanx style="verb">keyid</spanx> domain belongs
to a paired Protocol Server and MUST verify the signature against that
domain's JWKS before evaluating the credential; unauthenticated or
unpaired requests MUST be rejected without revealing whether the
presented credential is valid.  This authentication requirement is what
keeps the endpoint from acting as a credential-validity oracle (Section
4 of [RFC7662]).</t>

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

<t>The response is an [RFC7662] introspection response.  For an unknown,
expired or revoked credential the endpoint MUST respond with <spanx style="verb">{"active":
false}</spanx> and no other members.  For a valid credential the response
object MUST contain:</t>

<t><list style="symbols">
  <t><spanx style="verb">active</spanx> (boolean) - <spanx style="verb">true</spanx>.</t>
  <t><spanx style="verb">iss</spanx>, <spanx style="verb">sub</spanx>, <spanx style="verb">aud</spanx> (strings) - with the claim semantics this document
defines for access tokens (see Token Issuance by the OCM Server).</t>
  <t><spanx style="verb">exp</spanx> (integer) - for a JWT, the token's own <spanx style="verb">exp</spanx>; for a legacy
<spanx style="verb">sharedSecret</spanx>, the time until which the Protocol Server may rely on
this response.  The endpoint MUST set a short horizon (on the order of
minutes), since <spanx style="verb">exp</spanx> also bounds revocation latency.</t>
  <t><spanx style="verb">client_id</spanx> (string) - the Share's <spanx style="verb">providerId</spanx>, when the Share is
provisioned to the calling Protocol Server.</t>
  <t><spanx style="verb">ocm_ip</spanx> (object) - the Share information as defined for the <spanx style="verb">ocm_ip</spanx>
claim, when the Share is not provisioned to the calling Protocol Server.</t>
</list></t>

<t>The Protocol Server uses exactly one of these: a <spanx style="verb">client_id</spanx> naming a
Share Record, or the <spanx style="verb">ocm_ip</spanx> member, as described in Token
Verification.</t>

<t>The Protocol Server MAY cache a positive response until its <spanx style="verb">exp</spanx> and
MUST NOT rely on it beyond that.  Negative responses SHOULD NOT be
cached for more than a brief interval.</t>

</section>
</section>
<section anchor="front-channel-resource-access"><name>Front Channel: Resource Access</name>

<section anchor="token-issuance-by-the-ocm-server"><name>Token Issuance by the OCM Server</name>

<t>Token issuance follows the Code Flow of [OCM]: the Receiving Server
exchanges the <spanx style="verb">sharedSecret</spanx> from the Share Creation Notification for an
access token at the OCM Server's <spanx style="verb">tokenEndPoint</spanx>.  [OCM] treats the
issued <spanx style="verb">access_token</spanx> as an opaque bearer credential and leaves its
format at the issuer's discretion.  This document profiles that format.</t>

<t>For every Share in Provisioned or Self-Contained Integration, the
<spanx style="verb">access_token</spanx> MUST be a JWT conforming to the JWT Profile for OAuth 2.0
Access Tokens [RFC9068].  The JOSE header MUST include <spanx style="verb">typ</spanx> with the
value set to <spanx style="verb">at+jwt</spanx> and MUST include a <spanx style="verb">kid</spanx> parameter identifying the
OCM Server's signatory key advertised in <spanx style="verb">/.well-known/jwks.json</spanx>, and
MUST NOT use <spanx style="verb">none</spanx> as the <spanx style="verb">alg</spanx>.  The JWT MUST be signed with the
private key corresponding to that signatory key, allowing anyone with
access to the corresponding public key, including a Protocol Server, to
verify the token independently.  The <spanx style="verb">expires_in</spanx> value of the token
response MUST agree with the <spanx style="verb">exp</spanx> claim.  Receiving Servers are
unaffected: they continue to treat the token as opaque, per [OCM].</t>

<t>The JWT Claims Set MUST include the claims required by [RFC9068], with
the following OCM-specific semantics, on which the Protocol Server
relies:</t>

<t><list style="symbols">
  <t><spanx style="verb">iss</spanx> - the Sending Server identifier, derived from the scheme and
authority of the signatory keyId.</t>
  <t><spanx style="verb">sub</spanx> - the Share owner on the Sending Server.</t>
  <t><spanx style="verb">aud</spanx> - the OCM principal authorized by the token, i.e. the
<spanx style="verb">shareWith</spanx> value of the Share.  Per Section 4.1.3 of [RFC7519] the
interpretation of audience values is application-specific, and this
document defines that interpretation.</t>
  <t><spanx style="verb">client_id</spanx> - as defined in Section 4.3 of [RFC8693], which forwards
to Section 2.2 of [RFC6749].  Verifiers MUST NOT assume a particular
size or format beyond what this document specifies per integration
mode.</t>
  <t><spanx style="verb">iat</spanx>, <spanx style="verb">exp</spanx>, <spanx style="verb">jti</spanx> - as in [RFC9068].</t>
</list></t>

<t>Further requirements apply per integration mode.</t>

<t>For a Share in Provisioned Integration:</t>

<t><list style="symbols">
  <t>The <spanx style="verb">client_id</spanx> claim MUST equal the <spanx style="verb">providerId</spanx> of the Share.</t>
  <t>The token MUST NOT carry the <spanx style="verb">ocm_ip</spanx> claim.  Mixing the modes for a
single Share would allow a self-contained token to outlive the
revocation of the Share Record (see Security Considerations).</t>
</list></t>

<t>For a Share in Self-Contained Integration:</t>

<t><list style="symbols">
  <t>The token MUST carry the <spanx style="verb">ocm_ip</spanx> claim described in the next section.</t>
  <t>The <spanx style="verb">exp</spanx> claim MUST NOT be later than the Share's <spanx style="verb">expiration</spanx>, when
the Share has one.</t>
  <t>The token SHOULD be short-lived: the RECOMMENDED lifetime is on the
order of minutes or for special use-cases, hours, relying on the
Receiving Server to re-exchange the <spanx style="verb">sharedSecret</spanx> for a fresh token per
[OCM].  Because no revocation signal exists in this mode, the remaining
lifetime of the longest-lived valid token is exactly how long access
survives the end of the Share.</t>
  <t>Once the Share ends, the OCM Server MUST NOT issue further tokens for
it.  This holds in all modes, but in Self-Contained Integration it is
the only revocation mechanism.</t>
</list></t>

<t>For a Share in Introspected Integration, no additional issuance
requirements apply.  Typically no token is issued at all, since this
mode serves Receiving Servers that present the legacy <spanx style="verb">sharedSecret</spanx>
directly.  Should such a Share nevertheless be exchanged for tokens, the
Protocol Server can validate those tokens through the same introspection
endpoint.</t>

</section>
<section anchor="the-ocmip-claim"><name>The ocm_ip Claim</name>

<t>The value of the <spanx style="verb">ocm_ip</spanx> claim is a JSON object carrying the Share
information that the Share Provisioning Request carries in Provisioned
Integration.  The Share's parties are deliberately not part of the
claim: the owner and the Receiving Party are already bound by the <spanx style="verb">sub</spanx>,
<spanx style="verb">iss</spanx> and <spanx style="verb">aud</spanx> claims of the enclosing token.</t>

<t>Fields:</t>

<t><list style="symbols">
  <t>REQUIRED <spanx style="verb">protocol</spanx> (object) - as the <spanx style="verb">protocol</spanx> object of [OCM],
restricted to the protocol entries this token grants access to.  It MUST
NOT contain <spanx style="verb">sharedSecret</spanx> fields.</t>
  <t>REQUIRED <spanx style="verb">providerId</spanx> (string) - as in [OCM]; opaque identifier of the
Share at the OCM Server, useful for logging and correlation.</t>
  <t>REQUIRED <spanx style="verb">resourceType</spanx> (string) - as in [OCM].</t>
  <t>OPTIONAL <spanx style="verb">name</spanx> (string) - as in [OCM].</t>
  <t>OPTIONAL <spanx style="verb">shareType</spanx> (string) - as in [OCM].</t>
  <t>OPTIONAL <spanx style="verb">expiration</spanx> (integer) - as in [OCM].</t>
</list></t>

<t>Fields in the <spanx style="verb">ocm_ip</spanx> claim that the Protocol Server does not
understand MUST be ignored.</t>

</section>
<section anchor="token-verification-by-the-protocol-server"><name>Token Verification by the Protocol Server</name>

<t>When a front-channel request presents a credential, the Protocol Server
MUST authorize it as follows:</t>

<t><list style="numbers" type="1">
  <t>If the credential parses as a JWT, extract the <spanx style="verb">iss</spanx> claim without
trusting it; reject the credential if <spanx style="verb">iss</spanx> is missing or is not an
<spanx style="verb">https</spanx> URL, and continue with step 2.  If it does not parse as a JWT,
or when the Protocol Server prefers introspection over local
verification, validate the credential through Token Introspection
instead: an <spanx style="verb">active</spanx> response supplies the fields (<spanx style="verb">iss</spanx>, <spanx style="verb">sub</spanx>, <spanx style="verb">aud</spanx>,
<spanx style="verb">exp</spanx>, <spanx style="verb">client_id</spanx>, <spanx style="verb">ocm_ip</spanx>) used in steps 4 to 6, and steps 2 and 3
are skipped; an inactive response means the request is rejected.</t>
  <t>Resolve the signing key: fetch (or use a cached copy of) the JWKS at
<spanx style="verb">https://&lt;iss-host&gt;/.well-known/jwks.json</spanx> and select the key matching
the token's <spanx style="verb">kid</spanx> header parameter.</t>
  <t>Verify the token signature and validity per [RFC9068]: the algorithm
MUST be an asymmetric algorithm matching the key, MUST NOT be <spanx style="verb">none</spanx>,
and the <spanx style="verb">exp</spanx> claim MUST be in the future.  The claims <spanx style="verb">iss</spanx>, <spanx style="verb">sub</spanx>,
<spanx style="verb">aud</spanx>, <spanx style="verb">exp</spanx> and <spanx style="verb">client_id</spanx> MUST all be present.</t>
  <t>Determine the integration mode:
  <list style="symbols">
      <t>If a Share Record exists for the pair (host part of <spanx style="verb">iss</spanx>,
<spanx style="verb">client_id</spanx> claim), the token is authorized against that record
(Provisioned Integration).  Any <spanx style="verb">ocm_ip</spanx> claim in the token MUST be
ignored.</t>
      <t>Otherwise, if the verified token carries an <spanx style="verb">ocm_ip</spanx> claim and the
host part of <spanx style="verb">iss</spanx> is paired for Self-Contained Integration, or the
introspection response carries an <spanx style="verb">ocm_ip</spanx> member, the credential is
authorized against those claims.</t>
      <t>Otherwise, reject the request.  Because Share Records only come
into existence through signed back-channel requests from paired OCM
Servers, the <spanx style="verb">ocm_ip</spanx> claim is only honored for paired issuers, and
introspection only ever consults paired endpoints, credentials from
unrelated issuers, however validly signed, grant nothing.</t>
    </list></t>
  <t>Perform identity binding (next section).</t>
  <t>Serve the request according to the protocol entry of the Share Record
or of the <spanx style="verb">ocm_ip</spanx> claim or member, honoring its permissions (e.g.
<spanx style="verb">protocol.webdav.permissions</spanx>), its <spanx style="verb">expiration</spanx> if present, and any
protocol-specific restrictions.</t>
</list></t>

<t>The token's <spanx style="verb">exp</spanx> claim is authoritative for token lifetime.  Any expiry
hint delivered alongside the token on the front channel (such as the
<spanx style="verb">access_token_ttl</spanx> form field used by WOPI-style web applications) MUST
agree with the <spanx style="verb">exp</spanx> claim, otherwise the access MUST be rejected.</t>

<t>The Protocol Server MAY cache JWKS documents.  It SHOULD bound the cache
lifetime so that key rotation and key revocation at the OCM Server take
effect within a reasonable time.</t>

</section>
<section anchor="identity-binding"><name>Identity Binding</name>

<t>In Provisioned Integration, a valid signature and a matching Share
Record are not sufficient: the token MUST also be bound to the
identities stored in the record.  The Protocol Server MUST verify that:</t>

<t><list style="symbols">
  <t>the OCM Address formed as <spanx style="verb">&lt;sub&gt;@&lt;iss-host&gt;</spanx> equals the Share Record's
<spanx style="verb">owner</spanx>, and</t>
  <t>the <spanx style="verb">aud</spanx> claim equals the Share Record's <spanx style="verb">shareWith</spanx>.</t>
</list></t>

<t>Comparison of OCM Addresses SHOULD be performed after canonicalising the
host part (lowercasing, removing any stray scheme prefix or trailing
slash); the identifier part is opaque and MUST be compared byte for
byte.</t>

<t>These checks ensure that an access token can only be used for the exact
Share it was issued for: a token legitimately issued to one Receiving
Party for one Resource cannot be replayed against a Share Record
involving any other party or Resource, even at the same Protocol Server
and from the same OCM Server.  The same checks apply when the fields
come from an introspection response that names a Share Record via
<spanx style="verb">client_id</spanx>.</t>

<t>In Self-Contained Integration, and when serving from the <spanx style="verb">ocm_ip</spanx> member
of an introspection response, there is no stored record to compare
against: the credential itself is the authority, and the owner and the
Receiving Party are read directly from <spanx style="verb">&lt;sub&gt;@&lt;iss-host&gt;</spanx> and <spanx style="verb">aud</spanx>.
The cross-checks above therefore do not apply; what remains is to
enforce the scope of the <spanx style="verb">ocm_ip</spanx> claim (protocol entries, permissions,
expiration) and, where the protocol concerned authenticates the
Receiving Party, to derive that identity from <spanx style="verb">aud</spanx> using the same
canonicalisation rules.</t>

</section>
<section anchor="token-presentation-per-protocol"><name>Token Presentation per Protocol</name>

<t>How the access token reaches the Protocol Server depends on the access
protocol, and follows [OCM] and its protocol-specific companion
specifications.  Non-normative summary:</t>

<t><list style="symbols">
  <t><spanx style="verb">webdav</spanx> - the Receiving Server acts as the API client and presents
the token in the <spanx style="verb">Authorization: Bearer</spanx> header of its WebDAV requests
to the advertised <spanx style="verb">webdav</spanx> endpoint.</t>
  <t><spanx style="verb">webapp</spanx> - the Receiving Server delivers the token to the Receiving
Party's user agent, which presents it to the advertised <spanx style="verb">webapp</spanx>
endpoint via a form POST (<spanx style="verb">access_token</spanx> field), keeping the token out
of URLs.  The Protocol Server typically responds by establishing a
session (e.g. a cookie scoped to the application) and serving the
application.</t>
  <t><spanx style="verb">ssh</spanx> - SSH access is authenticated with the recipient's public key
per [OCM] rather than with a bearer token.  An SSH/SFTP Protocol Server
uses the Share Provisioning Request to learn which key material and
paths to authorize, and the Share Revocation Request to withdraw that
authorization.  The token verification rules of this section do not
apply to the SSH data channel itself, and Self-Contained Integration is
consequently not applicable to <spanx style="verb">ssh</spanx>: there is no token presentation
through which an <spanx style="verb">ocm_ip</spanx> claim could travel.</t>
</list></t>

</section>
</section>
<section anchor="lifecycle"><name>Lifecycle</name>

<section anchor="ordering"><name>Ordering</name>

<t>In Provisioned Integration, the OCM Server MUST send the Share
Provisioning Request, and receive a success response, before sending the
Share Creation Notification to the Receiving Server.  If provisioning
fails, the OCM Server MUST NOT create the Share: otherwise the Receiving
Party would be notified of a Share whose Resource access cannot work.</t>

</section>
<section anchor="revocation-and-expiration"><name>Revocation and Expiration</name>

<t>The OCM Server SHOULD send a Share Revocation Request whenever a Share
ends, whatever the cause: unshared by the Sending Party, declined by the
Receiving Party (e.g. on receipt of a <spanx style="verb">SHARE_DECLINED</spanx> notification), or
administratively removed.</t>

<t>Revocation is deliberately fire-and-forget: because it is idempotent on
the Protocol Server side, the OCM Server MAY retry it at any time, and a
failure to deliver it MUST NOT block the unshare operation on the OCM
Server.</t>

<t>The Protocol Server SHOULD apply its own bounds on Share Record lifetime
as a backstop against missed revocations:</t>

<t><list style="symbols">
  <t>If the provisioned Share carries an <spanx style="verb">expiration</spanx>, the Protocol Server
SHOULD stop serving the Share at that time.</t>
  <t>The Protocol Server MAY additionally expire Share Records after an
implementation-defined maximum lifetime; an OCM Server can always
re-provision (idempotently) to extend it.</t>
</list></t>

<t>Note that token expiry alone already limits the damage of a missed
revocation on bearer-token protocols: once the OCM Server stops issuing
fresh tokens for a Share, access ends when the last issued token
expires.</t>

</section>
<section anchor="lifecycle-in-self-contained-integration"><name>Lifecycle in Self-Contained Integration</name>

<t>Self-Contained Integration has no provisioning step and no revocation
push.  The Share's lifecycle is enforced entirely at token issuance:</t>

<t><list style="symbols">
  <t>The OCM Server MUST stop issuing tokens for a Share when it ends,
whatever the cause: unshared by the Sending Party, declined by the
Receiving Party, expired, or administratively removed.</t>
  <t>Until the last issued token expires, the Protocol Server will continue
to honor it.  Revocation latency is therefore bounded by the maximum
token lifetime, which is why the issuance rules require short-lived
tokens in this mode.</t>
</list></t>

<t>Because the Protocol Server keeps no per-share state, there is nothing
for it to expire or reap.  Protocols that do allocate per-share state
are steered to Provisioned Integration (see Integration Modes); a
Protocol Server that nevertheless creates transient state in this mode
(such as login sessions) SHOULD bound its lifetime independently of the
tokens that created it.</t>

</section>
<section anchor="lifecycle-in-introspected-integration"><name>Lifecycle in Introspected Integration</name>

<t>Introspected Integration needs neither provisioning nor a revocation
push for credential validity: every authorization consults the OCM
Server, modulo response caching, so a revoked or expired Share stops
being served as soon as cached introspection responses expire.
Revocation latency is bounded by the <spanx style="verb">exp</spanx> horizon of the responses,
which the introspection endpoint MUST keep short (see Token
Introspection).</t>

<t>Note that introspection only validates credentials.  If the Protocol
Server allocates per-share resources, it still needs the Share
Revocation Request of Provisioned Integration to release them, which is
one reason the two modes compose.</t>

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

<section anchor="no-secret-replication"><name>No Secret Replication</name>

<t>A central design goal of OCM-IP is that delegating protocol work does
not multiply the places where secrets live:</t>

<t><list style="symbols">
  <t>The <spanx style="verb">sharedSecret</spanx> of a Share is never stored on the Protocol Server:
it is stripped from the provisioning payload and absent from the
<spanx style="verb">ocm_ip</spanx> claim.  A compromise of the Protocol Server therefore does not
leak credentials that could be exchanged for tokens at the OCM Server's
<spanx style="verb">tokenEndPoint</spanx>.  (In Introspected Integration the Receiving Server does
present the legacy secret on the front channel; the Protocol Server
forwards it for introspection but MUST NOT retain it beyond the
request.)</t>
  <t>No pairing secret exists; the back channel is authenticated by HTTP
Message Signatures against published keys, the front channel by JWT
signatures against the same keys, and introspection requests by HTTP
Message Signatures against the Protocol Server's published keys.</t>
  <t>The Protocol Server holds no signing keys for this protocol, with two
exceptions: a Protocol Server using Introspected Integration holds a
request-signing key, published at its own <spanx style="verb">/.well-known/jwks.json</spanx>, and
a delegated Token Server (sketched in the note on delegating the token
endpoint) holds its own token-signing key, whose public part is
published through the OCM Server's JWKS.</t>
</list></t>

<t>The Protocol Server does handle bearer access tokens on the front
channel.  These MUST be treated as confidential, MUST NOT be placed in
URLs, and SHOULD NOT be logged or persisted beyond their lifetime,
consistent with the Code Flow considerations of [OCM].</t>

</section>
<section anchor="legacy-shared-secret-access-requires-introspection"><name>Legacy Shared-Secret Access Requires Introspection</name>

<t>Without the Code Flow, the only credential is the long-lived
<spanx style="verb">sharedSecret</spanx> itself, which the Receiving Server presents directly on
the front channel.  The Protocol Server cannot verify it on its own: the
secret is deliberately never replicated to it.  A Protocol Server MUST
NOT accept any front-channel credential other than a verifiable access
token or a credential validated through Token Introspection (or, for
SSH, the public-key mechanism of [OCM]).</t>

<t>Introspected Integration therefore reintroduces, deliberately and only
for compatibility, the per-request coupling to the OCM Server that the
other modes remove.  Deployments that do not need to serve legacy
Receiving Servers SHOULD NOT enable it.</t>

<t>The introspection endpoint is a sensitive interface: left
unauthenticated, it would let anyone test guessed or stolen credentials
for validity (Section 4 of [RFC7662]).  The signature and pairing
requirements of the Token Introspection section are therefore mandatory,
and the endpoint SHOULD additionally rate-limit failed introspections
per caller.</t>

</section>
<section anchor="trust-granted-to-the-paired-ocm-server"><name>Trust Granted to the Paired OCM Server</name>

<t>Pairing grants the OCM Server significant power over the Protocol
Server: every accepted Share Provisioning Request may consume resources
(storage, compute sessions) and instructs the Protocol Server to serve
content to third parties.  The allowlist is therefore REQUIRED, and an
empty allowlist means the Integration API rejects all requests.</t>

<t>The Protocol Server SHOULD apply resource limits per paired OCM Server
(number of Share Records, concurrent sessions, storage) so that a
misbehaving or compromised OCM Server cannot exhaust it.</t>

<t>Conversely, the OCM Server places trust in the Protocol Server to
enforce the permissions and identity bindings of this document.
Operators SHOULD treat the Protocol Server as part of the Sending
Server's trusted computing base for the protocols it serves.</t>

</section>
<section anchor="self-contained-tokens"><name>Self-Contained Tokens</name>

<t>Self-Contained Integration shifts all authority into the token, with
three major consequences:</t>

<t><list style="symbols">
  <t>Revocation latency.  An issued token cannot be withdrawn; it can only
expire.  The normative cap on token lifetime in the issuance rules is
what keeps "unshare" meaningful in this mode, and implementations MUST
NOT relax it by issuing long-lived self-contained tokens for
convenience.</t>
  <t>Metadata exposure.  The <spanx style="verb">ocm_ip</spanx> claim is readable by anyone who holds
the token.  For <spanx style="verb">webapp</spanx> Shares in particular, the token transits the
Receiving Party's user agent, so the embedded Share metadata is visible
to the Receiving Party.  The OCM Server MUST NOT place information in
the <spanx style="verb">ocm_ip</spanx> claim that the Receiving Party is not entitled to see, and
SHOULD keep the claim minimal.</t>
  <t>Allowlist is mandatory.  In Provisioned Integration, pairing is
implicitly enforced by the existence of the Share Record.  In
Self-Contained Integration the issuer allowlist is the only thing
standing between any internet-hosted JWKS and Resource access; the
requirement to check the token's issuer against the pairing allowlist
before honoring an <spanx style="verb">ocm_ip</spanx> MUST be enforced.</t>
</list></t>

<t>Provisioned and Self-Contained Integration MUST NOT be mixed for a
single Share.  If a provisioned Share's tokens also carried <spanx style="verb">ocm_ip</spanx>
claims, a token issued before a Share Revocation Request would continue
to grant access through the self-contained path until it expired,
silently surviving the revocation.  This is why the issuance rules
forbid the <spanx style="verb">ocm_ip</spanx> claim on tokens for provisioned Shares, and why
verification gives an existing Share Record precedence over the claim.
Introspected Integration, by contrast, composes safely with Provisioned
Integration: the introspection response names the Share Record via
<spanx style="verb">client_id</spanx>, and revocation of the record takes effect immediately.</t>

</section>
<section anchor="signature-and-token-verification-considerations"><name>Signature and Token Verification Considerations</name>

<t>All the verification rules of [OCM] for HTTP Message Signatures apply to
the back channel, in particular: exactly one <spanx style="verb">ocm</spanx>-labeled signature,
required covered components, <spanx style="verb">created</spanx> freshness, <spanx style="verb">keyid</spanx> domain
matching the sender domain, and rejection of symmetric algorithms.  Two
considerations deserve emphasis in the Protocol Server context:</t>

<t><list style="symbols">
  <t>Reverse proxies: when TLS terminates in front of the Protocol Server,
the internally observed URI differs from the signed <spanx style="verb">@target-uri</spanx>.  The
Protocol Server MUST reconstruct the public URL for verification, and
MUST only trust forwarding headers set by its own proxy.</t>
  <t>Issuer/key binding: on the front channel, the key used to verify a
token MUST be fetched from the JWKS of the token's own <spanx style="verb">iss</spanx> host, and
the Share Record lookup MUST use that same host.  An implementation that
verifies against one domain's keys but looks up records under another's
would allow cross-tenant confusion on multi-tenant Protocol Servers.</t>
</list></t>

</section>
<section anchor="denial-of-service"><name>Denial of Service</name>

<t>The Integration API performs the allowlist check before fetching any
keys, so unsolicited requests from arbitrary servers are rejected
without outbound traffic.  Front-channel token verification does fetch
JWKS documents from token-asserted issuers; implementations SHOULD
rate-limit verification failures and SHOULD restrict JWKS fetching to
the domains of paired OCM Servers, since no unpaired issuer's credential
can ever be honored in any integration mode.  In Introspected
Integration the Protocol Server additionally generates one introspection
request per uncached front-channel credential; implementations SHOULD
apply negative caching with a short lifetime so that a flood of invalid
credentials does not translate into a flood of introspection traffic
towards the OCM Server.</t>

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

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

<t>The following claim is to be registered in the "JSON Web Token Claims"
registry (using the template from [RFC7519]): Claim Name: ocm_ip Claim
Description: Open Cloud Mesh Share information for self-contained
Protocol Server integration Change Controller: IETF Specification
Document(s): the present Draft, once in RFC form</t>

</section>
<section anchor="oauth-token-introspection-response-registry"><name>OAuth Token Introspection Response Registry</name>

<t>The following member is to be registered in the "OAuth Token
Introspection Response" registry established by [RFC7662]: Name: ocm_ip
Description: Open Cloud Mesh Share information for Protocol Server
integration Change Controller: IETF Specification Document(s): the
present Draft, once in RFC form</t>

<t>No other IANA actions are required.  Neither the Integration API nor the
introspection endpoint is exposed at a Well-Known URI; their locations
are exchanged during pairing.</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>[OCM] Lo Presti, G., de Jong, M.B., Baghbani, M. and Nordin, M.  "<eref target="https://datatracker.ietf.org/doc/draft-ietf-ocm-open-cloud-mesh/">Open
Cloud Mesh</eref>", Work
in Progress.</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>[RFC7517] Jones, M., "<eref target="https://datatracker.ietf.org/doc/html/rfc7517">JSON Web Key (JWK)</eref>", May 2015.</t>

<t>[RFC7519] Jones, M., Bradley, J., Sakimura, N., "<eref target="https://datatracker.ietf.org/doc/html/rfc7519">JSON Web Token
(JWT)</eref>", May 2015.</t>

<t>[RFC7662] Richer, J. (ed), "<eref target="https://datatracker.ietf.org/doc/html/rfc7662">OAuth 2.0 Token Introspection</eref>", October 2015.</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>[RFC9068] Bertocci, V., "<eref target="https://datatracker.ietf.org/doc/html/rfc9068">JSON Web Token (JWT) Profile for OAuth 2.0
Access Tokens</eref>", October
2021.</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>

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

<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>[RFC8693] Jones, M., Nadalin, A., Campbell, B., Bradley, J. and
Mortimore, C., "<eref target="https://datatracker.ietf.org/doc/html/rfc8693">OAuth 2.0 Token Exchange</eref>", January 2020.</t>

</section>
</section>
<section anchor="appendix-a-examples"><name>Appendix A: Examples</name>

<t>The first set of examples shows Provisioned Integration:
<spanx style="verb">cloud.example.org</spanx> is the OCM Server and <spanx style="verb">hub.example.org</spanx> is a
Protocol Server running a computational notebook platform, paired with
<spanx style="verb">cloud.example.org</spanx> and serving the <spanx style="verb">webapp</spanx> protocol.  Alice
(<spanx style="verb">alice@cloud.example.org</spanx>) shares a notebook with Bob
(<spanx style="verb">bob@receiver.example.org</spanx>).  Self-Contained and Introspected
Integration examples follow at the end.</t>

<section anchor="share-provisioning-request-1"><name>Share Provisioning Request</name>

<t>The OCM Server pushes the Share to the Protocol Server before notifying
the Receiving Server.  The body is the Share Creation Notification with
every <spanx style="verb">sharedSecret</spanx> removed (line breaks in the signature headers for
display purposes only):</t>

<figure type="http"><artwork><![CDATA[
POST /services/ocm/shares HTTP/1.1
Host: hub.example.org
Date: Wed, 10 Jun 2026 14:00:00 GMT
Content-Type: application/json
Content-Digest: sha-256=:hj3LWOIuryd4XbzFhoHa6YMUbhtzMdMT3e9Bxpu2Lm0=:
Content-Length: 542
Signature-Input: ocm=("@method" "@target-uri" "content-digest"
"content-length" "date"); created=1781186400;
keyid="cloud.example.org#key1"; alg="ed25519"
Signature: ocm=:[signature-value]:

{
  "shareWith": "bob@receiver.example.org",
  "name": "analysis.ipynb",
  "providerId": "7c084226-d9a1-11e6-bf26-cec0c932ce01",
  "owner": "alice@cloud.example.org",
  "sender": "alice@cloud.example.org",
  "shareType": "user",
  "resourceType": "file",
  "protocol": {
    "name": "multi",
    "webdav": {
      "uri": "7c084226-d9a1-11e6-bf26-cec0c932ce01",
      "permissions": [
        "read",
        "write"
      ]
    },
    "webapp": {
      "uri": "https://hub.example.org/services/ocm/open",
      "viewMode": "write"
    }
  }
}
]]></artwork></figure>

<t>The Protocol Server stores the Share Record under (<spanx style="verb">cloud.example.org</spanx>,
<spanx style="verb">7c084226-d9a1-11e6-bf26-cec0c932ce01</spanx>) and responds:</t>

<figure type="http"><artwork><![CDATA[
HTTP/1.1 201 Created
Content-Type: application/json

{ "status": "stored" }
]]></artwork></figure>

<t>The OCM Server then sends the Share Creation Notification to
<spanx style="verb">receiver.example.org</spanx> per [OCM], with <spanx style="verb">must-exchange-token</spanx> in the
protocol requirements and with the <spanx style="verb">webapp</spanx> entry pointing at the
Protocol Server (and a fresh <spanx style="verb">sharedSecret</spanx>, which only the Receiving
Server learns).</t>

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

<t>When the Receiving Server performs the Code Flow at
<spanx style="verb">https://cloud.example.org/ocm/token</spanx>, the issued JWT carries the JOSE
header:</t>

<figure><sourcecode type="json"><![CDATA[
{
  "typ": "at+jwt",
  "alg": "EdDSA",
  "kid": "cloud.example.org#key1"
}
]]></sourcecode></figure>

<t>and the Claims Set:</t>

<figure><sourcecode type="json"><![CDATA[
{
  "iss": "https://cloud.example.org",
  "sub": "alice",
  "aud": "bob@receiver.example.org",
  "client_id": "7c084226-d9a1-11e6-bf26-cec0c932ce01",
  "iat": 1781186460,
  "exp": 1781190060,
  "jti": "f3b9c0aa-2f6e-4d57-9d24-6f0a1f6d9b11"
}
]]></sourcecode></figure>

</section>
<section anchor="front-channel-access"><name>Front-Channel Access</name>

<t>Bob's user agent form-POSTs the token to the advertised <spanx style="verb">webapp</spanx>
endpoint:</t>

<figure type="http"><artwork><![CDATA[
POST /services/ocm/open HTTP/1.1
Host: hub.example.org
Content-Type: application/x-www-form-urlencoded

access_token=eyJ0eXAiOiJhdCtqd3QiLCJhbGciOiJFZERTQSIs...
]]></artwork></figure>

<t>The Protocol Server verifies the JWT against
<spanx style="verb">https://cloud.example.org/.well-known/jwks.json</spanx>, looks up the Share
Record by (<spanx style="verb">cloud.example.org</spanx>,
<spanx style="verb">7c084226-d9a1-11e6-bf26-cec0c932ce01</spanx>), checks that
<spanx style="verb">alice@cloud.example.org</spanx> equals the stored <spanx style="verb">owner</spanx> and that
<spanx style="verb">bob@receiver.example.org</spanx> equals the stored <spanx style="verb">shareWith</spanx>, and then
starts (or resumes) the notebook session for the Share.</t>

</section>
<section anchor="share-revocation-request-1"><name>Share Revocation Request</name>

<t>When Alice unshares the notebook (body shown without the signature
headers, which are as in the provisioning example):</t>

<figure type="http"><artwork><![CDATA[
POST /services/ocm/revoke HTTP/1.1
Host: hub.example.org
Content-Type: application/json

{
  "sender": "alice@cloud.example.org",
  "providerId": "7c084226-d9a1-11e6-bf26-cec0c932ce01"
}
]]></artwork></figure>

<figure type="http"><artwork><![CDATA[
HTTP/1.1 200 OK
Content-Type: application/json

{ "status": "revoked" }
]]></artwork></figure>

<t>A repeated revocation for the same <spanx style="verb">providerId</spanx> returns <spanx style="verb">{ "status":
"gone" }</spanx> with HTTP status 200.</t>

</section>
<section anchor="self-contained-integration"><name>Self-Contained Integration</name>

<t><spanx style="verb">dav.example.org</spanx> is a stateless WebDAV gateway in front of an existing
storage system, paired with <spanx style="verb">cloud.example.org</spanx> for Self-Contained
Integration.  No provisioning takes place; the gateway exposes no
Integration API and keeps no Share Records.  Alice shares a folder with
Bob, and the OCM Server advertises a <spanx style="verb">webdav</spanx> endpoint at the gateway in
the Share Creation Notification.</t>

<t>When the Receiving Server performs the Code Flow at
<spanx style="verb">https://cloud.example.org/ocm/token</spanx>, the issued JWT carries:</t>

<figure><sourcecode type="json"><![CDATA[
{
  "iss": "https://cloud.example.org",
  "sub": "alice",
  "aud": "bob@receiver.example.org",
  "client_id": "receiver.example.org",
  "iat": 1781186460,
  "exp": 1781186760,
  "jti": "0d9e3c4b-5a6f-4e21-8c37-2b1a9f8e7d65",
  "ocm_ip": {
    "providerId": "9b2e41d7-aa31-4a02-9f0d-3c5e8b7a6f10",
    "resourceType": "folder",
    "name": "dataset-2026",
    "protocol": {
      "webdav": {
        "uri": "9b2e41d7-aa31-4a02-9f0d-3c5e8b7a6f10",
        "permissions": ["read"]
      }
    }
  }
}
]]></sourcecode></figure>

<t>Note the short lifetime (300 seconds): the Receiving Server re-exchanges
the <spanx style="verb">sharedSecret</spanx> at the <spanx style="verb">tokenEndPoint</spanx> for a fresh token before each
expiry, per [OCM], and unsharing takes effect within at most that
lifetime.</t>

<t>The Receiving Server accesses the Resource directly:</t>

<figure type="http"><artwork><![CDATA[
PROPFIND /dav/9b2e41d7-aa31-4a02-9f0d-3c5e8b7a6f10 HTTP/1.1
Host: dav.example.org
Authorization: Bearer eyJ0eXAiOiJhdCtqd3QiLCJhbGciOiJFZERTQSIs...
Depth: 1
]]></artwork></figure>

<t>The gateway verifies the JWT against
<spanx style="verb">https://cloud.example.org/.well-known/jwks.json</spanx>, finds no Share Record
for (<spanx style="verb">cloud.example.org</spanx>, <spanx style="verb">receiver.example.org</spanx>), confirms that
<spanx style="verb">cloud.example.org</spanx> is paired for Self-Contained Integration, and serves
the PROPFIND read-only, scoped to the <spanx style="verb">uri</spanx> in the <spanx style="verb">ocm_ip</spanx> claim.</t>

</section>
<section anchor="introspected-integration"><name>Introspected Integration</name>

<t><spanx style="verb">legacy.example.com</spanx> is a Receiving Server that does not support the
<spanx style="verb">exchange-token</spanx> capability.  Alice shares the same kind of folder with
Carol (<spanx style="verb">carol@legacy.example.com</spanx>).  The Share Creation Notification is
a legacy [OCM] share: the <spanx style="verb">webdav</spanx> entry points at <spanx style="verb">dav.example.org</spanx> and
carries a <spanx style="verb">sharedSecret</spanx>, with no <spanx style="verb">must-exchange-token</spanx> requirement.
<spanx style="verb">dav.example.org</spanx> is paired with <spanx style="verb">cloud.example.org</spanx> for Introspected
Integration and holds a request-signing key published at
<spanx style="verb">https://dav.example.org/.well-known/jwks.json</spanx>.</t>

<t>The Receiving Server presents the secret directly, per the legacy
resource access flow of [OCM]:</t>

<figure type="http"><artwork><![CDATA[
PROPFIND /dav/4f6a2c81-77b0-4c0e-9e64-1d2f3a5b6c7d HTTP/1.1
Host: dav.example.org
Authorization: Bearer shr-9wq4xkz7vmd2
Depth: 1
]]></artwork></figure>

<t>The credential does not parse as a JWT, so the gateway introspects it
(signature headers as in the provisioning example, but signed by the
gateway with keyid="dav.example.org#key1"):</t>

<figure type="http"><artwork><![CDATA[
POST /ocm/introspect HTTP/1.1
Host: cloud.example.org
Content-Type: application/x-www-form-urlencoded

token=shr-9wq4xkz7vmd2
]]></artwork></figure>

<figure type="http"><artwork><![CDATA[
HTTP/1.1 200 OK
Content-Type: application/json

{
  "active": true,
  "iss": "https://cloud.example.org",
  "sub": "alice",
  "aud": "carol@legacy.example.com",
  "exp": 1781186760,
  "ocm_ip": {
    "providerId": "4f6a2c81-77b0-4c0e-9e64-1d2f3a5b6c7d",
    "resourceType": "folder",
    "name": "dataset-2026",
    "protocol": {
      "webdav": {
        "uri": "4f6a2c81-77b0-4c0e-9e64-1d2f3a5b6c7d",
        "permissions": [
          "read"
        ]
      }
    }
  }
}
]]></artwork></figure>

<t>The gateway serves the PROPFIND read-only and MAY cache this response
until <spanx style="verb">exp</spanx>.  When Alice unshares the folder, introspection starts
returning <spanx style="verb">{"active": false}</spanx>, and Carol's access ends as soon as the
cached response expires.</t>

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

<t>This section collects the changes with respect to the previous version
in the IETF datatracker.  It is meant to ease the review process and it
shall be removed when going to RFC last call.</t>

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

<t><list style="symbols">
  <t>Initial version.</t>
</list></t>

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

<t>This protocol generalizes a working integration between Nextcloud and
JupyterHub developed at SUNET, and builds directly on the Code Flow, JWT
access token, and HTTP Message Signature work in the Open Cloud Mesh
specification.  Thanks to the OCM community for the discussions that
shaped the webapp sharing design this document extends, and in
particular to Enrique Pérez Arnaud and Matthias Kraus who helped shape
the format of this protocol.</t>

<t>Work on this document has been funded by [Sovereign Tech Agency][sta]
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>

</section>


  </middle>

  <back>








  </back>

<!-- ##markdown-source:
H4sIAAAAAAAAA+196XIbV5bm//sUGawfJt0ARFIUJUHtCtNabLm0tSiXu8eh
EBLIBJFWIhOdmSDFqna9zzzHvNic9S65gKS7Zmp6ohVVlgDkcpdzz36+Mx6P
TZM1eTqNvnq7SYvoaV5uk+h1Wq+il0WTXlRxk5VF9K4qm3JR5l+ZpFwU8Rqu
T6p42YyLskqyYlwu1uPMXT/eyPXjw0OziOH7srqeRnWTGJNtqmnUVNu6OT48
fHx4bOIqjafR2WaTZwu6u47iIonep3E+/pCtU/M5vb6C10xpRFWRNuNn+G5j
6gYu/BTnZQHjuU5r+AKetYYLn394YUy8bVZlNTVRNI6yop5GryfRGxovfBVF
PI3X2eJz6n9dVhdxkf2FRjKNzn968/wDfZ+u4yyfRp/jovy23sIoJnVKP2yr
bBqtmmZTT+/dW5RJOqnXZY4XwKPurfH5xo3h+0n0qoT1TOsm84bxfbat080m
bf0YDubp8/dv/LFcyE2TvNzQPd8uYH0mi1XPuPiHe3qlCVblu/hiNYcX+esS
r5Is/CEczLuySNIqOi+31SL1R7XGO7/d0M81/YoL0R1ScMWiXBtjxuNxFM9h
F+MFbO+HVRrdhiij/bdPX49fvjuIknSZFWkdrcoroCG62Xg343UH0XlaXcLA
F3CBkmwa1dvNpqyarLiIavq9HsF3i1UU1+b8/Id75y8+vHO/XKXzKHYEG23y
uFmW1Rp+KquIyHJMZBn9nM6fnf3Z2DubMtqkFV4b2TNSb9JFtswWEVD55wge
lzV1NE9Xcb6cGMNzg1X9DBPLmmhT1nU2z9MIHhKlX7KaBg1XycRqfEe5XOZl
nNh3GPsOnDIuL50zuNIfrB0lPvkSFj5bb/J0nRYNPT+Gg2ny7GLVXKX4X7k+
alZxE63gMTmMsCzya/gmpTs2cQVTKZdRDFuzyctrfNbUJFm9KOHOa1jjFRz/
aAHHFkeE6/MZ31vX27hYpMQI6uyigClOouisuG5W8E/TWTq7WTQmXJBlRqPB
8fEejHAxLrMEf4QdNfFikdY812pb4BsioQhansu0vcsjIpl5SlNNE1xjGK7B
hYNnrEuYh6VI3Qp9cprX6dUqrdKR7t91VAIhAOkl0VXWrGBNlkv4HZa6LpfN
Fa4KTh6owf2SFcsqhtOxXTTbKnW0oWTfrKo0jTw+DKNKUjjiMc+9hq/gffjl
CC6LrlYZLBpslnHkE2229QqedU4bA28EUuVnAbHgvrbmyEsc0y6liZnHi8/R
AlaoSPMn+HWaL8eLsmjirP/VPS/KapOu52mCiwyX4kX89Ij3TImkwYfDzpdM
gT2DM0WaJnVU0KEbM60BwTe8tvB1VszLLfzz7N3LCB4R5zho+MyUUJVIX7BF
pmfc7XW4jPMsgUfXEXJY2C4YL9B1Av/K4rw2sDnl9gJoVIdvn49zTotkU8JX
owjZc1kh0QBP3MCKzLM8a66ZSt6nizQj+raHHaeelDCZRpmYvCD9gvtw4dFJ
VjMl8LjnKZzjlNf3HN4fshFaBmREOk+jb8QTDocRuXN7OPgGHEhWXJb5JW3f
iB6UlCn9QhuClATHKCYiL2EH4VDXdlxTZD0VH3Tkd+Wc2EyNZJHBKInfbTPY
TGKCVbkOZiADUTaAPwnV6AvgMUQ5MIcXZcUvB/5TlzRWWYLgYa/P/i2Kk3ID
BOKf0waP78U1TofYhhxo2qkOK0DqWeRbfKxJJ8DNYJthBjAPGibqQ9FlFjND
TCLQeVDOwJPKbUOUABOFAwx344c8I/ZIb7LMVt44YTm6zhJgyMb8AWVmVSZb
IjSghZZE/QXu/cikIfx8CUQr/MMSCygatG+wh9nyGtbBbf07YPLX9gheA3sE
3jlHygIuRMfAHls4q2ukGhH6xHaSNM/mtHD5tZUigZQikbLdKAOicxIRNyXe
1R5JVgs3IR6Nl2SVDAEON7DOOLdD0KEBbdVbILR/38LOwtvWcRFfwP1zYNPw
gMoRj5M0LFaiX96/eHry+OjRxxGKlZEBkvKEhifcQZrYp8AevSyc9HbCEVWE
LjU31xt4Xg4DsxIZNAQYmdHNV/7BujNcKlPvED8dKSThms4wTHxRbjc5SY/U
3/q8vIBRy5ojS4IF4Yd7ig9dREfcWAUFCBhJZWrM1z0KRFSvYXRwCxyFho4w
0jPIJZJveJ4LHKBdGxMKvRE8tEqBGn1OZt/Cg9pnzSjGb+Ey2ScmbjriqMwZ
/Yz7RWPY8u1AHUDk6bwsP1u97gCWEZh1Ha23eZPhY2E6xts1WhjQmJISTjoM
UVlBzw6gSAetPabfw8k5boaPP5cB+rOxmsqgCoqLGDudAaa5AK0bjkVSgnqO
3D5mlo8KUlRfFwtWslg2XtdNup6g6g2nCEy9Le2d0y/uqJCPDMvLJPWJrLkq
YcELNElq0up8sQPsIL0gMUp0x2zcAEH4elaHqFHl3aGHsbjytZwKjZVCXgJv
gLXYBHyM5LAeIncsjHKmmpjvlDRyVuhrmgZqEs+cflsRc0qZQEArSESzMk9F
5QXTs0H+wJavyNW2biESkKkpYGCmtRR4sNDqzf6CZFIhQ6uRVwDnAKUV9i5h
BgdPBT4uEtL4elVN2jfzPuUuPAykC9i6DQm6JktJs2fxgYefJansH5GkWioq
xpDIcDeBJquUbByngbQ0jx4NCxjK0YSWJ9BWSYYS56n504KEZyTb+HOa5+M/
FeVVQZz60enRg48G1KpVNLs3ucIfP+OP9369+lxPfgUlYIYn6Mef/xSxQkp3
PXxw9PDjyFoj9DJhIOOmHNdKU7LaW6So6IcPYDLCGamRcZ7DbTGe8Zoe+Pjk
+OjjxBzzfJ6Cdhm9yMFozXFZmj7NSrU5+nXGWsI5rePMIIeAUx1ox1ersk7t
HGiT8jRGKkKFtEJhKytE2119VZNZBs+DrXMqI3Ba0TGXYFsADyGKx5lmlXIE
txuoCeHT8Pu6TVbA/X/8+UONRx+HRbTH0gW+xs0mjoRzeXsGNBwdTw6jM3qC
+cBPoJU7PEVRKwZBoADxIL6qLVGQGsV2o6HT7SlhqIevsioZ87EnRrNI2caD
BxZyQkTa8xyM08dA1iwaVTC9FSiR+6KxIcQQzeM6q29tqvFSMzMmqbTGB8qJ
Zga0AAZHsvWdZ9J5D5qqjI3QFhuLLUZ8SU2QfrtPH8e8qkovy8/WDgQ2VlYJ
qmJ9J3Nk4lUak7YVF9dt5WoCYz0PzcBguK0VJNOvdqahCUzDwhepoR2I2gUs
VgJ6BYtxJKtFHmdrYf9trvo5TTeDxmH6BdgXGS2+kfjEhMYJ25dxVRGPB4GS
JalvsNIIcQFeetZkd/rDtmQaw05Zg9I4gzK6nT3J7Ov09PijHnenWogCiAoz
/hCam0iOdNblV1LCUcYShcIpYf7XYVRqkQJ7WKCgkbHzQ1A0LK7b7AuWrRHy
EVGqB6tjyILSjJRNZ2UEe0N0cYl6ESoXfLjI+9e3qnqO0tqQmmnPRtsaYP6t
dOkZ8R3NKGNThfxBbNUCw1xuc/wARwHXCxhxdBXTCsA/QBWD1xhUYUn5FdHh
dGDkf6jeEmeD14u9QYuKjwt1XYPmcx0DY4u7WmvAXsR3RXbctuAFTdDLCHqB
xwZq1kGdlStK7QQNyQ8paDnslwXGiu5KIP691z+df9gb8d/Rm7f07/fP/+Wn
l++fP8N/n/9w9uqV/QdfYeDD259eye/4L3fn07evXz9/84xvhm+j1ldgje+x
ybH39t2Hl2/fnL3aY8bg7wyeZt4R0tiADMkSRSIBKQcWJ/mWvnv6Ljo6MXhI
jo+OHn9kHeHo4clHNDDFeUGkzx/JwAW1O40rUrSBFhfxBgwZNAxj0AlWqGig
adohFbJaxMoqcxD2RGO4ojyqpXBGFtZT80mp8tMo+kSc0P4j6lUe6efAbvw0
wqeE59O/iuxl/KJlQuNXpMsmCZzeGh/jKOQTL8onq7R8knMpjBe94zIdElOf
PrXO4adP0Tg6C5zHot92VXzjVPx99JqMrDMXbe2uGXRA50dXrhZvivO9+abG
iKVZ3ITKgzreceS+cQPcn0aO1B9IVtLzULyyyCDFOW67zUYt4QtKQpyho+eW
EtiIBOZxvYN7YbfseEAnGZfL8RxvQ/Uqu9jKqIGzbnBA8tbCY/9szHe5JHlj
2WPEXI1kELlBRoHXyqy3ZIuw82q/BoVGBgYbSmLogIfLRGv1FbzgPatHSgss
LYNlVQUK+ZHp6pl9agiMJC5qYFyV8u/Af92jArD8hkMHa8vPZakW86r7w38P
2yG29t0G31a0hgaPYhAdAaJaUGym3FhPZmx4HEwaoMujDwS0rbiuy0VGgYRK
6T4cNxKOJZXWa4Hg0bdDN4uo5jmiLmf8qAE9bYSM39mGSMO48RQJZAeDhlnS
6mUi2+8rqt6JskNqa8Ghn90jWN3eu0YnGjmyRrZnBId8SUymq61GDfmxQIYu
dPtRd31qddc7z8D0DLYCSywPFEZfpR2pnjsrF+tP2WZmSI0dadTCD7KgCoJC
3TIsp2befaTDemjcG9VAOgBCr67FoCIj6UZFFCzTps+/EO0D70bLWn1ASUSG
n/x8APrqMxGTyOVxFa5iVEF+f6DEN755BXnFo6e44HLArR0xsmKaxu5J95HY
27BgW7BYyBIp57/CGoB+UFXqaOmh2y4DVp5k+nkS7tgwSfIkXpAX9SlTiN17
8nqEYqhN/OrCAHET98e50GGaXWRFTHzKOiw7/grYIMu5W+rFV0SxIGkuaOXs
AsU+ZQVOKI99TjuejpJ4ZzRE+i7iagZNEF617/BYtReNDRl1OIyijteHVlU8
WW05NeDJGoVE0dIyjG4C6dxn1WIFNgP5h+HzH4KrX6MdZEzoQWVCt25U63em
7ALmbmUY9ZNgaVXmqXPpNSUfrtD/iTaj/OAHB+0pyxpDai6pcsshNwcsAB6X
Au09EiIcfU/oM1E5qY6gVe6QHqOO3xC9shRjWORZWqj3ts3VgPxaK85eXI57
6yljsWnlh/GkvGW9IkW8g11zKgMSiq/CZRSvKjxpgJ5gtb+JDwtLkvXegmHB
F+bZMl1cL/LUDyBiMHDT0ONFJVFKU82AbWnxali9gEfFFr0hs4bezTq4DgA0
64ku/i7ZR+vPk27LJA6lT9vHoe3aiW5w7agcNCoHfXdOh29mNbtvcryfzGeY
N/IDzNKg92FEldgex6oau/hx02jSB0qWmozsCM/PVXxdU0DJuIASjW3sPOgS
YOLQVVokbPy76J4EzwxHVw5G6olZlBxh8LYRLPe0APZEDqdUTE/kgSRZkRaa
bJ2yrv1KKePAbtew+B/dws9kbiviB3xNps/X1JLt0bBsV19UbG7hiXJ0i46N
AVeUGZL5M3UpjWk+MzTiY3mdnKSKzrYuybD3ynm6hKkyGchJgGm9bIChW4Oq
brmHNSazsPf7BqrTgsn8Mhg5Yz9xfFlmoPOZs86eYrKCzhX1W1jMOYlrVurx
YfQIGJreKgsFRxbpMO3jHJTXBgeLrNNWgFUdT8Y6npihNJT91Q6uylMcqz+I
xAMEgsMMcHuUv5jwMMyP1OxAZkTMOiYnnPJDcqI5+ygaVBd0MPPUkK9MnT/I
rYgEUT1D/o5pkvATLgUzFysxLR2aQPcEQkU61PS/rn/ziUtq8EJCWW3iyzjL
0V04crQQtWiB7TGPsijiinlzpDUMrCu9wpi//e1vxmoD8Mc7t/TH0hj+ccfM
/2AiSb+Iov1QrzjA6/yntT7RbZQe+h+R9yf40P4YXik3H03sHO5+M/z5HpYN
o/B3vnns/vzxd73Z/X48EdH4e24OPCx3vVmcGr9r2OPx8BLc/Ob7k+j48Kjv
8ptv/ufg1Xd984mutnWo3uFm+OO7X+/05vHwnz/e6s1DH/8jejDRJK273xwM
o+/m04mI7YBabjdn/M++5WsHw+O4eZ/DPze/+eFE9MpPzHH3waQ/uOWb/65b
9WjSMblvfzP8IbU2mMotbw7W75+C1bvFmx9PNBzOL40vMHmmufWwAwf7jz//
6Xx0hznnGNPabgK7bHTbm1kzJNnoybD/IIlHgaxiC0YJ+j/RU46h3NTlmQRx
EjEaYvutigvxPPp6W1zj6IJIExnVNuPDE7CcFKRmZ5+TvOXEhCernTXg9ES7
B/Q0WyWw7wdWyuUB2VQuskLpgC7XWjzf9ye9VhbRQSaBLNU1as1uGbE32Q/f
R5Ha0hRvWGC6TZ4mF+ilPhlYDWch9ka6dN6+8mHXHvRSUsexFoBzL/0NYNPR
0oJNmzRxcolJTbVbh8J/I/sw952yX1G2bozGG2h49Mgv1wemPw99Yh5M+hOm
+SVpO+mHKS5GR9k2zifmdOB2VR3rnrSgqCctCBeqY5vBmZzRr8+L5B3Oczby
QuBOE1XX0MQ87OwbuetqWwdAPtOefKQZe2Y+ZcmM6BjN+QiIKM5lBi54MFNr
hQlhE2S7cFzreGIeDSzMfln1LWnL9cjWlxBQGTgglEQOwgyGYE6t46dpFebx
LY5OyEjbG4LjCbKY6hHxwZryoO2iyMECE32fs7g0CGO8hT4YRZS8Ol6s0sVn
fntG1j3l8HFuC+x66cbF4XUv67Bbq9RJ8kErY4d59t+Gxv+jhsb/R6rv/f+T
qu/Jf03V90GP6nuXYZPGKUExYtf/EL359L+m3vzwH6k3E7uX7F4NstxRb96I
3in7f+s3k1hv//GU7iU7tqzYo882Kw11uEW6aSKbi++qQp30Nw8oiqbyNAwR
jMSNK/d39b3I6XvGqhOi5Q3ocINRB6xrk4xgSqmjoFCLXEfRqsy5FNEX3RKR
ydO4wkKnpaGwK19h087YrZxVdePySsibromnEw0M9ns0/1v0/rfotR/2JYrh
mwoHt7n5v6rcbt188veQJP7i3fbmO0qSB6puvAxibd0rB96sWso+G2QHwY+7
bv7PeVRPUd2gQOo/eY7s2w/bjwjf6c07CPJ2b/Y/gtwOBeBdbqZZtPfsDjeL
9yZt/eSk5y7PiJNlVNErh50zOohqMZJqAsEZOg38am3JOIBr1tu6GbeCpiMz
Txcx5qr3JgBJuGtVFiSr+sWncRFoltP9AWhvPTk5suPDMPvsv3tAEzg9YGeT
TfgPvFU2aSnYJqPrTunMA6KU8vQxv0VrvHuDastSckbitezWlJ1KFAWUBQtp
xG46W+bqJuhmYKrNj94nz8iXzI7WMymLsTYWk8NbVVl4iq3iPlGAWzMKuA7b
Bg/fpzmXJ64yqsJu1YD6+AJ5fC3e1CojRxlXGPSkG0VBuhHl+7R8Sn6NppZU
UtGEVcg66UdYg2CwZmCeapEapzBTanar5A80Rsr82vHaKl1kG80lellcYvUG
1qRtGqq/FyZbjySrx/spKOt0RdkUug0Ktm8YAdfCnfklYC6R2GZoGZehNY1a
ZXdVqprzlvJ0MQtD/D/XUrdMfqnE+N4oqqGktCgpsJQDjMmbuIninGs5DgVa
gZIQVuUV+kZxK1zSRwxHJ0WUDcxgES8rogVI/mWfhm1T1vaxVE/917IwVpYL
G1iCFcGr4BJGvMJeLN9eM9RATHtVt1YrK4yttPRLCZybS4L97M90TnSqHsMx
tPL/bVoGVscos0RXgAl8qrA3lLfkfHuURjfEiGzVnPEfv5Ndq1tbjgWXrWOh
PRa0Gc9CaipZrO4kxCOYFQHrKyuzIyE1il75GueYi3912UVKzFOjVNi/fIKK
BMcWk7ed2MnL4mKcZ7js/GDDNcgOUqJI+UhxjQizg6x5MmwuUd4WVp7A2a/x
CXDDIi9rKXC+iDdCGb0ZxmGWh+lmeXTSv8KEIIR5oFw6yvEiFdCEKiAe2XOt
6n9aUgo5D70+IH79B2Q+IHKeSSm2OPJZnXyuyVpcnkTHj/4uxracbsJ6Ruts
k0bhoiRSbjmvy3wLz/jp/SulsMCRbbGevFxpTmOXIkqJzLiaYq59mNvj1FMA
8hVRAvEiSkgNMKOkgpcTuCiFcFPByUDYBlRZPGaEeXoOi8HPR7MZ+CTC601W
odKhMqFuDLE/LwHcyi//KWLzC+EqkBWyVnTHjGzSpqfGuHp24ly2nh3Ho88Z
LFxn/h6b2WfQCPw7OCogHHwGK8V6Hl/HtZPtCRlHf9FLXdpOyv4B19mhk6IG
0qnpAGuVdIxl11V2iYuLU8D685AYbby0kFJZ4QKizM6ve04ZXttNO66d+2jS
txPiYYnnODDN17IVtBTViHNWziRr2E9opZpqCUMxubB+RUd25OqrWjmPFMw0
rOw5s4YTyNiFowu7r3IqSwUBJoyEVSb0cZVYdKpgMaDcZJWUv3HWsWBOZJ5e
CVQRKvrrrPCqMPzFEjrxJgJjVVUjbgS+oROEtR4xL4zcb6WMbCE9roUAAcAj
YyJZeT0iKXoGgTw1yIujUw4TUCPCzob4jV9gKJPNGnfoZBbwGJYQUgYFo7I1
OcGiUJGjoAE45Jf2lhOWlK2c2xCoSwtTJ8C/41XC7EmsRicPbdHRHDNSPAUP
inB/tNTGx8lruzWEfVroOVnXDh1rvQEVM5NeuODcydjF90kD1iwEkhN5kPE9
chnlWjqM7CLl4+4QVZgWrQEWHFHRXvjAtOsz0AyhQ40lYDByyph971QZ3wbB
VUcFbzfU2UCJhgnOQIe4tci5bWDYsmwLnmgCiDMeHcwDBDZOCQY48oHOGOWM
rBuh4c6rZaQdvCsaEtU594KjBdQa1qV1IdPSIMrtg0ahWm+F3E5/Or6kg4Qj
dLwT/IZkCQGxxnDDT+9f1hTGn6GYn2I+8wyLjLEiGYaJKfnn5z8cUNIsWVUN
1WYHanh4OEesWgYZG6jwW8ypjtpJmzmkj/ooSzhETAhmQADUjHH9PS8F2cUo
mc46xlk5F63ZR38aTM2gyLxji8KEvdXv7M1gSoyRbI6vo+dVVSJaZdpsq8It
Xc+kKRThZ7irTQNSYR0j76gHkMcU8inltPUFcgKEW1ukVvfwTBO23WABi5JB
GFyCPmzJAmEUqmy7Zm3f1QTyMZuy/iexGTpflAuDhnVJ+e1cV6d8WNhLuSmR
QacCcbCON8iQLfPwQRKGlBBYgmusDcO/6bSEpVloFlPNLDFyCybWxQr0E+zB
xjJaBCylJgxRyc4EWx88CAnGMg/e7bxJTrdlAdSUnBxG6GC2ditdu/iTxKQI
Oc7YkXuAdjDX3lqEeaql7uGkveUEZst8QYJidCzuVGhMKKBSIh/4zObXHpaF
v4Nip8FgcxT3nJvmHU3jChBxPbxNlDuFFVlonNZbZXsmqDXsSIux+5CBHcVf
sdHQgOKcIeQf6J5G45/sTdWqhGzJvhyO8KLgo3Xm7SbsxVqDiHCQsLAWbQGK
jzoYDCoylLJ9Y76Tuughyx8LSqQQvKX4qHTq9XtYGkCfnZT74XjZSGatC0kO
AQxGxqEdyu4zmh5yKGEtWPvA1VQSQEVuglY7cfEGtf2aTbK3bZN0KgLQ89wU
rnIekRZFBrYUAtbsgrxKrc9plzfu1wd4oIAx0uDoNA8XtuC75mh3oAUt82vV
Jw4UMkb7YOOmlWggwNxnf/WGAvf9NmPP2gFDnQ66tUceapJ4igUtUMbTAbNQ
OFDJbiAybPmetYbV7kEbzs17D66YvKoDi4G/ocwTn3lnpYE21lnTiADA+PlA
pJ58w/g2sjNiQm8pr8DaJtLrwnHw0IDAiISrFKu5TXtnLOYb+wOFQwkMruKL
2BcJJ1YnNcdGutkLtBasIPBj3REn3xIPdXmT3w3RbW+35bS4Hv0NlPC36M0Q
vbkLVUdxZGfMm1IRba29ZT1hSZRsiRVIcgoiteUKJyK80YdtAJ7FOFukKN0I
rwfCOAkhco1VqjhhuQQ1E8TMyHrAo44HfNA9A9s6UyT7f2ZS+eOQX8aHEKxN
b1ZyZ+KhkhXMHH/+8ecPpnaTLrvFs/XAtEja2NxSbK5Arn16d9Yu7bTkLQMA
OXu9XqcY3EG6GbmtMD1bEW5Atwyb1t6lubK63FOuvcvpJb7K9mG36iXqvTae
SejTcdsRh1Sv0tE35aIAl3qkLvqs2e2bV9DTlkMTX7qDUQ76e8mn28EIoEm3
mZHEO4JSbJjbgOhBquuIlLAUnLSHHdqLhfWW+Jr6VwKcJfHAI8HQWlCFdYgH
yA45VsO/TwuQ9rlv3CPEAZyPId5Lgl71DKI5clV8eHUe7YdwaTVppEsFRyQX
TY7SgJgJWERNKiXbYAlteP4HI326xhzo4ndv4Rs4CatSFNuZp3rf43PPDmMz
e8ruuvEHUC5m1qmCkImInejG7oNaxsUAh/MYnI8iYfIYmC4JktnIRxjTI89u
XumQ0I9bqiYhi2bLXnh8Cwb6F+Uqmn3Lk4eXzb5t4uoibcbAzWeYei7TTbIL
eCxeoN/kaXHRrMT5jB672SiMXNFyCYTCDB2iMPJGPcTBFusixZYhgZi9KMEw
XK25esHE5HXuFnaE5vUwX3lbsCt1w86BYogAe2vruYqIhgzTqBW3lfSDWQRc
OfcMfgsWWibsKWF2K3a1Z/S4WygWGi8b8cnlvCcz2jUqM6JXa/apuuDCh2W1
xtUGVCFjDVJWkgnQxh8w7QLRKUIvbOvo5PCIg9xXWc1FROE4WNWZjYla08Qj
Ml9GYaqrKr0toy+k7CBcYAMZHFDaF1xneiEfj5Hz2RE509+CvIigJAHhAp01
wMbpuD24f/hx5CiT/NcEtL0EvrUqGHGiSMorIHYgOgyryBpTcYuFUffnAozl
TqtakPW1jLOcm39gkI92liRT9tkHIulPDtKlGXno+cEKUqCptn4R3yfVIl0+
EHE1z5oqrq6NeFZqsQ9IGbE0JZnINjVphQiKRe2jcMGbzTKF9YY9m/aCIlEc
Aq9Ia1bNcGjkoAMJvSCnoNnE19j2piaXa61umaalOOPyojt/2Xduaf7kMLXw
mDAckCVjxGpU3CPxIRryIY7wFWIkoN5BKG68aD5ndKfQDxFx25T9bJJORn7M
D7TxA/a+XFqgEafwhR4iipBKjAavY8mCnL6xDhQcqBTpDBYaglZROj+G1iR2
TH2aKpJDb9WikYeRVAa67xil98ggqGco+YQCavFENxT3qdjOZt/0jVWAHaiv
FjqK2CL4NpYZIbcVJYQ9aD+ev33jQYj6YKGSokLh9Rd4BMRLGDwsu7l0UVDB
HMwSRtTaQSSClOWGGYIn0xcRkHgQ+gcZGc+BiqEqkibSSqVTF4jDpwg3/6wa
rqHcj5GVs3imL8ln06dha14Fxxq18BMPpHTdwWONk2LDT/R0ejcj1g15mTmi
vGW1ToFkHf/Zx9Sy4uIgGkceRqlarlTdx4kYxKtZA+OSVp6H8GWSn2GyXY8P
gFH783TB5X8dbkmorx6VxPPykmAD3bhBrbjLsOHyWshauqRE0U+1xos1bWue
8fHoxZwJlw2n/nOGWtfuIbTCShPzn3mrH7z2XhvX1uZ9EpWbGI6O24NKJb7g
XLZ5JYq5DO+wyDGEruPs9CA/El1GeVZ87jGJ5DiFFjYxDXVbdBaQNff+mYSX
qyfx9nfo8YOrmTm0rlZYU/aU+uRmmNw6Nc0NJfeSdaDMv1W9eTtcVAs96FY3
gP4hEXeVzpP4csbMAxVqknWk4ZNrjjGDZiSp9QbgT7PI3nCZpVeIZDejlVdM
52iGATW0Hni+GxwsfqQD9SyrwXK7fkOXGGEOwZcI8qR5EbM27Xnzj3OtNzL+
HT74Unt1BCKI3XcdLC5z5iDohd25LlU7JIMGSzi2Z3yLB+Q+uf2zJekxlOcD
/LZMRCDJ/suRk+wt/wyKYMIDEQTDQ9Q2CYXTwXBYqfZrq3mLKQlChoNcLMku
tjH1e9IuBk3PINonWLq3gSJ1Q4DHZ9UazsS4jH/mezJpRVWRwbh0aednZRHY
aihgpJx9qf3BhPgx6RrNpVZM9oBTjHlUZMJ601ZkM9YMKa83ZpzQqFXftpEW
GBIONVYRuWUqlrW7tNOHONQCe9dv8sHL1d4j7H1neTInh/vInNNQWmh4RBKs
suZ2xA7KwVUMQuZdWSsgGAXgg8HYZAsKZjHaMW/U/FpSEp6gmWFCVh70y+i6
Tp1X1Nv0CSZmWI9hTwpW6EMUrP/iYovuGULm4n55hnrFWYB40OI5wJSXF7Uc
1veSBkMOhnorgxgIWEjMKenahAiZRL42Q1qr6JXW2+pOK/MgjoZZ3soPCQQU
daWb7XEe1N4s5MW9QsqKnARzt/LaIshZ3Nb2lMIDFWZZSq+a2CFB8BtNS2WG
ZfxZo9I2pUjU+FpISMbKd3YMGObfiO9Gp5ktWjqSIbbdSHJzOWVKBNsNUxSj
zdqB/WZNR1iXSzICym3DeAy7sucopRUrO3BJcCPZGW8U+T21k/G8RRphIV5E
pnndY2Y3pbEogC63J7kGUawef6d9cTsoTIfFWg/O4EGZoAqW3ZzOjjC6a+MO
uGxfr6VS9/mUKYbGYpH4Qgf6hEEthnB1tNJn/5mXDBxkEYvEZM3AZtzvTJ4j
wmZfq583R5l0Yb4rR/V0fQwMIbN1CTtqszJNZGyVT8AwkjDXW1LOZQcnBwOS
EZceyysiT1PzvZI8vqnTyr+qg0txMRJQKRNnzYWYSd0M55GkW/Ybf0BTbFy7
aoUhGup1p9iAhKhIPUoUZR/tAFviTKFdqgjpKmS3xzkc0ATbVnaAg4V58zll
ShI42MqhIQlHMH3M3aIDMx69P1QYyHpTNuSjwFSPTPL2/C4DcQTyldIQNgn1
NOpT4Nl/HPt7ajg2e4AbVKXj8L1oxVOumN0Xlisnh4cgDjqebHG7UXou+Vak
26J1wjLnBVWH3o6WZQXzzdnUmdCDj+TBzlGMa8KXj9zF6H+Ic0K5ygp6oRoc
puPztqH59IYUAMpeeHB4X4bQ4ylscCOquMqwQ2lBSZeN70JzzgfP9dbtJCES
zSK8M0xuw1AIm4z8KvQlaLBefl7LZCffi21o6qmDSF5JFV8VA5IwcOaZ7vCG
XXkMcD37Hc61rqJiPEVlp9tHJIH6L5iZem4dc5NbB3sqCQ8pnf7haIHAjyy9
CWxSTGJzMAh5K/9HR6sMIK5A+PJ6dmNPcoaG6Kcf3ZlkZNBDBK+yi2NbehCr
YoLr+FEYCUrIxG874pCBvQYktKkgpUIlCoew4RYm/VDAxMmv4pohg8XrZEcy
8g41STiDCoq9W3MTJFaRtUv6Djpqt7d+VjZYjjplIztk5lwSZoeFDLcwO9MR
b6/PG8vyD8Ne5mHKYdSgLhhAvtdwYoBFwwaNYWQXaaMio9O4lTIYVZd3afh4
3m5tFzBpgmHACm6scgz3jdQt4xDvgWxmexfwVr26oXgTXqoJuVTxIcTeEimk
VsS1g1YOBDVz0le4BdggqgcB21IrrzTpX98//2BZUx8nmxlKNe8wOLDte4Tz
ofRO8iwvu3fGZSviRa2cU42EUn8Nm9Hcyfoz8HJbB8O1PnqVaD+4LARrrtlE
3KGtCxlhzIcezHbt+ddXEM4tLajg2WW4mDBz5MNwlhilqQ50eCkrzI4h6Ly2
tm3L8kZi3Qc68xP6Bszp0XDW2eiG5LKXGgjsAXvEMXZLFaeRjau2+P6IvURe
sr96lV2rDC9E66AYghYn6gOnFFbR+wvpoVr5jS/VT9ah9RUdKdX1kpSDlKkm
uZLkazWfcqunMfcdxbCNRcKXtGfqIgKLRnncY6DMmPiM17+cY8vIctpgD5JE
HGaaB51LuCDPiuROLYPiEbhwpdZ+DXQo6ufEgrnKKTaGUnnazKE3rTEooAAq
tQ0P2ERqK79BStCX8dXVFTLq9Xhb5WmB9W2gAYjaxB7FmbEpL2GLGI9qvGIO
N2E/ImNc74EP4a3iYY4HOhmQbu6AOznr/AkbL3q4SYZx6Tx3F/AbksZ0wFhV
YTOKNcpYUuncVk/C4Gl/8pZvvPWkRnUzDgdSo6IgNcoqnkhhppsGwqELm4Nk
06YGFT9uLqtpH5zOxDoWFg5J7W4PFUpiI8O6uYTMILHURW44aeu2iaYTs4NB
92YGtdJWMBJWXCANuFaFnUCt7o+X3dOXzwMykZ8qIHYa9U/RS+V8Fo6UnqAt
tYXvqBaxYYiBbSHDsOlqLk79KzMurSrF7IwY4Uv82rD+7iZKr9Yz5l6r2Zle
RRIWUhhuGxycCi60Y2cfNyCybxjT47luKcZ0hP1zkcsn5NFUDnKgrE211A++
94Pd8q6/Sj94jOR8w5XbgmhjZNh8xAVU1Sw8su2jHains7/uMZjT3tQs47xO
f5tpCzquPVpjRx+q36H3ytFvvcC6uURzkWxCsgxJ+5zxS0DpnJclWBgFap2z
ptqm5ISmenVQKMFmw7/irbOparzSHmiO6bg6tLCeXXVhYkxBEd7twis0FFhO
eDkpiejqHQubA6Y5cn43zVjGi5/IFcxxWzXYcg929NnCkPMdIcd1jDojBb2M
1MrZPf/Q2UWMeGHFOvaAoVAIoqeIjOCucuXSgJ6wbdL6QHur8ORgm0vGBK57
GhPRInhhtJZtqz5C38YdtWvIsrBCS/Qm9C6TJ6PtEPzaFUd4oQfvcX4zvbAa
kPhaq4ViZzCcGXaHAfXmm1NGuB+YZG0dnacBThO2jcm8bp5qZbfrQPhktbJL
gC9zgvifvTSUgQGhrF+AjUGKUVln3CZb+QmTG4UyedfBfLMeYaEzNOTn6XUp
QJpAaG/Ixew9p45c82bEcKEX8to7JS+O5qDYLrkP8yWimYOhEnQonLradS6P
lXrM3SfSGjZ6BXuSmDV3UctbcUt9yG4E9duEMhlm3QQh5FtgrMN6SgYYPpX9
t1JzOPORameCtCKmwjyFkVQ+jxUAUQJ8aGqjYTQeAZsSYdy37SWQuLOE7fl+
dMRzIXt17fpOhqg/OyoDGA+gNQ+V16xkYrRKW73zicNv30kMnIp5CeHpeHJo
pGj6A/Nr0vIOTx8pmv+Pb8+fS85jCwepud7MrHwwHHSvGbpiFjf/9OuVAN4F
d8WCi+JUcVXnNNU+2NaglKiVbT6UXD4KDxwGImcFrOrMRj/j/GKm04Nl6VOD
Wadx8CphhLERT1Kr0inWqLB2p8dmqZZ0+yKVFoLGa0DYVynflMbTA7VPnPY3
A7ao8DPi0f6UAUnwlmhVJ/E2y6PY1LjABpJWxDO30i6APeAwYG2A7rhckkJI
R5690CDr2EQnL5obYaw2OAc2NcCs6/6Ui2XP06ZTp6CFtDaYIfYgUSabGSYM
xGNxus3AsmoKtSEfFPywHCA72CnOwD3jIMymoQgvYSNwh5JODkx5TU4GI6kR
zucUkMdLirmQohWIWMq46m8aSjeQSja2HE/glmKXieF8QdrXcQKKC7EILz8x
IAZN8HuHDj3Rc08mR5P7Vmt+cPT4I3NNFCwbxI/RLHcYUEbIAhIHz2q/MN5u
guY2+bk2qiayNRs8ua38jH19g7ry6jDtIB+dPr7/UVPJFEUHjSq99nhyrNee
Pjx5jCyNhbuiGRKDiIGLr0mSI0TQYpvHlalhWanLLvN7kdRXKzW27YzUY0Gh
W7+E1mAJLWvYcSMJc/jXr03mJcxZZgsSYVuR2h9AyHHIv/XoiB9tXjgvQFt+
+Gh2iivSzdCiJZAail3BE01m4lPt8gpsDmSnhejr7ItantxGj+S4kaIRHvJV
uc0T5pmEFBYUrdkeIGBy5lqt46nMQWxHAglkauwAb2ut17CAtUvmTXhosqEG
ib8X6RdMTlgEaWCOtQYoN6j5V6zJBSp+K1dSmh/z0NErCZscboptrMiGCaP2
iVb2/Onb16+fv3n2/Flkm5xmWtZq1GSJxGQRsrewXSA/xwjdRSjrWyxXQhXW
ZSp3SwQo+mAREntVP9oJKu/R9Dzgxlqu+51AEBalbyRJ20mJFtFaS4fZkVjC
a46Guk6uQiTobElrWRMxoy3og5oVK6BCvFD9c/W2utTQP/WdbR+It8XCj+ih
07O/mAO3mjTFaClHXExjrDHPbFxJ4Oyocl4bOc+3zW5K5fobzm7CclJvvdYp
rn9Wr7uUP1y3DkvuStet8m+6PAlHbZEk4C67nqJlc2G+Wr8kBbgTM3upB/Ad
b2wIa7RHFKGaEAMR1DCeHKW/wN1USzxPvYAFmaxSut30JM9R+Ejd3Q1FvWWb
Oo7zENk49J7jifS73LO2EwjfFv8gKGk/y7Db096EGeWiY+1Is9FwRygVeqJM
Nu+I0fEk58gH+KTKrsq2+6YxM19hxUWTkDrttdBLKRk8nHUnSgq7mowHlEga
jih8skagX+Qld8niBFLJXGrlLwxl96s0C3OabIWe0bQ655Do5AwSd2GqFrQX
q8hztMsCTexMr/u/UrlRp8ttThSelxcXmbR7J1Mjt8rV3asoWsUCt7ryVgUd
7nK/isD3/AU3tLLWWufHnof2ib5dupr1hfy5BY7ZZy9oJhGFgsaaEq2BFtvL
LL4pRsbWqVXgI8Y/FRcLFzdLAaXniqBKZ06VYZ8o6BnYWJ0XhY4Tr4h46g1B
XnBq2RO/Etb30C/lTpf3RQkh7LiLC8PRkhkFhxUMiO097tXAneIiHG7WuDxu
rsq2QwUlw/kG2/u0IeCTNnQDBaooFyWoCxv5TDoNveHMpvui9BgrAU40RVeP
dYhbWxgRGXLNZ5Kikv0ex/jIqBLvQ8MrOR5w3Z0U4tbRCbKWU140/uaY/n3f
EIze52yzwVxTLAgopKuDHdE6jS1Gus2A1UgMFaCjTy+X4iEPcWPKVbwE7Ycq
VByJ13BRbq4tujfFieLGuFAYTHaMeQWDwS9Xq0dPQJcIVXCjvuX75tm7I/4i
6+ShWvU/tx0YXjirEL0MFXdyFahhxKLGgg8Y6+YaACfQQekoR4G6zX4gLg1v
eTw8pEemgy2OTMO8LJwCmjBME87HGxhYfMARCsMWHVFHzmc2iaBZdSGXptjE
4ms8TPHOHCku6MENs8KZx4b3d+y8Ay98EkkYThwHfhxRco7wEfsDtiRiXZ1h
QnhLhSm8F8g64mMsl6VZvW0kZXKEbAdvsMUifKdqLXhIwxco/hk8pztpB87G
SU07/KaStNppIuIqHXqGoNGCNuukPpK9a4nKI5NMd+pdRALP4gm6V7FGvyjX
OuCSySBljZq5nfgssdSsLY8k2dwDnIi0cZTCIHc0UXql4uDhasrd7OnmYoHu
8tFdqSIDbfPGbogtcxh5S8cDw8dsC9JQ/BdoYwNiB/BYnuBIqpQkwY1avr5j
gLtuBe2+b4EfUH/Xc1tpqQwVtLmySjwHeQukv8fBgFKsX4cvK0sltHgsdMN0
/n1M9TNWK51waefEL+M8GNmokdWK4KgI/9BKDddPwDk8/ToR8bBajuzxOHf4
G441WavIegbkhNMQrs0qI68dWs64nTHlLSiCM9/YC6m1z1ZZ3Y1UfGqanBwA
a0lQ12r1n9++ezmum+s8bWNt1gesbA+7q0dePjbJC1bV2zkMN0bzSDCqb69m
PV89K2TDEA/AS52TQbNKUSTCg7UCL+EvvIzSTuIpFoeYlNzpkcU8AYsJBC4n
u+N2cPc5JfHvmMQJLnsQ9FBTBUL5GjvZ6OOBulzH7RIoKaPEvBY357B1qmvA
RaVel1tB97ZVJVQvOowT6KfHcPa7rIsmnbtq7Nk/g6z947dOP5n5DY39w/lV
bQQNgJnU1xLqsbbl8I1+HT+BSK9BvmQ1exm9cbmI7Dz14DW5zmMRg26B/pBM
mzsbJ6r2Qa9Pq0XMdRUE/SBhIuzlE19rFAFV4ewLiakqzjBCbuo8rlcHnCjm
2YSMsBDkOCq1L2j8dKgaOuEG/8G0X9uM+xQYdaX5k2Efa/KFEE+fp3w8Ve8g
Z5kYohlnlYu/B67AYLzwEr/kSi5AV27hl7aymwCfzN9LjNr2LOH6nmtPsIY6
ESj1l6AC6zpyzgx3o/FayxAOuD185L5p22K4di6cg1d4qXQC647faqkCueS9
1pEEV4JiWjKVujB/olww5DI8qlPPdJnFflNphsPfpcjEFI1AHVqKDxyUUKi2
GMYS6h8RaQGap6GnWDLPsS8LE5J2Lpp2NCBuRyTZzjb65YraAw9RB1od54/+
ocj2fadJ9Bx56yXizLug4TahNPA8KO8tKdl0xV16whEb7fhEDh2Toi9NXLc1
mEVDfrn9tkto5ItzSf5yjSE82KceVG4/9S2t+5ZjxCnGgkwWN06t4VUhRuYa
x3N+peM5HkiX79R4x6qDZJ7DZliwWfNDeeXLSj65lDnfwui1/hSKNrfgMK0u
wruuWSKcfMFV2w7l0ekrRFoFmub6FUt6zIPxm+WAVFqv44qREBQNQ6KhXQx/
BJIR7x8mkfKBolGoa8ZrGaTepKD71xRUcUwBsSYso1cqNLhq1qaLDG8H5/zB
Xzs4joERi2blN61vwxExn/yqZhSb+IIUQUVZFn9TZmutWgPCd1sHNXW1i1n1
oqzs/VYKCbEy0EGlWYav422pKQ8W3A/IdQcrLekNBCMAaxVT6i1nZWlJEqnC
6Jsoy8+ZnEKHtu8UvwNxO9j6KuP9yNH0eoWLe37+Q+Rq88LsVqsv2nZz6O+2
iRfGZiZEcJpXGo2TzHFJCGInNGrG+Kp75y8Qo7IlRihJ7Qa/PEyRoBxkA8WL
AoeeM40M1oZQqog1Kx0zHSpPw8u1BjHiwlmfomW/eB/7Ef24tFpkA/NPE9Sa
4/ImcRNb9Z45/0i6ZQ0Hp1AuelCxyphhBFLUQRsYdBSwcB2OcRk1dnnVuu6B
BQWCQGW6TDkBziLGECt8ixHOG7XmvtAdA4TZMEzfnip6IyF1YRxbMCecjO3C
sJmbgdc6vIJ9rH7FsEG0wh0xR86yd8OftoyktirG8fh5Kj1yUsYh1GA9OTXa
XXC8shXNsHb2DizLcysj2fLaXRzbR9yo5KRccs17wHFWlOvppcBzku9kGm0L
AcPuK5Yftet7O+oIM6WyVRo6O//h7P3zT8+eP3318s3zZ7OggdABFwUn66zI
UI9HiUUckKHdgmLIdue8VnXh1Dbey7RXkFahlxz875TZZEkPeiCYslWK/gvu
44qaMZqR4jswAnDJugbJHguvSC7SvETg3lWqiyndAdjJoy/TLj791rRsLDMQ
7ZEmOc9lEeq9akQbihSgE4sqalXhR2UrTTwjmuN/Ehrx04r5qb73Lsig6AvB
KAG2S3i9MBv+h2zw/t6ZhEbjY/tz8l3LiycwAIUJ0ZLHmtu0jr9k6+3arsWT
FhjHgsD0r+Lr2viQAdG+I5H8WkCSENmQgQRccZw2SER/DjlwXFw2z9YZJ8cC
e19jtQ/RPC97kG1TiCQcWzAl7u8APEXTIHzcTVhTtgyJTbk0j9qvXBopFyGt
0hpUBLZrjUZMWpScRq1NVejJnYkRZgd6v9b1BfALFMmS+gs3c7PZ1qtWrNw1
8sX0EbYm0NPZZNwZS5dcsyf6uu+ydEHSk1XqWR9eEjiexPLM35/lKf4BZ8gP
s7Gvo58oo713dxyGQh+Tusry3IYMUWv2Ola/7xRAiCkplhzxDDc3OScmdFfa
NiFIQXyhTVlnBUdyV/y8KGP70UY2iWiC/Vlc69P2RLguCYnGQhZhwXJoQpNv
2hCqY8MHkvgBlQfFG6+lsqS7gK5lAYFaz+UgYZOm0hBiQG3hnDf/C8T6qw+A
ifSjzwcJMhbFEyEQyVaidwfrYqwrF9s3FRYY4CB0jCIfccllfmaypi/YbBoL
Hyqsqn2oh7KTdnQOZ0TFIs3YCeSf60JAUYITTcesXZ4NtrZiuoYgZzaoEcq/
Ea7PNi/96BH5V6meOLYlYYTWwIVi57LBwB4N9++jfChyddYl19hIwLbfY1PL
oyam//S0zgy7yLVISfwc9lnaS0EikYPVjEj7Uu+0q4+CEzk90SHXit6LA7FO
6x83BbzTY1F758KCYhAkdN0gaxEoTauh92iQwz0aOFGRUTfgEWvHSwxKSfbE
sxV8VUoeq/SoJytjINWUKPoNZSFjT5b3qTVZqTUbepNiRHWjnhUXZZyLm1ka
LDJncIhT1plExeGYYWFQ55ZWX4JBSq3oxQPFkMB4HC+d7GlXIzvNHjlX0KOz
v6GQYb0Uw0yYuOChn/mnTTDCWducUy6fXmg6ScJntJrwc2Ybw3b9Cp5jT9J5
YMM+B9FEZilqvfSl/PWVDJluydD+y2HuM+DAwe3oyVqUfjx9sbEnvdqobQIr
PTzCI4R5oF4FmfRydQVktjqewMiA9gSXQcfB6QP85gCVtOMtAcYx1HBGtXLX
U4YxmrvRP3hIq4VOp0eOwDsXXUYnsetbDKRnHdW1Y4c3pLtztm1R+skzHiSp
82qy++iqNBasru6D0GfP7CDx8Oti3aax99ZWk56b+lBzdCv2Gm0HfV73688E
4++y0RnDLurDsLOuwYNWM236NRwkOwDEbybRJ+NG7ifJBhVcGFIdsBTpRAPJ
JLmtvAtrh4eBF7SCCc57I7pETCiwy8zm3fmJP8QgqS0n+jDFceVXV1LmJAtr
kDjY7g4Pgz1fWeU0TiP98AKgLVcSuQiEgQ+siYoOswfivMlYJIQU4L3XlkYt
hJmfpfA+eA0fO84QCQruiQmVxYVouh2QQ3bcOcHfYWnWq2zDMuKACBHJ+93A
4hC61M512gIFiIpRPFyjsjDNWPDuWVSyyktGQk/bS8279YAywnxMb0FK59GN
xftJrkcfhIOhObpgPR5V9+QUYordSBvl+s0lxuTV1eR7u/8Hkx36q5NyVUr8
EJtc16NwjZBmccPJwKAASpMxxpG8HjQlzW4BabjJveSWAAdGkIsFZYDUGrb1
YL2fObAZa6P4wLwMWS4F990sfu9MpZzEkGlzgmFAIyz+KaSImorClnBYp/CS
JebuBvKJVD92VOZpo3WW2FgqIrRgPsGgyeQYxnY6Aq2ZzTDct8VkLZQIifYG
eRMiSsMaCNFW+uhCHelx5Ycl1/AoKgV0yYd2CdRj5ruScM/H5J+hpjRtg6Cm
sAUGXGyDXeox9z2BhNtYyrs2OJ8x2iFUktrbnhtk+ejexMplzFlwjclbKvrU
A/feNNa26Q17IL4CGVFrT4sHwxLWA0T7KGLgutSzLVkxYJDf/mik0qIRCC+e
clYlWssgm+mABwPngmbDa1KVSdcbjEnbq10Kbheb5ldqWYHZnQ6g8GZfqG2D
Km63TVp10RPNfrHFuD1SWOBHpAZKYG9Qr11dKG4MEiOiqKYhxQj3OU9X8aXk
cjsdO2m5FfFcp19WMTUnbLh9Op7iVDG6vcvFwmi0k2H/lgTB9QDLFvezlafn
Yk+acTUxby28myydKynuAOTUfmGKur5cF0oaqoAPbUnvoUawNoXWa78uVUkC
Ixr6Dbksfqc7sV5lS6EHVwJM+ZpW07Ily5jBto5/Lb0migupQO5a9BxxDLxt
Lj3G4o4ieptN2RFnqRC/i6Mv4g2pU4HzTDey5TEDxe6KM9rQ57UnTsY9OhKw
jlhrEpbf0e62ewGqmMYMzy9krVxbZ6dTUHrrPrk0boHUWFCpMWrxr8HsoSAk
tUN0udndJFZ0bpPsoU7RXIm/KlnFdQkAgqtjQ/TcJjESmFOuA/YTp9lJ1vQm
b7TC8wInhwk4SWJZ41ongLBIjGtnOsE+bg8TDQJKM+SxXw+WsXY2VBXTDnNJ
aQcdxVxlehogkZK/h7zM9Ch0C69j6kFz5jNTK9LQjbMjsLqxPakpBJItMlQq
reNcXFUutbkn85besOsIKhWL68hn+Kwks2uWioAyr+08Ko+kchRpMxZgRa6O
AJJuRTufWENbQaswR4q6r1kq+cp2DPeNVF0BOzQjMWGbLOzHtNWw0RUCtuSv
7Q0xd9/qWWdfxA0Sll6z3y3uRtC+sqYXpXxyPC1pwfyg+eSFOMhOksbmw2Fc
Utn8QIB0ndAGDV6JZcgQCC5TEXVswAKmk7N3met01ax1fl4tqx0MDKBKOM+k
DqSVzl344ZjOKtWaf3cdtqxiqPC4cGjkQbBzg4HlhEncxnHIFbajd/icETaq
GDMNxPmIOPhLtAjI+hwo8Jz2uHWto5qTENunrJ2GqKkN7aJ7zRAk7HTJX87W
6zTJyFARMRoo0T0ldm2nKTVpXu3uOonbMdSaWjNWTNvJNQp5+jRAkhpomDky
Fnmkr5elQzC0LSrbvSlNUInUQjN2rSllWXtKmUiBvSpNy58A1hqZYKCvruI6
q4eUMVKLvzSqWaBaR30KEe+EI4uIAqltF1nwsYXf74kd2R7xFVso5VxiFz+9
fxkl2ZJq+FweLdelBD0aBcxxALk5bO7oGjXSpoclgBbfh1k76aTDHRrVqbXh
Lo1fE+pVWt1DO11U0Wmvp5alP15GSdDAtMSvEZug1Ek6Z3o+ca/FaohaR/VK
KGd4Ep0TmJfl5+3G74iMKEPoMMWbRB8MNC26RPiQ5xtF2ra4kOTbRB8yPh5U
lY0c4ZqbXcFQyBfwFeh9HiYHp9kKCC261ra15AIE8LSt7RQt+hlobhzZwK+z
RdrfVFuy6CWDuNXTVMSKdi6l0hf2G4NsAq20JF0i9UArOQFb+6baJqUcPeIa
EKM4lrYbDFyLlQ+oDwZupJ6UOfJY0nhMWCoiW09u07iG93o1TU86urG0yPFs
/OAtkqRT+15KLfBh0rJLIuyOd7ru77OgIAwFLlpQz/WVH43DbGIu4pqntgQs
cypSAD5DGt8QgnW/ueZ7Ny6oDXkj4OkhnoKtpkaveqGgdwMOvsG1ZWlQKKae
RGY1rZODmZ0SnjhawgmhvDeBxDd+nMlWN5MpkHOknDBcvdt8eSuUBdyCYzuh
Tc2t58/enPXFDwkQ4ud0LpJToLLepxeYoXEt7T4t+JU1fbh1VkWXpV5Nzl7v
8/ZMJQ+M9l1qObbdoMkRTVs0qIMp3xVhB8BpCHLxzDURnEZgw+MLym2CYnrV
gyTZbVLfEQo+xT1lHBnUd6sSPV7T6OXzDy+icz913DyTs7hfH0zFwuew3DPY
hWbEiUqwHDAfyoHm1FBCwetz4ylW7OCac33FzkX3nm76n74X2R2wudJpG/3a
X/Dfs9TtWOOd1zZqr625cW3fKIotEXisHayq1EK6EeRlJv75rmQopFZ32G1M
fgCBmgHSzvPxnzBWhvrIE43ZaN4gpdMMotfjQXxabgh0ZYHQfHIOyX9IHp19
9ElS+aE1XQJnIyvbFevK6HqososVGogGC+9HXIuPredxr7P5VvJyMaSvjYYr
i7AMHDbsR4aCD9Xr7XrkYJjL6zhH179gijCOKHUrR4uq5iZavhcODfAL9g9j
DZobSiJvxGR5GFCtPn8FNoH7c1CpSATTaoxQ36hpdGhJIOPjmWCqS5GUoGsy
qLMjRFrj9wj0QA4vyZFQ75T/A2v6r0qqXWmyUfT9BAMh0Y8lZta8nnwHH7+L
L1bzuMjwM63rG6rlpY/R3i94LIw7Fh/3jQIdoP8FQTM+A/vN0mY5KauLeyDF
7yVIyGP8agwHbVzCE8YLfMIYLKXVvYO9UfQzTNEwos4FlgPClPCQHh8hVN53
VZwUmBN0PoEB/CnFdGpk+UsBYuDDQbziJRAYBjPMe8+V8Aokb15/3L9xoKtm
nd+rlgt8LYzKvI6rxSo6evz4oYyHIMpxtdBOfQ2LtfeLZf44rn3QIA5usyT6
Jnwgzv91fI2tsx649zwO3oNLkGOo+Ef4cB5/ztbbKh5Fb8IhMDeEQXw4uMNs
8WV9YyC87vcZ6AgVvjfaT7GABShA0U37ePudJg9vwBe/XTQlsnvv5Y+OHp4A
oabZHGb5HW772XqeXWwFAPKnzYZKPsGirYGcr+SDcEncPoPb8TOSyQ0roYPB
N3qroDv+6PTowUcsIkCfwype0zHY+8VniUVGZT/Wo/XSVpLWZh8YZn2XzcD3
ecN4LMMgvI7oO9B9y8UCjuafezY+oo2/DRDtHcaDL/b2yBwfHh/pmKhfwXdw
8zoG9nAGQ/KohfTrTVkV17Jkvm/BON+CG0tTlnnd3Rh8DY7gRTqvtmh5wBBO
dAgP7h9+jN6BcIU1eT/BZauuQF0cRc9ogZ5lCE4nbe/vQpr44L6XYr24Mt42
b4XxnDw+gm16tgUrJQY7bhS9mniTf4455NKqEDYHN+6ZExRGiuUEYerPLAXg
48f96FYUjC9HZmp+3ILif3x4qDRM+JzRD6AmN7gw9iCTH9we5qBWD8w1ED4o
eG5aNX07vqR1mI/tGXp8P+Bmb+IEuxwwzTyN15t5inh234WMjl0RYExkCMkN
F076uM9zUTzusrs4IBzrj3Ghm3tIQvRsg6m12ZfobAoPpi5goqoss4raYpIL
RxqE1WjrXNXD4KAzknITuRyHYRta+w0PsQJ3tZ13ruumGVfbQnrShf3IMBFp
XpafMYTRIHmO1Fal0FjfOFrVfy5WY0E0ougsR+fC/izGv7/tPuSA24piloEd
ASlc35VzuG1ezr+V4q0qvA8RBkM3Ow5n0Oa1680WgmYcwlb53Qn7wuOd0ijM
UA7cs01/eyLxj1BF0rUCMfXUjeHjtWuOe2h/9RntBUf2W6lDUg4Q7WNJQTSH
uz9b56PLmFDfGwbwEu4YD/Op2G2N7rqDqTF/+9vfuC/QvZqdQ/U9ULruyUYh
H7p3NDkyP5RYdN6iOvMMVKcpMCZgoEeHEfARPBqn0dHJ9PAQ/hd9//oDBrIx
J2CMQHRTv6L0HubQ2Z+Z9U6RQsbHD06/ma5+vf/q57cvt9V1cvKv87+8WJU/
xKf/9vqn+ar5y+vk9Yf76ePvvmy2x6/Wh99M7WNepcVFs5pGD06OndAYvyyA
+Mls+2Z/79t1Cpwr2Yv2PIcofJLkhXFCI9kz9oucnglXYCLS3sETTZn/5ujh
o6OjR6cnh4dPDDmcv9nrEP0f4IejPezeffHNXpocPwDtac8NjQc1/cXu2pjw
KT/CzvzVgP5s0TD2ptHe0AHZQ6ypPVT/8aoYTvh1nYFo3FwXc/7NgR3iFQ8X
h49Ojo9Px8nj+Gh8dJSejudL+LhIF4eLx/ePF+nhEd9HqAH00P4jzVexR/3m
yxSPEK/EGC1/7UMg4i+ojdhR0yGDb3ExvDmS15Mugi+52tteBN/ght5lnnST
lyMBN/8iX9MA48Rehu+rMqAD+fyR/v7NDQUovGcoKmtaJyg8dGjpuPFcZukV
VpDg7d4rfzP4/9/o4P51isXe6Tf0+L3f+hNfKJe8J8LE/ub9HmY/MrPbLN3s
wO/tWwszUZZBfduf8km5iQmYvwJ1UM9BnKw0Zo92zDHIoSPojSK5maE2pZn1
ChgHiS8egNl6WzcWNnksRfnMYS3MQgsevPDq2610ZAAr8pOQIOZ0v/YW7TMo
EFfntVvncH6oRM79UmG5marYpftn5OvtXvv4bmap7+x3CbM+EGGHLohGeSlG
LsqfcJMLr5k3tqkwLHyYJiLaZOJnsJXEJ6gnBZ9y4Iz41fPk2fkZf/M5IzY1
wEuF9m3unmtd0HkbDNA/fEN8aTu3vEuGtE1u5rc2OHs3lprFDdygouP0kL5M
v2z0y8eHh/Llrw2xjuX9+ePFYQxicXmajk+SBw/Hj5Pjk/Hp8jA+Wp4mj+dH
blH+IB1nxtJxxvaZARUryIwh3+AYJX8P4sUu6IphnQHZ100awzAj6G0baIwP
i/FNev3jYfqvZ9nb7MdV8rT59+T+v2Svnv64mn+/wO9e/I/n7z/8y/nLejKZ
3J4/2ngdRws/aNxu10kYqgewQT3LihTaa379n2O1I8U8ohjjoIrtI2tJEZFA
cQl4Bd48qGj33e3wuCz+RWGof3FN0KbAs7brtD6wFQ6k1iu8SNDg+Fa9wcmI
0GraOnzqPqnOaEUV1vka6LzCdmrlmjE32BXVOCiPknnv0IG5aPD3U7SItjto
SL9DTRvSBFqi+DB6+6e7SWFtgzwkhs+wRIDLPby0FN1vipMHGNsgzLYgp6KZ
9xbDvZOj32a9zYd7k0CDKtQZwjZ27GAunSXfu4AFYXUOto71Eyu85CAjqbtR
fV03aWgNR33WcBfctAXo/qZV0s4JOpQxyKVfOiKOnGAs07TDLgxcKLXOQQKy
2trOngZLN0k5bIGs3kHV+I4D5ep4QwcjSa1kt1TmBn1q8g9QMP6BIn74sptE
+qPTh6FIP0wep/cXJ/Pxg/h0OT5Jj4/Gjxb3H46P50fx4+Wj9GFy+kAMMIo0
OgMo5BCP58fpyVHycBzH94/GJ/Hh8fjx8jAZ3188SB/NH8LDjw7VSuqYWUQx
+qsaVugLq8EkRjtef+uYYX02lzN17jCoPruLza2P8vtvHZtHa5vTdubA/n3g
cjXmLiUadu5QpdcLhdOPW44V7REblqP29EjRzq7xYsVp3tcj34jA08cizB3+
Frooxha1a6wFfGUNpQdNbcGYlzwpCRxoUZhKsPdv3714+eZZdA925t5tdqEt
2lrM1PTCsUV3UcKepRv0xhwNa2PKbv6eWtgyK5IO06Syo14VLOo3Cg9GXMTI
TAwZV7979pZ41+pAFcKzu4XkPkbrbtQCX5thnl5/owWNLAyBM8y4KMwOdVGu
RTJ2GwRxYZlk0yD8Ph4qNFJnbfN3EW9iLnJryx8r8T9n3J3HF0dP4wqUbVh5
/PvbnpFprdcu0z2rje3mzVHpmnG01NoWWWatbaoz76oHGCOw0ERdUxvlPdBN
v/nvmfuTfs3jNmrDoNcaCURqk6Oe2uSgNNmditYwBs7EEGOxBaacGEv1oMpW
mKHhD1JiWLUQx5ZB19E+JnSyPI2PF4+Oxg8fzg/HJ4vDdPw4PT0ZHyXHy/vx
g/np4mHy+5hQvarGj6/+/eTL5788vFwnx7fgNF5V6VBvDK0WcTqQ7hWWJpn9
rm99t3HBXaMUF56Bf/TZRCTiNW7Nmf0coWWCqpEbTnvROrR2d0ObLezOuv79
jAvSuqTLNiYKp6O/g/42xFT2hnWw3SrVbUj2/7pKdYdB7XRlqzPbfjGsZu0U
1tI5rF+OMQC2xXEPmngbrh4hLBzg+kMGPy/kqJXCyU4Hw4YknjKvbXskbdtZ
zpLI+aoOQM08WB88hpLMasswPGAzScSjSK6HxrnAnDwtgdVeynSK8SHUSEK7
F6SXWQkmrGRmGeEQlMznB5sJ0x6rt9KYK5gU/gYt6iy9Qp5CE2DwXgMrxF1M
NP5HtQMXpRSXYy4LYYJhLTKrCJIVEB0eElhfkXFRPX/LIewFyoo8TS7Yjy2T
tj5uTg/Os7+QwMQIP9WPeXJL67fepF8aOr4kZH/cbq6btPphO48SzKcizQZE
8vlPb55/4F2abzOUdh62QWgsjgi5xIeh4Pv6q04Yk0eWupWMGSIbk7oRF59t
I2C0kYFnrLdFJjDolMid1Yut1MyS/gfLT+rZiroiAIeLVMEXAKGwHSlDAFpk
FePKXvC9z4sqQ7T4d//rf1bpX6Kzqoh55aLXcQMPAjL9UxVvay6XTHN8Mw1A
eu1SL1Qt2nUxeDDJcRnK9mAQZm+Ou7S0oFS/nFM1DQ78Q7pYRWcXWOf68Rc4
Zh+NXwX2C/38Am6kH8f4CA2UxNp1dRH9AqPAvH6+CLgs4mzYf09tUgpIn0mt
r5408Ox79J9Wnp/cSy/befMGcwDjdX0PLzVmPB5TyZH535mOS8bzDwEA

-->

</rfc>