Repository: cs3org/OCM-API
Pull request #165: Clarify how access happens for shares without absolute URIs
Author: login: glpatcern
Created: 2025-02-25T20:32:20Z | Merged: 2025-03-13T14:54:58Z

As we are implementing OCM 1.2 in Reva, we realized that full URIs in new share payloads are:
1) Not less trustworthy than any other metadata a receiver can use to establish the sender's address.
2) ~~Actually required~~ if we want to support deployments that make use of reverse proxies (such as CERNBox), where the receiver has no other way than contacting the sender at their advertised URI (typically different from the sender's address). Edit: if the owner's OCM address is provided, then full URIs are not required.

See https://github.com/cs3org/reva/pull/5076#discussion_r1970426187 for more details.

With this PR, ~~we are "un-deprecating" the full URI concept in new share payloads~~ we make the OCM address' FQDN mandatory.

Additionally, some fixes and a re-harmonization of the IETF text have been included, most notably:
* The `webdav.uri` property is `REQUIRED`, not `OPTIONAL`
* Use of the `/.well-known/ocm` discovery endpoint
* No secret hashes in URIs
* `uriTemplate` was renamed to `uri`


Diff:
diff --git a/IETF-RFC.md b/IETF-RFC.md
index 2c68518c..d44bb013 100644
--- a/IETF-RFC.md
+++ b/IETF-RFC.md
@@ -73,7 +73,7 @@ We define the following concepts (with some non-normative references to related
 * __Discovering Server__ - a server that tries to obtain information in OCM API discovery
 * __Discoverable Server__ - a server that tries to supply information in OCM API discovery
 * __OCM Address__ - a string of the form `<Receiving Party's identifier>@<fqdn>` which can be used to uniquely identify a user or group "at" an OCM Server. `<Receiving Party's identifier>` is an opaque string,
-unique at the server. `<fqdn>` is the Fully Qualified Domain Name by which the server is identified. This can, but doesn't need to be, the domain at which the OCM API of that server is hosted.
+unique at the server. `<fqdn>` is the Fully Qualified Domain Name by which the server is identified. This MUST be the domain at which the `/.well-known/ocm` endpoint of that server is hosted.
 * __OCM Notification__ - a message from the Receiving Server to the Sending Server or vice versa, using the OCM Notifications endpoint.
 * __Invite Message__ - out-of-band message used to establish contact between parties and servers in the Invite Flow, containing an Invite Token (see below) and the Invite Sender's OCM Address
 * __Invite Sender__ - the party sending an Invite
@@ -222,11 +222,11 @@ When OCM API discovery can occur in preparation of a Share Creation Notification
 ## Process
 At the start of the process, the Discovering Server has either an OCM Address, or just an FQDN from for instance the `recipientProvider` field of an Invite Acceptance Request.
 
-Step 1: In case it has an OCM Address, it should first extract `<fqdn>` from it (the part after the `@` sign).
+Step 1: In case it has an OCM Address, it should first extract `<fqdn>` from it (the part after the last `@` sign).
 Step 2: The Discovering Server SHOULD attempt OCM API discovery a HTTP GET request to `https://<fqdn>/.well-known/ocm`.
-Step 3: If that results in a valid HTTP response with a valid JSON response body within reasonable time, go to step 8.
+Step 3: If that results in a valid HTTP response with a valid JSON response body within reasonable time, go to step 7.
 Step 4: If not, try a HTTP GET with `https://<fqdn>/ocm-provider` as the URL instead.
-Step 5: If that results in a valid HTTP response with a valid JSON response body within reasonable time, go to step 8.
+Step 5: If that results in a valid HTTP response with a valid JSON response body within reasonable time, go to step 7.
 Step 6: If not, fail.
 Step 7: The JSON response body is the data that was discovered.
 
@@ -234,7 +234,7 @@ Step 7: The JSON response body is the data that was discovered.
 The JSON response body offered by the Discoverable Server SHOULD contain the following information about its OCM API:
 
 * REQUIRED: enabled (boolean) - Whether the OCM service is enabled at this endpoint
-* REQUIRED: apiVersion (string) - The OCM API version this endpoint supports. Example: `"1.1.0"`
+* REQUIRED: apiVersion (string) - The OCM API version this endpoint supports. Example: `"1.2.0"`
 * REQUIRED: endPoint (string) - The URI of the OCM API available at this endpoint. Example: `"https://my-cloud-storage.org/ocm"`
 * OPTIONAL: provider (string) - A friendly branding name of this endpoint. Example: `"MyCloudStorage"`
 * REQUIRED: resourceTypes (array) - A list of all resource types this server supports in both the Sending Server role and the Receiving Server role, with their access protocols. Each item in this list should
@@ -375,7 +375,7 @@ To create a share, the sending server SHOULD make a HTTP POST request
           Option 3: Set the `name` field to `multi`, and put the protocol
           details in a field carrying the name of the protocol.
 
-                Option 1 using the `options` field now deprecated. Implementations are encouraged to
+                Option 1 using the `options` field is now deprecated. Implementations are encouraged to
                 transition to the new optional properties defined below, such that
                 this field may be removed in a future major version of the spec.
 
@@ -394,6 +394,10 @@ If `multi` is given, one or more protocol
                 only support `webdav`.
 
    * Protocol details for `webdav` MAY contain:
+     * REQUIRED uri (string)
+                    An URI to access the remote resource. The URI SHOULD be relative,
+                    in which case the prefix exposed by the `/.well-known/ocm` endpoint MUST
+                    be used. Absolute URIs are deprecated.
      * OPTIONAL sharedSecret (string) - required if no `code` field is given for the Share as a whole (see above).
                     An optional secret to be used to access the resource,
                     such as a bearer token.
@@ -410,19 +414,12 @@ If `multi` is given, one or more protocol
                       - `use-code` requires the consumer to exchange the given `code` via a
                         signed HTTPS request. This MAY be used if the recipient provider exposes
                         the `receive-code` capability.
-     * OPTIONAL uri (string)
-                    An URI to access the remote resource. The URI MAY be relative,
-                    in which case the prefix exposed by the `/ocm-provider` endpoint MUST
-                    be used, or it may be absolute (recommended). Additionally, the URI
-                    MAY include a secret hash in the path, in which case there MAY be
-                    no associated `sharedSecret`.
    * Protocol details for `webapp` MAY contain:
-     * REQUIRED uriTemplate (string)
-                    A templated URI to a client-browsable view of the shared resource,
-                    such that users may use the web applications available at the site.
-                    The URI MAY include a secret hash in the path. If the path includes
-                    a `{relative-path-to-shared-resource}` placeholder, implementations
-                    MAY replace it with the actual path to ease user interaction.
+     * REQUIRED uri (string)
+                    An URI to a client-browsable view of the shared resource, such that
+                    users may use the web applications available at the site. The URI SHOULD
+                    be relative, in which case the prefix exposed by the `/.well-known/ocm`
+                    endpoint MUST be used. Absolute URIs are deprecated.
      * REQUIRED viewMode (string)
                     The permissions granted to the sharee. A subset of:
                     - `view` allows access to the web app in view-only mode.
@@ -432,16 +429,16 @@ If `multi` is given, one or more protocol
                     An optional secret to be used to access the remote web app,
                     for example in the form of a bearer token.
    * Protocol details for `datatx` MAY contain:
+     * REQUIRED srcUri (string)
+                    An URI to access the remote resource. The URI SHOULD be relative,
+                    in which case the prefix exposed by the `/.well-known/ocm` endpoint MUST
+                    be used. Absolute URIs are deprecated.
      * OPTIONAL sharedSecret (string)
                     An optional secret to be used to access the resource,
                     for example in the form of a bearer token.
                     To prevent leaking it in logs it MUST NOT appear in any URI.
-     * REQUIRED srcUri (string)
-                    An URI to access the remote resource. The URI MAY be relative,
-                    in which case the prefix exposed by the `/ocm-provider` endpoint MUST
-                    be used, or it may be absolute (recommended). Additionally, the
-                    URI MAY include a secret hash in the path.
      * OPTIONAL size (integer)
+                    The size of the file to be transferred from the sending server.
 
 ## Decision to Discard
 The Receiving Server MAY discard the notification if any of the following hold true:
@@ -492,7 +489,7 @@ They could give the Receiving Party the option to accept or reject the Share, or
 
 # Resource Access
 To access the Resource, the Receiving Server MAY use multiple ways, depending on the body of the Share Creation Notification. The procedure is as follows:
-1. A root path `<sender-ocm-path>` MUST be obtained by querying the [Discovery](#ocm-api-discovery) endpoint at the Sending Server and getting `resourceTypes[0].protocols.webdav`.
+1. The receiver MUST extract the OCM Server FQDN from the `sender` field of the received share, and MUST query the [Discovery](#ocm-api-discovery) endpoint at that address: the `resourceTypes[0].protocols.webdav` value is the `<sender-ocm-path>` to be used in step 3.
 2. If `code` is not empty, the receiver SHOULD make a signed POST request to the `/token` path inside the Sending Server's OCM API, to exchange the code for a short-lived bearer token, and then use that bearer token to access the Resource.
 3. If `protocol.name` = `webdav`, the receiver SHOULD inspect the `protocol.options` property. If it contains a `sharedSecret`, as in the [legacy example](https://cs3org.github.io/OCM-API/docs.html?branch=develop&repo=OCM-API&user=cs3org#/paths/~1shares/post), then the receiver SHOULD make a HTTP PROPFIND request to `https://<sharedSecret>:@<sender-host><sender-ocm-path>`. Note that this access method, based on Basic Auth, is _deprecated_ and may be removed in a future release of the Protocol.
 4. Otherwise, if `protocol.name` = `multi`, the receiver MUST inspect the `protocol.webdav.uri` property: if it's a complete URI, the receiver MUST make a HTTP PROPFIND request against it to access the remote resource. If it only contains an identifier `<key>`, the receiver MUST make a HTTP PROPFIND request to `https://<sender-host><sender-ocm-path>/<key>` in order to access the remote resource. Additionally, the receiver MUST pass an `Authorization: bearer` header with either the short-lived bearer token obtained in step 2, if applicable, or the `protocol.webdav.sharedSecret` value.
diff --git a/spec.yaml b/spec.yaml
index 28b84523..3144ca1c 100644
--- a/spec.yaml
+++ b/spec.yaml
@@ -606,21 +606,18 @@ components:
                   uri:
                     type: string
                     description: >
-                      An URI to access the remote resource. The URI SHOULD be
-                      relative,
+                      An URI to access the remote resource. The URI SHOULD be relative,
                       such as a key or a UUID, in which case the prefix exposed by the
-                      `/.well-known/ocm` endpoint MUST be used to access the resource,
-                      or it MAY be absolute, including a hostname. The latter is NOT
-                      recommended because of security concerns.
+                      `/.well-known/ocm` endpoint MUST be used to access the resource, or
+                      it MAY be absolute, including a hostname. The latter is deprecated.
                       In all cases, for a `folder` resource, the composed URI acts
-                      as the root path, such that other files located within SHOULD
+                      as the root path, such that other files located within it SHOULD
                       be accessible by appending their relative path to that URI.
                   sharedSecret:
                     type: string
                     description: >
                       An optional secret to be used to access the resource, such
-                      as
-                      a bearer token. If a `code` is provided, it SHOULD be used
+                      as a bearer token. If a `code` is provided, it SHOULD be used
                       instead via the code flow interaction, and the `sharedSecret`
                       SHOULD be omitted. To prevent leaking it in logs it MUST NOT
                       appear in any URI.
@@ -665,13 +662,12 @@ components:
                   uri:
                     type: string
                     description: >
-                      An URI to a client-browsable view of the remote resource,
-                      such that
+                      An URI to a client-browsable view of the remote resource, such that
                       users may use a web application available at the sender site.
                       The URI SHOULD be relative, such as a key or a UUID, in which case
                       the prefix exposed by the `/.well-known/ocm` endpoint MUST be used
                       to access the resource, or it MAY be absolute, including a hostname.
-                      The latter is NOT recommended because of security concerns.
+                      Similar considerations as for the `webdav` case apply here.
                       In all cases, for a `folder` resource, the composed URI acts
                       as the root path, such that other files located within SHOULD
                       be accessible by appending their relative path to that URI.
@@ -689,8 +685,7 @@ components:
                   sharedSecret:
                     type: string
                     description: >
-                      An optional secret to be used to access the remote web
-                      app, such as
+                      An optional secret to be used to access the remote web app, such as
                       a bearer token. To prevent leaking it in logs it MUST NOT appear
                       in any URI. If a `code` is provided, then the sending host MUST
                       accept the short-lived bearer token when serving the web app,
@@ -704,8 +699,7 @@ components:
                   sharedSecret:
                     type: string
                     description: >
-                      An optional secret to be used to access the resource, such
-                      as
+                      An optional secret to be used to access the resource, such as
                       a bearer token. If a `code` is provided, it SHOULD be used
                       instead via the code flow interaction, and the `sharedSecret`
                       SHOULD be omitted. To prevent leaking it in logs it MUST NOT
@@ -713,13 +707,11 @@ components:
                   srcUri:
                     type: string
                     description: >
-                      An URI to access the resource at the sending server. The
-                      URI
+                      An URI to access the resource at the sending server. The URI
                       SHOULD be relative, such as a key or a UUID, in which case the
                       prefix exposed by the `/.well-known/ocm` endpoint SHOULD be used
-                      to access the resource, or it MAY be absolute, including
-                      a hostname. The latter is NOT recommended because of security
-                      concerns.
+                      to access the resource, or it MAY be absolute, including a
+                      hostname. Similar considerations as for the `webdav` case apply.
                   size:
                     type: integer
                     description: >


Reviews:
user: login: michielbdejong
body: I don't think I understand what the problem is. The way I understand the flow is:

* einstein@server1.com shares "files/bla.txt" with marie@server2.com
* server1.com does a lookup of server2.com/.well-known/ocm
* the Share Creation Notification is POSTed. This may go through proxies, doesn't matter. The important part here is part after the `@` symbol in the `sender` field, so in [our API docs example](https://cs3org.github.io/OCM-API/docs.html?branch=v1.2.0&repo=OCM-API&user=cs3org#/paths/~1shares/post) that would be `apiwise.nl` instead of server1.com.
* server2.com retrieves server1.com/.well-known/ocm
* checks whether it thinks this spam or not. It can do so for instance by checking the request headers against the pubkey announced there, or by checking whether the share is actually accessible at the announced WebDAV API of server1 (see next step).
* it uses the base path from [`resourceTypes[0].protocols.webdav`](https://cs3org.github.io/OCM-API/docs.html?branch=v1.2.0&repo=OCM-API&user=cs3org#/paths/https:~1~1%3Cdiscovery-fqdn%3E~1.well-known~1ocm/get) to find the webdav base URL, in our API docs example that would be `/remote/dav/ocm/` but this can also be an absolute URL at https://storage.server1.com or https://proxy.sever1.com or similar.
* It adds the relative path of the share to the WebDAV base URL to get (in this example) https://apiwise.nl/remote/dav/ocm/files/bla.txt as the WebDAV URL.

Which part of this is made impossible by the use of (reverse) proxies?
state: CHANGES_REQUESTED
author_association: CONTRIBUTOR
submitted_at: 2025-03-03T12:09:30Z
user: login: glpatcern
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-03-05T12:00:49Z
user: login: michielbdejong
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-03-06T12:47:45Z
user: login: glpatcern
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-03-06T13:50:56Z
user: login: michielbdejong
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-03-13T14:37:48Z
user: login: michielbdejong
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-03-13T14:40:35Z
user: login: michielbdejong
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-03-13T14:41:00Z
user: login: michielbdejong
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-03-13T14:41:14Z
user: login: michielbdejong
body: see inline comments
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-03-13T14:42:04Z
user: login: glpatcern
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-03-13T14:47:24Z
user: login: glpatcern
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-03-13T14:47:49Z
user: login: glpatcern
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-03-13T14:49:03Z
user: login: mickenordin
body: LGTM
state: APPROVED
author_association: MEMBER
submitted_at: 2025-03-13T14:52:29Z
user: login: michielbdejong
state: APPROVED
author_association: CONTRIBUTOR
submitted_at: 2025-03-13T14:53:13Z

Review comments:
diff_hunk: @@ -73,7 +73,7 @@ We define the following concepts (with some non-normative references to related
 * __Discovering Server__ - a server that tries to obtain information in OCM API discovery
 * __Discoverable Server__ - a server that tries to supply information in OCM API discovery
 * __OCM Address__ - a string of the form `<Receiving Party's identifier>@<fqdn>` which can be used to uniquely identify a user or group "at" an OCM Server. `<Receiving Party's identifier>` is an opaque string,
-unique at the server. `<fqdn>` is the Fully Qualified Domain Name by which the server is identified. This can, but doesn't need to be, the domain at which the OCM API of that server is hosted.
+unique at the server. `<fqdn>` is the Fully Qualified Domain Name by which the server is identified. This MUST be the domain at which the OCM API of that server is hosted.
path: IETF-RFC.md
user: login: glpatcern
body: Reviewing myself, I believe this is the only significant change, all the rest being a matter of better phrasing and realigning of the IETF text to the spec.

I believe we have to force a `MUST` here, otherwise my argument of un-deprecating full URIs in share payloads remains valid. Otherwise, if a share payload does not contain a usable owner, and the URI is relative, how can a receiver contact the sender, assuming that its remote address may not be valid?
created_at: 2025-03-05T12:00:48Z
author_association: MEMBER
diff_hunk: @@ -73,7 +73,7 @@ We define the following concepts (with some non-normative references to related
 * __Discovering Server__ - a server that tries to obtain information in OCM API discovery
 * __Discoverable Server__ - a server that tries to supply information in OCM API discovery
 * __OCM Address__ - a string of the form `<Receiving Party's identifier>@<fqdn>` which can be used to uniquely identify a user or group "at" an OCM Server. `<Receiving Party's identifier>` is an opaque string,
-unique at the server. `<fqdn>` is the Fully Qualified Domain Name by which the server is identified. This can, but doesn't need to be, the domain at which the OCM API of that server is hosted.
+unique at the server. `<fqdn>` is the Fully Qualified Domain Name by which the server is identified. This MUST be the domain at which the OCM API of that server is hosted.
path: IETF-RFC.md
user: login: michielbdejong
body: I think this "doesn't have to be" phrase refers to the fact we are allowing the OCM API  (i.e. where `POST ./shares` and other endpoints live) as advertised in `/.well-known/ocm` to be on a different server than `/.well-known/ocm` itself, right?
created_at: 2025-03-06T12:47:45Z
author_association: CONTRIBUTOR
diff_hunk: @@ -73,7 +73,7 @@ We define the following concepts (with some non-normative references to related
 * __Discovering Server__ - a server that tries to obtain information in OCM API discovery
 * __Discoverable Server__ - a server that tries to supply information in OCM API discovery
 * __OCM Address__ - a string of the form `<Receiving Party's identifier>@<fqdn>` which can be used to uniquely identify a user or group "at" an OCM Server. `<Receiving Party's identifier>` is an opaque string,
-unique at the server. `<fqdn>` is the Fully Qualified Domain Name by which the server is identified. This can, but doesn't need to be, the domain at which the OCM API of that server is hosted.
+unique at the server. `<fqdn>` is the Fully Qualified Domain Name by which the server is identified. This MUST be the domain at which the OCM API of that server is hosted.
path: IETF-RFC.md
user: login: glpatcern
body: Ah, my interpretation was that the `/.well-known/ocm` must be on the same server as the owner's (or recipient's) OCM address that is sent by a `POST ./shares`
created_at: 2025-03-06T13:50:56Z
author_association: MEMBER
diff_hunk: @@ -73,7 +73,7 @@ We define the following concepts (with some non-normative references to related
 * __Discovering Server__ - a server that tries to obtain information in OCM API discovery
 * __Discoverable Server__ - a server that tries to supply information in OCM API discovery
 * __OCM Address__ - a string of the form `<Receiving Party's identifier>@<fqdn>` which can be used to uniquely identify a user or group "at" an OCM Server. `<Receiving Party's identifier>` is an opaque string,
-unique at the server. `<fqdn>` is the Fully Qualified Domain Name by which the server is identified. This can, but doesn't need to be, the domain at which the OCM API of that server is hosted.
+unique at the server. `<fqdn>` is the Fully Qualified Domain Name by which the server is identified. This MUST be the domain at which the OCM API of that server is hosted.
path: IETF-RFC.md
user: login: michielbdejong
body: ```suggestion
unique at the server. `<fqdn>` is the Fully Qualified Domain Name by which the server is identified. This MUST be the domain at which the `/.well-known/ocm` endpoint of that server is hosted.
```
created_at: 2025-03-13T14:37:47Z
author_association: CONTRIBUTOR
diff_hunk: @@ -492,7 +489,7 @@ They could give the Receiving Party the option to accept or reject the Share, or
 
 # Resource Access
 To access the Resource, the Receiving Server MAY use multiple ways, depending on the body of the Share Creation Notification. The procedure is as follows:
-1. A root path `<sender-ocm-path>` MUST be obtained by querying the [Discovery](#ocm-api-discovery) endpoint at the Sending Server and getting `resourceTypes[0].protocols.webdav`.
+1. The receiver MUST extract the OCM Server FQDN from the `owner` field of the received share, and MUST query the [Discovery](#ocm-api-discovery) endpoint at that address: the `resourceTypes[0].protocols.webdav` value is the `<sender-ocm-path>` to be used in step 3.
path: IETF-RFC.md
user: login: michielbdejong
body: `sender`, not `owner`, right?
```suggestion
1. The receiver MUST extract the OCM Server FQDN from the `sender` field of the received share, and MUST query the [Discovery](#ocm-api-discovery) endpoint at that address: the `resourceTypes[0].protocols.webdav` value is the `<sender-ocm-path>` to be used in step 3.
```
created_at: 2025-03-13T14:40:35Z
author_association: CONTRIBUTOR
diff_hunk: @@ -394,6 +394,10 @@ If `multi` is given, one or more protocol
                 only support `webdav`.
 
    * Protocol details for `webdav` MAY contain:
+     * REQUIRED uri (string)
path: IETF-RFC.md
user: login: michielbdejong
body: why is this one moving from optional to required, was that discussed?
created_at: 2025-03-13T14:41:00Z
author_association: CONTRIBUTOR
diff_hunk: @@ -410,19 +414,12 @@ If `multi` is given, one or more protocol
                       - `use-code` requires the consumer to exchange the given `code` via a
                         signed HTTPS request. This MAY be used if the recipient provider exposes
                         the `receive-code` capability.
-     * OPTIONAL uri (string)
-                    An URI to access the remote resource. The URI MAY be relative,
-                    in which case the prefix exposed by the `/ocm-provider` endpoint MUST
-                    be used, or it may be absolute (recommended). Additionally, the URI
-                    MAY include a secret hash in the path, in which case there MAY be
-                    no associated `sharedSecret`.
    * Protocol details for `webapp` MAY contain:
-     * REQUIRED uriTemplate (string)
-                    A templated URI to a client-browsable view of the shared resource,
-                    such that users may use the web applications available at the site.
-                    The URI MAY include a secret hash in the path. If the path includes
-                    a `{relative-path-to-shared-resource}` placeholder, implementations
-                    MAY replace it with the actual path to ease user interaction.
+     * REQUIRED uri (string)
path: IETF-RFC.md
user: login: michielbdejong
body: is this a breaking change?
created_at: 2025-03-13T14:41:14Z
author_association: CONTRIBUTOR
diff_hunk: @@ -394,6 +394,10 @@ If `multi` is given, one or more protocol
                 only support `webdav`.
 
    * Protocol details for `webdav` MAY contain:
+     * REQUIRED uri (string)
path: IETF-RFC.md
user: login: glpatcern
body: In fact it has always been required (in spec.yaml), the IETF text was actually incorrect
created_at: 2025-03-13T14:47:24Z
author_association: MEMBER
diff_hunk: @@ -410,19 +414,12 @@ If `multi` is given, one or more protocol
                       - `use-code` requires the consumer to exchange the given `code` via a
                         signed HTTPS request. This MAY be used if the recipient provider exposes
                         the `receive-code` capability.
-     * OPTIONAL uri (string)
-                    An URI to access the remote resource. The URI MAY be relative,
-                    in which case the prefix exposed by the `/ocm-provider` endpoint MUST
-                    be used, or it may be absolute (recommended). Additionally, the URI
-                    MAY include a secret hash in the path, in which case there MAY be
-                    no associated `sharedSecret`.
    * Protocol details for `webapp` MAY contain:
-     * REQUIRED uriTemplate (string)
-                    A templated URI to a client-browsable view of the shared resource,
-                    such that users may use the web applications available at the site.
-                    The URI MAY include a secret hash in the path. If the path includes
-                    a `{relative-path-to-shared-resource}` placeholder, implementations
-                    MAY replace it with the actual path to ease user interaction.
+     * REQUIRED uri (string)
path: IETF-RFC.md
user: login: glpatcern
body: (see previous comment, it's not a change)
created_at: 2025-03-13T14:47:49Z
author_association: MEMBER
diff_hunk: @@ -224,17 +224,17 @@ At the start of the process, the Discovering Server has either an OCM Address, o
 
 Step 1: In case it has an OCM Address, it should first extract `<fqdn>` from it (the part after the `@` sign).
path: IETF-RFC.md
user: login: glpatcern
body: ```suggestion
Step 1: In case it has an OCM Address, it should first extract `<fqdn>` from it (the part after the last `@` sign).
```
created_at: 2025-03-13T14:49:02Z
author_association: MEMBER

PR comments:
user: login: mickenordin
created_at: 2025-03-03T11:53:08Z
body: I think I am missing something.  Why is it not possible to use the endpoint designated in the discovery endpoint when using a reverse proxy?

Is it not the job of the reverse proxy to proxy the request to the correct backend server? It is not intended that the communication bypass the reverse proxy and go directly to the backend, right?
author_association: MEMBER
user: login: glpatcern
created_at: 2025-03-04T13:57:42Z
body: OK, now I understand what you (both) meant: the key is all in `The important part here is part after the @ symbol in the sender field`. So effectively the spec says to use an information that is part of the payload, not in the request header / remote address (which cannot be trusted, that was the whole point).

I must say that I have missed that, I'll try and spell it out explicitly in the [discovery section](https://github.com/cs3org/OCM-API/blob/develop/IETF-RFC.md#resource-access) even if it's explained in the Invite flow section.

At this point, no need to "un-deprecate" the full URL in the payload, on the basis that the payload MUST contain the server in the `owner` field. I will amend this PR to just leave the other corrections.
author_association: MEMBER